SlideShare a Scribd company logo

NDC2019 - 게임플레이 프로그래머의 역할

NDC2019에서 발표한 내용입니다. 저 개인의 경험에 비추어 좋은 게임플레이 프로그래머가 되기 위해 노력해야 할 점들을 정리해 보았습니다.

1 of 95
Download to read offline
게임플레이 프로그래머의 역할
넥슨코리아 / 왓 스튜디오
최호영
발표자 소개
2009 - 2012 루니아 전기
2012 - 2019 야생의 땅: 듀랑고
NDC 2013 Typescript,
javascript의 안정성을 높이기 위한 시도
NDC 2014 가죽 장화를 먹게 해달라니
NDC 2016 <야생의 땅: 듀랑고>
중앙 서버 없는 게임 로직
NDC 2018 NoSQL 위에서 MMORPG 개발하기
발표의 목적
• 왓 스튜디오에서의 경험을 바탕으로
• 발표자가 생각하는 게임플레이 프로그래머의 역할
• 좋은 게임플레이 프로그래머가 되기 위한 방법
• 지망생과 커리어 초반의 프로그래머에게 도움이 되었으면
게임플레이 프로그래머
무슨 일을 하는가?
NDC 2014 가죽 장화를 먹게 해달라니
NDC 2016 <야생의 땅: 듀랑고> 중앙 서버 없는 게임 로직
NDC 2018 NoSQL 위에서 MMORPG 개발하기
무슨 일을 하는가?
• 친구
• 전투
• 부족 전쟁
• 건축물 이력
• 우편
• 상점
• 퀘스트
• 이벤트
• 상태 이상
• 스킬
• 운영툴
• 게임 로그
Ad

Recommended

홍성우, 게임 프로그래머는 어떻게 가르치나요?, NDC2018
홍성우, 게임 프로그래머는 어떻게 가르치나요?, NDC2018홍성우, 게임 프로그래머는 어떻게 가르치나요?, NDC2018
홍성우, 게임 프로그래머는 어떻게 가르치나요?, NDC2018devCAT Studio, NEXON
 
김동건, 구세대 개발자의 신세대 플레이어를 위한 게임 만들기, NDC2011
김동건, 구세대 개발자의 신세대 플레이어를 위한 게임 만들기, NDC2011김동건, 구세대 개발자의 신세대 플레이어를 위한 게임 만들기, NDC2011
김동건, 구세대 개발자의 신세대 플레이어를 위한 게임 만들기, NDC2011devCAT Studio, NEXON
 
[NDC 2021] 게임 PD가 되어 보니
[NDC 2021] 게임 PD가 되어 보니[NDC 2021] 게임 PD가 되어 보니
[NDC 2021] 게임 PD가 되어 보니Yongha Kim
 
게임 프로그래밍 기초 공부법
게임 프로그래밍 기초 공부법게임 프로그래밍 기초 공부법
게임 프로그래밍 기초 공부법Chris Ohk
 
3D 게임 그래픽스의 이해
3D 게임 그래픽스의 이해3D 게임 그래픽스의 이해
3D 게임 그래픽스의 이해ByungChun2
 
게임제작개론 8
게임제작개론 8게임제작개론 8
게임제작개론 8Seokmin No
 
[KGC2011_박민근] 신입 게임 개발자가 알아야 할 것들
[KGC2011_박민근] 신입 게임 개발자가 알아야 할 것들[KGC2011_박민근] 신입 게임 개발자가 알아야 할 것들
[KGC2011_박민근] 신입 게임 개발자가 알아야 할 것들MinGeun Park
 
ndc 2017 어쩌다 신입 - 초보 게임 개발자 2년 간의 포스트모템
ndc 2017 어쩌다 신입 - 초보 게임 개발자 2년 간의 포스트모템ndc 2017 어쩌다 신입 - 초보 게임 개발자 2년 간의 포스트모템
ndc 2017 어쩌다 신입 - 초보 게임 개발자 2년 간의 포스트모템Chaeone Son
 

More Related Content

What's hot

그럴듯한 랜덤 생성 컨텐츠 만들기
그럴듯한 랜덤 생성 컨텐츠 만들기그럴듯한 랜덤 생성 컨텐츠 만들기
그럴듯한 랜덤 생성 컨텐츠 만들기Yongha Kim
 
NDC 2010 이은석 - 마비노기 영웅전 포스트모템 1부
NDC 2010 이은석 - 마비노기 영웅전 포스트모템 1부NDC 2010 이은석 - 마비노기 영웅전 포스트모템 1부
NDC 2010 이은석 - 마비노기 영웅전 포스트모템 1부Eunseok Yi
 
Multiplayer Game Sync Techniques through CAP theorem
Multiplayer Game Sync Techniques through CAP theoremMultiplayer Game Sync Techniques through CAP theorem
Multiplayer Game Sync Techniques through CAP theoremSeungmo Koo
 
마비노기듀얼 이야기-넥슨 김동건
마비노기듀얼 이야기-넥슨 김동건마비노기듀얼 이야기-넥슨 김동건
마비노기듀얼 이야기-넥슨 김동건강 민우
 
NDC 2015 이광영 [야생의 땅: 듀랑고] 전투 시스템 개발 일지
NDC 2015 이광영 [야생의 땅: 듀랑고] 전투 시스템 개발 일지NDC 2015 이광영 [야생의 땅: 듀랑고] 전투 시스템 개발 일지
NDC 2015 이광영 [야생의 땅: 듀랑고] 전투 시스템 개발 일지Kwangyoung Lee
 
