소규모 개인 게임 회고 - Action의 남용에 대한 반성.

https://github.com/Toaaaa/3D-Idle-Advanture

GitHub - Toaaaa/3D-Idle-Advanture

 

"오늘도 우라라" 레퍼런스 게임을 만들면서,

이전에 여러 장점을 배우게 되고 손에 익은 Action을 여러 상황에 자주 사용하게 되었다.

 

아래와 같은 UI관리 코드를 작성하였고 이후 규모가 커지며 문제가 생겼다.

 

public class UIManager : MonoBehaviour
{
    [SerializeField] AudioSource uiSoundSource;
    [SerializeField] ParticleSystem particle;
    [SerializeField] TextMeshProUGUI goldText;
    [SerializeField] TextMeshProUGUI potionCountText;
    [SerializeField] GameObject playerStatsPanel;
    [SerializeField] GameObject inventoryPanel;
    [SerializeField] GameObject shopPanel;
    public InventoryUI inventoryUI;
    public PlayerEquipment playerEquipment;


    public Action UpdateUIs;
}

 

처음에는 이런 느낌으로 UI와 관련된 모든 UI 상태의 갱신을 UpdateUIs()  하나의 호출을 통해 관리를 하려고 제작하였다.

 

이후 UI가 점점 늘어나고 각종 데이터 관리와 상태 갱신 로직이 복잡해지자, 데이터 흐름을 파악하기 어려워졌고, 곳곳에서 NullReferenceException과 같은 오류가 나타나기 시작했다.

 

마감 기한이 촉박한 상황에서 코드를 전면적으로 개선할 시간은 부족했다. 결국, 기능 구현 자체는 완료했지만, 코드 구조는 스파게티 코드처럼 엉키게 되었고, 만족스러운 결과물을 만들지는 못했다.

 

이 경험을 통해 Action 을 활용하면 여러 기능을 한 번에 호출할 수 있다는 장점이 있지만, 무분별하게 기능을 엮으면 코드의 흐름이 복잡해진다는 점을 깨달았다. 따라서 앞으로는 기능별로 명확히 분류하고, 필요에 따라 모듈화해 관리하는 것이 중요하다는 교훈을 얻었다.