확고해진 방향성

저번에 키우기 게임으로 방향을 확실히 잡았더니 기획이 간편해졌다.

지도 확장, 그리고 직원 수집과 육성 두 가지 키워드에 맞추어 머리를 열심히 굴리니 얼추 필요한 부분들의 메커니즘이 완성된 것 같다.

그리고 UML으로 주요 클래스들의 참조 관계도를 그려봤다.

아마도 개발 도중 많은 추가와 변경이 생기는 것을 막을 순 없겠지만 최대한 줄여보기 위해 힘썼다.

 

참 단순한 것 같지만 내가 제일 중독됐었던 게임인 "cell to sinqularity"라는 게임을 생각해 보면 사람을 사로잡을 수 있는 방법이 복잡한 메커니즘뿐은 아닐 거라 생각한다.

 

어찌 됐든 조미료는 프로토타입이 나온 뒤 치도록 하고 구상 단계는 이쯤에서 멈추기로 하였다.

 

 

 

계획을 세우자

이대로 개발을 시작하려다 여전히 체계가 부족하다는 느낌이 들더라.

큰 틀은 잡았지만 클래스 하나하나를 어떻게 짤 것인지에 대해 고민이 많아졌다.

 

(난 우선 레벨업 기능부터 넣으려고 했는데 그거 하나 하는 데 생각해 보니 UI를 다루는 클래스를 또 생성해야 하고 그럼 그리드 뷰에서 눌린 직원 객체를 EmployeePresenter로 보내야 할 것이고... 역으로 이 UI를 초기화할 때는 EmployeePresenter가 보유 직원 리스트를 보내줘야 하겠구나 뭐 그런... )

 

그래서 일단 언제 어디까지 구현할 것인지에 대해 일정을 잡고 그 날 구현할 부분에 대해 브레인스토밍 하는 시간을 갖고 개발에 들어가는 게 좋겠구나 싶었다.

 

 

일단 프로토타입을 만드는 것을 목표로 했다.

너무 빡빡하게 잡지 않았나 생각이 들지만 아마 어차피 얼마 안 가 수정해야 할 것이다.

내가 빼먹은 기능이 있을테니까.

 

 

계획을 세우면서도 UML이 계속 바뀌는 것을 보면 분명 그럴 것이다.

 

 

 

오늘의 회고

그림 그리는 거 어떡하지.

일단 이게 제일 큰 고민이다.

 

코딩 한 부분을 전혀 올리지 않았으나 안한 건 아니고, UML을 클래스에 그대로 옮겨넣는 부분 정도만 작성했다.

 

그리고 레벨, 랭크, 등급, 한계초월 같은 부분을 int로도 할 수 있겠으나 오류 방지와 직관성을 위해 enum으로 따로 만들어 놨는데 이게 과연 괜찮을지 고민이다.

namespace Enums
{
    public enum Grade
    {
        none,

        star1,
        star2,
        star3,
        star4,
        star5,
        star6,
    }

    public enum Level
    {
        none,

        newcomer,
        beginner,
        faithful,
        expert,
        excellent,
        elite,
        master,
    }

    public enum Rank
    {
        none,

        employee,
        manager,
        owner,
    }

    public enum Limit
    {
        none,

        limit1,
        limit2,
        limit3,
        limit4,
        limit5,
    }
}

 

뭔가 좋은 참고 자료가 없을까?

 

그리고 Character 클래스를 스크립터블 오브젝트로 만들었는데, 나중에는 csv 파일을 이용해 정보를 가져오는 것으로 변경하고 싶다.

+ Recent posts