저는 Unity에서 Crusader Kings 2와 같은 수백 가지 캐릭터가 들어있는 간단한 RTS 게임을 만들고 있습니다. 그것들을 저장하는 가장 쉬운 방법은 스크립트 가능한 객체를 사용하는 것이지만 런타임에 새로운 객체를 만들 수 없으므로 좋은 해결책이 아닙니다.

그래서 모든 데이터를 포함하는 "Character"라는 C # 클래스를 만들었습니다. 모든 것이 잘 작동하지만 게임이 시뮬레이션함에 따라 지속적으로 새로운 캐릭터를 만들고 일부 캐릭터를 죽입니다 (게임 내 이벤트가 발생할 때). 게임이 지속적으로 시뮬레이션함에 따라 1000 개의 캐릭터가 생성됩니다. 기능을 처리하는 동안 문자가 "Alive"인지 확인하기위한 간단한 검사를 추가했습니다. 따라서 성능에 도움이되지만 가계도를 만드는 동안 정보가 필요하기 때문에 죽은 경우 "캐릭터"를 제거 할 수 없습니다.

내 게임의 데이터를 저장하는 가장 좋은 방법은 목록입니까? 또는 10000 개의 캐릭터가 생성되면 문제가 발생합니까? 한 가지 가능한 해결책은 목록이 일정량에 도달하면 다른 목록을 작성하고 죽은 문자를 모두 이동시키는 것입니다.

고려해야 할 세 가지가 있습니다.

1. 그것은 않습니다 실제로 성능 문제의 원인? 실제로 1000 대는 많지 않습니다. 최신 컴퓨터는 엄청나게 빠르며 많은 것을 처리 할 수 ​​있습니다. 문자 처리에 걸리는 시간을 모니터링하고 너무 걱정하기 전에 실제로 문제를 일으킬 지 여부를 확인하십시오.

2. 현재 최소한의 활동적인 캐릭터의 충실도. 초보자 게임 프로그래머의 실수는 화면상의 문자와 동일한 방식으로 화면상의 문자를 정확하게 업데이트하는 것에 집착하는 것입니다. 이것은 아무도 실수입니다. 대신 오프 스크린 캐릭터가 여전히 행동 하고 있다는 인상 을 주어야합니다 . 화면 외부 수신 업데이트 문자의 양을 줄이면 처리 시간을 크게 줄일 수 있습니다.

3. 데이터 지향 디자인을 고려하십시오. 1000 개의 문자 객체를 갖고 각각에 대해 동일한 함수를 호출하는 대신 1000 개의 문자에 대한 데이터 배열을 보유하고 각각 1000 개의 문자에 대해 하나의 함수 루프를 하나씩 차례로 업데이트합니다. 이러한 종류의 최적화는 성능을 크게 향상시킬 수 있습니다.

이 상황에서 Composition을 사용하는 것이 좋습니다 .

클래스가 구성에 따라 다형성 동작 및 코드 재사용을 달성해야한다는 원칙 (원하는 기능을 구현하는 다른 클래스의 인스턴스를 포함하여)

이 경우 Character클래스가 신 처럼 된 것처럼 들리며 캐릭터가 라이프 사이클의 모든 단계 에서 어떻게 작동하는지에 대한 모든 세부 정보가 들어 있습니다 .

예를 들어, 죽은 문자는 가계도에서 사용되므로 여전히 필요합니다. 그러나 살아있는 캐릭터의 모든 정보와 기능이 가계도에 표시하기 위해 여전히 필요한 것은 아닙니다. 예를 들어 이름, 생년월일 및 세로 아이콘이 필요할 수 있습니다.

해결책은 귀하 의 인스턴스를 소유하는 Character하위 클래스로 분리 Character하는 것입니다. 예를 들면 다음과 같습니다.

• CharacterInfo 이름, 생년월일, 사망일 및 진영이 포함 된 간단한 데이터 구조 일 수 있습니다.

• Equipment캐릭터가 보유한 모든 아이템 또는 현재 자산이있을 수 있습니다. 또한 이러한 기능을 관리하는 로직이있을 수 있습니다.

