아키텍처, 성능 및 게임
sw 아키텍처
- 코드를 구성하는것이 중요.
- 저자에게 좋은 디자인이란, 변경한 부분을 더해도, 프로그램 전체가 그를 예상하고 작성된 것처럼 만들어진 것
- 아키텍처는 변화하고, 누군가는 코드베이스를 수정해야한다.
- 좋은 디자인은 변경사항을 쉽게 수용한다.
변경
- 코드를 변경하려면, 기존 코드가 수행하는 작업을 이해해야한다.
- 전체를 알 필요는 없지만 관련된 부분은 전부 이해해야함.
- 이 부분이 프로그래밍에서 가장 시간이 많이 걸리는 부분
- 올바른 문맥을 모두 파악한 후, 솔루션을 파악해야한다.
- 코드를 작성하고, 테스트를 작성하고, 코드 검토하기전 몇가지 정리 작업을 수행해야한다.
디커플링
- sw 아키텍처의 대부분은 학습 단계에 관한것이다.
- 코드 전체 부분을 이해하는데 더 빠르게하기 위한것.(코드의 양을 줄이는것)
- 분리: 두 개의 코드가 결합되면, 다른 하나를 이해하지 않고는 하나를 이해할 수 없다.
- 분리하면, 독립적으로 추론 가능, 한 부분만 관련된 경우, 그 부분만 이해하면된다.
- 저자의 sw아키텍처의 핵심목표: 진행하기전에 필요한 지식의 양을 최소화하는것.
- 디커플링의 또 다른 정의: 코드의 한 부분에 대한 변경이 다른 부분에 대한 변경을 필요로 하지 않는다는것.
- 커플링이 적으면, 나머지 부분을 덜 변경할 수 있다.
비용
- 추상화, 모듈화, 디자인패턴, 소프트웨어 아키텍처: 생산성에 큰차이를 만들어줌
- 노력과 훈련이 필요
- 어떤 부분을 분리해야하는지 생각해야하고, 해당 지점에 추상화를 도입해야함.
- 확장성을 엔지니어링해야하는 위치를 결정해야함
- 이는 추측으로 이루어져, 여러 코드를 추가하게됨.
- 미래를 예측하는 것은 어렵고, 모듈화가 도움이 되지 않으면 해가된다.
- 더 많은 코드를 처리해야되는 상황이 일어남
- 무언가를 수행하는 실제 코드를 찾기 위해 모든 스캐폴딩을 추적해야함.
성능 및 속도
- 게임 성능이 저하: 가상 디스패치, 인터페이스, 포인터, 메시지 등은 런타임 비용이 있는 기타 메커니즘에 의존한다.
- 유연성: 변경하는 양을 줄이기 위한것.
더 빨리 프로토타입을 만들 수 있도록, 프로그램을 더 유연하게 만들면 성능 비용이 약간든다. (코드를 최적화하면 유연성이 떨어짐)
- 재미있는 게임을 빠르게 만드는것이 더 쉽다.
- 디자인이 안정될 때까지 코드를 유연하게 유지하고, 나중에 성능을 향상시키기 위해 일부 추상화를 제거하는것
나쁜 코드의 좋은점
- 게임 디자인은 많은 실험과 탐색이 필요
- 초기에는 버릴 것을 알고 있는 코드를 작성하는것이 일반적
- 게임플레이 아이디어가 작동하는게 우선.
- 프로토타이핑 주의사항
- 폐기코드를 작성하는 경우, 폐기할 수 있는지 확인해야함. -폐기코드를 사용하는것은 유지관리 할 수 없다는것을 의미하고, 다시 작성할 필요가 있다는것을 알아야함.
실제 코드가 될 필요가 없도록하는 방법: 다른 언어로 작성하는것
균형잡기
- 프로젝트 생명주기 동안 코드를 더 쉽게 이해할 수 있는 멋진 아키텍처
- 빠른 런타임 성능
- 단기 개발속도
- 위의 목표들은 부분적으로 반비례한다.
- 좋은 아키텍처는 장기적으로 생산성을 향상, 하지만 이를 유지하기위한 비용이든다.
- 빠른 개발과 성능은 둘다 잡기 힘들다. 최적화에는 상당한 엔지니어링 시간이 걸린다.(고도로 최적화된 코드는 유연하지 않고, 변경하기 쉽지않다.)
- 빠른 개발은 코드베이스를 엉망으로 만들 가능성이 있다.
절충이 중요.
- 잘못된 게임디자인: 한가지 승리 전술로 무너짐.
단순함
- 제약을 완화하는 방법
- 데이터 구조와 알고리즘을 올바르게 얻은 다음 거기에서 시작하는것.
- 단순하면 전체적인 코드가 적다.
- 오버헤드가 적고, 실행할 코드가 적어 성능이 좋다.(항상 그런것이 아님, 루프 나 재귀등)
- 좋은 솔루션은 코드의 추가(an accretion of code)가 아니라 코드의 증류(a distillation of code)
- 정신적 노력이 가장 적게 드는 솔루션은 해당 사용 사례를 한 번에 하나씩 코딩하는 것.
조언
추상화 및 분리는 프로그램을 더 빠르고 쉽게 발전시킴, 하지만 문제의 코드에 이러한 유연성이 필요하다고 확신하지 않는한 시간을 낭비하게함.
개발 주기 전반에 걸처 성능에 대해 생각하고 설계하되, 가능한 늦게 까지 코드에 가정을 잠그는 저수준의 핵심 최적화를 미뤄야한다.
게임의 디자인 공간을 탐색하기 위해 빠르게 움직이되, 너무 빨리 움직이지 말아야한다.(Move quickly to explore your game’s design space, but don’t go so fast that you leave a mess behind you.)
버리는 코드를 작성하는 경우 예쁘게 만드는데 시간을 낭비하지 않아야한다.