180bpm

UI 구조 및 작업 방침. (작성중) 본문

Develop/Unity

UI 구조 및 작업 방침. (작성중)

powdersnow 2018. 3. 20. 17:58

현 프로젝트에서 생겼던 문제들을 기록하고 그에 대한 대응 제시


  1. 이벤트 처리
    1. 현프로젝트의 제일 큰 문제점은 이벤트 처리 방침이 불분명하다는 점이다.
      명확한 가이드가 없어서 대부분의 코드가 싱글턴패턴으로 이벤트 처리를 하고 있는데 이에 따른 문제는 다음과 같다.일전에 썼던 포스팅과 중복됨 ( http://180bpm.tistory.com/138 )
      1. 스파게티 코드
        1.  상호참조는 기본, 클래스가 분리되지 않음
      2. 메모리 누수
        1. Unity.의 사양중 하나인 "start 시점을 포함한 이전 시점에서 gameobject가 deactive가 된경우 ondestroy가 발생 안함" 때문에 ondestroy에서 싱글턴 해제 코드를 넣었다고 하더라도 동작 안함. 이로 인한 메모리
      3. MVC의 분리가 되지 않음. 모듈화가 불가능
        1. 한 CS 파일이 6000줄 가까이 넘어가버리는 경우가 생김.  비슷한 기능을 추가하려면 또 C/V 해야함.
      4. 각각의 기능에 접근하기 위한 레퍼런스 카운트가 깊어짐.
        1. ex) int value = WorldData.instance.myData.inventoryData.slotlist[0].value;
    2. 지킬점 & 대안
      1. OOP 개념 철저 준수
        1. 은닉, 상속, 동적바인딩만 지켜도 충분할거같은데..
      2. eventListener
        1. 사실 각각의 클래스가 서로를 알고 있을 필요는 없어야 한다. 알게 되는 순간 은닉이 깨짐
           정 애매하면 옵저버 한개만 알고 있게 하거나..
        2. 이렇게 되면 은닉도 성립
      3. 제발..확장을 염두합시다
        1. 절대라는건 없습니다 feat.짜쟌맨
          1. 서버야 어떨지 모르겠지만..우리는 확장성있게 짠다고 뭐 죽는것도 아닌데..
            1. 유지보수와 기능추가를 염두해둡시다 제발
        2. strict한 이름은 좀..
          1. 게임의 장비아이템이 sword만 있다고 swordData 이렇게 하지 맙시둥..
            1. 저렇게 이름 지으면 작업하면서도 나도 모르게 고정관념이 박혀버림. 그럼 코드가 확장이 어려워지게 짜여짐.
        3. 기획이 이상한걸 부탁하는건 아니잖아요
          1. sword만 있는상태에서 게임의 재미와 컨텐츠 확장을 위해 armor를 추가한다고 하자.
            "처음 기획때 절대 안변한다고 하지 않았냐. 변경은 못하겠다." 이러지 마십시다..
            솔직히 좀 실력없어 보이고 무책임하고 모잘라보였음.
      4. 데이터는 그냥 다 비슷하자넝..ㅎㅎ
        1. 멍게소리일수도 있지만 모바일 게임에서의 캐릭터/아이템데이터는 거의 비슷하다
          tableid, name, type, iconname..etc
          같은 데이터는 묶고 상속받아서 각각의 추가데이터를 들고 있게 하자.
          기껏 만들었는데 잘 안씀..
      5. 데이터는 컨트롤러가 주입
        1. 아 이건 좀 애매하다.. 이전 코드들 보고 나은 방법을 찾기로
      6. 변수 선언부에서 값 넣지 않도록
        1. AS3때도 피봤는데.. 이번 엔진 업데이트에서도 피봤다
          변수 선언시점에 엔진에서 쓰는 상수/변수 사용시 런타임 오류남.
          런타임 오류라서 해결하기 더 까다롭다..
    1. sudocode

      using NobDefine;
      using System.Collections.Generic;
      using UnityEngine;
       
      public class uiManager : MonoBehaviour
      {
          // 이벤트 리스너 리스트
          private List<Listener> Listeners;
          
          // 씬 변경시 UI 생성
          private void SceneChange()
          {
              // 가진 리스너 초기화
              Listeners.Clear();
              for (int i = 0; i < createdUI; i++)
              {
                  createdUI[i].release();
              }
              createdUI.clear();
       
       
              // 
              List<uiData> uiDatas = GetUIdata(SceneType.Lobby);
              for (int i = 0; i < uiDatas; i++)
              {
                  UI createdUI = createUI(uidata);
                  Listeners.Add(createdUI.init());
                  list<UI>.add(createdUI);
              }
          }
      }
      

      이거도 정리되면 다시..

  1. 아틀라스 관리
    1. 그냥 다 쪼개버렸으면 좋겠다..

    2. common UI를 권장
      1. 제발 특별한 버튼은 좀..
    3. ngui? ugui?
      1. 이건 판단 불가.
  2. 기능
    1. 무한스크롤링
      1. 우리 슬롯만 몇천개 만들어지는거같은데..
    2. 공통된 폼
      1. 폼을 공통되게 가져가야 UI간 호환이 쉬워진다
      2. 같은 UI Instantiate 하지 맙시다..

3. 문제된점

1. 스크롤링 리스트

개선을 위해 내부에서 선택되고 외부에서는 선택된 리스트만 받게 했는데

이경우 리스트를 쓰는 외부 UI에서 선택 제어가 필요한 경우가 생김. 지금은 임시방편으로 외부UI에 데이터 들고 있게 하기->선택취소->유저 선택에 따라 재선택

시키고 있는데 이거 문제 있음.


Comments