Windows에서 전체화면(Fullscreen) 최적화의 이해 on Microsoft Blog

원본

DirectX Dev Blog: Demystifying Fullscreen Optimizations

요약: 전체화면 모드(FullScreen Mode) vs 창 모드(Windowed Mode)

  • Windows 10 출시와 함께 전체화면 전용 게임을 전체 화면을 차지하는 고도로 최적화된 전체 창 모드(Borderless) 형식으로 실행하는 전체화면 최적화가 추가되었음
  • 이 최적화로 전체 창 모드로 프로그램(게임)을 실행해도 시각 경험과 성능이 전체화면 모드와 거의 동일하게 개선되었음
  • 다만 전체화면 모드와 창 모드의 이점을 갖는 대신 진짜 전체화면 모드와 비교했을 때 성능 부하가 있기에 완전히 성능이 동일하다고 볼 수는 없음
    • (참고) 전체화면 모드 + 다른 프로그램의 오버레이 케이스에서는 전체화면 모드에서도 성능 저하가 있을 수 있음
  • 전체화면 최적화 기능을 끄고 싶다면 (전체화면, Fullscreen Exclusive) 아래처럼 설정
    • 프로그램 파일(.exe 파일) 오른쪽 클릭 > 속성(Properties) 선택
    • 호환성(Compatibility) 탭 선택
    • 전체 화면 최적화 사용 중지 선택 > 적용

마무리

원본 글을 보시면 알 수 있지만 저희가 게임에서 전체화면 모드라고 생각했지만 실제로 OS단에서 전체 창 모드로 보여주고 있을 가능성이 있네요.
실제 게임에서 전체화면 모드를 지원하더라도 OS에서 최적화를 통해 창모드로 실행되고 있을 수 있겠습니다. 😂
최근 게임 성능 테스트하면서 전체화면 모드 vs 전체 창 모드를 테스트해보았었는데 FPS가 비슷했어서 의아했는데 이제 알게되었습니다.
이 최적화는 Windows 10 특정 업데이트부터 적용된 것 같긴하네요. (2019년 글이니 그 전에 반영되었다고 볼 수 있겠습니다.)

NDC 발표 리뷰: NDC2019 5년차 모바일 게임 생존기

NDC 영상

NDC: 〈크루세이더 퀘스트〉 5년차 모바일 게임 생존기
Video: https://www.youtube.com/watch?v=Pi3LBWu-4Es

세션 설명:
게임이 생존하려면 무엇이 필요할까요? 게임의 생존에 도움이 되는 방법은 없을까요?
본 세션에선 이 질문에 대해 답을 시도합니다. 그리고, 이러한 답이 모바일게임 〈크루세이더 퀘스트〉의 개발 및 서비스 과정에 적용된 사례를 공유합니다.
오래된 개발 환경의 개선, 유저분들의 실망을 만회해야하는 상황, 개발 프로세스의 문제 등 다양한 이슈와 마주한 분들께 조금이라도 도움이 되는 내용이길 희망합니다.

리뷰

23년에 19년 발표 자료를 보고 리뷰하는게 뭔가 싶을 수 있지만.. 😁
라이브 서비스하는 조직의 이야기는 굉장히 귀하기에 지난번에 보고 리뷰를 남겨보고 싶었습니다

강연에서 이야기한 내용의 요약

무려 40분짜리 발표여서 요약을 한번 쓱 해보겠습니다.
아래 참고기사에서 잘 요약해준 내용도 있으니 참고해보면 좋을 것 같네요.

강연 노트

강연 목표: “더 다양한 게임이 오래도록 생존하여 서로 의사결정의 길잡이가 되어주면 좋겠다!”

  • 게임의 생존 조건, 생존 사례, 생존 전략을 다뤄봅니다
  • 넓은 범위의 생존 = 유저가 게임을 플레이할 수 있음
  • 좁은 범위의 생존 = 지속 가능성을 기준으로 손익분기점(break-even point, BEP)을 넘겨야 생존한 게임

