팀 프로젝트

팀 프로젝트 시작 전 구조 설계가 탄탄히 잡혀있다면 확장하기도 편하고좀더 빠르고 체계적으로 할 수 있지않을까? 라는 생각으로 구조 설계를 하게되었다.전체적으로 코드의 재사용을 줄이는 것과 확장성을 고려하는 것이다. 플레이어Player의 FSM구조 설계플레이어의 데이터를

유한 상태 머신이라고도 불린다. 상태가 다른상태로 전이하는 형식이다.해당 객체의 상태를 세세하게 관리하여 상태의 전이조건이 만족되면 전이시킨다.플레이어의 상태이다. 이 스크립트를 상속받아 상태를 만들 수 있도록 설계되었다.하나하나 살펴보자면Enter()상태가 시작될때

ScriptableObject로 에셋 형태로 아이템의 데이터를 관리하게 하였다.ItemType아이템이 재료인지, 장비인지, 상호작용 타입인지를 판단하기 위해 열거형으로 작성하였다.StringBuilderstring을 자주 수정할 경우에는 StringBuilder을 사용

UI와 게임로직이 직접적으로 연결 될 수 밖에 없는 구조였다.그래서 이를 수정하고자 MVP패턴을 활용하여 수정하기로 하였다.하이어라키 제네릭 타입의 싱글톤을 상속받는 InventoryManager을 만들었다.✧ 사용빈도의 고려Inventory는 아이템 추가, 제거 등이

잠긴 문 등에 필요한 ItemData needItem이 있다. ( 필요없다면 세팅X )foreach로 인벤토리 리스트를 순회하며 만약 아이템이 있다면 기믹을 실행하고아이템이 없다면 실패하였을 때 원하는 기능을 실행한다.정말 간단히 상속받아 문 같은 것들을 구현할 수 있

스텟을 구현하는 것은 크게 어렵지는 않았다.하지만 이 스텟을 어떻게 관리할지가 제대로 판단되지않아 시간이 좀 걸렸다.Stat이란 클래스이고 스텟으로서 쓰일 예정이다.List에 추가능력치를 추가할 수도있고 추가된 능력치를 볼 수도있으며 GetValue함수로 추가 능력치를

원래 싱글톤은 크게 시작될때 바로 생성과 처음 사용될때에 생성이 있다.여기서 문제점은 이 싱글톤들은 생성된 시점부터 사라지지않고 메모리를 차지한다. 그래서 약한참조 싱글톤이 있다.데미지 계산을 static Class로 하였는데 이는 계속 메모리누수가 발생할 수 있어서

먼저 저장할 데이터가 있는 객체에 세이브 인터페이스를 구현한다.세이브 로드 시 모든객체의 세이브 인터페이스를 가져와 순회하며 저장 / 로드 한다.GameData C4. 저장 시 하나의 GameData에 모든 데이터가 저장되길 원하여 ref 키워드를 사용해 GameDat