[🐣질문] 개발 고수들 도와줘요!

[Indie(122.40)]

1. 현재 코드가 플레이어가 인벤토리를 가지고 있음

2. 근데 지금 와서 생각해보니 왜 플레이어가 인벤토리를 가지고 있어야 하는가? 라는 생각이 들었음

3. 플레이어는 그냥 조작용 장난감에 불과하다고 생각해서 결국 인벤토리를 누군가가 관리해야 하는데 누가 해야할지 고민임

4. 씬이 관리하기에는 씬도 교체가 되면 자원 해제를 하고 소멸하고 생성하는 과정을 거쳐서 좀 애매함

흠.. 여러분의 코드 설계 방식좀 알려주심 감사하겠습니다

[123번뇌왕(winner0000)]

플레이어가 인벤토리를 가지는게 왜 싫은건지 궁금한데 저장할때 인벤토리 변수를 플레이어가 가지고 있게 되니까 싫은건가

[글쓴 Indie(122.40)]

각 클래스의 쓰임새와 역할의 범위를 고찰하다보니 그런 결론에 이르렀습니다

[츄르도둑(intrigue3985)]

그냥 빈오브젝트 만들어서 거기 인벤토리 넣고, 플레이어는 인벤토리 키는 인풋역할만하고, 인벤토리 오브젝트를 싱글톤으로 바꿔서 다음 씬으로도 그대로 두게하면 안됌?

[123번뇌왕(winner0000)]

개인적으로 저는 이렇게 짬요 플레이어가 저장할때 가지고 있어야 되는 데이터가 있다. 근데 그 플레이어가 몹이나 기타 캐릭터와 비슷하게 데이터를 가지고 있고 좌표, 돈, hp mp 기타 등등 데이터성 값을 가지고 있다 이 데이터들은 CharacterBean으로 묶음 자바식 이름 짓기임 Bean은 콩이라고 하는거고 모델 클래스(데이터류 클래스) 뒤에 관용적으로 붙이는 이름임 ( 혹자는 Info라던가 Data라던가 그런거도 씀 ) 데이터성 클래스는 직렬화 하면 저장 불러오기가 쉬움 제가보기엔 플레이어에 인벤토리가 있는게 싫은건. 인벤토리는 아이템 소지에 대한 '데이터'고 플레이어는 조작을 하는 컨트롤러로 쓰고 계신거 같음. 이 상황에서 캐릭터 컨트롤러와 캐릭터 빈을 분리할수가 있음 근데 이런식으로 분리하면

[123번뇌왕(winner0000)]

코드가 길어지고 귀찮아서 그냥 합쳐서 쓰는 사람도 있음 개인전으론 엔진 ( 고도, 유니티 ) 등에 의존하는 입출력 받거나 화면에 그려지는것은 Actor라고 부르거나 그게 사용자 입력을 받는 경우는 Controller라고 부르거나 그런식으로 씀요 캐릭터뷰라고 쓸데도 있는데 그거는 GUI로 만들때 많이 씀 엔진이 관리하는 뷰/액터/컨트롤러 클래스는 실시간으로 게임 켜졌을때 동작하는 점프시 현재위치라던가. AI가 선택하는 현재행동 (패트롤)이라던가 ( 날아가도 되는 데이터 )를 주로 관리하고 해당 컨트롤러에 해당 캐릭터 빈값을 줘서 저장할때는 루프돌면서 모두 빈값을 저장하던가 하는 것도 방법임 근데 이거는 좀 리팩토링 쪽인데 리팩토링만 하다가 시간 허비하고 완성 못하는 케이스도 있으니 분량을 빼는 쪽을 추천

[익명(175.193)]

니 생각이맞음 이런게 다 회사가서 배우는거

[yakitory(favorite2166)]

좋은 데이터 드리븐 사고방식임

[yakitory(favorite2166)]

인벤토리를 가지고있어야하는 플레이어가 여러개 존재해야한다면 플레이어가 인벤토리를 가져야겠지만, 그게 아니라면 보통 “세이브데이터”에 연결되어있겠지.

[Kokone(kokone1234)]

나 같은 경우는 흐름 이렇게 가져감 Inventory 기능을 플레이어가 가짐 -> 변경에 취약함과 인벤토리 기능이 플레이어에게 귀속된다는것이 문제임을 인지 Inventory 기능을 하나의 ActorComponent 또는 오브젝트로 구성하여 플레이어의 하위 인스턴스로 구성 -> Is 관계가 아닌 Has 관계의 컴포넌트로 구성함으로 의존성, 다형성을 보완함. -> 하지만 Inventory의 기능을 플레이어만 가지고 있는게 아닌 경우를 대비할 수 없음

[Kokone(kokone1234)]

Inventory 기능을 오브젝트로 구성하되, 이를 감싸는 래퍼를 하나 구상함, 해당 레퍼는 DI 를 이용하여 인벤토리 기능을 제공하되, EnemyInventory, PlayerInventory등의 정보를 DI로 주입함과 동시에, 래퍼 클래스의 함수 (보통 함수는 인터페이스로 부착하여 동일한 행동을 보장함) 를 통해 쉬운 교체가 가능해짐 이를 Inventory System이라고 명칭함 -> 만약 영속적인 데이터를 다루게 될 경우, 도메인 서비스 비즈니스 로직이 영속 계층과 혼합될 경우 수정이 힘들어짐

[Kokone(kokone1234)]

@Kokone 씬 교체를 언급했으니 Singletone 기반 Inventory System -> Inventory 기능 -> [Inventory Repository 영속 계층 담당] -> Database 순으로 DDD 패턴을 도입함 -> Inventory Repository 이전을 기준으로 왼쪽은 게임 엔진 코드가 포함되는 비즈니스 로직 / 오른쪽은 영속 계층의 분리가 됨.

[흑_두루미(combedro)]

게임에 인벤토리가 없음

[Ray.(choxu0826)]

나는 캐릭터 다중 조작해야해서 각 캐릭터가 아이템과 개수만 가지고 있고, 인벤토리 동작 자체는 다른 클래스에서 플레이어 캐릭터가 가지는 아이템을 표시하는 역할만 하도록 했음

[dryrain(dryrain1025)]

ItemDataManager라는 싱글톤 클래스 만들어놓고 아이템 데이터 흐름은 걔가 관리함

[211214(tomatoss)]

ㅇㅇ.. 저도 플레이어가 가질 필요는 없다고 생각. 게임에 따라 다르겠지만은