이승재, 일정대로 출시하기 왜 & 어떻게: 개발자를 위한 제작진행개론, NDC2017
이승재, 일정대로 출시하기 왜 & 어떻게: 개발자를 위한 제작진행개론, NDC2017이승재, 일정대로 출시하기 왜 & 어떻게: 개발자를 위한 제작진행개론, NDC2017
이승재, 일정대로 출시하기 왜 & 어떻게: 개발자를 위한 제작진행개론, NDC2017devCAT Studio, NEXON
 
[데브루키/141206 박민근] 유니티 최적화 테크닉 총정리
[데브루키/141206 박민근] 유니티 최적화 테크닉 총정리[데브루키/141206 박민근] 유니티 최적화 테크닉 총정리
[데브루키/141206 박민근] 유니티 최적화 테크닉 총정리MinGeun Park
 
NDC2016 프로젝트 A1의 AAA급 캐릭터 렌더링 기술
NDC2016 프로젝트 A1의 AAA급 캐릭터 렌더링 기술NDC2016 프로젝트 A1의 AAA급 캐릭터 렌더링 기술
NDC2016 프로젝트 A1의 AAA급 캐릭터 렌더링 기술Ki Hyunwoo
 
김동건, 할머니가 들려주신 마비노기 개발 전설, NDC2019
김동건, 할머니가 들려주신 마비노기 개발 전설, NDC2019김동건, 할머니가 들려주신 마비노기 개발 전설, NDC2019
김동건, 할머니가 들려주신 마비노기 개발 전설, NDC2019devCAT Studio, NEXON
 
게임제작개론 : #4 게임 밸런싱
게임제작개론 : #4 게임 밸런싱게임제작개론 : #4 게임 밸런싱
게임제작개론 : #4 게임 밸런싱Seungmo Koo
 
김혁, <드래곤 하운드>의 PBR과 레이트레이싱 렌더링 기법, NDC2019
김혁, <드래곤 하운드>의 PBR과 레이트레이싱 렌더링 기법, NDC2019김혁, <드래곤 하운드>의 PBR과 레이트레이싱 렌더링 기법, NDC2019
김혁, <드래곤 하운드>의 PBR과 레이트레이싱 렌더링 기법, NDC2019devCAT Studio, NEXON
 
레벨 디자인의 구성
레벨 디자인의 구성레벨 디자인의 구성
레벨 디자인의 구성준태 김
 
최은영, 아티스트가 기획을 - 하이브리드의 길 Ver.1, NDC 2012
최은영, 아티스트가 기획을 - 하이브리드의 길 Ver.1, NDC 2012최은영, 아티스트가 기획을 - 하이브리드의 길 Ver.1, NDC 2012
최은영, 아티스트가 기획을 - 하이브리드의 길 Ver.1, NDC 2012devCAT Studio, NEXON
 
전형규, 좋은 이름, 나쁜 이름, 이상한 이름, NDC2018
전형규, 좋은 이름, 나쁜 이름, 이상한 이름, NDC2018전형규, 좋은 이름, 나쁜 이름, 이상한 이름, NDC2018
전형규, 좋은 이름, 나쁜 이름, 이상한 이름, NDC2018devCAT Studio, NEXON
 
임태현, MMO 서버 개발 포스트 모템, NDC2012
임태현, MMO 서버 개발 포스트 모템, NDC2012임태현, MMO 서버 개발 포스트 모템, NDC2012
임태현, MMO 서버 개발 포스트 모템, NDC2012devCAT Studio, NEXON
 
위대한 게임개발팀의 공통점
위대한 게임개발팀의 공통점위대한 게임개발팀의 공통점
위대한 게임개발팀의 공통점Ryan Park
 
게임제작개론 : #7 팀 역할과 게임 리소스에 대한 이해
게임제작개론 : #7 팀 역할과 게임 리소스에 대한 이해게임제작개론 : #7 팀 역할과 게임 리소스에 대한 이해
게임제작개론 : #7 팀 역할과 게임 리소스에 대한 이해Seungmo Koo
 
이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018
이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018
이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018devCAT Studio, NEXON
 
[NDC 19] 시스템 기획서 잘 쓰는 법
[NDC 19] 시스템 기획서 잘 쓰는 법[NDC 19] 시스템 기획서 잘 쓰는 법
[NDC 19] 시스템 기획서 잘 쓰는 법Na Eun Lee
 
MMOG Server-Side 충돌 및 이동처리 설계와 구현
MMOG Server-Side 충돌 및 이동처리 설계와 구현MMOG Server-Side 충돌 및 이동처리 설계와 구현
MMOG Server-Side 충돌 및 이동처리 설계와 구현YEONG-CHEON YOU
 

What's hot (20)

그럴듯한 랜덤 생성 컨텐츠 만들기
그럴듯한 랜덤 생성 컨텐츠 만들기그럴듯한 랜덤 생성 컨텐츠 만들기
그럴듯한 랜덤 생성 컨텐츠 만들기
 
NDC 2010 이은석 - 마비노기 영웅전 포스트모템 1부
NDC 2010 이은석 - 마비노기 영웅전 포스트모템 1부NDC 2010 이은석 - 마비노기 영웅전 포스트모템 1부
NDC 2010 이은석 - 마비노기 영웅전 포스트모템 1부
 
Multiplayer Game Sync Techniques through CAP theorem
Multiplayer Game Sync Techniques through CAP theoremMultiplayer Game Sync Techniques through CAP theorem
Multiplayer Game Sync Techniques through CAP theorem
 
