지금 게임 구조가 논리영역, UI영역이 분리되어서 진행됨. 실제 게임진행은 논리영역에서 진행되고 UI영역은 논리영역의 정보를 받아서 출력하는 역할만 함
여기서 예를들어 맵을 이동했을때 맵을 새로 그리는 함수는 어디서 호출해야 할까?
1. 맵 UI객체에 논리영역 참조를 담아놨다가 맵이 변화하면 감지해서 호출
2. 맵 변동이 발생할때 논리영역에서 새로고침이 필요한 모든 부분에 Dirty 플래그를 넣어서 호출유도
1번 하다보니까 점점 출력중인 UI가 많아지면서 중앙관리가 안돼서 스파게티가 되어가는중인데 이거 맞나
그렇다고 업데이트 필요한 부분을 일일히 정해주는게 1번보다 딱히 깔끔할것 같지는 않은데...
1, 2번 섞여있어서 이미 감당안되기 직전이라 지금 교통정리 딱 해야될거같다
논리영역? - dc App
그러니까 안보이는 부분에서 코드상으로만 게임이 진행되는 영역을 임의로 칭한거. UI는 그 진행정보를 받아와서 불러오는 역할만 하는데 본문에 적힌 UI영역이 이부분을 말한 것. '유저 입력 -> 게임 진행 -> 진행 정보를 화면에 표시' 사이클로 돌아가고 있음
아하.. 2번에서 갱신 요청만 모아서 한군데 받아놓고 플레이어 눈에 보이기 전에 한번만 갱신하면 되지 않을까 말로는 쉬운데 크흠 - dc App
아니 순간 내가 이런 질문을 올렸던가? 했네ㄷㄷ 완전 비슷한 고민하고 있네. 나도 지금 1번 방향으로 하다가 문제가 생긴게, 참조해야되는 구조가 좀 복잡해서 매 루프마다 체크하니까 퍼포먼스 이슈가 생겼는데, 그렇다고 주기적으로만 체크하자니 UI 반응성이 이상해지고, 2번쪽으로 싹다 갈아 엎는게 맞나 고민하고 있음. 실제 변화 지정하는 메서드 같은 것 싹다 UI쪽에만 몰고 그거 호출하고 처리는 화면 그리기 전에 하는식으로 하면 깔끔해지지 않을까 기대하고 있었는데 어차피 이쪽으로 하면 적당히 일일이 뭐 바꿀지 다 지정하진 않고 적당히 묶어줘도 되니까. 사실 1번쪽도 제대로 코드만 짜면 문제 없긴 할텐데 그거 정리하는거 자체가 뭔가 스파게티 되는 느낌이라... 나도 이거 뭐가 효율적일지 궁금하네 - dc App
어...? 퍼포먼스 부분은 전혀 고려 안하고 있었는데... 단순 if체크 중첩만으로 유의미한 부하가 걸림?
아 쓸데없는 소리기는 했음 if 중첩이 문제가 아니라 ui중 몇몇개가 띄우는데 참조하는 자료가 구조가 복잡해서 그거 변했나 매 루프마다 직접 읽어오면서 생기는 문제라서... 애당초 틀려먹은 구존거고 이건, 어차피 참조할 정리된 값 따로 논리구조에서 정리해서 바뀌었는지 던져주는거면 그거 값 바뀔 때 dirty 플래그 처리도 되는거로 통일하는게 더 깔끔하겠다 싶어서 2번으로 가는거 생각하고 있었음 - dc App
선택지 중에 골라야 한다면 2번으로 구현하면 됨. 왜 새로고침을 해야 하고 개별 관리하는진 모르겠지만 싹 날리고 모두 다시 그려. UI랑 Map 그려주는 로직 같다는 의미인가?
그러니까 방치형 게임을 예로 들면 전투 행동을 코드로 계산하고, 데미지 표기나 애니메이션,아이템 획득 등의 이미지를 출력하는 걸 말하는거지? 여러 지역에 파티를 파견보내 동시에 많은 전투를 하고, 실황을 확인하기 위해 해당 지역 선택 시 전투 화면 출력 전투 진행 실시간 화면 출력 출력 화면 정보 갱신 으로 나눈 뒤
전투 진행에서 전투를 진행하되, 실시간으로 처리하지 않아도 되는 부분을 스킵하고, 출력 화면 정보 갱신 부분에서 아이템 드롭이나 데미지 표기 등 실시간 화면 출력의 값을 자연스럽게 기획하면 될거같음
스크립트 간의 데이터 관리를 효율적으로,유연하기 위해 공통된 인터페이스를 사용하는 것도 추천함