• CharacterAI또는 CharacterController등 캐릭터의 현재 목표, 자신의 유틸리티 기능에 대해 필요한 모든 정보가있을 수 있습니다 그리고 그것은 또한 공동 좌표 그 사이의 의사 결정 / 상호 작용이 개별 부품의 것을 실제 갱신 로직을 가질 수있다.

캐릭터를 분리 한 후에는 더 이상 업데이트 루프에서 Alive / Dead 플래그를 확인할 필요가 없습니다.

대신 간단하게 만들 것 AliveCharacterObject을 가지고 그 CharacterController, CharacterEquipment그리고 CharacterInfo스크립트를 첨부합니다. 캐릭터를 "킬 (kill)"하려면 더 이상 관련이없는 부분 (예 :)을 제거하면 CharacterController메모리 나 처리 시간이 낭비되지 않습니다.

CharacterInfo가계도에 실제로 필요한 유일한 데이터는 어떻 습니까? 클래스를 더 작은 기능으로 분해하면 전체 AI 기반 특성을 유지할 필요없이 사망 후 작은 데이터 개체를보다 쉽게 ​​유지할 수 있습니다.

이 패러다임은 Unity가 사용하기 위해 만든 유일한 패러다임이라는 점을 언급 할 가치가 있습니다. 이것이 많은 별도의 스크립트로 사물을 처리하는 이유입니다. 큰 신 물체를 만드는 것이 Unity에서 데이터를 처리하는 가장 좋은 방법은 아닙니다.

처리 할 데이터가 많고 모든 데이터 포인트가 실제 게임 오브젝트로 표시되는 것은 아니지만, 일반적으로 Unity 특정 클래스를 포기하고 오래된 C # 오브젝트를 사용하는 것은 나쁜 생각이 아닙니다. 그렇게하면 오버 헤드가 최소화됩니다. 그래서 당신은 여기에 올바른 길을 가고있는 것 같습니다.

하나의 List ( 또는 array ) 에 살아있는 문자 또는 죽은 문자를 모두 저장하면 해당 목록의 색인이 표준 문자 ID로 사용될 수 있기 때문에 유용 할 수 있습니다. 인덱스로 목록 위치에 액세스하는 것은 매우 빠른 작업입니다. 그러나 죽은 문자가 필요한 것보다 훨씬 자주 반복해야 할 가능성이 있기 때문에 모든 살아있는 문자의 ID 목록을 별도로 유지하는 것이 유용 할 수 있습니다.

당신의 게임 메카닉의 구현이 진행됨에 따라, 당신은 또한 어떤 다른 종류의 검색이 가장 많이 수행되는지를보고 싶을 것입니다. "특정 위치의 모든 살아있는 캐릭터"또는 "특정 캐릭터의 모든 살아있는 또는 죽은 조상"처럼. 이러한 종류의 쿼리에 최적화 된 일부 보조 데이터 구조를 만드는 것이 좋습니다. 그들 각각은 최신 상태로 유지되어야한다는 것을 기억하십시오. 추가 프로그래밍이 필요하며 추가 버그의 원인이됩니다. 성능이 크게 향상 될 것으로 예상되는 경우에만 수행하십시오.

CKII는 자원을 저장하는 것이 중요하지 않은 것으로 간주 될 때 데이터베이스에서 문자를 " 정리 ( prune) "합니다. 죽은 캐릭터 더미가 오래 실행되는 게임에서 너무 많은 리소스를 소비하는 경우 비슷한 작업을 수행하고 싶을 수도 있습니다 (이 "가비지 수집"이라고 부르고 싶지 않을 수도 있습니다. "존중 한 창작자").

실제로 게임의 모든 캐릭터에 대한 게임 오브젝트가있는 경우 새로운 Unity ECS 및 작업 시스템 이 유용 할 수 있습니다. 매우 유사한 게임 오브젝트를 수행하는 방식으로 처리하도록 최적화되어 있습니다. 그러나 소프트웨어 아키텍처를 매우 엄격한 패턴으로 만듭니다.

그건 그렇고, 나는 CKII를 좋아하고 수천 개의 고유 한 AI 제어 캐릭터로 세계를 시뮬레이션하는 방식을 좋아하므로 장르에 대한 당신의 테이크를 기대하고 있습니다.