생존 조건 = 이용자, 개발팀, 수익

  • 이용자: 유입은 어렵고, 이탈은 쉽게 이뤄짐 / 개발팀: 프로젝트 매력도 등등.. / 수익: BM 설계 등등..
  • 게임 특징: 2019년 당시 5년차 모바일 게임. 글로벌 서비스 (23년 기준 9년차..)
  • 이용자 이탈 🔥
    • 1개월 없데이트, 업데이트한 내용 불만족, 부족한 이벤트, 반복되는 연장점검과 긴급점검, 앱 용량, 게임 정보 취득 어려움, 버그
      • Action: 장기 서비스 유지를 위해 이용자 이탈 개선을 우선순위로 개발 목표 설정
      • Result: 이탈 위험이 높은 유저 지표가 개선되었음
    • 대규모 업데이트 후 이용자 수 지속적으로 하락
      • 게임 피로도 상승, 콘텐츠에 대한 피로도가 높은 상태였음
      • Action: 이용자 수 하락 원인 개선 - 편의성 업데이트, 보상 개선
      • Result: DAU 하락세 방어
  • 개발팀 HP 경고(피로도 누적) 🔥
    • 개발팀 추가 근무량이 많아 피로 스트레스가 많았음. 실제 업무 시간 파악도 어려웠음
    • 개발 계획 변동, 일정 부족, 계약으로 인해 고정된 출시 목표, 밤샘 테스트, 서버 불안정
    • Action: 개발환경 개선 → Unity 4 → 5 업그레이드
      • 서버 최적화를 최우선 순위로 개발 일정 조정
      • 근본적인 버그 대응을 위해 엔진 버전 업데이트
    • Action: 추가근무 시간 기록, 개발 프로세스 개선 - 병목 지점 파악 후 우선순위로 개선
      • 개발 진행상황을 누구나 쉽게 알 수 있도록 시각화
      • Result: 추가 근무 시간 62% 감소. 콘텐츠 업데이트도 안정적으로 진행
  • 수익화 - 구매자 수(PU, Pay User) 감소세 🔥
    • 게임에 대한 애정 감소, 구매 동기 저하, 상품 매력 감소 등
    • Action: 좋은 보상(애정을 회복할 수 있도록 이벤트), 콜라보, 상점 UX 개선 등

생존 전략 = 포지셔닝, 병목 현상 제거, 끝맺기

  • 포지셔닝 - 어떤 게임으로 인식되고 싶은지 명확하게 정의. 우선순위를 설정하기 위해서
  • 병목 제거 - 리소스를 효과적으로 사용하기 위해서. 포스트잇 활용해서 시각화하고 개선해봄
  • 끝맺기 - 체크리스트를 정리하고 마지막까지 확인해야함. 회의 마지막에 리캡하고 공유함
  • 실무에 도입할때는 팀이 받아들일 준비가 되었을 때 실무에 적용하자
  • 모바일 게임의 생존률(좁은 범위 생존)은 40% 정도
  • 의사결정이 큰 영향을 주고 있으니 생존 조건의 적신호에서 잘 대응해나가야 한다

리뷰 소감

현재 라이브 중인 게임의 프로덕션 과정, 이슈 관리 등을 이야기하는 것이 쉽지 않았을텐데 이런 이야기를 들을 수 있게되어서 좋았던 것 같습니다.
생각해보면 다른 소프트웨어 개발도 다 마찬가지이지만 게임 개발에 있어서 많은 난관이 있는데 어떤 기준으로 해결해나갔는지 알 수 있어서 좋았습니다.

역시 서비스에서는 이탈 개선이 반드시 이뤄져야하고 개발팀의 리텐션도 중요하고 돈도 잘 벌어야하고 쉽지 않네요 😇

인풋랙(Input Lag)? 그게 뭔데?

인풋랙(Input lag)?

참고 이미지: BenQ 인풋랙

https://en.wikipedia.org/wiki/Input_lag

인풋랙은 말 그대로 인풋(마우스, 키보드 등) → 연산장치(컴퓨터) → 디스플레이(모니터)까지 사용자의 인풋에 따른 디스플레이까지의 지연을 의미합니다.
인풋랙이라고 부르긴하지만 시스템 지연 시간으로 볼 수 있어요.

이번 포스트에서는 게임에서 주로 느끼는 인풋랙에 대해서만 다뤄보겠습니다.
(주로 인풋랙에 민감하게 반응하는 영역이 게임이기 때문에)

중간에 인풋랙을 찾다가 디스플레이 랙(Display Lag)으로 잘못 빠졌었는데 Latency(지연 시간, 응답 속도) 측면에서 완전히 분리할 수는 없지만 인풋랙과는 다른 영역이었네요.
디스플레이 랙 = 디스플레이 장치(예: 모니터, TV)에서 입력 신호를 받아 처리하여 화면에 표시되는 시간
참고: https://en.wikipedia.org/wiki/Display_lag