마비노기듀얼 이야기-넥슨 김동건
마비노기듀얼 이야기-넥슨 김동건마비노기듀얼 이야기-넥슨 김동건
마비노기듀얼 이야기-넥슨 김동건
 
NDC 2015 이광영 [야생의 땅: 듀랑고] 전투 시스템 개발 일지
NDC 2015 이광영 [야생의 땅: 듀랑고] 전투 시스템 개발 일지NDC 2015 이광영 [야생의 땅: 듀랑고] 전투 시스템 개발 일지
NDC 2015 이광영 [야생의 땅: 듀랑고] 전투 시스템 개발 일지
 
이승재, 일정대로 출시하기 왜 & 어떻게: 개발자를 위한 제작진행개론, NDC2017
이승재, 일정대로 출시하기 왜 & 어떻게: 개발자를 위한 제작진행개론, NDC2017이승재, 일정대로 출시하기 왜 & 어떻게: 개발자를 위한 제작진행개론, NDC2017
이승재, 일정대로 출시하기 왜 & 어떻게: 개발자를 위한 제작진행개론, NDC2017
 
[데브루키/141206 박민근] 유니티 최적화 테크닉 총정리
[데브루키/141206 박민근] 유니티 최적화 테크닉 총정리[데브루키/141206 박민근] 유니티 최적화 테크닉 총정리
[데브루키/141206 박민근] 유니티 최적화 테크닉 총정리
 
NDC2016 프로젝트 A1의 AAA급 캐릭터 렌더링 기술
NDC2016 프로젝트 A1의 AAA급 캐릭터 렌더링 기술NDC2016 프로젝트 A1의 AAA급 캐릭터 렌더링 기술
NDC2016 프로젝트 A1의 AAA급 캐릭터 렌더링 기술
 
김동건, 할머니가 들려주신 마비노기 개발 전설, NDC2019
김동건, 할머니가 들려주신 마비노기 개발 전설, NDC2019김동건, 할머니가 들려주신 마비노기 개발 전설, NDC2019
김동건, 할머니가 들려주신 마비노기 개발 전설, NDC2019
 
게임제작개론 : #4 게임 밸런싱
게임제작개론 : #4 게임 밸런싱게임제작개론 : #4 게임 밸런싱
게임제작개론 : #4 게임 밸런싱
 
김혁, <드래곤 하운드>의 PBR과 레이트레이싱 렌더링 기법, NDC2019
김혁, <드래곤 하운드>의 PBR과 레이트레이싱 렌더링 기법, NDC2019김혁, <드래곤 하운드>의 PBR과 레이트레이싱 렌더링 기법, NDC2019
김혁, <드래곤 하운드>의 PBR과 레이트레이싱 렌더링 기법, NDC2019
 
레벨 디자인의 구성
레벨 디자인의 구성레벨 디자인의 구성
레벨 디자인의 구성
 
최은영, 아티스트가 기획을 - 하이브리드의 길 Ver.1, NDC 2012
최은영, 아티스트가 기획을 - 하이브리드의 길 Ver.1, NDC 2012최은영, 아티스트가 기획을 - 하이브리드의 길 Ver.1, NDC 2012
최은영, 아티스트가 기획을 - 하이브리드의 길 Ver.1, NDC 2012
 
전형규, 좋은 이름, 나쁜 이름, 이상한 이름, NDC2018
전형규, 좋은 이름, 나쁜 이름, 이상한 이름, NDC2018전형규, 좋은 이름, 나쁜 이름, 이상한 이름, NDC2018
전형규, 좋은 이름, 나쁜 이름, 이상한 이름, NDC2018
 
임태현, MMO 서버 개발 포스트 모템, NDC2012
임태현, MMO 서버 개발 포스트 모템, NDC2012임태현, MMO 서버 개발 포스트 모템, NDC2012
임태현, MMO 서버 개발 포스트 모템, NDC2012
 
위대한 게임개발팀의 공통점
위대한 게임개발팀의 공통점위대한 게임개발팀의 공통점
위대한 게임개발팀의 공통점
 
게임제작개론 : #7 팀 역할과 게임 리소스에 대한 이해
게임제작개론 : #7 팀 역할과 게임 리소스에 대한 이해게임제작개론 : #7 팀 역할과 게임 리소스에 대한 이해
게임제작개론 : #7 팀 역할과 게임 리소스에 대한 이해
 
이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018
이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018
이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018
 
[NDC 19] 시스템 기획서 잘 쓰는 법
[NDC 19] 시스템 기획서 잘 쓰는 법[NDC 19] 시스템 기획서 잘 쓰는 법
[NDC 19] 시스템 기획서 잘 쓰는 법
 
MMOG Server-Side 충돌 및 이동처리 설계와 구현
MMOG Server-Side 충돌 및 이동처리 설계와 구현MMOG Server-Side 충돌 및 이동처리 설계와 구현
MMOG Server-Side 충돌 및 이동처리 설계와 구현
 

Similar to NDC2019 - 게임플레이 프로그래머의 역할

[IGC2018] 펄어비스 김광삼 - 대면 커뮤니케이션 주도의 게임 디자인과 게임 개발법
[IGC2018] 펄어비스 김광삼 - 대면 커뮤니케이션 주도의 게임 디자인과 게임 개발법[IGC2018] 펄어비스 김광삼 - 대면 커뮤니케이션 주도의 게임 디자인과 게임 개발법
[IGC2018] 펄어비스 김광삼 - 대면 커뮤니케이션 주도의 게임 디자인과 게임 개발법강 민우
 