플레이어 근처에 소수의 캐릭터 만있을 때는 수천 명의 캐릭터를 시뮬레이션 / 업데이트 할 필요가 없습니다. 현재 시점에서 플레이어가 실제로 볼 수있는 내용 만 업데이트하면되므로 플레이어에서 멀리 떨어진 캐릭터는 플레이어가 가까이있을 때까지 일시 중단되어야합니다.

게임 메카닉이 시간의 흐름을 보여주기 위해 먼 캐릭터를 요구하기 때문에 이것이 효과가 없다면, 플레이어가 가까이 가면 하나의 "큰"업데이트로 업데이트 할 수 있습니다. 게임 메카닉이 각 캐릭터가 실제로 게임 내 이벤트에 반응하도록 요구하는 경우, 캐릭터가 플레이어 나 이벤트와 관련이있는 위치에 관계없이 플레이어가 더 멀리있는 캐릭터의 빈도를 줄이는 것이 효과적 일 수 있습니다 업데이트 됨 (즉, 여전히 게임의 나머지 부분과 동기화되어 업데이트되지만 자주는 아니므로 멀리있는 캐릭터가 이벤트에 응답하기 전에 약간의 지연이 발생하지만 문제를 일으키거나 플레이어가이를 알지 못할 수도 있음 ). 또는 하이브리드 방식을 사용하고 싶을 수도 있습니다.

질문의 설명

나는 Crusader Kings 2와 같은 수백 명의 캐릭터가 Unity에 포함 된 간단한 RTS 게임을 만들고 있습니다.

이 답변에서 나는 전체 게임이 많은 캐릭터를 갖는 것에 대한 부분이 아니라 CK2와 같다고 가정합니다. CK2의 화면에 표시되는 모든 것은 수행하기 쉽고 성능을 위협하거나 Unity에서 구현하기가 복잡하지 않습니다. 그 뒤에있는 데이터는 복잡해집니다.

비 기능성 Character수업

그래서 모든 데이터를 포함하는 "Character"라는 C # 클래스를 만들었습니다.

게임의 캐릭터 는 단지 데이터 이기 때문에 좋습니다 . 화면에 표시되는 것은 해당 데이터의 표현 일뿐입니다. 이 Character클래스는 게임의 핵심이며 " 신의 대상 " 이 될 위험이 있습니다. 따라서 나는 그것을 방지하기 위해 극단적 인 조치를 권합니다. 해당 클래스에서 모든 기능을 제거하십시오. GetFullName()이름과 성을 결합 하는 방법 입니다. 그러나 실제로 "무엇을하는"코드는 없습니다. 이 코드를 하나의 작업을 수행하는 전용 클래스에 넣습니다 . 예를 들어 Birther메소드 Character CreateCharacter(Character father, Character mother)가있는 Character클래스 는 클래스 에서 해당 기능을 갖는 것보다 훨씬 깨끗합니다 .

코드에 데이터를 저장하지 마십시오

그것들을 저장하기 위해 가장 쉬운 옵션은 스크립트 가능한 객체를 사용하는 것입니다.

아니요. Unity의 JsonUtility를 사용하여 JSON 형식으로 저장하십시오. 비 기능성 Character클래스를 사용하면 간단합니다. 게임의 초기 설정과 savegames에 저장하는 데 효과적입니다. 그러나 여전히 지루한 일이므로 귀하의 상황에서 가장 쉬운 옵션을 제공했습니다. 텍스트 파일에 저장된 사람이 XML을 읽을 수있는 한 XML 또는 YAML 또는 다른 형식을 실제로 사용할 수도 있습니다. CK2는 실제로 대부분의 게임과 동일합니다. 또한 사람들이 귀하의 게임을 개조 할 수있는 훌륭한 설정이지만, 나중에 생각할 것입니다.

추상적 인 생각

[...]를 처리하는 동안 캐릭터가 "Alive"인지 확인하는 간단한 확인을 추가했지만 가계도를 만드는 동안 정보가 필요하기 때문에 죽은 경우 "Character"를 제거 할 수 없습니다.