인풋랙 깊게 살펴보기

엔비디아에서 좋은 글, 좋은 영상이 있어서 들고왔습니다.
(엔비디아 Reflex에 대한 소개가 있긴하지만요 😅)

게임에서 인풋랙은 많은 요소들이 영향을 준다고 볼 수 있습니다. 적당히 풀어서 정리해볼게요.

  • 주변기기 지연 - 인풋 기기의 폴링 레이트(Polling Rate)에 맞춰 컴퓨터에서 신호 처리가 되는데 그 처리에서 지연 시간이 있습니다. (USB 신호 처리, CPU 처리 등)
  • PC 지연 - 입력을 받고 PC에서 처리되는 동안 발생하는 지연
    • CPU - 게임 내에서 일어나는 애니메이션, 물리 엔진 연산 등에 사용되는 시간
    • Render Queue - CPU 연산 뒤 렌더링을 위해 렌더링 명령들을 Queue에 적재하고 대기하는 시간
    • GPU - Render Queue에 있는 명령들을 렌더링하는 시간
  • 디스플레이 지연 - PC로 부터 받은 신호들을 보이도록 처리하는 시간

우리가 게임에서 말하는 인풋랙은 이렇게 크게 3가지 지연 시간을 합해서 계산해볼 수 있습니다.
물론 네트워크를 이용한 멀티플레이 게임의 경우, 네트워크 레이턴시도 포함해서 봐야하지만 그건 PC 지연에 포함한다고 가정하고 넘어가겠습니다

게임과 인풋랙

주로 인풋랙에 영향을 많이 받는 게임은 FPS(Shooter), 격투 게임, 리듬 게임이 작은 지연에도 큰 영향을 받는 게임 장르로 볼 수 있습니다.

  • FPS, Shooter: 인풋랙에 따라 상대방을 조준, 사격하는데에 있어서 인풋랙의 영향을 받습니다.
    • 추가로 네트워크 레이턴시도 추가되어 흔히 이야기하는 핑(ping) 차이가 발생하기도 합니다
    • 핑이 높으면 피커스 어드벤티지(Peeker’s advantage) 현상이 더 크게 발생할 수 있습니다
  • 격투 게임: 인풋랙에 따라 콤보를 넣을 수 있느냐, 상대의 공격을 인식해서 방어, 회피할 수 있냐가 달라지기에 크게 영향을 받는다고 볼 수 있습니다.
    • 한 사례로 콘솔 기기와 PC 설정 환경 차이로 인해 인풋렉의 차이가 발생해서 PC로 대회를 열 수 밖에 없었다는 사례도 있었네요. (스트리트파이터5 참고 사례, 참고 사례 링크2)
  • 리듬 게임: 인풋랙에 따라 노트를 정확하게 맞출 수 있냐 없냐가 달라지니 크게 영향을 받는다고 볼 수 있습니다.
    • 게임이 얼마나 세세하게 판정하냐에 따라 영향도는 달라질 수는 있지만 게임 자체 이슈, 모니터, 컨트롤러의 지연 요소에 따라 인풋랙이 크게 발생할 수 있습니다

인풋랙 측정 방법

퀘이사존: 모니터 인풋랙은 무엇이고, 어떻게 측정할까? https://quasarzone.com/bbs/qn_report/views/113059

상세한 내용은 퀘이사존에서 자세히 설명해주고 있어서 위 글을 참고해보시면 좋을 것 같습니다.

요약해보면 마우스 입력 → 화면 반응까지 시간을 LDAT(Latency Display Analysis Tool)이라는 장치를 이용해서 측정합니다.
LDAT이 없을때는 화면 반응을 카메라를 이용해서 촬영, 측정했다고 하네요. 🤩

인풋랙 개선 방법

엔비디아 글에서 여러가지 인풋랙 개선 방법들이 있어 간단히 남겨보겠습니다.