카카오스토리 웹팀의 코드리뷰 경험
카카오스토리 웹팀의 코드리뷰 경험카카오스토리 웹팀의 코드리뷰 경험
카카오스토리 웹팀의 코드리뷰 경험Ohgyun Ahn
 
임태현, 프로그래머 생존 가이드
임태현, 프로그래머 생존 가이드임태현, 프로그래머 생존 가이드
임태현, 프로그래머 생존 가이드태현 임
 
2022 01-okky-코드리뷰
2022 01-okky-코드리뷰2022 01-okky-코드리뷰
2022 01-okky-코드리뷰Myeongseok Baek
 
Code Review - DevOn2013
Code Review - DevOn2013Code Review - DevOn2013
Code Review - DevOn2013호정 이
 
쩌는 게임 기획서, 이렇게 쓴다(How to write great design documents) from GDC 2008 (Korean)
쩌는 게임 기획서, 이렇게 쓴다(How to write great design documents) from GDC 2008 (Korean)쩌는 게임 기획서, 이렇게 쓴다(How to write great design documents) from GDC 2008 (Korean)
쩌는 게임 기획서, 이렇게 쓴다(How to write great design documents) from GDC 2008 (Korean)Kay Kim
 
SWDeveloprStory201601
SWDeveloprStory201601SWDeveloprStory201601
SWDeveloprStory201601Suho Kwon
 
윤석주, 신입 게임 프로그래머가 되는 법 - 넥슨 채용 프로세스 단계별 분석, NDC2019
윤석주, 신입 게임 프로그래머가 되는 법 - 넥슨 채용 프로세스 단계별 분석, NDC2019윤석주, 신입 게임 프로그래머가 되는 법 - 넥슨 채용 프로세스 단계별 분석, NDC2019
윤석주, 신입 게임 프로그래머가 되는 법 - 넥슨 채용 프로세스 단계별 분석, NDC2019devCAT Studio, NEXON
 
애자일 프랙티스
애자일 프랙티스애자일 프랙티스
애자일 프랙티스한 경만
 
어쩌다로봇
어쩌다로봇어쩌다로봇
어쩌다로봇민건 주
 
Software engineer가 되기 위한 여정
Software engineer가 되기 위한 여정Software engineer가 되기 위한 여정
Software engineer가 되기 위한 여정Aree Oh
 
KGC2014 코딩을 몰라도 가능한 프로토타입 제작
KGC2014 코딩을 몰라도 가능한 프로토타입 제작KGC2014 코딩을 몰라도 가능한 프로토타입 제작
KGC2014 코딩을 몰라도 가능한 프로토타입 제작Seokho Lee
 
프로그래머에게 사랑받는 게임 기획서 작성법
프로그래머에게 사랑받는 게임 기획서 작성법프로그래머에게 사랑받는 게임 기획서 작성법
프로그래머에게 사랑받는 게임 기획서 작성법Lee Sangkyoon (Kay)
 
[RAPA/C++] 1. 수업 내용 및 진행 방법
[RAPA/C++] 1. 수업 내용 및 진행 방법[RAPA/C++] 1. 수업 내용 및 진행 방법
[RAPA/C++] 1. 수업 내용 및 진행 방법MinGeun Park
 
쩌는게임기획서 이렇게 쓴다
쩌는게임기획서 이렇게 쓴다쩌는게임기획서 이렇게 쓴다
쩌는게임기획서 이렇게 쓴다Jinho Jung
 
(독서광) 필독! 개발자 온보딩 가이드
(독서광) 필독! 개발자 온보딩 가이드(독서광) 필독! 개발자 온보딩 가이드
(독서광) 필독! 개발자 온보딩 가이드Jay Park
 
만능 개발자를 위한 아틀리에 시스템
만능 개발자를 위한 아틀리에 시스템만능 개발자를 위한 아틀리에 시스템
만능 개발자를 위한 아틀리에 시스템KwangSam Kim
 
(독서광) 프로그래머의 뇌
(독서광) 프로그래머의 뇌(독서광) 프로그래머의 뇌
(독서광) 프로그래머의 뇌Jay Park
 

Similar to NDC2019 - 게임플레이 프로그래머의 역할 (20)

[IGC2018] 펄어비스 김광삼 - 대면 커뮤니케이션 주도의 게임 디자인과 게임 개발법
[IGC2018] 펄어비스 김광삼 - 대면 커뮤니케이션 주도의 게임 디자인과 게임 개발법[IGC2018] 펄어비스 김광삼 - 대면 커뮤니케이션 주도의 게임 디자인과 게임 개발법
[IGC2018] 펄어비스 김광삼 - 대면 커뮤니케이션 주도의 게임 디자인과 게임 개발법
 
카카오스토리 웹팀의 코드리뷰 경험
카카오스토리 웹팀의 코드리뷰 경험카카오스토리 웹팀의 코드리뷰 경험
카카오스토리 웹팀의 코드리뷰 경험
 
임태현, 프로그래머 생존 가이드
임태현, 프로그래머 생존 가이드임태현, 프로그래머 생존 가이드
임태현, 프로그래머 생존 가이드
 
2022 01-okky-코드리뷰
2022 01-okky-코드리뷰2022 01-okky-코드리뷰
2022 01-okky-코드리뷰
 
Code Review - DevOn2013
Code Review - DevOn2013Code Review - DevOn2013
Code Review - DevOn2013
 
