처음에는 인벤토리의 기능을 모두 공용으로 쓰려했고기능의 낭비가 많아 창고 부모 클래스와 인벤토리 자식 클래스를MVC로 나눠서 제작했다. 그래서 창고 클래스를 NPC역할을 하는 모든 것들에게 부착하고공용으로 사용하려 했지만 정말 당연하게도 문제가 발생했다.NPC는 UI를 사용하지 않는데 창고 클래스의 컨트롤러에서는 UI 정보를 받고있고모델에서는 Refresh 메서드로 UI를 계속 갱신하고 있다. 따라서 오늘 팀원과 회의를 하면서 NPC가 가지는 보관함 기능을 독립적으로 제작 할지아니면 창고와 인벤토리 클래스를 자식으로 넣고 순수히 아이템의 추가, 삭제의 기능만가지는 상위 부모 컨트롤러 클래스를 제작할지에 대해 이야기 했다. 내 의견은 상속을 하는건 그 자체로 기능의 변경에서 이로움이 있지만너무 많은 기능들..
프로젝트 기록/Project N
아이템 소모 기능 자체는 만들기 어렵지 않았지만 구조적으로 기능들을 어떤 곳에 넣어야 할지 고민을 많이 했다. 우선 대략적인 호출 순서를 적어보자면 동작에 의해 실행되는 부분 -> 인벤토리 컨트롤러의 아이템 소모 메서드 -> 인벤토리 모델의 아이템 소모 메서드 -> 아이템 패널의 실질적 소모 메서드 이런 형식으로 진행된다. 동작에 의해 실행되는 부분은 유저의 정보를 불러오고 있었고 정보 클래스에는 인벤토리의 정보가 들어있었다. 그래서 인벤토리에 쉽게 접근할 수 있었고 기능을 연결하도록 제작했다. 1. 동작에 의해 실행되는 부분 public class Consume : ItemFunction { public override void execute(GameObject user) { if (user.TryGe..
현재 만들고 있는 창고의 구도는 다음과 같다. 1. 아이템을 보관할 창고 공간 2. 인벤토리의 아이템 리스트를 불러올 창고 공간 이런 형식으로 인벤토리의 아이템을 관리할 예정이다. 이를 위해선 인벤토리의 정보가 필요했고 마침 캐릭터가 빌드 될 때 인벤토리의 객체 정보를 가지면서 생성됐다. 그래서 창고와 상호작용을 함과 동시에 캐릭터의 객체 정보를 넘겨줘야 했기 때문에 우선 창고 클래스에 상호작용 인터페이스를 적용했고 PlayerInput 쪽에 상호작용 키를 담당하는 부분에서 캐릭터 정보를 넘기도록 했다. 1. PlayerInput public override async void OnInteractionAsync(InputAction.CallbackContext callbackContext) { if (!..
인벤토리를 MVC패턴으로 나누고 기능의 배분도 명확해졌기 때문에 인벤토리의 기능을 물려받는 창고를 제작하려고 했다. 하지만 여기서 간과한 점이 있었는데 인벤토리는 창고와 비슷한 기능을 하는 것 처럼 보이지만 결국 다른 기능을 하고 있었다. 예를 들어, 인벤토리의 기능을 창고가 그대로 물려받는다면 창고는 퀵슬롯의 기능, 아이템의 장착 여부, 아이템 사용 등 사용하지 않는 기능의 코드가 많아져 가독성과 클래스의 명확성이 확 떨어질 것이다. 그리고 현재 만드는 게임은 AI 캐릭터가 농사와 사냥 등을 해주는 게임이고 AI 캐릭터가 빌드되는 스크립트에 얻은 아이템을 저장할 창고 객체를 생성해야 하는데, 만약 AI 캐릭터가 100개 늘어난다면 불필요한 코드도 100개만큼 늘어난다. 그래서 AI 캐릭터와 창고가 사용..
며칠전에 UI를 UIPopup, UIBase, UIManager의 구조로 각각 어떤 기능이 들어가면 좋을지 적어봤었다. 그래서 오늘은 이를 토대로 UI 관련 스크립트를 제작했고 현재 어떤 부분이 어떤 기능을 하는지 적어보며 회고하려한다. 1. UI_Base public class UI_Base : MonoBehaviour { protected bool _init = false; public virtual bool Init() { if (_init) return false; return _init = true; } private void Start() { if (_init) return; Init(); } } UI_Base에는 UI들이 기본적으로 가지고 있어야 할 공통적인 기능들을 넣고자했다. 먼저 생각났..
이번에 진행하는 팀 프로젝트에서 UIManager를 제작하게 되었다. 다른 사람들과 프로젝트를 진행하면서 UIManager를 항상 사용하는 입장이어서 대략적인 이유와 사용법은 알지만 제작하는 입장을 생각해 보니 이를 왜 만들고 어떤 구조로 제작해야 하는지 감이 안 잡혔다. 따라서 UIManager를 왜 제작해야 하며 이를 통해 얻을 수 있는 장점을 알아보고자 한다. 1. UIManager가 뭘까? 유니티에서 주로 특정 기능을 주로 담당하는 스크립트를 주요기능 + Manager 형식의 이름으로 제작하곤 한다. 그럼 UIManager는 오로지 UI를 관리하기 위해 제작하는 스크립트라고 할 수 있다. 요약하자면 유니티 프로젝트에서 UI요소들을 관리하고 제어하기 위해 제작하는 기능이다. 2. UIManager의..
오늘은 어제 정리한 MVC 패턴 글을 참고하여 인벤토리의 기능을 구조화했다. 1. 기존 인벤토리 코드 using System.Collections; using System.Collections.Generic; using UnityEngine; using System.Linq; using System; using UnityEngine.UI; using static TMPro.SpriteAssetUtilities.TexturePacker_JsonArray; public class Inventory : MonoBehaviour { [SerializeReference] public List items = new List(); [Space] [Header("Inventory Menu Components")] [S..
프로젝트에서 인벤토리의 기능들을 어느정도 완료하고 팀원들과 회의를 하던 도중 인벤토리를 MVC패턴으로 구조화 하면 좋을 것 같다는 요청이 있어서 실행해보려고 한다. 하지만 MVC패턴에 대한 개념과 이를 왜 쓰는지 이유를 정확히 알아야 구현과 유지보수에 있어서 흔들리지 않을 것이다. 그럼 MVC패턴이 무엇인지 살펴보자. 1. MVC(Model-View-Controller) MVC란 모델, 뷰, 컨트롤러로 영역을 나눠서 기능을 담당하는 패턴이다. Model 모델에서는 게임의 데이터, 데이터의 처리, 비즈니스 로직을 담당한다. 비즈니스 로직이란 어떻게 데이터가 생성되고 저장되고 수정되는지를 정의한다. 이말인 즉, 게임의 로직은 들어가면 안되며 비즈니스적인 로직만 담당해야 한다. View 뷰에서는 영어 뜻 그대..
