부트캠프/본캠프

[내일배움캠프_2025AUG26] 3D 방치형 RPG Idle Adventure 1일차 + 팀의 위기..

Young_A 2025. 8. 26. 23:35

목차

    3D 방치형 RPG: Idle Adventure 1일차 + 팀의 위기..

    인벤토리와 3D 방치형 RPG 중에 후자를 진행하려고 한다.

     

    우선 지난 팀플에서 비슷한 부분을 맡아본 적도 있고, UI 같은 부분을 다듬으면 좋을 것 같긴 하지만!

    게임을 게임답게 만들어주는 중요한 요소인 플레이어나 적과 같은 로직을 스스로 구현해내고 싶은 마음이 있다.

     

    그래서 3D 너~무 싫고, 조금 어려울지도 모르지만 도전해보려고 한다.


    Finite State Machine (FSM)

    플레이어를 직접 조종하는 것이 아니니, 적(Enemy)의 AI를 짜는 것처럼 상태를 나누어 진행하도록 해야했다.

    유한 상태 머신(Finite State Machine)을 채택하여 캐릭터의 행동을 유한한 상태(Idle, Move, Attack)으로 나누고, 각 상태에 따라 다른 행동을 정의했다.

    복잡한 행동 로직을 깔끔하게 분리하여 관리하는 데 효과적인 것 같다.

    public class PlayerMovementController : MonoBehaviour
    {
        [Header("Configuration")]
        public float moveSpeed = 5f;
        public float attackRange = 2f;
        public float rotationSpeed = 5f;
        public Transform targetEnemy;
    
        private PlayerState currentState = PlayerState.Move;
        private Rigidbody _rigidbody;
        private PlayerAttackController attackController;
    
        void Start()
        {
    				//...중략...//
        }
    
        private void FixedUpdate()  //rigidbody 
        {
            switch (currentState)
            {
                case PlayerState.Idle:
    				//...중략...//
                    break;
                case PlayerState.Move:
    				//...중략...//
                    break;
                case PlayerState.Attack:
    				//...중략...//
                    break;
            }
        }
    }

     

    다만 이후 EnemyController를 작성하는데, 방치형 게임이라 플레이어를 직접 조작할 일이 없어서 그런지 PlayerMovementController와 중복되는 부분들이 꽤 있는 것 같다.

    그렇기 때문에 둘 다 MovementController로 통합하여 진행해도 되지 않을까? 하는 생각도 든다.

    하지만 EnemyController는 MovementController와 Condition을 나눠서 관리하진 않을 예정이라 일단은 이대로 진행하기로 했다.


    코드 응집성에 대한 고민

    이전 과제와 비슷하게 일단은 IDamagable 인터페이스를 상속 받는 방식으로 PlayerCondition과 EnemyController를 구현했다.

    다만 Player는 MovementController, Condition, 등 기능별로 스크립트가 쪼개지는 것에 반해 Enemy는 단일 컨트롤러로 구현하게 될 것 같아서 조금 헷갈릴 여지는 있을지도 모르겠다.

    FSM 구현에 있어서 EnemyController를 쪼개야 할까...? 하고 고민했던 것과 겹치는 부분이라 EnemyController를 단일로 가져가는 것이 옳을까 하는 생각이 들지만!

    코드의 응집성을 높히는 방향으로 진행해보려고 한다.

     

    응집성은 한 클래스나 모듈의 기능이 얼마나 밀접하게 관련되어 있는가를 나타내는 척도이다.

    관련 기능이 한 곳에 모여 있을수록 응집도가 높다고 말한다.

    응집도가 높은 코드는 이해하고 유지보수하기 쉽다.

     

    적의 이동(찾기, 이동, 공격)과 컨디션, 추후 개발할 재화/경험치/(아이템) 정보 정도만 들고 있을테고,

    각 기능들이 더 발전시키거나 고도화하지 않을 것 같아서...

    굳이 스크립트를 쪼개어 서로를 참조하며 Coupling을 높이는 것보다는 나을 것 같다는 생각도 든다.

     

    일단 계속 구현을 해보면서 지켜보는 걸로... to be continued...


    느낀점

    오늘 갑자기 폭탄이 떨어졌다...

    8시부터 한시간 가량 열심히 게임 기획 스크럼을 갖고 팀 프로젝트에 대한 기대감과 함께 TIL을 쓰려고 티스토리를 켰는데..

    9시 16분.. 갑자기 팀원 중 한분이 하차 통보를 하시고 사라지셨다.

    기획 스크럼 때 적극적으로 의견을 내지 않으셔서.. 아 개발에 의욕이 없으신가보다 라는 의심은 했지만 하차까지 하실줄이야.

     

    마침 튜터님이 지나가셔서 하소연을 하느라 어떻게 진행하는 것이 나을지에 대해서 팀원들의 의견을 들어보니,

    다들 이 팀을 찢는 것도 많이 아쉬울 것 같고, 그렇다고 다른 팀에서 팀원을 차출하자니 그 분들께 미안하고.

    일단은 우리끼리 진행을 해보는 방향으로 갔으면 하는 것 같았다.

     

    자세한건 내일 매니저님들과 상의를 한 후 결정되겠고, 이 인원으로 진행하는 것도 걱정이 많이 되지만...

    아무튼 우리 팀원들 다들 성격이 좋고 커뮤니케이션에도 적극적이니 같이 팀 프로젝트를 계속해서 진행할 수 있었으면 좋겠다.


    내일 학습 할 것은 무엇인지

    체력과 골드 재화에 관한 UI를 간단하게 만든 뒤 통화 시스템을 구축할 예정이다.

    전투 중 사용할 수 있는 아이템(체력회복)을 위한 UI Slot과, 캐릭터를 업그레이드하거나 아이템을 구매/장착할 수 있는 상점 시스템까지 구현하고 싶다.

    근데 이 부분은 UI를 어떻게 짜면 좋을지 고민이 된다.... 흠... 너무 설계 없이 뛰어들었나.