쩌는 게임 기획서, 이렇게 쓴다(How to write great design documents) from GDC 2008 (Korean)
쩌는 게임 기획서, 이렇게 쓴다(How to write great design documents) from GDC 2008 (Korean)쩌는 게임 기획서, 이렇게 쓴다(How to write great design documents) from GDC 2008 (Korean)
쩌는 게임 기획서, 이렇게 쓴다(How to write great design documents) from GDC 2008 (Korean)
 
2019 11-code review
2019 11-code review2019 11-code review
2019 11-code review
 
SWDeveloprStory201601
SWDeveloprStory201601SWDeveloprStory201601
SWDeveloprStory201601
 
윤석주, 신입 게임 프로그래머가 되는 법 - 넥슨 채용 프로세스 단계별 분석, NDC2019
윤석주, 신입 게임 프로그래머가 되는 법 - 넥슨 채용 프로세스 단계별 분석, NDC2019윤석주, 신입 게임 프로그래머가 되는 법 - 넥슨 채용 프로세스 단계별 분석, NDC2019
윤석주, 신입 게임 프로그래머가 되는 법 - 넥슨 채용 프로세스 단계별 분석, NDC2019
 
애자일 프랙티스
애자일 프랙티스애자일 프랙티스
애자일 프랙티스
 
어쩌다로봇
어쩌다로봇어쩌다로봇
어쩌다로봇
 
Software engineer가 되기 위한 여정
Software engineer가 되기 위한 여정Software engineer가 되기 위한 여정
Software engineer가 되기 위한 여정
 
KGC2014 코딩을 몰라도 가능한 프로토타입 제작
KGC2014 코딩을 몰라도 가능한 프로토타입 제작KGC2014 코딩을 몰라도 가능한 프로토타입 제작
KGC2014 코딩을 몰라도 가능한 프로토타입 제작
 
프로그래머에게 사랑받는 게임 기획서 작성법
프로그래머에게 사랑받는 게임 기획서 작성법프로그래머에게 사랑받는 게임 기획서 작성법
프로그래머에게 사랑받는 게임 기획서 작성법
 
[RAPA/C++] 1. 수업 내용 및 진행 방법
[RAPA/C++] 1. 수업 내용 및 진행 방법[RAPA/C++] 1. 수업 내용 및 진행 방법
[RAPA/C++] 1. 수업 내용 및 진행 방법
 
쩌는게임기획서 이렇게 쓴다
쩌는게임기획서 이렇게 쓴다쩌는게임기획서 이렇게 쓴다
쩌는게임기획서 이렇게 쓴다
 
Chean code chapter 1
Chean code chapter 1Chean code chapter 1
Chean code chapter 1
 
(독서광) 필독! 개발자 온보딩 가이드
(독서광) 필독! 개발자 온보딩 가이드(독서광) 필독! 개발자 온보딩 가이드
(독서광) 필독! 개발자 온보딩 가이드
 
만능 개발자를 위한 아틀리에 시스템
만능 개발자를 위한 아틀리에 시스템만능 개발자를 위한 아틀리에 시스템
만능 개발자를 위한 아틀리에 시스템
 
(독서광) 프로그래머의 뇌
(독서광) 프로그래머의 뇌(독서광) 프로그래머의 뇌
(독서광) 프로그래머의 뇌
 

