[💬] 게임 프로그래밍 패턴 1

[개발공부(210.179)]

밑에 추천해준 패턴 책을 봤는데 전에 한글판 사서 몇장 읽다가 바쁘다는 핑계로 고이 모셔둔 책이더라고... _-

안그래도 요즘 다시 공부를 좀 해야겠다고 생각하고 있었는데 새해도 됐고 생각난 김에 여기에 조금씩 정리를 해볼 생각임 

챕터 1. 구조, 성능, 게임

> 코드를 고치는 방법

기본 프로세스 : 업무 할당 -> 코드 파악 -> 문제 해결 코드 작성 -> 코드 정리 

- 코드를 수정하려면 기존 코드를 파악하고 전체 그림이 그려지면 수정할 사항을 정리해서 그대로 구현하고 테스트를 하면서 문제 있는 부분을 정리하는 단계를 거침

- 소프트웨어 구조의 많은 부분이 코드 파악 단계와 관련이 있음

- 코드가 서로 여기저기 얽혀 있는 상태라면 조그만 수정을 위해서도 전체 구조를 다 파악해야만 함

- 가능한 코드의 각 부분이 따로 이해할 수 있도록 디커플링 된 상태를 유지하는게 좋음

(*양쪽 코드에서 한쪽이 없으면 다른 쪽을 이해할 수 없을때 커플링 되었다고 표현)

> 유연하고 확장성 있는 코드를 만들기 위한 비용

- 유연한 코드를 만들기 위해 추상화, 모듈화, 디자인 패턴 등을 사용하는데 이러한 부분은 결국 예측에 기반하기에 코드를 추가하고 복잡성을 늘리는 원인이 될 수도 있음

- 다행이 예측이 맞는다면 나중에 작업 시간을 아낄 수 있지만 그렇지 못한 경우 작업량이 늘어나기에 안한것만 못함

- 게임 개발 자체보다 확장성의 환상에 사로잡혀 엔진 개발 자체에 시간을 낭비하는 경우가 많음

> 성능과 속도

- 게임 개발은 반복과 실험의 연속임

- 아이디어를 빠르게 시험해 보고 더 많은 시도해 볼수록 멋진걸 찾을 가능성이 높아짐

- 빠른 개발은 보통 성능을 희생함

- 코드 최적화 시 성능을 올릴 수 있지만 최적화된 코드는 유연성이 떨어짐

- 재미있는 게임을 최적화 하는 것이 최적화 된 게임을 재미있게 만다는 것보다 훨씬 쉬움 

> 나쁜 코드의 장점

- 구조화된 코드를 유지하려면 많은 노력이 필요

- 많은 노력을 들인 코드일지라도 기획이 별로였다고 판단되면 모두 버려질 수도 있음

- 따라서 기획 초기 검증을 위해서는 빠른 프로토타이핑을 추천함

- 버려질 코드는 확실하게 버리고 다시 만들 것

> 균형잡기

1. 간결한 코드와 구조

2. 실행 성능 최적화

3. 빠른 구현

- 위 목표는 서로 상반되는 경우가 많음

- 정답은 없고 오답에 대한 다양한 취향이 있을뿐..

코드 파악하는 방법 관련해서..

회사 플젝처럼 규모가 좀 있는 프로젝트에서 다른 사람이 짠 코드를 수정할 일이 있으면 쓰던 방법인데

전체 구조가 복잡하면 간단한거 하나 수정하려고 해도 생각보다 확인해야할 부분이 많음

그러면 일단 수정해야할 대상 클래스/멤버변수/함수명 등의 네이밍을 하나씩 내 방식으로 다시함

그리고 컴파일을 하면 에러가 우수수 나옴

에러를 따라가면서 하나씩 수정을 하다보면 해당 기능이 사용되는 곳을 대부분 파악할 수 있고 전체 기능도 머리속에 들어옴 

그냥 참조되는 부분 검색해서 눈으로만 살펴보다보면 꼭 놓치는 부분이 생기더라고..

물론 이렇게 네이밍을 바꿔버리면 다른 팀원이 헷갈릴 수 있으니 완전히 자기가 오너쉽을 가져가 경우가 아니라면 다시 원상복귀 해 놓아야함 (그냥 다 revert...)

[잔잔(175.115)]

무슨말하는지 느껴짐 개추박아슴 알파 베타버전 만드는것의 실제를 말한거 맞음?

[잔잔(175.115)]

지레짐작으로 한번에 만들려고하지말고 겪어보고 사실적으로 돌파하는것

[잔잔(175.115)]

마크주커버그도 비슷한말하던뎅

[잔잔(175.115)]

실제 코딩하고 느껴보면 예상치 못한게 분명 튀어나오니까 그걸 해결하면서 가야한다는것

[잔잔(175.115)]

모듈화에 신경쓰는건 이걸 예상하지 못하기 쉽다는말