https://www.nvidia.com/en-us/geforce/guides/system-latency-optimization-guide/

  1. Turn on NVIDIA Reflex (게임 설정): 게임에서 Reflex 기능 On
  2. Turn on Ultra Low Latency Mode (엔비디아 설정): Low Latency를 Ultra로 설정
  3. Turn on Exclusive Fullscreen (게임 설정): 게임에서 “전체화면” 설정
  4. Turn off VSYNC (엔비디아 설정): Vsync 기능 off
  5. Turn on “Game Mode” in Windows(OS 설정)
  6. 설정 > 게임 > 게임 모드 >게임모드 On 설정
  7. Overclocking (PC 하드웨어 설정): CPU, GPU, Ram 오버클럭
  8. Consider Faster Hardware: 하드웨어 업그레이드 😂
  9. Reduce settings (게임 설정):
  10. 하위 옵션으로 반응성을 올려라
  11. Enable your maximum refresh rate: 디스플레이의 주사율을 최대로 설정
  12. Turn on G-SYNC Esports mode (엔비디아 설정)
  13. Turn on some overdrive: 모니터에서 오버드라이드 모드 설정

마무리

요렇게 인풋랙에 대해서 짧게 알아보았는데요. 정리해보고나니 일상적으로 게임에서 이야기하는 인풋랙은 시스템 레이턴시(시스템 지연 시간) 정도로 볼 수 있을 것 같습니다.

인풋랙은 워낙 많은 요소들이 영향을 주는 것이다 보니 하나만으로는 개선이 어렵고 이것저것 다 최적화해야하는 느낌이네요.

개인의 입장에서는 하드웨어 업그레이드, 게임 설정으로 개선할 수 있고
게임 입장에서는 게임 최적화, 하드웨어 기능 호환 등을 지원하는 것이 개선 방법이 될 수 있겠습니다.

참고

Product Plan vs Release Plan 글을 보고

원문

https://www.aha.io/blog/the-product-plan-vs-the-release-plan

Product Plan vs Release Plan?

제목을 번역해보면 “제품 계획 vs 출시 계획”으로 볼 수 있겠네요
처음에 이 글을 봤을 때, 두 계획이 다른 것은 이미 알고 있는데 어떻게 다른가에 대해 깊게 고민한적은 없었던 것 같습니다.

위 글에서 두 계획에 대해 정의한 것이 인상깊어 공부 겸 글 내용을 정리해보았습니다.

제품 계획은 제품의 전략적 방향을 정의하는 반면 출시 계획은 비전을 달성하는 데 필요한 작업을 정의합니다.”

두 계획 모두 중요하지만 다른 것을 정의하고 있습니다.
제품 계획은 왜(Why) 이것을 만들고 있는지, 우리는 무엇(What) 을 성취하려고 하는지 답을 줍니다.
출시 계획은 정확히 무엇(What) 을 빌드해야하는지, 언제(When) 만들 것인지, 제품 경험을 어떻게(How) 제공할 것인지를 정의합니다.

6하 원칙으로 정리하는게 깔끔하긴 하네요.
제품 계획에는 왜 라는 프로덕트 목표 설정이 중요한 것 같고
출시 계획에는 언제 어떻게 무엇을 전달 또는 배포할 수 있을지 정의하는 것이 중요하겠네요.
Who, Where은 때에 따라 제품 계획에 들어갈 수 있을 것 같습니다. 😁

목표(Goal) 관점

제품 계획 목표: 제품의 방향성을 전달하는 것. 전략 및 비즈니스 목표를 기반으로 제품이 비즈니스 가치를 제공하는 방법을 보여줍니다.

출시 계획 목표: 제품 팀이 수행할 작업에 대해 책임을 지도록 하는 것. 작업의 세부 사항을 분명히 하고 완료해야하는 작업 단계를 강조합니다.

목표 관점에서 각 계획이 가지는 목표는 성격이 다른 것은 누구나 알 수 있겠지만 저는 상위 방향성 vs 상위 방향성이 동작하게 하는 워크플로우, 프로세스 등의 집합체 정도로 이해했습니다.
여기서 제 PM 업무를 떠올려보면 2가지 계획에 모두 기여를 해야하지만 출시 계획을 잡고 개발팀과 헉헉하느라 제품 계획에는 신경쓰지 못하는 것 같습니다. 😥

끝이 없네 끝이 없어..

매 주기마다 개발부서들과 개발한 콘텐츠 업데이트와 라이브 이슈 대응의 연속..

이니셔티브(initiative) 관점

제품 계획: 향후 6개월에서 1년 동안 주요 테마, 초점 영역 및 기능을 나타내는 이니셔티브를 제시합니다.