NDC2019 - 게임플레이 프로그래머의 역할

  • 2. 발표자 소개 2009 - 2012 루니아 전기 2012 - 2019 야생의 땅: 듀랑고 NDC 2013 Typescript, javascript의 안정성을 높이기 위한 시도 NDC 2014 가죽 장화를 먹게 해달라니 NDC 2016 <야생의 땅: 듀랑고> 중앙 서버 없는 게임 로직 NDC 2018 NoSQL 위에서 MMORPG 개발하기
  • 3. 발표의 목적 • 왓 스튜디오에서의 경험을 바탕으로 • 발표자가 생각하는 게임플레이 프로그래머의 역할 • 좋은 게임플레이 프로그래머가 되기 위한 방법 • 지망생과 커리어 초반의 프로그래머에게 도움이 되었으면
  • 5. 무슨 일을 하는가? NDC 2014 가죽 장화를 먹게 해달라니 NDC 2016 <야생의 땅: 듀랑고> 중앙 서버 없는 게임 로직 NDC 2018 NoSQL 위에서 MMORPG 개발하기
  • 6. 무슨 일을 하는가? • 친구 • 전투 • 부족 전쟁 • 건축물 이력 • 우편 • 상점 • 퀘스트 • 이벤트 • 상태 이상 • 스킬 • 운영툴 • 게임 로그
  • 7. 게임플레이 프로그래머 • 유저들의 경험과 맞닿는 모든 것을 프로그래밍 하는 사람 • 깊이 있는 프로그래밍 보다는 • 다양하게 주어지는 의도를 전달 받아 • 빠르고 효율적으로 구현하는 프로그래머
  • 8. 어떤 사람이 좋은 게임플레이 프로그래머인가 • 아름다운 코드를 만드는 사람? • 게임을 사랑하는 사람? • 야근을 적극적으로 하는 사람?
  • 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 만들 때 실수로 빠지지 않도록 템플릿을 사용
  • 36. 리뷰이: MR의 생성 * 설명적인 제목과 명확한 의도를 적어야 한다
  • 38. 리뷰이: MR 내용 입력 * 이 MR만 봐도 작업의 전후 맥락을 파악할 수 있는 자세한 설명
  • 40. 리뷰어: 체크리스트 확인 * 리뷰어가 잊는 부분이 없도록 체크 리스트를 만들어 두면 좋다
  • 42. 리뷰어, 리뷰이: 코멘트와 피드백 * 피드백이 필요한 라인에 직접 피드백 주기
  • 43. 리뷰어, 리뷰이: 코멘트와 피드백 * 공격적이지 않은 어투를 사용하되 직설적인 의견 제시
  • 44. 리뷰어, 리뷰이: 코멘트와 피드백 * 제안은 충실히 검토하되 무조건 받아들일 필요는 없다
  • 47. 그래도 코드 리뷰 싫어요 • 코드 한 줄 고쳤는데 반영되는데 이틀 걸렸어요 • 작업할 시간도 없는데 남이 짠 코드 언제 해독하고 있어요 리뷰하기 좋은 MR과 좋은 리뷰로 개선할 수 있습니다
  • 48. 리뷰하기 좋은 MR • MR은 최대한 작게 • 클 수록 코드 파악이 어려워 리뷰어가 어렵기 때문에 리뷰가 너무 오래 걸리거나 리뷰가 충실하지 못함 • 리팩토링 할 땐 작업과 삭제를 분리하기 • 큰 작업은 인터페이스와 구현을 분리하기 ✗아이템에 xx 기능 추가 + 겸사 인벤토리 버그 수정 ✗퀘스트 시스템 ✓퀘스트 시스템 중 재발급 기능 구현
  • 49. 리뷰하기 좋은 MR • 내용은 최대한 구체적으로 • 리뷰어가 전후 문맥을 파악하기 쉽게 구체적으로 작성 ✗ 채집할 때 다른 아이템이 나오는 문제 수정 ✓ 채집할 때 카테고리 별 데이터 연결이 틀려 잘못된 아이템을 획득하는 문제 수정 • 관련된 다른 MR을 링크 • 미래 언제 봐도 독립적으로 내용을 파악할 수 있게 작성
  • 50. 좋은 리뷰 • 피드백은 간결하고 건조하게 • 돌려 말하지 않고 직접적으로 피드백 할 것 • 미사여구는 요점을 흐리고 리뷰를 방해할 뿐 • 스탠다드와 취향의 구분은 명확하게 • 취향을 드러내면 피드백을 주는 것이 나쁜 것은 아니지만 취향에 따른 의견임을 명확히 할 것 • 작은 코멘트(단순 실수 등)는 남기되 미리 Merge를 승인 할 것 • 핑퐁 횟수를 최대한 줄이기 위함
  • 51. 조심할 점 • 형식적인 리뷰어 지정이 되지 않도록 조심 • 리뷰 잘 안해주는 사람을 지정하는 경향 • 리뷰 잘 해주는 사람을 지정하는 경향 • 잘 아는 사람 + 잘 모르는 사람 을 지정하는 것을 추천 (최소 2명) • 리뷰어의 집중을 방해하지 말아야 함 • 되도록 리뷰의 재촉은 금지하되 모두의 합의 하에 적당한 리마인드만 • 시급도가 높은 경우에만 별도로 호출 • 내 작업이 반영되는 속도가 늦어 지기 때문에 업무를 투트랙으로 진행하는 것을 추천
  • 52. 코드 리뷰 경험이 없다면 • 오픈 소스 프로젝트에 관심을 가져보자 • 직접 기여하는 것이 물론 베스트 • 다른 사람들의 MR/PR을 구경하는 것도 도움이 된다 • 취미 프로젝트에서 사용해 보자 • 물론 2인 이상일 경우에 가능 • 형식적인 것처럼 느껴지고 어색하더라도 한번 해보자 • 페어 프로그래밍도 일종의 코드 리뷰 • 리뷰 시스템 도입이 힘들다면 페어 프로그래밍을 적극적으로 해보자
  • 55. 고객들은 기다려 주지 않는다 • 모든 작은 행동들이 이탈율로 이어지는 현실 • 퀄리티 좋은 결과물도 중요하지만 • 기대보다 늦은 출시 • 기대보다 긴 업데이트 주기 • 는 전부 고객 이탈로 이어진다
  • 56. 다양한 선택들 • 프로덕션 단계에서 순간적으로 엄청난 푸쉬 • AAA 게임들 • 비용이 많이 들여 빨리 만든다 • 선택과 집중으로 원하는 재미 포인트만 빠르게 뽑아낸다 • 캐주얼 게임, 인디 게임 • 볼륨이나 리소스 퀄리티를 희생해서 비용을 낮추고 빨리 만든다 • 선택과 집중으로 속도를 희생한다 • 내가 취미로 만드는 게임 • 몇 년째 진척이 없다
  • 57. 우리가 할 수 있는 것은? • 이런 선택들은 개발 전반에 걸친 결정 • 개인인 프로그래머가 직접 관여할 수 있는 분야는 아니다
  • 58. 개발 일정 지키기 • 개발 기간을 당길 순 없지만 • 늦추지 않을 순 있다
  • 59. 일정 지키기 • 일정은? • “지키지 않기 위해 존재하는 것“ • “틀어지기 위해 존재하는 것“ • 2N + 하루의 법칙 • 계산할 수 없는 방해요소를 미리 계산하는 것 • 경험적인 공식이지만 의외로 꽤 맞다 • 하지만 어디까지나 반쯤 농담
  • 60. 일정을 지키기 힘든 이유 • 외부적 요인 • 작업 방향의 강제적 전환 • 디자인 방향의 변경 • 작업 범위 변경 • 내부적 요인 • 잘못된 방향 설정 • 잘못된 업무량 예측
  • 61. 일정을 지키기 힘든 이유 • 외부적 요인 • 작업 방향의 강제적 전환 • 디자인 방향의 변경 • 작업 범위 변경 • 내부적 요인 • 잘못된 방향 설정 • 잘못된 업무량 예측 프로세스의 문제
  • 62. 잘못된 방향 설정 • 대부분 프로젝트의 구조에 대한 이해 부족으로 발생 • 경험 부족으로 설계 자체가 잘못되었거나 • 이미 존재하는 바퀴를 재발명 했거나 • 우리 프로젝트에만 있는 특수한 사이드 이펙트를 몰랐거나 • 그냥 미처 생각이 미치지 않은 부분이 있거나 • 등등 • 실력이 부족한 사람이 자꾸 변명하네!
  • 63. 실수는 누구나 한다 • 누구나 신입일 때가 있다 • 누구나 내 프로젝트에 모르는 부분이 있을 수 있다 • 인간의 실수는 당연한 것, 다만 줄이려고 노력할 뿐이다
  • 64. 실수를 줄이려면? • 내가 실력을 키운다 • 노력을 더 많이 한다 • 여러 사람의 눈을 빌린다 • 코드 리뷰 !?
  • 65. 코드 리뷰 • 이미 작업한 다음에 리뷰 받는 것이므로 재작업을 피할 수 없다 • 코드 리뷰 과정에서 큰 문제가 발견되는 것이 • 흔한 작업 딜레이의 사유 • 소 잃고 외양간 고치는 격
  • 66. 기술 명세서 리뷰 도입 • 디자인 문서를 전달 받은 작업자가 명세서를 작성 • 명세서를 동료 프로그래머에게 리뷰 받고 • 리뷰가 통과하면 작업을 시작
  • 67. PROGRAMMER = 인간의 언어보다 기계의 언어를 잘 쓰는 사람 (저만 그런 가요)
  • 68. 기술 명세서 • 테크니컬 라이팅(Technical Writing) 능력이 부족한 프로그래머가 많음 • 쏟아지는 작업마다 일일이 문서를 쓰기엔 시간이 부족 • 리뷰 도구의 부재 • 문서 보관소에 문서처럼 작성하고 리뷰 → 리뷰용 도구가 없어서 리뷰가 불편 • 문서를 Git에 보관하고 코드 처럼 리뷰하는 것도 고려 • 어차피 위 문제가 해결이 안되기 때문에 실제로 해보지는 않음 • 결국 대규모 피처일 경우 문서화를 위해 쓰는 정도로 타협 → 원래 의도했던 기능은 수행하지 못하게 됨
  • 69. 현실적인 대안 • 글쓰기가 힘들다면 대화로 해결하자 • 정기적으로 짧은 미팅을 가지기 • 내가 앞으로 할 일에 대해 설명하고 피드백을 받기 • 스크럼 회의처럼 최대한 간결하게 설명 • 디테일을 이야기 하지 않는다 • 작업 방향에 쟁점이 생긴다면 회의 이후에 관련자들끼리 따로 논의 • 작업 비용에 대한 피드백을 받는 부가 효과 • 일정 예측이 정확해 진다 • 플래닝 포커 등 다양한 방법을 시도 중
  • 70. 중요한 점 • 내 작업을 동료가 알게 하라 • 간결하게 핵심만 • 동료에게 인터럽트 없이 알려줄 방법을 찾아라 • 피드백은 공격이 아니다 • 내 생각은 완벽하지 않으니 언제나 조언을 받으라 • 결국 사람 간의 문제 감정이 상하지 않게 언제나 조심하되 비효율이 줄어들게 미사여구를 줄이라
  • 71. 호프스태터의 법칙: 그 일은 항상 당신이 예상한 것보다 더 오래 걸린다, 비록 호프스태터의 법칙을 고려했다고 해도 말이다.
  • 72. 물론 일정 예측 실패의 가능성은 언제나 있다 • 모든 사람이 실패는 한다 • 실패했을 때 중요한 것은 틀어지고 있는 일정을 숨기지 않는 것 • 숨긴 일정 지연이 더 큰 일정 지연이 되어 돌아온다
  • 76. 원활한 소통 능력? • 시키는 거 잘 알아 듣는 사람? • 재치 있는 표현을 섞어서 즐겁게 소통하는 사람? • 인-싸?
  • 77. 게임플레이 프로그래밍 • 게임 디자이너에게 의뢰를 받아서 • 실제로 결과물을 낸다 • 피드백을 받고 수정 작업
  • 78. 게임 디자이너의 역할 • 게임 디자이너 • 어떻게 하면 재밌을까? • 어떻게 하면 유저가 오래 게임을 즐길까? • 어떻게 하면 유저가 상품을 구입하고 싶을까? • 유저의 입장에서 게임을 설계한다
  • 79. 디자이너와 프로그래머의 관계 • 게임플레이를 함께 만드는 둘 • 하지만 보는 관점이 다르다 • 애증의 관계
  • 80. 흔히 생기는 불만 • 우리 게임에서 구현이 어려운 게임플레이를 요청 • 큰 규모의 작업을 짧은 일정에 해달라고 요청 • 완성도가 떨어지는 디자인 문서 • 주로 예외 상황과 코너 케이스 고려가 안됨
  • 81. 게임 디자이너가 알기 힘든 것 • 구현의 규모와 한계 • 프로그래머가 아니기 때문에 결국 이해하기가 힘듦 • 예외 상황과 코너 케이스 인지가 힘든 것도 이 때문 • 경력이 긴 디자이너도 경험적으로 짐작할 뿐 • 게다가 사실 프로그래머도 일단 구현에 들어가 봐야 아는 경우도 있는데 디자이너가 알 수 있을 리가...
  • 82. 게임플레이 프로그래머의 역할 • 우리 게임에서 구현이 어려운 게임 플레이를 디자인 → 어려운 이유를 설명하고 대안을 제시한다 • 큰 규모의 작업을 짧은 일정에 해달라고 요청 → 필요한 일정을 설명하고 작업을 여러 단계로 나눠서 진행 • 완성도가 떨어지는 디자인 문서 → 논리적 허점이나 디자인이 커버하지 않는 코너 케이스를 피드백
  • 83. 왜 이렇게까지 해야 하나요? • 게임 디자이너가 알기 힘든 부분을 제일 잘 아는 직군 • 디자인의 완결성을 높이는 것이 게임플레이 프로그래머의 중요한 역할 중 하나 ✗열정을 가지고 업무 범위를 넓혀라 ✓원래 해야 하는 업무 잘 수행할 수록 경쟁력이 높아진다
  • 84. 디자이너에게 요청할 것들 • 프로그래머만 열심히 한다고 가능하지 않다 • 게임 디자이너와의 합의가 필요하다 • 참견이 아닌 피드백 • 외주가 아닌 협력
  • 85. 디자이너에게 요청할 것들 • 디자인 문서에 다음과 같은 부분을 명확하게 해달라고 요청하기 • 의도 ✗ 특정 건축물을 여러 명이 때리면 데미지가 감소하게 해 주세요 ✓ 특정 건축물은 몇명이 때리던지 최소 일정 시간은 부서지지 않게 하고 싶어요 • 구현의 범위 ✗ 아이템을 소비하여 경험치를 올리는 시스템을 만들어 주세요 ✓ 어떤, 어떤 보상을 일정 구간마다 줘야 합니다 ✓ 경험치 올리는 속도를 올리는 상품을 팔 계획이 있습니다 • 구체적 예시 ✗ 아이템에 추가 성능을 붙일 수 있게 해주세요 ✓ 무기에 공격력과 내구도를 올릴 수 있게 해주세요
  • 86. 조심해야 할 부분 • 내가 게임 디자인을 하는 것이 아니다 • “내가 해도 저것 보단 잘 하겠네”를 조심 • 단순한 거절이 되지 않도록 • “안됨. 암튼 안 됨.” • 공격적인 표현 자제 • 디자이너가 피드백 안 받기 위해서 몸을 사리지 않도록 • 친절하되 건조하고 현실적인 내용으로
  • 87. 테크니컬 디자이너 • 이런 일을 전문적으로 하는 사람 • 업계 전반으로 통용되는 직군 이름은 아닌 듯 • 논리적인 디자인을 주로 하는 디자이너를 가리키는 용어로도 쓰임 • 프로그래머와 디자이너 사이의 회색 지대 • 프로그래밍에 소양이 있는 디자이너 • 게임 디자인에 관심과 경험이 많은 프로그래머
  • 88. 테크니컬 디자이너 • 회사에 따라서는 별개의 역할로 구분 • 만드는 프로덕트에 따라선 별개의 역할로 존재하기 힘들 수도 • 새로운 게임을 만들 때 • 프로덕트가 크게 변화할 때 • 규모가 일정 이하의 팀일 때 • 별개의 포지션이 없다면 게임플레이 프로그래머가 하기에 가장 적합 • 적극적인 디자이너와의 소통으로 나의 경쟁력을 키워 보자 • 게임플레이 프로그래머의 리더/매니저가 되기 위해선 필수적인 소양
  • 89. 원활한 소통 능력 • 사업팀, 운영팀, QA팀과 일할 때도 비슷 • 프로그래머가 아닌 팀의 요청을 받았을 때 ✗작업의 가능, 불가능 여부를 알려준다 ✗(상대에서 수용하기 힘들) 일정을 통보한다 ✓작업의 규모와 난이도를 납득 가능하게 설명할 수 있는가 ✓상호 합의를 통해 작업의 방향과 내용을 좋은 방향으로 이끌 수 있는가
  • 90. 게임플레이 프로그래머 = 상대의 의도를 이해하고 정해진 일정에 맞춰 좋은 품질의 프로그래밍을 하는 사람
  • 91. 결국 소통 프로그래머가 일반적으로 갖춰야 하는 공통 소양 + 게임에 대한 이해 + 비 프로그래머와의 소통 + 동료 프로그래머와의 소통
  • 92. 결국 소통 프로그래머가 일반적으로 갖춰야 하는 공통 소양 + 게임에 대한 이해 + 비 프로그래머와의 소통 + 동료 프로그래머와의 소통 서로의 발전을 위해 지속적으로 피드백을 요청하고 지속적으로 피드백을 해주는 것 상대의 의도를 적극적으로 파악하고 현실적인 방향으로 갈 수 있도록 도움을 주는 것
  • 93. 발전하는 개발 환경 • 발전하는 도구 • 발전하는 프레임워크 • 점점 게임플레이 프로그래밍이 쉬워지고 있다 → 자동화 되고 있다 • 이럴 때일 수록 내 경쟁력을 챙겨야 한다
  • 94. 게임플레이 프로그래머 = 소통 스페셜리스트 동료와의 소통은 내 업무시간을 빼앗는 행위가 아니고 내 업무 범위 안의 일이면서 내가 성장하는 길이다