NDC2019 - 게임플레이 프로그래머의 역할
•
3 likes•2,681 views
NDC2019에서 발표한 내용입니다. 저 개인의 경험에 비추어 좋은 게임플레이 프로그래머가 되기 위해 노력해야 할 점들을 정리해 보았습니다.
NDC2019 - 게임플레이 프로그래머의 역할
- 1. 게임플레이 프로그래머의 역할 넥슨코리아 / 왓 스튜디오 최호영
- 2. 발표자 소개 2009 - 2012 루니아 전기 2012 - 2019 야생의 땅: 듀랑고 NDC 2013 Typescript, javascript의 안정성을 높이기 위한 시도 NDC 2014 가죽 장화를 먹게 해달라니 NDC 2016 <야생의 땅: 듀랑고> 중앙 서버 없는 게임 로직 NDC 2018 NoSQL 위에서 MMORPG 개발하기
- 3. 발표의 목적 • 왓 스튜디오에서의 경험을 바탕으로 • 발표자가 생각하는 게임플레이 프로그래머의 역할 • 좋은 게임플레이 프로그래머가 되기 위한 방법 • 지망생과 커리어 초반의 프로그래머에게 도움이 되었으면
- 4. 게임플레이 프로그래머
- 5. 무슨 일을 하는가? NDC 2014 가죽 장화를 먹게 해달라니 NDC 2016 <야생의 땅: 듀랑고> 중앙 서버 없는 게임 로직 NDC 2018 NoSQL 위에서 MMORPG 개발하기
- 6. 무슨 일을 하는가? • 친구 • 전투 • 부족 전쟁 • 건축물 이력 • 우편 • 상점 • 퀘스트 • 이벤트 • 상태 이상 • 스킬 • 운영툴 • 게임 로그
- 7. 게임플레이 프로그래머 • 유저들의 경험과 맞닿는 모든 것을 프로그래밍 하는 사람 • 깊이 있는 프로그래밍 보다는 • 다양하게 주어지는 의도를 전달 받아 • 빠르고 효율적으로 구현하는 프로그래머
- 8. 어떤 사람이 좋은 게임플레이 프로그래머인가 • 아름다운 코드를 만드는 사람? • 게임을 사랑하는 사람? • 야근을 적극적으로 하는 사람?
- 9. 게임플레이 프로그래머
- 10. 좋은 • 좋은 품질의 코드를 만드는 사람 • 언어의 특징을 파악하고 충분히 활용하는 사람 • 복잡한 시스템을 잘 설계하는 사람 • 다른 사람의 코드를 잘 분석하는 사람 • 다양한 라이브러리를 적절하게 잘 사용하는 사람 프로그래머
- 11. 좋은 • 좋은 품질의 코드를 만드는 사람 • 언어의 특징을 파악하고 충분히 활용하는 사람 • 복잡한 시스템을 잘 설계하는 사람 • 다른 사람의 코드를 잘 분석하는 사람 • 다양한 라이브러리를 적절하게 잘 사용하는 사람 프로그래머게임플레이 가장 어렵기 때문!
- 12. 게임 • 게임은 유저를 즐겁게 해주는 대신 비용을 받는 서비스 • 절제된 재미를 깊게 주려는 게임도 있지만 • 많은 경우 되도록 풍성한 시스템과 다양한 콘텐츠를 제공하고 싶어 한다
- 13. 다양한 콘텐츠 • 오늘 퀘스트 시스템을 개선하고 • 내일 출석부를 만들고 • 모레 전투 시스템의 버그를 잡는다 잦은 Context Switching → 하나의 작업에 집중하기 힘듦
- 14. 복잡하게 연관된 피처들 아이템을 고치면 → 인벤토리 시스템을 고치고 → 장비 시스템을 고치고 → 능력치 시스템을 고치고 → 관련 패킷을 고치고 → ... 넓은 범위의 코드를 동시에 파악하고 있어야 함
- 15. 지속적인 서비스 • 지속적인 업데이트 • 장기간 서비스 • 이전 개발자의 코드를 관리해야 함 완전히 파악하지 못한 코드를 수정해야 함
- 16. 좋은 품질의 코드가 중요한 이유 • 내가 작업했던 시스템을 추가 개선할 땐 누가 하나요? • 내가 작업했던 시스템에서 버그가 생기면 누가 수정하나요?
- 17. 좋은 품질의 코드란? • 작업물의 결과를 가독성이 좋게 유지하는 것 • 작업에 대한 문서화를 충실히 하는 것
- 18. 어떤 점이 어려운 가요? • 작업물의 결과를 가독성이 좋게 유지하는 것 가독성에 대한 판단은 개인이 혼자 내릴 수 없다 바쁘면 적당히 스스로와 타협하게 된다 하루가 멀다 하고 스펙이 바뀌는 게임 개발은 문서 관리가 너무 어렵다 문서를 작성하는 능력은 개인차가 크다 • 작업에 대한 문서화를 충실히 하는 것
- 19. Code review (sometimes referred to as peer review) is a software quality assurance activity in which one or several humans check a program mainly by viewing and reading parts of its source code, and they do so after implementation or as an interruption of implementation. At least one of the humans must not be the code's author. 코드 리뷰가 답이다
- 20. 코드 리뷰 많이들 하시나요? • 우리 스튜디오의 면접 질문 중엔 코드 리뷰가 언제나 있음 • 하지만 실제 코드 리뷰를 경험한 면접자는 거의 없었음
- 21. 저희의 경우는 • 초기 개발진이 오픈 소스에 관심이 많은 분들 • 오픈 소스 진영은 이미 코드 리뷰가 활성화 된 곳 • 코드 리뷰의 유경험자들 • 서버 개발 언어가 Python • 정적 분석을 통한 오류 검출이 힘든 언어 • 단순 오타 등의 자잘한 실수의 방지는 작업자 스스로 조심하는 것으론 한계가 있음 • 코드 리뷰 경험자들이 필요에 의해서 도입
- 22. 코드 리뷰는 왜 좋은 가요? • 코드 리뷰 얘기는 들어봤는데 뭐가 좋은 지 모르겠어요 • 코드 품질 관리에 어떻게 도움이 되나요?
- 23. 리뷰 그 자체 • 한 명의 눈으로 문제를 찾는 것이 아니라 • 여러 명의 눈으로 문제를 찾는다
- 24. 역지사지 • 리뷰이는 또한 리뷰어기도 하다 • 동료의 코드를 읽다 보면 어떤 부분이 가독성에 해가 되는지 자연스럽게 깨달을 수 있다
- 25. 좋은 코드를 위한 자발적 의지가 생김 • 코드 리뷰가 오래 걸릴 수록 내가 힘들다 • 코드 리뷰를 빨리 통과하기 위해서라도 작업하면서 가독성을 고려하여 작업하게 된다 • 난해할 것 같은 지점을 탐색해보고 주석을 다는 습관이 생긴다
- 26. 일관성 있는 코딩 스타일 • 모두가 서로를 리뷰하기 때문에 자연스럽게 코딩 스타일이 모여짐 • 입사자들이 초반에 팀 스타일에 적응하는 속도가 빨라짐 • 신규 입사자들의 성장 속도가 빨라짐
- 27. 문서화 • 문서화의 목적 • 시스템에 대한 이해도가 낮은 사람이 접근할 수 있게 하는 것 • 어떤 지점을 보고 있을 때 전후 맥락을 파악할 수 있게 하는 것 ✓ 전자는 큰 흐름을 기술하는 문서를 남기면 잘 변하지 않아 오래도록 보관해도 의미가 있다 ✗ 후자의 문서는 수명이 짧고 아무리 자세하게 기술해도 부족하다
- 28. 문서화 • 코드 리뷰는 리뷰이와 리뷰어가 작업에 대해 논의하는 과정 • 리뷰 요청과 코멘트, 그에 따른 응답이나 개선이 모두 기록에 남는다 • 이것 자체가 문서 • 어떠한 지점에서 문제가 생겼건, 의도를 파악하기 힘들 때 • 해당 기록을 찾으면 의도를 파악할 수 있다 blame 기능이 비난의 용도로 쓰이지 않게 됩니다!
- 29. 그래도 코드 리뷰 싫어요 • 개발하기 바쁜데 코드 리뷰 시스템 언제 마련하고 있나요 • 코드 한 줄 고쳤는데 반영되는데 이틀 걸렸어요 • 작업할 시간도 없는데 남이 짠 코드 언제 해독하고 있어요
- 30. 그래도 코드 리뷰 싫어요 • 개발하기 바쁜데 코드 리뷰 시스템 언제 마련하고 있나요 → 리뷰 시스템 구성은 초반에 손이 많이 가긴 합니다. 하지만 GitLab, GitHub, Bitbucket 등 이미 좋은 도구들이 많으니 활용해 보시면 좋을 것 같습니다. → 몇가지 규칙을 지키면 개선될 수 있습니다 • 코드 한 줄 고쳤는데 반영되는데 이틀 걸렸어요 • 작업할 시간도 없는데 남이 짠 코드 언제 해독하고 있어요 저희가 어떻게 하고 있는지 한번 보여 드릴 게요
- 31. 저희 팀은 이런 도구를 사용합니다
- 32. 공용 작업 공간 commit (작업 단위) merge (작업 반영) 개인 작업 공간
- 33. Merge Request • Pull Request 라고도 부름 • 공용 작업 공간에 반영(Merge)되는 작업의 최소 단위 • MR 단위로 코드 리뷰를 진행
- 34. 리뷰이: MR의 생성 * MR 만들 때 실수로 빠지지 않도록 템플릿을 사용
- 35. 리뷰이: MR의 생성
- 36. 리뷰이: MR의 생성 * 설명적인 제목과 명확한 의도를 적어야 한다
- 37. 리뷰이: MR 내용 입력
- 38. 리뷰이: MR 내용 입력 * 이 MR만 봐도 작업의 전후 맥락을 파악할 수 있는 자세한 설명
- 39. 리뷰어: 체크리스트 확인
- 40. 리뷰어: 체크리스트 확인 * 리뷰어가 잊는 부분이 없도록 체크 리스트를 만들어 두면 좋다
- 41. 리뷰어, 리뷰이: 코멘트와 드백
- 42. 리뷰어, 리뷰이: 코멘트와 드백 * 드백이 필요한 라인에 직접 드백 주기
- 43. 리뷰어, 리뷰이: 코멘트와 드백 * 공격적이지 않은 어투를 사용하되 직설적인 의견 제시
- 44. 리뷰어, 리뷰이: 코멘트와 드백 * 제안은 충실히 검토하되 무조건 받아들일 필요는 없다
- 45. MR 머지 리뷰어개발 PM
- 46. MR 머지
- 47. 그래도 코드 리뷰 싫어요 • 코드 한 줄 고쳤는데 반영되는데 이틀 걸렸어요 • 작업할 시간도 없는데 남이 짠 코드 언제 해독하고 있어요 리뷰하기 좋은 MR과 좋은 리뷰로 개선할 수 있습니다
- 48. 리뷰하기 좋은 MR • MR은 최대한 작게 • 클 수록 코드 파악이 어려워 리뷰어가 어렵기 때문에 리뷰가 너무 오래 걸리거나 리뷰가 충실하지 못함 • 리팩토링 할 땐 작업과 삭제를 분리하기 • 큰 작업은 인터페이스와 구현을 분리하기 ✗아이템에 xx 기능 추가 + 겸사 인벤토리 버그 수정 ✗퀘스트 시스템 ✓퀘스트 시스템 중 재발급 기능 구현
- 49. 리뷰하기 좋은 MR • 내용은 최대한 구체적으로 • 리뷰어가 전후 문맥을 파악하기 쉽게 구체적으로 작성 ✗ 채집할 때 다른 아이템이 나오는 문제 수정 ✓ 채집할 때 카테고리 별 데이터 연결이 틀려 잘못된 아이템을 획득하는 문제 수정 • 관련된 다른 MR을 링크 • 미래 언제 봐도 독립적으로 내용을 파악할 수 있게 작성
- 50. 좋은 리뷰 • 드백은 간결하고 건조하게 • 돌려 말하지 않고 직접적으로 드백 할 것 • 미사여구는 요점을 흐리고 리뷰를 방해할 뿐 • 스탠다드와 취향의 구분은 명확하게 • 취향을 드러내면 드백을 주는 것이 나쁜 것은 아니지만 취향에 따른 의견임을 명확히 할 것 • 작은 코멘트(단순 실수 등)는 남기되 미리 Merge를 승인 할 것 • 핑퐁 횟수를 최대한 줄이기 위함
- 51. 조심할 점 • 형식적인 리뷰어 지정이 되지 않도록 조심 • 리뷰 잘 안해주는 사람을 지정하는 경향 • 리뷰 잘 해주는 사람을 지정하는 경향 • 잘 아는 사람 + 잘 모르는 사람 을 지정하는 것을 추천 (최소 2명) • 리뷰어의 집중을 방해하지 말아야 함 • 되도록 리뷰의 재촉은 금지하되 모두의 합의 하에 적당한 리마인드만 • 시급도가 높은 경우에만 별도로 호출 • 내 작업이 반영되는 속도가 늦어 지기 때문에 업무를 투트랙으로 진행하는 것을 추천
- 52. 코드 리뷰 경험이 없다면 • 오픈 소스 프로젝트에 관심을 가져보자 • 직접 기여하는 것이 물론 베스트 • 다른 사람들의 MR/PR을 구경하는 것도 도움이 된다 • 취미 프로젝트에서 사용해 보자 • 물론 2인 이상일 경우에 가능 • 형식적인 것처럼 느껴지고 어색하더라도 한번 해보자 • 페어 프로그래밍도 일종의 코드 리뷰 • 리뷰 시스템 도입이 힘들다면 페어 프로그래밍을 적극적으로 해보자
- 53. 게임플레이 프로그래머
- 54. 콘텐츠 공급 과잉 시대
- 55. 고객들은 기다려 주지 않는다 • 모든 작은 행동들이 이탈율로 이어지는 현실 • 퀄리티 좋은 결과물도 중요하지만 • 기대보다 늦은 출시 • 기대보다 긴 업데이트 주기 • 는 전부 고객 이탈로 이어진다
- 56. 다양한 선택들 • 프로덕션 단계에서 순간적으로 엄청난 푸쉬 • AAA 게임들 • 비용이 많이 들여 빨리 만든다 • 선택과 집중으로 원하는 재미 포인트만 빠르게 뽑아낸다 • 캐주얼 게임, 인디 게임 • 볼륨이나 리소스 퀄리티를 희생해서 비용을 낮추고 빨리 만든다 • 선택과 집중으로 속도를 희생한다 • 내가 취미로 만드는 게임 • 몇 년째 진척이 없다
- 57. 우리가 할 수 있는 것은? • 이런 선택들은 개발 전반에 걸친 결정 • 개인인 프로그래머가 직접 관여할 수 있는 분야는 아니다
- 58. 개발 일정 지키기 • 개발 기간을 당길 순 없지만 • 늦추지 않을 순 있다
- 59. 일정 지키기 • 일정은? • “지키지 않기 위해 존재하는 것“ • “틀어지기 위해 존재하는 것“ • 2N + 하루의 법칙 • 계산할 수 없는 방해요소를 미리 계산하는 것 • 경험적인 공식이지만 의외로 꽤 맞다 • 하지만 어디까지나 반쯤 농담
- 60. 일정을 지키기 힘든 이유 • 외부적 요인 • 작업 방향의 강제적 전환 • 디자인 방향의 변경 • 작업 범위 변경 • 내부적 요인 • 잘못된 방향 설정 • 잘못된 업무량 예측
- 61. 일정을 지키기 힘든 이유 • 외부적 요인 • 작업 방향의 강제적 전환 • 디자인 방향의 변경 • 작업 범위 변경 • 내부적 요인 • 잘못된 방향 설정 • 잘못된 업무량 예측 프로세스의 문제
- 62. 잘못된 방향 설정 • 대부분 프로젝트의 구조에 대한 이해 부족으로 발생 • 경험 부족으로 설계 자체가 잘못되었거나 • 이미 존재하는 바퀴를 재발명 했거나 • 우리 프로젝트에만 있는 특수한 사이드 이펙트를 몰랐거나 • 그냥 미처 생각이 미치지 않은 부분이 있거나 • 등등 • 실력이 부족한 사람이 자꾸 변명하네!
- 63. 실수는 누구나 한다 • 누구나 신입일 때가 있다 • 누구나 내 프로젝트에 모르는 부분이 있을 수 있다 • 인간의 실수는 당연한 것, 다만 줄이려고 노력할 뿐이다
- 64. 실수를 줄이려면? • 내가 실력을 키운다 • 노력을 더 많이 한다 • 여러 사람의 눈을 빌린다 • 코드 리뷰 !?
- 65. 코드 리뷰 • 이미 작업한 다음에 리뷰 받는 것이므로 재작업을 피할 수 없다 • 코드 리뷰 과정에서 큰 문제가 발견되는 것이 • 흔한 작업 딜레이의 사유 • 소 잃고 외양간 고치는 격
- 66. 기술 명세서 리뷰 도입 • 디자인 문서를 전달 받은 작업자가 명세서를 작성 • 명세서를 동료 프로그래머에게 리뷰 받고 • 리뷰가 통과하면 작업을 시작
- 67. PROGRAMMER = 인간의 언어보다 기계의 언어를 잘 쓰는 사람 (저만 그런 가요)
- 68. 기술 명세서 • 테크니컬 라이팅(Technical Writing) 능력이 부족한 프로그래머가 많음 • 쏟아지는 작업마다 일일이 문서를 쓰기엔 시간이 부족 • 리뷰 도구의 부재 • 문서 보관소에 문서처럼 작성하고 리뷰 → 리뷰용 도구가 없어서 리뷰가 불편 • 문서를 Git에 보관하고 코드 처럼 리뷰하는 것도 고려 • 어차피 위 문제가 해결이 안되기 때문에 실제로 해보지는 않음 • 결국 대규모 피처일 경우 문서화를 위해 쓰는 정도로 타협 → 원래 의도했던 기능은 수행하지 못하게 됨
- 69. 현실적인 대안 • 글쓰기가 힘들다면 대화로 해결하자 • 정기적으로 짧은 미팅을 가지기 • 내가 앞으로 할 일에 대해 설명하고 드백을 받기 • 스크럼 회의처럼 최대한 간결하게 설명 • 디테일을 이야기 하지 않는다 • 작업 방향에 쟁점이 생긴다면 회의 이후에 관련자들끼리 따로 논의 • 작업 비용에 대한 드백을 받는 부가 효과 • 일정 예측이 정확해 진다 • 플래닝 포커 등 다양한 방법을 시도 중
- 70. 중요한 점 • 내 작업을 동료가 알게 하라 • 간결하게 핵심만 • 동료에게 인터럽트 없이 알려줄 방법을 찾아라 • 드백은 공격이 아니다 • 내 생각은 완벽하지 않으니 언제나 조언을 받으라 • 결국 사람 간의 문제 감정이 상하지 않게 언제나 조심하되 비효율이 줄어들게 미사여구를 줄이라
- 71. 호프스태터의 법칙: 그 일은 항상 당신이 예상한 것보다 더 오래 걸린다, 비록 호프스태터의 법칙을 고려했다고 해도 말이다.
- 72. 물론 일정 예측 실패의 가능성은 언제나 있다 • 모든 사람이 실패는 한다 • 실패했을 때 중요한 것은 틀어지고 있는 일정을 숨기지 않는 것 • 숨긴 일정 지연이 더 큰 일정 지연이 되어 돌아온다
- 73. 게임플레이 프로그래머
- 76. 원활한 소통 능력? • 시키는 거 잘 알아 듣는 사람? • 재치 있는 표현을 섞어서 즐겁게 소통하는 사람? • 인-싸?
- 77. 게임플레이 프로그래밍 • 게임 디자이너에게 의뢰를 받아서 • 실제로 결과물을 낸다 • 드백을 받고 수정 작업
- 78. 게임 디자이너의 역할 • 게임 디자이너 • 어떻게 하면 재밌을까? • 어떻게 하면 유저가 오래 게임을 즐길까? • 어떻게 하면 유저가 상품을 구입하고 싶을까? • 유저의 입장에서 게임을 설계한다
- 79. 디자이너와 프로그래머의 관계 • 게임플레이를 함께 만드는 둘 • 하지만 보는 관점이 다르다 • 애증의 관계
- 80. 흔히 생기는 불만 • 우리 게임에서 구현이 어려운 게임플레이를 요청 • 큰 규모의 작업을 짧은 일정에 해달라고 요청 • 완성도가 떨어지는 디자인 문서 • 주로 예외 상황과 코너 케이스 고려가 안됨
- 81. 게임 디자이너가 알기 힘든 것 • 구현의 규모와 한계 • 프로그래머가 아니기 때문에 결국 이해하기가 힘듦 • 예외 상황과 코너 케이스 인지가 힘든 것도 이 때문 • 경력이 긴 디자이너도 경험적으로 짐작할 뿐 • 게다가 사실 프로그래머도 일단 구현에 들어가 봐야 아는 경우도 있는데 디자이너가 알 수 있을 리가...
- 82. 게임플레이 프로그래머의 역할 • 우리 게임에서 구현이 어려운 게임 플레이를 디자인 → 어려운 이유를 설명하고 대안을 제시한다 • 큰 규모의 작업을 짧은 일정에 해달라고 요청 → 필요한 일정을 설명하고 작업을 여러 단계로 나눠서 진행 • 완성도가 떨어지는 디자인 문서 → 논리적 허점이나 디자인이 커버하지 않는 코너 케이스를 드백
- 83. 왜 이렇게까지 해야 하나요? • 게임 디자이너가 알기 힘든 부분을 제일 잘 아는 직군 • 디자인의 완결성을 높이는 것이 게임플레이 프로그래머의 중요한 역할 중 하나 ✗열정을 가지고 업무 범위를 넓혀라 ✓원래 해야 하는 업무 잘 수행할 수록 경쟁력이 높아진다
- 84. 디자이너에게 요청할 것들 • 프로그래머만 열심히 한다고 가능하지 않다 • 게임 디자이너와의 합의가 필요하다 • 참견이 아닌 드백 • 외주가 아닌 협력
- 85. 디자이너에게 요청할 것들 • 디자인 문서에 다음과 같은 부분을 명확하게 해달라고 요청하기 • 의도 ✗ 특정 건축물을 여러 명이 때리면 데미지가 감소하게 해 주세요 ✓ 특정 건축물은 몇명이 때리던지 최소 일정 시간은 부서지지 않게 하고 싶어요 • 구현의 범위 ✗ 아이템을 소비하여 경험치를 올리는 시스템을 만들어 주세요 ✓ 어떤, 어떤 보상을 일정 구간마다 줘야 합니다 ✓ 경험치 올리는 속도를 올리는 상품을 팔 계획이 있습니다 • 구체적 예시 ✗ 아이템에 추가 성능을 붙일 수 있게 해주세요 ✓ 무기에 공격력과 내구도를 올릴 수 있게 해주세요
- 86. 조심해야 할 부분 • 내가 게임 디자인을 하는 것이 아니다 • “내가 해도 저것 보단 잘 하겠네”를 조심 • 단순한 거절이 되지 않도록 • “안됨. 암튼 안 됨.” • 공격적인 표현 자제 • 디자이너가 드백 안 받기 위해서 몸을 사리지 않도록 • 친절하되 건조하고 현실적인 내용으로
- 87. 테크니컬 디자이너 • 이런 일을 전문적으로 하는 사람 • 업계 전반으로 통용되는 직군 이름은 아닌 듯 • 논리적인 디자인을 주로 하는 디자이너를 가리키는 용어로도 쓰임 • 프로그래머와 디자이너 사이의 회색 지대 • 프로그래밍에 소양이 있는 디자이너 • 게임 디자인에 관심과 경험이 많은 프로그래머
- 88. 테크니컬 디자이너 • 회사에 따라서는 별개의 역할로 구분 • 만드는 프로덕트에 따라선 별개의 역할로 존재하기 힘들 수도 • 새로운 게임을 만들 때 • 프로덕트가 크게 변화할 때 • 규모가 일정 이하의 팀일 때 • 별개의 포지션이 없다면 게임플레이 프로그래머가 하기에 가장 적합 • 적극적인 디자이너와의 소통으로 나의 경쟁력을 키워 보자 • 게임플레이 프로그래머의 리더/매니저가 되기 위해선 필수적인 소양
- 89. 원활한 소통 능력 • 사업팀, 운영팀, QA팀과 일할 때도 비슷 • 프로그래머가 아닌 팀의 요청을 받았을 때 ✗작업의 가능, 불가능 여부를 알려준다 ✗(상대에서 수용하기 힘들) 일정을 통보한다 ✓작업의 규모와 난이도를 납득 가능하게 설명할 수 있는가 ✓상호 합의를 통해 작업의 방향과 내용을 좋은 방향으로 이끌 수 있는가
- 90. 게임플레이 프로그래머 = 상대의 의도를 이해하고 정해진 일정에 맞춰 좋은 품질의 프로그래밍을 하는 사람
- 91. 결국 소통 프로그래머가 일반적으로 갖춰야 하는 공통 소양 + 게임에 대한 이해 + 비 프로그래머와의 소통 + 동료 프로그래머와의 소통
- 92. 결국 소통 프로그래머가 일반적으로 갖춰야 하는 공통 소양 + 게임에 대한 이해 + 비 프로그래머와의 소통 + 동료 프로그래머와의 소통 서로의 발전을 위해 지속적으로 드백을 요청하고 지속적으로 드백을 해주는 것 상대의 의도를 적극적으로 파악하고 현실적인 방향으로 갈 수 있도록 도움을 주는 것
- 93. 발전하는 개발 환경 • 발전하는 도구 • 발전하는 프레임워크 • 점점 게임플레이 프로그래밍이 쉬워지고 있다 → 자동화 되고 있다 • 이럴 때일 수록 내 경쟁력을 챙겨야 한다
- 94. 게임플레이 프로그래머 = 소통 스페셜리스트 동료와의 소통은 내 업무시간을 빼앗는 행위가 아니고 내 업무 범위 안의 일이면서 내가 성장하는 길이다
- 95. 감사니다