출시 계획 : 전략적 이니셔티브가 존재한다고 가정하고 팀에 집중하는데 중점을 둡니다.
출시 계획은 일상적인 성공을 위한 명확한 경로를 제시합니다. 출시 계획의 이니셔티브는 동기 부여, 책임에 관한 것입니다.

이 글에서 말하는 이니셔티브 개념은 목표를 달성하기 위한 액션 아이템 또는 액션 아이템들을 묶을 수 있는 계획이라고도 볼 수 있을 것 같습니다.
액션 아이템과 목표를 잘 버무린 계획의 느낌이네요.
OKR에서는 이니셔티브를 Key Result를 달성하기 위한 액션아이템, 어떻게 달성할지에 대한 것으로 정의하고 사용하는 케이스를 볼 수 있었습니다.

사실 사회에서 말하는 “이니셔티브”는 번역으로는 주도권, 주장이 되는 위치에서 이끌거나 지도할 수 있는 권리로 이야기하니 “권한”의 성격을 띄고 있습니다.
기업에서 특정 이니셔티브 그룹에 가입하면서 이야기하는 “이니셔티브”는 계획에 더 가깝습니다. 특정 문제를 해결하기 위한 그룹 정도로 이해할 수 있을 것 같네요.

청중(Audience) 관점

제품 계획: 외부 또는 내부 전략 로드맵으로 시각화할 수 있습니다. 고객을 위해 기대할 수 있는 새로운 기능 또는 개선 사항의 주요 영역을 제시합니다.

츨시 계획: 내부 제품 팀 및 기타 교차 기능 기여자를 위한 것. 향후 작업을 계획하고 해당 작업의 세부 정보를 추적하는 데 도움이 됩니다.

여기서 청중은 이 계획을 듣는 사람들을 의미하는 것 같습니다.
제품 계획은 외부에 공유하는 러프한 로드맵 이런 것으로 바꿔서 사용할 수 있는 것,
출시 계획은 내부 프로덕션 프로세스 문서, 업무 가이드가 될 것 같네요.

타임라인(Timeline) 관점

제품 계획: 장기간에 걸친 전략적 목표와 이니셔티브를 제시합니다. 소프트웨어 회사의 경우 1년이 일반적입니다.
출시 계획: 기능 배포 또는 주요 출시로 이어지는 특정 작업 단계를 추적합니다. 30, 60, 90일 단위인 경우가 많습니다.

제품 계획은 타임라인으로 보면 1년 계획 + 더 큰 차원의 계획도 있을 수 있겠다 싶습니다.
예를 들면, 게임의 핵심 재미를 정의하고 어떻게 그 재미를 더 키울 수 있을까를 계획하거나 다른 맛을 곁들이거나 하는 등의 방향 설정이 있을 것 같아요.

출시 계획은 단순히 생각하면 업데이트 주기를 말할 수 있겠습니다. 그 주기에 맞춰 필요한 일들의 타임라인을 정리하고 프로세스화 한 것을 출시 계획으로 볼 수 있겠죠.

마무리

글 마지막에는 “How do you use product plans and release plans in your work?” 라고 질문을 해주었는데 글을 읽다보니 저는 제품 계획이 잘 이뤄질 수 있도록 출시 계획을 관리하고 있었구나 싶었습니다.

Being responsible for a product plan and a release plan challenges product managers to think about every element of delivering a Complete Product Experience. It is a good way to encourage both big and small thinking.

이런 말을 글 마지막에 크게 달아뒀는데 각 계획을 정의하고 그 정의에 맞춰 일을 정리해나가는 것이 좋은 경험이 되는 것 같습니다.
어떤 게임 개발사는 패키지 형태로 한번에 빡 출시하고, 어떤 개발사는 얼리억세스부터 지속적인 업데이트를 통해 출시하고 여러 방법이 있으니 각자의 계획이 다 다르겠죠

너는 다 계획이 있구나! - 기생충

어쨌든 각자의 계획이 다 있는 것 아니겠습니까 😁

우리는 어떤 계획을 가지고 살고 있는지, 2개의 계획을 분리해서 보자면 어떻게 정의하고 있는지 생각해볼 수 있는 시간이었어서 재미있는 글이었습니다.
다른 재미있는 글들도 있으니 나중에 보고 또 공부 겸 포스트해보겠습니다.

