[내일배움캠프_2025AUG29] Idle Adventure 제출, 구조에 대한 아이디어

Idle Adventure 제출, 구조에 대한 아이디어

---

3D 방치형 게임 Idle Adventure 제출

과제 제출하면서 적은 구구절절문

 

이전 팀 프로젝트에서 인벤토리를 경험했기 때문에, 이번에는 새로운 도전으로 방치형 게임을 선택했습니다.
프로젝트 완성에 대한 불확실성을 감수하고 시작했지만, 끝내 완성을 하지 못하게 되어 아쉬움이 큽니다.

방치형 게임에 대한 경험 부족으로 핵심 구조, 특히 인벤토리 같은 시스템에 대한 명확한 아이디어가 없었습니다.
이 때문에 개발 과정에서 구조를 계속 뒤집느라 예상보다 많은 시간이 소모되었고 결국 완성을 하지 못했습니다.

본래 프로젝트 시작 전에 유사 게임을 분석하며 구조를 설계했어야 했지만,
이번에는 '일단 구현부터 해보자'는 생각으로 기능별로 하나씩 추가하는 방식을 택했습니다.
이는 그동안 초기 설계에 지나치게 많은 시간을 쏟다가 결국 계획이 변경되어 비효율적이었던 경험 때문이었습니다.

이번 과제를 통해 초기 설계의 중요성을 다시 한번 뼈저리게 느꼈습니다.

---

Rider 사용

팀원분이 다른 튜터님께 Rider를 추천받아서 사용하고 계신데 괜찮은 것 같다고 하셔서 바로 다운로드 받았다.

 

위와 같이 비용이 높은 경우 경고를 해주는 부분이 제일 마음에 든다.

또한 private public 접근자 추천을 해준다거나, 변수명 추천 등등의 기능도 있다고 한다.

학습의 목적이라면 별로일 수도 있으나, 속도를 향상시키기에는 좋을 것 같다.

이번 팀 프로젝트는 2인으로 빠르게 진행해야하니 최종 프로젝트 때 사용할 수 있을지 없을지를 이번 팀 프로젝트를 진행하면서 테스트해본다는 느낌으로 일주일 정도 사용해보려고 한다.

참고

https://com789.tistory.com/2

---

제네릭 싱글톤

제네릭 싱글톤을 만들어두면 확실히 편하게 할 수 있을 것 같아서 구현했다.

하단의 링크를 많이 참고했다.

 

Instance 프로퍼티가 호출될 때 비로소 싱글턴의 생성이 이루어지는 게으른 초기화가 구현되었다고 한다.

즉시 초기화(Eager Initialization) vs 게으른 초기화 (Lazy Initialization)

즉시 초기화는 프로그램이 시작될 때 모든 객체를 미리 만들어 놓는 방식이다.

게으른 초기화는 객체가 처음으로 호출되는 시점에 생성하는 방식이다.

 

게으른 초기화 방식을 사용하는 경우 초기화 순서를 보장하기 좋을 것 같다는 생각이 든다.

또한 게임 시작 순간에 모든 객체들이 미리 생성되는 것을 방지하고 필요한 시점에만 초기화하므로 메모리 효율성에도 좋지 않을까?

참고

https://seoksii.tistory.com/83

 

---

느낀점

오늘 튜터님과 다른 팀원과 진대를 하면서 프로젝트 시작단계에서 어떻게 하면 좋을지에 대한 조언을 많이 들었다.

역할을 플레이어/배틀, 아이템/조합/상점으로 나누어서 진행하려고 했다~ 고 말씀드리니

프로젝트를 시작하기 전에 UI프레임워크/게임플로우/게임로직을 위해 작업을 분배해서 먼저 진행하는 점에 대해서 조언해주셨다.

 

팀원 한 명이 줄었지만... 의욕 없는 팀원이 있는 것보단, 이렇게까지 꼼꼼하게 챙겨주시는 튜터님이 계신게 더 개이득이 아닐까? 싶을 정도.

메모

자신이 맡은 파트에 대한 구조를 짜야함.

1. UI 프레임워크 제작
2. 게임 기본 플로우. 시작(인트로)-셋팅(여러 매니저들 이니셜라이즈)
스타트매니저 State 패턴 인트로, 타이틀, 로딩, 메인 등 사이마다 정해진 작업 진행.
3. 게임 로직 설계. (게임매니저, 데이터매니저)

---

내일 학습 할 것은 무엇인지

내일은 놀러가서! 놀러가기 전에 스타트매니저를 상태패턴을 적용해서 구현해보고 싶다. 

일요일은 약속이 있지만! 오전 저녁 시간이 남으니까 게임 기본 플로우와 게임 로직(게임매니저)쪽을 진행하면 좋을 것 같다.