이것은 종종 자연적인 사고 방식과 충돌하기 때문에 말보다 쉽습니다. 당신은 "캐릭터"의 "자연적인"방식으로 생각하고 있습니다. "문자는"있는 데이터의 적어도 2 개 개의 다른 종류가있는 것처럼하지만, 게임의 관점에서, 보인다 내가 전화 할게 ActingCharacter하고 FamilyTreeEntry. 죽은 캐릭터 FamilyTreeEntry는 업데이트 할 필요가 없으며 아마도 active보다 훨씬 적은 데이터가 필요합니다 ActingCharacter.

강건한 OO 디자인에서 Entity-Component-System (ECS) 디자인에 이르기까지 약간의 경험을 통해 이야기하겠습니다.

얼마 전 나는 너와 똑 같았고, 비슷한 속성을 가진 여러 가지 유형의 것들이 있었고 다양한 객체를 만들고 상속을 사용하여 해결하려고했습니다. 매우 똑똑한 사람 은 그렇게하지 말고 대신 Entity-Component-System을 사용하십시오.

이제 ECS 는 큰 개념이며 제대로 이해하기가 어렵습니다. 엔터티, 구성 요소 및 시스템을 올바르게 구축하는 데 필요한 많은 작업이 있습니다. 그러기 전에 용어를 정의해야합니다.

1. 엔티티 : 이것은이다 것은 , 플레이어, 동물, NPC, 무엇이든 . 컴포넌트가 필요합니다.
2. 구성 요소 : 이는 귀하의 경우 "이름"또는 "나이"또는 "부모"와 같은 속성 또는 특성 입니다.
3. 시스템 : 이것은 구성 요소의 논리 또는 동작 입니다. 일반적으로 구성 요소 당 하나의 시스템을 구축하지만 항상 가능한 것은 아닙니다. 또한 때때로 시스템이 다른 시스템 에 영향을 주어야 합니다.

그래서 여기에 내가 갈 곳이 있습니다.

무엇보다도 ID캐릭터를 위한를 만드 십시오. int, Guid당신이 원하는대로. 이것이 "엔터티"입니다.

둘째, 당신이 겪고있는 다양한 행동에 대해 생각하기 시작하십시오. "패밀리 트리"와 같은 것들 — 행동입니다. 엔티티의 속성으로 모델링하는 대신 모든 정보 를 보유하는 시스템을 빌드 하십시오 . 그런 다음 시스템은 무엇을할지 결정할 수 있습니다.

마찬가지로, "캐릭터가 살아 있거나 죽었습니까?"에 대한 시스템을 구축하려고합니다. 이것은 다른 모든 시스템에 영향을 미치기 때문에 설계에서 가장 중요한 시스템 중 하나입니다. 일부 시스템은 "죽음"문자 (예 : "스프라이트"시스템)를 삭제하고 다른 시스템은 내부적으로 새로운 상태를 더 잘 지원하기 위해 항목을 다시 정렬 할 수 있습니다.

예를 들어 "스프라이트", "도면"또는 "렌더링"시스템을 구축합니다. 이 시스템은 캐릭터에 표시 할 스프라이트와 표시 방법을 결정해야합니다. 그런 다음 캐릭터가 죽으면 제거하십시오.

또한 캐릭터에게 무엇을해야하는지, 어디로 가야하는지 등을 알려주는 "AI"시스템. 다른 많은 시스템과 상호 작용하고이를 기반으로 결정을 내려야합니다. 다시 말하지만 죽은 문자는 더 이상 아무것도하지 않기 때문에이 시스템에서 제거 될 수 있습니다.

"이름"시스템 및 "패밀리 트리"시스템은 아마도 문자 (생존 또는 사망)를 메모리에 보관해야합니다. 이 시스템은 캐릭터의 상태에 관계없이 해당 정보를 리콜해야합니다. (Jim은 매장 한 후에도 여전히 Jim입니다.)

또한 시스템 이보다 효율적으로 반응 할 때 변경 하는 이점도 있습니다. 시스템에는 자체 타이머가 있습니다. 일부 시스템은 빠르게 발사해야하지만 일부는 그렇지 않습니다. 여기서 우리는 게임을 효율적으로 운영하기 시작합니다. 우리는 밀리 초마다 날씨를 다시 계산할 필요가 없습니다. 아마도 5 년마다 그렇게 할 수 있습니다.

