지금 본인이 하는 일이

"께임" 개발자 인지

게임 "개발자" 인지

구분 잘해야함

이 게임을 어떻게 재미있게 만들지? 몬스터 나오는 타이밍을 바꿔볼까 아이템 위치가 문제인가? 등으로

고민 하는게 아니라

최적화가 어쩌고 구조 설계가 저쩌고 하고 있으면

헛다리 짚고 있다는 거지

넌 어차피 계속해서 기능추가를 할 거고 기능이 늘어나니 버그와 최적화 할 것들도 늘어나고

크기가 커지고 달라지니 다시 구조를 설계할 거고...

결국 게임 코딩에 집착하면 영원히 코딩만 하게 되는거고

시간은 썼는데 재미있는 게임은 없고 구조적으로 이쁜 깃허브 포폴하나만 덩그라니 남아있을거야

그리고 그마저도 서류컷때문에 누구 보여줄 일도 없고

앉혀놓고 알고리즘 시키지 깃허브 읊는건 비중도 거의 없거든 취업할때.

돈이 필요해 불안하다면 취업을 해라

본인이 하는 일이 "께임" 만들기 라는 사실을 잊지마

막상 게임을 성공적으로 출시해보고 중상타 처보면 뭘 알게 되냐면

이 완벽한 설계라는 건 게임 업계에서 쓸수 없다는 거임

예를들면 이런거지

완벽한 정규화된 구조대로 딱딱 돌아가는 마인크래프트 인벤토리가 있다고 치자고

근데 기획자가 인벤토리에 아이템을 그림 그리듯 흙블록을 x자로 배치하고 스크린샷 버튼을 누루면

천국 포탈이 열리게 해달라하는거야

개발자는 개좆같지 이 저능아 기획자가 뭔 개말도 안되는걸 시키냐

이제 예외적인 if switch가 존나 들어가면서 코드가 썩창이 될텐데;;;;

근데 게이머 입장에선 이런건 흥미로울 수 있다는 거야

(진짜 저게 좋다는게 아니라 코딩 구조가 깨지는 예시를 든 기능일뿐임)

게이머가 흥미를 느끼는게 중요하지 내 코드가 깨끗한게 중요한게 아니란거야

그래서 재미있게 만들다보면 이 구조라는게 진짜 절대 유지를 못하고 결국 마지막엔

덕지덕지 걸레짝 코드가 되어버림 아무리 처음에 노력했어도.

그러니 성공한 인디 게임들 코드 까보면 goto switch 장애구조 도배로 구현되어있는게

어쩌면 현명했을지도 모르는거야

"유지보수와 인수인계를 포기하는 대신"

"흥미로운 게임 경험"을 위해 기존에 우리가 알던 구조를 깨고

유동적이고 직관적으로 개발할수 있게 고안되었다고 해석 할 수 있는거지

이미 컴싸 잘배운 애들이 원시인처럼 코딩할 필욘 없는데

창의적인 게임을 만들다보면 절대 정석적인 구조는 유지 될 수 없고 

이에 집착해서 게임의 "재미"를 놓치지 마셈