Unreal Lighting 공부 - Coloso '언리얼로 구현하는 게임 라이팅 입문'

Coloso “언리얼로 구현하는 게임 라이팅 입문” 공부

21년 마지막날에 갑자기 22년에는 뭔가 공부해야겠다 싶어서 이것저것 보다가
그동안 관심이 있던 아트 쪽을 공부해볼까 싶어 Coloso 강의를 질러보았습니다
사실 환급 과정이라고 해서 더 강의를 도전해봐야겠다 싶기도했네요

Coloso: 언리얼로 구현하는 게임 라이팅 입문

Coloso와 Class101의 차이는 보니까 강의를 구매하고나면 평생 시청할 수 있다는 점이었는데
지금은 다 수강하고 보니 다시 볼 일이 있을까 싶기도합니다

강의 내용이 부족해서라기보다 입문 강의다보니 숙련되면 따로 더 챙겨볼 일이 없겠다는 생각이 들었어요

Coloso 환급 과정 진행

환급 과정은 블로그 포스트를 1달동안 매일 작성하는 방식으로 진행했습니다
(지금 글쓰고 있는 시점에도 21일차를 완료했네요.)

현재 쓰고 있는 블로그 포스트들: https://blog.naver.com/pineoc
이번에 이 글을 쓰면서 알게된 것은 네이버 블로그는 태그 내용으로 정리된 리스트 링크를 볼 수 없네요

재미로 저랑 같이 공부하는 사람들은 얼마나 있는지 한번 알아보았습니다
블로그 검색: 언리얼로 구현하는 게임 라이팅 입문
이렇게 검색하면 저랑 같이 하시는 분은 한 4분 정도 있네요. 😁

강의 수가 얼마되지 않아서 다들 강의 듣고 원하는 씬을 작업하면서 인증하고 계신 것 같았어요
저는 개인 프로젝트를 진행하면서 인증하고 있습니다 💪💪💪

강의 내용

강의 내용은 처음 언리얼 엔진을 처음 다뤄보는 사람들, 라이팅 입문하는 사람들을 위한 내용입니다
내용 자체는 기본적인 내용으로 강의가 진행되었고 게임 개발과 관련한 내용을 아트 관점에서 정리할 수 있어서 좋았습니다

다만 라이팅과 관련한 내용에 대해 입문으로 시작해볼 수 있지만
숙련 과정까지 끌어올려주는 강의로는 부족하다는 생각이 들었습니다

강의 내용 퀄리티가 부족하기보다 강의 횟수, 강의 내용의 절대적인 양이 부족하다고 느꼈고
입문 후에 라이팅에 더 관심을 가지고 달려갈 사람들에게는 적당한 수준의 내용이지 않을까 싶었습니다

개인 프로젝트 진행

우리집-밤 풍경

환급 과정 인증을 위한 개인 프로젝트는 “우리집 꾸미기”해보고 있습니다
다이나믹 라이팅, 스태틱 라이팅 등을 공부하면서 느낀 것은
아트 작업에 대한 공부는 역시 모델링이나 실제 어떤 것을 만들고 싶은지 고민이 있어야한다는 것이었네요
사실 엔지니어링 관점에서도 뭘 개발하고 싶은지 고민하긴해야하니까요 😊

첫 프로젝트는 집 모델링 프로젝트이고 다음 프로젝트는 회사 사무실 모델링이 목표입니다
집보다 회사 평수가 20배 이상 크니까… 더 오래걸리겠죠
일단 집 프로젝트를 마무리하고 올해 상반기에 회사 사무실 프로젝트를 진행해보려합니다

이러면 사실 라이팅 프로젝트가 아니라 모델링 프로젝트가 아닐까 싶은…

마무리

환급 과정을 하게되어서 환급 과정에 더 많이 집중된 것 같지만 😅
강의 + 환급 과정은 마무리 단계(데일리미션 마지막주 + 최종미션)라서 프로젝트 마무리에 집중하고 있습니다.
강의를 보고 배운 것들을 정리해보면..

  • 게임 개발, 영상 작업의 아트 영역에서 라이팅은 무엇을 고민하는지
  • 아트 영역에서는 라이팅 효과로 어떤 것들을 주로 작업하는지
  • 라이팅 작업에서 필요한 기본 개념들

개인 프로젝트 결과는 완성되면 여기에도 올려보겠습니다. 😁