또한보다 창의적인 활용도를 제공합니다. A에서 B까지의 경로 계산을 처리하고 필요에 따라 업데이트 할 수있는 "Pathfinder"시스템을 구축하여 이동 시스템이 "어디에서해야합니까? 다음에가? " 우리는 이제 이러한 우려를 완전히 분리하고보다 효과적으로 추론 할 수 있습니다. 운동은 경로를 찾을 필요가 없습니다.

시스템의 일부를 외부에 노출하려고합니다. 당신의 Pathfinder시스템에서 아마 당신은 원할 것입니다 Vector2 NextPosition(int entity). 이러한 방식으로 이러한 요소를 엄격하게 제어되는 배열 또는 목록에 유지할 수 있습니다. 더 작은 struct유형을 사용 하면 구성 요소를 더 작고 연속적인 메모리 블록에 유지하여 시스템 업데이트를 훨씬 빠르게 수행 할 수 있습니다 . (특히 시스템에 대한 외부 영향이 최소화 된 경우 이제는 시스템과 같은 내부 상태 만 신경 쓰면됩니다 Name.)

그러나, 나는 이것을 충분히 강조 할 수 없습니다. 이제는 타일, 객체 등을 포함하여 Entity단지입니다 ID. 엔티티가 시스템에 속하지 않으면 시스템은 그것을 추적하지 않습니다. 우리는, 우리의 "트리"객체를 생성에 저장할 수있는이 수단 Sprite과 Movement(나무가 이동하지 않습니다,하지만 그들은 "위치"구성 요소가) 시스템과 다른 시스템의 그들을 유지. 나무를 렌더링하는 것은 종이 인형 외에 캐릭터와 다르지 않기 때문에 더 이상 나무에 대한 특별한 목록이 필요하지 않습니다. 합니다 (어떤 Sprite시스템을 제어 할 수 있습니다, 또는 Paperdoll시스템을 제어 할 수 있습니다.) 이제 우리는 NextPosition약간의 재 작성 할 수 있습니다 Vector2? NextPosition(int entity), 그리고 그것은 반환 할 수 null그것에 대해 상관하지 않는다 엔티티 위치를. 우리는 또한 이것을 나무에 적용하고 나무와 바위를 NameSystem.GetName(int entity)반환 null합니다.

나는 가까운이를 그릴 수 있습니다, 그러나 여기에서 아이디어는 당신에게 ECS에 대한 몇 가지 배경을 제공하는 것입니다, 당신은 할 수있는 방법 정말 당신에게 게임에 대한 더 나은 디자인을 제공하기 위해 활용. 성능을 높이고 관련없는 요소를 분리하며보다 체계적인 방식으로 유지할 수 있습니다. (당신이있는 경우에 내가보기 엔 F 번호 체크 아웃하는 것이 좋습니다 F # 및 LINQ 등이 또한 쌍 아니라 기능적인 언어 / 설정, 아니 이미 그것은 쌍 아주 잘 C #을 사용하면 함께 사용할 때.)

Unity에서이 작업을 수행 할 때 가장 쉬운 방법은 다음과 같습니다.

• 캐릭터 또는 유닛 유형 당 하나의 게임 오브젝트 생성
• 프리 팹으로 저장
• 그런 다음 필요할 때마다 프리 팹을 인스턴스화 할 수 있습니다
• 캐릭터가 죽으면 게임 오브젝트를 파괴하면 더 이상 CPU 나 메모리를 차지하지 않습니다

코드에서 List와 같은 객체에 대한 참조를 유지하여 Find () 및 그 변형을 항상 사용하지 못하게 할 수 있습니다. CPU 사이클을 메모리로 교환하고 있지만 포인터 목록은 매우 작기 때문에 수천 개의 객체가 있어도 큰 문제는 아닙니다.

게임을 진행하면서 개별 게임 오브젝트를 갖는 것이 탐색 및 AI를 포함하여 많은 이점을 제공한다는 것을 알게 될 것입니다.