KR20190140802A

KR20190140802A - 비디오 게임 엔진의 성능 향상을 위한 방법 및 시스템

Info

Publication number: KR20190140802A
Application number: KR1020180072069A
Authority: KR
Inventors: 조아킴 크리스토프 안테; 팀 요한슨
Original assignee: 유니티 아이피알 에이피에스
Priority date: 2018-06-12
Filing date: 2018-06-22
Publication date: 2019-12-20
Also published as: US11132289B2; KR102124561B1; US20200278924A1; KR20200074069A; US20190377672A1; CA3009230C; US10599560B2; KR102228448B1; CA3009230A1

Abstract

본 명세서에는 엔티티 컴포넌트 시스템(ECS)을 사용하여 비디오 게임 엔진의 성능을 향상시키는 방법들 및 장치들이 설명된다. 실시예에 따르면, ECS는 값 데이터 타입들을 사용하여 전체적으로 구성되는, 게임 객체들을 표현하는, 엔티티들을 생성하고 사용한다. ECS는 메모리 내의 엔티티들을 조밀하게 패킹된 선형적 방식으로 구성하며, 이에 의해 ECS는 게임 내의 객체들을 (예를 들어, 게임 진행 동안) 지속적으로 모니터링하고, 게임이 진행됨에 따라 메모리 사용의 최대 밀도가 실시간으로 유지되도록 메모리 내의 엔티티 분포를 조정한다.

Description

비디오 게임 엔진의 성능 향상을 위한 방법 및 시스템{METHOD AND SYSTEM FOR IMPROVED PERFORMANCE OF A VIDEO GAME ENGINE}

본 개시 내용은 비디오 게임 엔진의 성능을 향상하기 위한 소프트웨어 툴 분야에 관한 것이다.

대부분의 최신 비디오 게임 개발은 객체 지향 프로그래밍(object oriented programming)(OOP)을 사용하여 행해지는데, 프로그래밍 객체들은 게임의 각 요소에 사용된다. 게임 내의 요소들을 나타내는 프로그래밍 객체들은 종종 게임 객체들 또는 게임 엔티티들이라고 불리며, 본 명세서에서는 게임 객체들이라고 지칭된다. 게임 객체는 캐릭터들, 총기들, 보물들, 나무들, 배경들, 효과들 등을 비롯한 게임 내의 거의 모든 것을 나타낼 수 있다. 게임 객체는 전형적으로 게임 객체에 대한 메소드들 및 변수들을 포함하는 OOP 클래스 구조의 인스턴스로서 정의된다. 컴퓨터 메모리 내에서, OOP 객체(예를 들어, 클래스의 인스턴스)는 메모리 내의 다른 위치들에 있는 데이터 및 데이터로의 포인터들을 포함하는 구조이다. 예를 들어, 게임 캐릭터는 위치, 방향, 크기, 메쉬 등에 대한 값들을 갖는 클래스에 속할 수도 있으며, 또한 캐릭터의 거동을 정의하는 메소드들을 가질 수 있다. 캐릭터 게임 객체가 들어 있는 메모리 위치는 데이터를 포함하고, 캐릭터 게임 객체의 더 많은 데이터가 들어 있는 다른 메모리 위치들로의 포인터들을 포함할 수 있다.

현재의 객체 지향 프로그래밍은 데이터를 직접 포함하고 있기보다는 데이터로의 포인터들을 갖고 있는 참조 값 객체들을 부분적으로 사용하기 때문에 성능이 최적화되지 않는다. 기존의 게임 개발 기술은 게임 내의 객체들을 정의하기 위해 흔히 참조 값 구조들을 사용한다. 이것은 객체 지향 프로그래밍 프레임워크 내의 객체라는 개념에 기초한 것이며 (예를 들어, 프로그래밍 객체의 거동 및 속성들은 게임 객체의 거동 및 속성들과 잘 맞추어지기 때문에) 프로그래밍을 간략화하는데 사용된다. 그러나, 객체 지향 프로그래밍은 개념 수준에서 최적화될 수 있고 그리고 프로그래밍의 편의를 위해 최적화될 수 있지만, 비디오 게임 진행과 관련하여 성능에 대해서 항상 최적화되는 것은 아니다. 최적화된 성능이 부족한 주요 원인은 OOP 프로그래밍이 메모리의 최적한 사용을 자동으로 제공하지 않는다는 것이다. OOP 객체들은 흔히 데이터로의 포인터들을 포함하지만, 데이터 자체는 멀리 있는 메모리 위치들 전체에 걸쳐 무작위로 흩어져 있다. 그 결과, 게임 객체 데이터는 보통 메모리 내의 무작위의 위치에 놓여 있고 메모리 내의 다른 무작위의 위치들에는 보통 (예를 들어, 데이터로의) 포인터들이 들어 있다. 하나 이상의 캐릭터에 대한 데이터에 액세스하기 위해 (예를 들어, 장면 내의 캐릭터 위치를 결정하기 위해), 게임 엔진은 종종 여러 개의 별개의 무작위 메모리 위치들에 액세스하여야 할 것이다. 또한 두 개의 상이한 게임 객체에 대한 메모리 내 데이터의 상대적 위치를 확실하게 보장하는 것도 어렵다. 초당 60 프레임(fps) 이상으로 실행되는 비디오 게임 장면 속의 모든 게임 객체들의 무작위 메모리 위치들에 액세스하는 것은, 특히 임의의 주어진 비디오 게임 프레임 동안 전형적으로 진행 중에 있는 다량의 게임 객체들을 고려한다면 비효율적이다. 게임 객체 데이터가 메모리 전반에 산재되어 있으면 메모리 액세스 시간(예를 들어, 중앙 처리 유닛(central processing unit)(CPU)이 메모리 위치에 액세스하는데 걸리는 시간, 이 시간은 메모리 위치가 액세스될 때마다 일반적으로 수백 CPU 사이클임)으로 인해 비효율성을 자아낸다. 모든 메모리에 액세스하는 것은 시간이 걸린다; 그러나 무작위로 먼 위치들에 있는 메모리에 액세스해야 한다면 하드웨어 프리페칭의 장점들이 무효화되기 때문에 부수적인 시간이 필요하다. 메모리 내에 산재되어 있는 데이터에 액세스하는데 걸리는 부수적인 시간은 런타임에서 실행된 게임 코드의 성능을 저하시킨다. 이것은 CPU 속도가 주어진 경우, 프레임 속도가 유지되어야 한다면(예를 들어, 전형적인 게임들의 경우 초당 60 프레임) 게임 진행 동안 한 프레임에서 활성화될 수 있는 게임 객체들의 수에 제한들을 가한다. 이것은 최소 품질의 시각적 출력에 초당 90 프레임을 필요로 하는 가상 현실 애플리케이션들에 특히 중요하다. 최신 게임 디자인은 그래픽 처리 유닛(graphical processing unit)(GPU)들을 통합하여 CPU로부터의 처리를 넘겨줄 뿐만 아니라, 다중스레드 코딩 기술들을 통합하여 다수의 CPU/GPU 코어들 전체에서 게임 데이터의 처리를 병렬화함으로써 성능을 향상시킨다. 그러나 이러한 기술들은 게임 객체들의 별개의 무작위 메모리 위치들에 액세스하는 근본적인 문제를 극복하지 못한다.

게임 성능은 또한 객체 지향 프로그래밍 방법론과 대조적으로 데이터 지향 프로그래밍 방법론을 고려함으로써 향상될 수도 있지만, 데이터 지향 프로그래밍은 게임 개발자에게 고도의 지식을 요구하고, 수작업으로 행해지며, 특히 각 게임을 대상으로 하고 있다. 프로그래밍 방법론의 기본적인 지식만을 가지고 있는 게임 개발자들과 게임 디자이너들의 대부분의 역량은 이에 미치지 못한다.

본 발명의 추가의 특징부들 및 장점들은 첨부 도면들과 함께 접하는 다음의 상세한 설명으로부터 명백해질 것이다.
도 1은 일 실시예에 따른 엔티티 컴포넌트 시스템(entity component system) (ECS) 시스템 내 ECS 디바이스를 도시하는 개략도이다.
도 2a는 일 실시예에 따른 ECS 시스템 내 청크에 대한 메모리 레이아웃을 도시하는 개략도이다.
도 2b는 일 실시예에 따른 ECS 시스템에서 두 개의 청크 내의 메모리 레이아웃을 도시하는 개략도이다.
도 3은 일 실시예에 따른 ECS 시스템에서 청크 내의 컴포넌트 데이터 어레이에 대한 메모리 레이아웃을 도시하는 개략도이다.
도 4a는 일 실시예에 따라 ECS 시스템에서 아키타입에 엔티티를 통합하기 위한 방법을 도시하는 개략도이다.
도 4b는 일 실시예에 따라 ECS 시스템에서 아키타입 내에 엔티티를 생성하기 위한 방법을 도시하는 개략도이다.
도 4c는 일 실시예에 따라 ECS 시스템 내의 엔티티를 수정하기 위한 방법을 도시하는 개략도이다.
도 5는 일 실시예에 따라 ECS 시스템 내의 엔티티 데이터를 수정하기 위한 방법을 도시하는 개략도이다.
도 6a, 도 6b 및 도 6c는 일 실시예에 따라 ECS 시스템 내의 엔티티를 삭제하기 위한 방법을 도시한다.
도 7a 및 도 7b는 일 실시예에 따라 객체 지향 프로그래밍 객체를 ECS 시스템 내의 엔티티로 변환하기 위한 방법을 도시한다.
도 8은 본 명세서에 설명된 다양한 하드웨어 아키텍처들과 함께 사용될 수 있는 예시적인 소프트웨어 아키텍처를 도시하는 블록도이다.
도 9는 머신 판독 가능한 매체(예를 들어, 머신 판독 가능한 저장 매체)로부터 명령어들을 판독하고 본 명세서에서 논의된 임의의 하나 이상의 방법론을 수행하도록 구성된, 일부 예시적인 실시예에 따른 머신의 컴포넌트들을 도시하는 블록도이다.
첨부 도면들 전체에서 동일한 특징부들은 동일한 참조 부호들로 식별된다는 것이 주목될 것이다.

다음의 설명은 본 개시 내용의 예시적인 실시예들을 구성하는 시스템들, 방법들, 기술들, 명령어 시퀀스들 및 컴퓨팅 머신 프로그램 제품들을 설명한다. 다음의 설명에서, 설명의 목적으로, 본 발명의 주제의 다양한 실시예의 이해를 제공하기 위해 다수의 특정 세부 사항들이 설명된다. 그러나, 관련 기술분야에서 통상의 기술자에게는 본 발명의 주제의 실시예들이 이러한 특정 세부 사항들 없이 실시될 수 있음이 명백할 것이다.

현재의 객체 지향 프로그래밍은 데이터를 직접 포함하고 있기 보다는 데이터로의 포인터들을 갖고 있는 참조 값 객체들을 부분적으로 사용하기 때문에 성능이 최적화되지 않는다. 기존의 게임 개발 기술은 게임 내의 객체들을 정의하기 위해 흔히 참조 값 구조들을 사용한다. 이것은 객체 지향 프로그래밍 프레임워크 내의 객체라는 개념에 기초한 것이며 (예를 들어, 프로그래밍 객체의 거동 및 속성들은 게임 객체의 거동 및 속성들과 잘 맞추어지기 때문에) 프로그래밍을 간략화하는데 사용된다. 그러나, 객체 지향 프로그래밍은 개념 수준에서 최적화될 수 있고 그리고 프로그래밍의 편의를 위해 최적화될 수 있지만, 비디오 게임 진행과 관련하여 성능에 대해서는 항상 최적화되는 것은 아니다. 최적화된 성능이 부족한 주요 원인은 OOP 프로그래밍이 메모리의 최적한 사용을 자동으로 제공하지 않는다는 것이다. OOP 객체들은 보통 데이터로의 포인터들을 포함하지만, 데이터 자체는 멀리 있는 메모리 위치들 전체에 걸쳐 무작위로 흩어져 있다. 그 결과, 게임 객체 데이터는 보통 메모리 내의 무작위의 위치에 놓여 있고 메모리 내의 다른 무작위의 위치들에는 보통 (예를 들어, 데이터로의) 포인터들이 들어 있다. 하나 이상의 캐릭터에 대한 데이터에 액세스하기 위해 (예를 들어, 장면에서 캐릭터 위치를 결정하기 위해), 게임 엔진은 보통 여러 개의 별개의 무작위 메모리 위치들에 액세스하여야 할 것이다. 또한 두 개의 상이한 게임 객체에 대한 메모리 내 데이터의 상대적 위치를 확실하게 보장하는 것도 어렵다. 초당 60 프레임(fps) 이상으로 실행되는 비디오 게임 장면 속의 모든 게임 객체들의 무작위 메모리 위치들에 액세스하는 것은, 특히 임의의 주어진 비디오 게임 프레임 동안 전형적으로 진행 중에 있는 다량의 게임 객체들을 고려한다면 비효율적이다. 게임 객체 데이터가 메모리 전반에 산재되어 있으면 메모리 액세스 시간(예를 들어, 중앙 처리 유닛(central processing unit)(CPU)이 메모리 위치에 액세스하는데 걸리는 시간, 이 시간은 메모리 위치가 액세스될 때마다 일반적으로 수백 CPU 사이클임)으로 인해 비효율성을 자아낸다. 모든 메모리에 액세스하는 것은 시간이 걸린다; 그러나 무작위로 먼 위치들에 있는 메모리에 액세스해야 한다면 하드웨어 프리페칭의 장점들이 무효화되기 때문에 부수적인 시간이 필요하다. 메모리 내에 산재되어 있는 데이터에 액세스하는데 걸리는 부수적인 시간은 런타임에서 실행된 게임 코드의 성능을 저하시킨다. 이것은 CPU 속도가 주어진 경우, 프레임 속도가 유지되어야 한다면(예를 들어, 전형적인 게임들의 경우 초당 60 프레임) 게임 진행 동안 한 프레임에서 활성화될 수 있는 게임 객체들의 수에 제한들을 가한다. 이것은 최소 품질의 시각적 출력에 초당 90 프레임을 필요로 하는 가상 현실 애플리케이션들에 특히 중요하다. 최신 게임 디자인은 그래픽 처리 유닛(graphical processing unit)(GPU)들을 통합하여 CPU로부터 처리를 넘겨줄 뿐만 아니라, 다중스레드 코딩 기술들을 통합하여 다수의 CPU/GPU 코어들 전체에서 게임 데이터의 처리를 병렬화함으로써 성능을 향상시킨다. 그러나 이러한 기술들은 게임 객체들에 대한 별개의 무작위 메모리 위치들에 액세스하는 근본적인 문제를 극복하지 못한다.

엔티티 컴포넌트 시스템(ECS)을 사용하여 비디오 게임 엔진의 성능을 향상하는 방법들 및 장치들이 본 명세서에서 설명된다. 실시예에 따르면, ECS는 게임 객체들을 정의하는 OOP 참조 값 구조들(예를 들어, 포인터들)의 사용을 (예를 들어, 게임 개발 동안 및 런타임에서) 없앤다. 그 대신, ECS는 포인터들을 사용하지 않고 데이터를 저장하는 데이터 값 구조들(예를 들어, C#의 '데이터구조(struct)')을 가지고 게임 객체들을 정의한다. 이러한 의미에서, 본 명세서에 설명되는 바와 같은 게임 객체는 객체 지향 프로그래밍 프레임워크 내에서 정의된 '객체'가 아니며; 따라서, (예를 들어, ECS 내의) 본 명세서에 설명된 바와 같은 게임 객체는 '엔티티(entity)'라고 지칭된다.

실시예에 따르면, ECS는 값 데이터 타입들(예를 들어, 포인터들을 사용하지 않는 C#에서의 데이터구조들)을 사용하여 전체적으로 구성되는 엔티티들을 생성하여 사용한다. 엔티티는 캐릭터들, 총기들, 보물들, 나무들, 배경들, 애니메이션, 효과들(예를 들어, 비디오 및 사운드), 3D 포인트들 등을 비롯한 비디오 게임에서 무엇이든 표현하는데 사용되는 데이터의 모음이다. ECS는 복수의 엔티티를 엔티티들이 유사한 속성들 (예를 들어, 본 명세서에 설명된 바와 같은 컴포넌트들) 및 메모리 레이아웃을 공유하는 아키타입(archetype)으로 그룹화한다. ECS는 (예를 들어, 그 안의 컴포넌트들을 포함하는) 엔티티들을 메모리 내에서 조밀하게 패킹된 선형 방식으로 구성한다. ECS는 (예를 들어, 게임 진행 동안) 게임 내의 엔티티들을 지속적으로 모니터링하고, 게임이 진행되고 있을 때 최대의 메모리 사용 밀도가 실시간으로 유지되도록 메모리 내의 (예를 들어, 그 안의 데이터를 포함하는) 엔티티 분포를 조정하며, 이에 따라서 (예를 들어, 하드웨어 프리페칭을 사용하는) 효율적인 메모리 액세스 및 멀티스레딩으로 인해 높은 성능을 가능하게 한다. ECS 시스템은 다수의 (예를 들어, 수백 또는 수천의) 유사한 게임 객체들(예를 들어, 논플레이어 캐릭터들, 로켓들, 우주선들 등)을 포함하는 게임 상황들에 높은 성능을 제공한다.

이제 도면들을 참조하면, 본 발명의 실시예에 따라 (예를 들어, 비디오 게임들 또는 시뮬레이션들을 디스플레이하는) 비디오 게임 엔진에 높은 처리 성능을 제공하도록 구성된 엔티티 컴포넌트 시스템(ECS)을 위한 시스템들 및 방법들이 설명된다. 실시예에 따르면, 도 1은 ECS 기능성을 제공하도록 구성된 예시적인 엔티티 컴포넌트 시스템(100)을 도시한다. ECS는 하나 이상의 중앙 처리 유닛(104)(CPU)들 및 그래픽 처리 유닛(106)(GPU)들을 포함하는 ECS 디바이스(101)를 포함한다. CPU(104)는 메모리(102)에 액세스하여 그 안에 저장된 명령어들을 검색하고 이러한 명령어들을 실행하는 임의의 유형의 프로세서, 다중 처리 요소들(도시되지 않음)을 포함하는 프로세서 어셈블리이다. 이러한 명령어들의 실행 시, 명령어들은 ECS 디바이스(101)로 하여금 본 명세서에서 설명된 바와 같은 일련의 작업을 수행하게 한다. CPU는 CPU 내에 캐시 메모리(105)를 포함할 수 있다.

ECS 디바이스(101)는 또한 예를 들어 키보드 또는 키패드, 마우스, 포인팅 디바이스 및 터치 스크린과 같은 하나 이상의 입력 디바이스(108)를 포함한다. ECS 디바이스(101)는 사용자에게 비디오 게임 환경 또는 가상 시뮬레이션 환경을 디스플레이하도록 구성될 수 있는 컴퓨터 모니터, 터치 스크린 및 헤드 장착형 디스플레이(head mounted display)(HMD)와 같은 하나 이상의 디스플레이 디바이스(110)를 더 포함한다. 디스플레이 디바이스(110)는 하나 이상의 GPU(106) 및 선택적으로는 CPU(104)에 의해 구동되거나 제어된다. GPU(106)는 디스플레이 디바이스(110)를 통한 출력의 렌더링을 가속화하는 것을 지원하는 그래픽 출력의 양태들을 처리한다.

또한 ECS 디바이스(101)는 디스플레이 디바이스(110)와 통신하고 그리고 입력 디바이스(들)(108)과 같이 게임(예를 들어, 비디오 게임) 또는 시뮬레이션을 사용자(도면에 도시되지 않음)에게 제공하는 다른 하드웨어와도 통신하는 (예를 들어, CPU(104) 또는 GPU(106)에 의해 실행되는) 게임 엔진(112)을 저장하도록 구성된 메모리(102)를 포함한다. 게임 엔진(112)은 전형적으로 사용자에게 비디오 게임(또는 시뮬레이션) 환경을 제공하기 위해 물리적 엔진, 충돌 검출, 렌더링, 네트워킹, 사운드, 애니메이션 등을 포함할 것이다. 게임 엔진(112)은 본 명세서에 설명된 바와 같이, 다양한 엔티티 컴포넌트 시스템 기능성을 제공하는 ECS 모듈(114)을 포함한다. ECS 모듈(114) 및 게임 엔진(112) 각각은 동작 중에 CPU(104)에 의해 실행되고 선택적으로는 GPU(106)와 함께 실행되는 메모리(102)에 상주하는 컴퓨터 실행 가능한 명령어들을 포함한다. ECS 모듈(114)은 게임 엔진(112) 내에 직접 통합될 수 있거나, 소프트웨어의 외부 부재(예를 들어, 플러그인)로서 구현될 수 있다.

실시예에 따르면, ECS 디바이스(101)상에서 실행되는 ECS 모듈(114)은 데이터를 포함하고 그리고 비디오 게임(또는 시뮬레이션)의 장면 내의 게임 객체의 표현인 엔티티를 생성하고 조작하도록 구성될 수 있다. 엔티티는 캐릭터들, 소품들, 무대 배경 및 효과들을 비롯한 임의의 게임 객체(예를 들어, 게임 또는 시뮬레이션 내의 임의의 가상 객체)를 표현할 수 있다. 엔티티는 게임 객체가 시간에 따라 표현하는 게임 객체의 모든 양태들, 특성들 및 거동들을 서술하는 데이터(예를 들어, 엔티티 데이터)를 포함한다. 데이터는 게임 객체의 시각적인 양태들(질감, 컬러, 크기, 형상, 방향 등)을 서술하는 데이터를 포함하며; 데이터는 게임 객체의 거동(예를 들어, 객체의 움직임 및 환경 내의 다른 객체들과의 상호 작용의 물리적 현상)을 서술하는 데이터를 포함한다. 엔티티의 거동은 엔티티의 데이터를 수정하는 프로세스들(예를 들어, 기능들)에 의해 정의된다.

실시예에 따르면, 엔티티 데이터는 본 명세서에서 컴포넌트 데이터라고 지칭되는 데이터의 하나 이상의 작은 그룹을 포함한다. 실시예에 따르면, 실행 동안 (예를 들어, 게임 진행 중 런타임에서), ECS 모듈(114)은 데이터 값 어레이 구조(예를 들어, C# 프로그래밍 언어 출처의 '데이터구조') 내에 엔티티에 대한 컴포넌트를 생성하며, 어레이 내의 요소들은 메모리(102) 내의 인접한 메모리 블록들에 배치된다. 컴포넌트는 메모리(102) 내의 다른 먼 위치들에 있는 데이터로의 포인터를 갖고 있지 않는다. 컴포넌트는 데이터의 논리적 그룹핑 및 단일 엔티티에 기능을 추가하는 데 사용되는 거동들과 연관된 데이터를 포함한다. 컴포넌트는 시각적 속성들 및 (예를 들어, 동일한 엔티티 내 또는 상이한 엔티티 내) 다른 컴포넌트들과의 상호 작용을 비롯한 임의의 유형의 기능성을 엔티티에 추가할 수 있다. 엔티티 내 컴포넌트들과 컴포넌트들 내 데이터의 조합은 게임 진행 동안 게임 세계 속의 엔티티의 속성들 및 기능들에 기여한다. 예를 들면, 엔티티에 카메라의 속성들을 부여하는 카메라 컴포넌트가 있을 수 있다. 엔티티에 빛의 속성들을 부여하는 조명 컴포넌트가 있을 수 있다. 예를 들면, 컴포넌트는 게임 세계 내에서 엔티티의 위치, 회전 및 규모를 정의할 수도 있다. 간략한 설명을 위해, 엔티티의 변환 컴포넌트를 수정하는 것은 게임 세계 내의 엔티티를 이동, 회전 또는 크기 조정하는 것(즉, 엔티티를 변환하는 것)일 것이기 때문에, 엔티티의 위치, 회전 및 크기 조정을 정의하는 컴포넌트는 변환 컴포넌트라고 지칭될 것이다. 컴포넌트의 다른 예로서, 본 명세서에서 강체 컴포넌트(rigidbody component)라고 지칭되는 컴포넌트는 엔티티가 게임 세계 내의 중력의 영향을 받게 함으로써 엔티티가 물리적인 거동을 행하게 해줄 수 있다. 컴포넌트의 또 다른 예는 하나 이상의 다른 엔티티와의 물리적 충돌을 목적으로 엔티티의 형상을 정의하는, 본 명세서에서 콜라이더 컴포넌트(collider component)라고 지칭하는 컴포넌트일 수 있다.

통상적인 게임 또는 시뮬레이션에서, 복수의 엔티티는 이들 엔티티들이 포함하는 컴포넌트들의 타입에서 약간씩 중첩될 것이다(예를 들어, 두 개 이상의 엔티티는 동일한 타입의 하나 이상의 컴포넌트를 가질 것이다). 예를 들면, 장면 내에 다섯 개의 엔티티를 포함하고 각각의 엔티티가 (예를 들어, 각 엔티티마다 독립적인 변환 데이터를 갖는) 변환 컴포넌트를 갖는 게임을 고려해 본다. 실시예에 따르면, 두 개 이상의 엔티티가 정확히 동일한 수 및 타입의 컴포넌트들을 포함할 때, 엔티티들은 본 명세서에서 아키타입(archetype)이라고 지칭된다. 아키타입이 동일한 모든 엔티티는 동일한 수 및 타입의 컴포넌트들을 가지며, 그러므로 엔티티들이 메모리(102)에서 차지하는 영역에 관련하여 유사성들을 공유한다. 그러나, 동일한 아키타입을 갖는 모든 엔티티가 동일한 수 및 타입의 컴포넌트들을 갖더라도, 엔티티에 특정한 컴포넌트 데이터는 다른 엔티티들과는 독립적이다(그리고 통상적으로 상이하다). 실시예에 따르면, ECS 모듈(114)은 (예를 들어, 도 2a, 도 2b, 도 3과 관련하여 설명되고 도 4a, 도 4b 및 도 4c에서 설명되는 방법들과 관련하여 설명되는 바와 같이) 한 아키타입의 복수의 엔티티(예를 들어, 한 아키타입의 모든 엔티티)를 메모리(102) 내에 인접하게 함께 그룹화한다(예를 들어, 배치한다). 단일 아키타입의 복수의 엔티티가 함께 그룹화되는 메모리(102) 내의 위치는 본 명세서에서 청크라고 지칭된다. 청크는 동일한 아키타입을 공유하는 엔티티를 포함하는 메모리(102) 내의 인접 블록(예를 들어, 섹션 또는 영역)이다. 일부 실시예에 따르면, 단일 아키타입은 단일 청크 내에 포함된다. 다른 실시예들에 따르면, 단일 청크가 그 아키타입을 포함하기에 충분히 크지 않다면, 단일 아키타입은 두 개 이상의 청크로 분할될 수 있다. 실시예에 따르면, 청크는 메모리에서 고정된 크기(예를 들어, 16 킬로바이트 또는 64 킬로바이트)를 갖는다.

실시예에 따르면, 도 2a에는 메모리(102) 내의 청크(200)에 대한 데이터 레이아웃의 개략도가 도시된다. 청크(200) 내의 데이터는 (예를 들어, ECS 모듈(114)에 의해) 복수의 섹션으로 나뉘어지고, 하나의 섹션에는 청크(200)와 연관된 아키타입 내의 모든 엔티티에 대한 단일 타입의 컴포넌트(예를 들어, 변환 컴포넌트)의 데이터가 포함된다. 일부 실시예에서, 섹션 내의 데이터는 ECS 모듈(114)에 의해 어레이와 같은 데이터 값 구조 내에서 생성된다. 본 명세서의 설명 전체에서, (예를 들어, 컴포넌트 타입에 대해) 섹션 내의 모든 데이터를 포함하는 어레이는 컴포넌트 데이터 어레이라고 지칭된다. 실시예에 따르면, 도 2a에 도시된 바와 같이, 청크(200) 내의 복수의 상이한 컴포넌트 데이터 어레이는 모든 컴포넌트 데이터가 메모리(102) 내에서 선형적으로 콤팩트하게 (예를 들어, 인접하게) 배치되도록 ECS에 의해 메모리(102)에서 인접하게 놓여진다. 도 2a는 청크(200)가 모두 세 개의 컴포넌트: 제1 컴포넌트(컴포넌트 'A'), 제2 컴포넌트(컴포넌트 'B') 및 제3 컴포넌트(컴포넌트 'C')를 포함하는 복수의 엔티티 (예를 들어 다섯 엔티티)를 갖는 아키타입을 포함하는 예를 도시한다. 컴포넌트(A)에 대한 데이터는 ECS 모듈(114)에 의해 제1 섹션(204A) 내의 제1 데이터 어레이에 배치된다. 컴포넌트(B)에 대한 데이터는 제2 섹션(204B) 내의 제2 데이터 어레이에 배치된다. 컴포넌트(C)에 대한 데이터는 ECS 모듈(114)에 의해 제3 섹션(204C) 내의 제3 데이터 어레이에 배치된다. 아키타입과 연관된 메모리 청크(200) 내에서, 모든 컴포넌트(A) 데이터(예를 들어, 아키타입 내의 모든 엔티티에 대한 컴포넌트(A) 데이터)는 ECS 모듈(114)에 의해 컴포넌트(A) 데이터 어레이(204A) 내에서 인접하게 배치되고, 그 다음으로 모든 컴포넌트(B) 데이터(예를 들어, 아키타입 내의 모든 엔티티에 대한 컴포넌트(B) 데이터)가 ECS 모듈(114)에 의해 컴포넌트(B) 데이터 어레이(204B) 내에 인접하게 배치되고, 그 다음으로 모든 컴포넌트(C) 데이터(예를 들어, 아키타입 내 모든 엔티티에 대한 컴포넌트(C) 데이터)가 ECS 모듈(114)에 의해 컴포넌트(C) 데이터 어레이(204C) 내에 인접하게 배치된다.

실시예에 따르면, 또한 도 2a에 도시된 바와 같이, 청크(200)는 또한 (예를 들어, 엔티티 ID 데이터 어레이(202) 내의) 엔티티 ID 데이터를 포함할 수 있다. 엔티티 ID 데이터는 청크(200)에 포함된 특정 엔티티들을 서술하는 정보를 포함한다. 일부 실시예에서, 엔티티 ID(202)는 각 컴포넌트 데이터 어레이 내의 각 엔티티에 대해 특정 위치 정보(예를 들어, 어레이 요소 번호들)를 포함한다. 예를 들면, 엔티티 ID(202)는 컴포넌트 데이터 어레이 내의 특정 위치(예를 들어, 요소 어레이 번호 12)를 특정 엔티티(예를 들어, 특정 게임 캐릭터 객체를 표현하는 엔티티 123)에 링크하는 정보를 포함할 것이다. 실시예에 따르면, 동일한 청크 내의 모든 컴포넌트 데이터 어레이는 모든 컴포넌트 데이터 어레이(예를 들어, 컴포넌트(A), 컴포넌트(B) 및 컴포넌트(C)) 내의 요소 어레이 번호 12가 엔티티 123에 링크되도록 동일한 순서의 엔티티 데이터를 갖는다.

실시예에 따르면, 도 2b에는 제1 청크(200A)(예를 들어, 청크 'X'로 표시됨) 및 제2 청크(200B)(예를 들어, 청크 'Y'로 표시됨)에 대한 데이터 레이아웃의 개략도가 도시된다. 제1 청크(200A)는 도 2a의 청크(200)와 유사하다. 제2 청크(200B)는 네 개의 컴포넌트: 제1 섹션(208A)의 제1 데이터 어레이 내 제1 컴포넌트(컴포넌트 'A'), 제2 섹션(208B)의 제2 데이터 어레이 내 제2 컴포넌트(컴포넌트 'D'), 제3 섹션(208C)의 제3 데이터 어레이 내 제3 컴포넌트(컴포넌트 'E') 및 제4 섹션(208D)의 제4 데이터 어레이 내 제4 컴포넌트(컴포넌트 'F')를 포함하는 제2 아키타입에 대한 데이터를 포함한다. 두 개의 상이한 아키타입(예를 들어, 제1 청크(200A)의 제1 아키타입 및 제2 청크(200B)의 제2 아키타입)은 하나 이상의 (전부는 아님) 유사한 컴포넌트 타입을 가질 수 있다(예를 들면, 컴포넌트 'A'(204A) 및 컴포넌트 'A'(208A)는 둘 모두 변환 컴포넌트와 같은 동일한 타입의 컴포넌트일 수 있다). 청크 'X'(200A) 내의 컴포넌트 'A'(204A)에 대한 컴포넌트 타입이 청크 'Y'(200B) 내의 컴포넌트 'A'(208A)에 대한 컴포넌트 타입과 유사함에도 불구하고, 두 섹션 내의 데이터는 동일하지 않은데, 그 이유는 두 섹션이 각각 엔티티들의 상이한 세트를 나타내기 때문이다.

실시예에 따르면, 도 3에는 메모리(102) 내의 컴포넌트 데이터 어레이에 대한 메모리 레이아웃의 개략도가 도시된다. 도 3은 도 2a 및 도 2b에서 설명된 청크 'X'(200A) 내의 두 개의 컴포넌트 데이터 어레이에 대한 일부의 내부 데이터 구조를 도시한다. 제1 컴포넌트 데이터 어레이(204A)는 컴포넌트 'A' 데이터를 포함하고, 제2 컴포넌트 데이터 어레이(204B)는 컴포넌트 'B' 데이터를 포함한다. 도 3에 도시된 바와 같이, 제1 컴포넌트 데이터 어레이(204A)는 단지 하나의 타입의 게임 컴포넌트(예를 들어, 변환 컴포넌트와 같은 단지 컴포넌트(A))로부터의 데이터를 포함하며, 어레이(204A)의 각 요소는 상이한 특정 엔티티에 속하는 데이터를 포함한다. 도면에 도시된 예에서, 아키타입 내에는 5 개의 엔티티가 있으며, 제1 컴포넌트 데이터 어레이(204A)는 메모리(102)에서 인접하게 배치된 컴포넌트 'A'에 대한 아키타입 내의 모든 데이터를 포함한다. 보다 구체적으로, 엔티티 1, 엔티티 2, 엔티티 3, 엔티티 4 및 엔티티 5에 대한 컴포넌트 'A' 데이터를 포함하는 다섯 개의 섹션은 각각 제1 섹션(300), 제2 섹션(302), 제3 섹션(304), 제4 섹션(306) 및 제5 섹션(308)에 있고, 그럼으로써 다섯 개의 섹션은 메모리(102)에서 서로 옆에 있다(예를 들어, 인접해 있다). 도 3에 도시된 예에서, 제2 컴포넌트 데이터 어레이(204B)는 메모리(102)에서 인접하게 배치된 컴포넌트 'B'에 대한 아키타입 내의 모든 데이터를 포함한다. 보다 구체적으로, 엔티티 1, 엔티티 2, 엔티티 3, 엔티티 4 및 엔티티 5에 대한 컴포넌트 'B' 데이터를 포함하는 다섯 개의 섹션은 각각 제1 섹션(312), 제2 섹션(314), 제3 섹션(316), 제4 섹션(318) 및 제5 섹션(320)에 있고, 그럼으로써 다섯 개의 섹션은 메모리(102)에서 서로 옆에 있다(예를 들어, 서로 인접해 있다). 실시예에 따르면, 도 3에서 헤더(310)로서 도시된 바와 같이, 컴포넌트 데이터 어레이(예를 들어, 컴포넌트 'B' 데이터 어레이(204B))는 컴포넌트 데이터 앞에 있고 컴포넌트 데이터 어레이에 대한 헤더 데이터 또는 메타 데이터를 포함하는 하나 이상의 섹션을 포함한다.

실시예에 따르면 하나의 엔티티에 대한 데이터의 컴포넌트 데이터 어레이 내의 위치(예를 들어, 어레이 인덱스)는 청크 내의 모든 컴포넌트 데이터 어레이 전체에 걸쳐 일관된다. 예를 들어, 도 3에 도시된 바와 같이, 제1 엔티티(예를 들어, 엔티티 1)는 제1 어레이 인덱스 번호(예를 들어, 어레이 인덱스 0)에 있는 제1 컴포넌트 데이터 어레이(204A)의 제1 섹션(300) 내 컴포넌트 'A' 데이터를 가질 수 있고; 유사하게, 제1 엔티티는 동일한 어레이 인덱스 번호(예를 들어, 어레이 인덱스 0)를 갖는 제2 컴포넌트 데이터 어레이(204B)의 제1 섹션(312) 내의 컴포넌트 'B' 데이터를 가지며; 유사하게 (예를 들어, 도 3에는 도시되지 않음), 제1 엔티티는 동일한 어레이 인덱스 번호(예를 들어, 어레이 인덱스 0)를 갖는 제3 컴포넌트 데이터 어레이(204C)의 제1 섹션 내의 컴포넌트 'C' 데이터를 갖는다. 이러한 방식으로, 컴포넌트 데이터 어레이 내의 엔티티의 위치(예를 들어, 어레이 인덱스 번호)는 청크 내의 상이한 컴포넌트 데이터 어레이들 전체에 걸쳐 일관된다. 예를 들어, 도 3의 예에서, '0'이라는 컴포넌트 데이터 어레이 인덱스는 청크 내의 모든 컴포넌트 데이터 어레이에 대해(예를 들어, 제1 컴포넌트 데이터 어레이(204A), 제2 컴포넌트 데이터 어레이(204B), 제3 컴포넌트 데이터 어레이(204C) 등에 대해) 제1 엔티티(예를 들어, 엔티티 1)를 지칭한다. 유사하게, '1'이라는 컴포넌트 데이터 어레이 인덱스는 청크(200A) 내의 모든 컴포넌트 데이터 어레이들에 대해 제2 엔티티(예를 들어, 엔티티 2)를 지칭하고, '2'라는 컴포넌트 데이터 어레이 인덱스는 청크(200A) 내의 모든 엔티티에 대해 제3 엔티티(예를 들어, 엔티티 3)를 지칭하며, 청크(200A) 내의 모든 엔티티에 대해서도 마찬가지이다.

전술한 바와 같이, 컴포넌트 데이터 어레이 요소는 특정 컴포넌트 및 특정 엔티티와 링크된다. 예를 들면, 도 3에서, 제1 어레이 인덱스 번호(인덱스 0)에 있는 제1 컴포넌트 데이터 어레이(204A)의 제1 섹션(300) 내의 컴포넌트 데이터 어레이 요소는 엔티티 1의 컴포넌트 'A'에 대한 데이터를 지칭한다. 엔티티 1의 컴포넌트 'A'에 대한 데이터를 가진 섹션(300)은 그 컴포넌트에 특정한 데이터를 포함하는 다른 어레이를 포함할 수 있다. 예를 들어, 컴포넌트 'A'가 적어도 9 개의 값(예를 들어, 3 개의 값은 크기, 세 개의 값은 위치, 3 개의 값은 방향에 대한 것)을 필요로 하는 변환 컴포넌트라고 간주하면, 청크(200A)에 대한 제1 컴포넌트 데이터 어레이(204A)의 제1 섹션(300)(및 예를 들면, 모든 다른 섹션들(302, 304, 306 및 308))은 적어도 9 개의 요소의 어레이를 저장한다.

도 2a, 도 2b 및 도 3에 도시된 바와 같이 컴포넌트 데이터 어레이들을 생성하고 구성함으로써, ECS 모듈(114)은 게임 내의 모든 유사한 엔티티들에 대한 단일 컴포넌트 타입 내의 요소들에 대해 (예를 들어, 그 안의 값들을 변경하기 위해) 신속하게 반복할 수 있다(예를 들면, 유사한 엔티티들이 동일한 아키타입 내에 있고 또한 메모리(102) 내에서 동일한 청크 내에 있기 때문이다). 청크 내의 컴포넌트 데이터에 대해 신속한 반복은 도 2a, 도 2b 및 도 3과 관련하여 본 명세서에 설명된 바와 같이 컴포넌트 데이터의 메모리(102) 내에서 데이터의 선형적이고 콤팩트한 (예를 들어, 인접한) 레이아웃을 보장하는 것에 기인한다. 도 3에 도시된 바와 같은 엔티티 데이터의 인접한 선형적 레이아웃 및 도 2a 및 도 2b에 도시된 바와 같은 컴포넌트 데이터 어레이들의 인접한 선형적 레이아웃은 청크 내의 모든 엔티티들에 대해 선형적인 반복을 보장하여, 하드웨어 프리페칭을 최대로 사용할 수 있게 한다. 하드웨어 프리페칭은 CPU가 데이터를 필요로 하기 전에 데이터를 저속 액세스 메모리 위치(예를 들어, 메인 메모리(102))로부터 CPU 내의 고속 액세스 로컬 캐시 메모리(예를 들어, 도 1에 도시된 캐시 메모리(105))로 가져오는 CPU에서 사용되는 기술이다. 도 2a, 도 2b 및 도 3에 도시된 엔티티 및 컴포넌트 데이터의 인접하고 콤팩트한 선형적 레이아웃은 하드웨어 프리페칭 기술들의 효율성을 극대화한다.

메모리(102) 내의 아키타입들 및 아키타입 구조의 예로서, 5 개의 '큐브' 엔티티(예를 들어, 큐브들인 5 개의 게임 객체)를 포함하는 (예를 들어, 비디오 게임 환경의) 게임 장면을 고려해 본다. 이 예에서, 5 개의 엔티티는 2 개의 아키타입으로 그룹화되고 메모리(102)에서 2 개의 청크(예를 들어, 두 개의 아키타입 각각 하나의 청크)를 차지한다. 구체적으로, 이 예의 일부로서, 5 개의 엔티티는 아키타입 I과 아키타입 II로 나뉘어진다. 이 예의 일부로서, 아키타입 I는 '큐브 1', '큐브 2'및 '큐브 3'과 같은 레이블들이 붙은 3 개의 큐브 엔티티를 포함한다. 아키타입 I 내의 모든 엔티티(예를 들어, 세 개의 큐브 엔티티 '큐브 1', '큐브 2'및 '큐브 3')는, 예를 들면, (예를 들어, 엔티티의 크기, 방향, 및 위치를 서술하는) 변환 컴포넌트, (엔티티의 형상을 서술하는) 큐브 컴포넌트, (예를 들어, 엔티티와 연관된 충돌 볼륨을 정의하는) 박스 콜라이더 컴포넌트, (예를 들어, 엔티티에 대한 메쉬의 렌더링 정보를 서술하는) 메쉬 렌더러, (예를 들어, 엔티티의 조명 발생 속성들을 서술하는) 조명 컴포넌트 및 (예를 들어, 엔티티와 연관된 오디오 소스를 서술하는) 오디오 소스 컴포넌트를 비롯한 6 개의 컴포넌트를 포함한다. 따라서, 아키타입 I에 대한 청크는 6 개의 컴포넌트 각각 하나의 어레이를 포함하는 6 개의 컴포넌트 데이터 어레이를 갖는다. 또한 계속하여 예를 참조하면, 아키타입 II는 (예를 들어, '큐브 4' 및 '큐브 5'라는 레이블이 붙은) 2 개의 큐브 엔티티를 포함하며, 두 개의 큐브 엔티티(아키타입 내의 모든 엔티티)는: 변환 컴포넌트, 큐브 컴포넌트, 박스 콜라이더 컴포넌트 및 메쉬 렌더러 컴포넌트를 비롯한 4 개의 컴포넌트를 포함한다. 예에서는 5 개의 큐브가 있지만, 5 개의 큐브는 단일 아키타입에 속할 정도로 충분히 유사하지 않은데, 그 이유는 큐브들 중3 개의 큐브('큐브 1', '큐브 2' 및 '큐브 3')가 한 세트의 컴포넌트들을 포함하지만, 큐브들 중 2 개의 큐브('큐브 4' 및 '큐브 5')가 상이한 세트의 컴포넌트들을 포함하기 때문이다. 그 대신, 5 개의 큐브는 고유한 세트의 컴포넌트 데이터 어레이들을 각각 갖는 두 개의 상이한 아키타입(예를 들어, 아키타입 I 및 아키타입 II))으로 그룹화된다.

도 2a, 도 2b 및 도 3에 도시된 바와 같이 청크들 내에서 메모리(102)를 패킹하는 방법은 ECS 모듈(114)이 개개의 컴포넌트들에 대한 데이터에 매우 효율적으로 액세스하게 해준다. 제1 컴포넌트에 대한 데이터에 액세스하는 것은 제2 컴포넌트에 대한 데이터에 액세스하는 것과 무관하다. 예를 들어, 아키타입 내의 하나 이상의 엔티티에 대한 한 가지 타입의 게임 컴포넌트 데이터(예를 들어, 변환 데이터)에 액세스하는 것은 동일한 하나 이상의 엔티티에 대한 모든 다른 게임 컴포넌트 데이터를 (예를 들어, 메모리(102)로부터 캐시(105) 내로) 로딩하는 것을 수반하지 않는다. 특정 예로서, 전술한 아키타입 1을 고려해 보자. 아키타입 1에 대해, 아키타입 내의 엔티티들에 대한 변환 컴포넌트 데이터를 변경하는 것은 다른 컴포넌트 데이터 중 임의의 데이터; 즉, 큐브 컴포넌트 데이터, 박스 콜라이더 컴포넌트 데이터, 메쉬 렌더러 컴포넌트 데이터, 조명 컴포넌트 데이터 및 오디오 소스 컴포넌트 데이터를 (예를 들어, 메모리(102)로부터 캐시(105)에) 로딩하는 것을 수반하지 않는다.

실시예에 따르면, 도 4a에는 엔티티(예를 들어, 새로운 엔티티 또는 수정된 엔티티)를 기존의 청크들 (및 연관된 아키타입들)을 포함하는 ECS 시스템에 통합하기 위한 컴퓨터에 의해 구현되는 방법(400)의 흐름도가 도시된다. 컴퓨터에 의해 구현되는 방법(400)(이하, "방법(400)"이라고 지칭함)은 적어도 하나의 하드웨어 프로세서 및 메모리(102)를 포함하는 (예를 들어, ECS 디바이스(101)와 같은) 컴퓨팅 디바이스에 의해 수행된다. 동작 동안 (예를 들어, 게임 진행 동안), 게임 내의 이벤트는 엔티티를 통합하기 위한 방법(400)을 요구할 수도 있는 새로운 엔티티(또는 기존 엔티티의 수정본)의 생성을 필요로 할 수 있다. 방법은 ECS 모듈(114)이 청크로 통합될 엔티티를 수신할 때(수신하는 것의 상세 내용들은 본 명세서에서 도 4b 및 도 4c와 관련하여 설명됨) 프로세스(404)에서 시작한다. 프로세스(406)에서, ECS 모듈(114)은 수신된 엔티티 내의 컴포넌트들을 (예를 들어, 메모리(102)에 기존부터 있는) 기존의 아키타입 청크들 내의 컴포넌트들과 비교하여 수신된 엔티티를 기존의 아키타입들 중 하나로 분류하려고 시도한다. 프로세스(408)에서, 프로세스(406)의 비교에 기초하여, 수신된 엔티티가 (예를 들어, 기존의 아키타입 내의 엔티티들과 동일한 수 및 타입의 컴포넌트들을 갖는) 기존의 아키타입과 컴포넌트 가능하여 기존의 아키타입으로 분류되는지 또는 수신된 엔티티가 기존의 아키타입으로 분류되지 않는지에 관해 판단이 이루어진다. 수신된 엔티티가 기존의 아키타입으로 분류된다면, 프로세스(416)에서, 수신된 엔티티가 기존의 아키타입으로 분류되는 것에 기초하여, 수신된 엔티티 내의 각각의 컴포넌트에 대해, ECS 모듈(114)은 컴포넌트로부터의 데이터를 분류된 기존의 청크(예를 들어, 분류된 기존의 아키타입과 관련된 청크) 내의 동일한 타입의 연관된 컴포넌트 데이터 어레이에 추가한다(예를 들면, 수신된 엔티티로부터의 컴포넌트 'A' 데이터를 컴포넌트 'A' 데이터 어레이의 끝에 추가한다). 프로세스(410)에서, 수신된 엔티티가 기존의 아키타입으로 분류되지 않은 것에 기초하여, ECS 모듈(114)은 수신된 엔티티로부터의 컴포넌트들을 사용하여 메모리(102)에 (새로운 아키타입에 대한) 새로운 청크를 생성한다. 프로세스(412)에서, ECS 모듈(114)은 새로운 청크 내에서, 수신된 엔티티 내의 각각의 컴포넌트 타입에 대해 하나의 새로운 컴포넌트 데이터 어레이를 생성한다. ECS 모듈(114)은 생성된 어레이들을 수신된 엔티티로부터의 연관된 컴포넌트 데이터로 채운다.

실시예에 따르면, 도 4b에는 새로운 엔티티를 생성하기 위한 컴퓨터에 의해 구현되는 방법(420)의 흐름도가 도시된다. 컴퓨터에 의해 구현되는 방법(420)(이하, "방법(420)"이라고 지칭함)은 적어도 하나의 하드웨어 프로세서 및 메모리(102)를 포함하는 (예를 들어, ECS 디바이스(101)와 같은) 컴퓨팅 디바이스에 의해 수행된다. 동작 동안(예를 들어, 게임 진행 동안), 프로세스(422)에서, 게임 내의 이벤트는 새로운 엔티티(예를 들어, 생성물/캐릭터의 산란, 무기의 발사, 캐릭터의 움직임 등)을 생성할 것을 요구한다. 프로세스(424)에서, 새로운 엔티티의 생성을 요구하는 게임 진행 이벤트에 기초하여, ECS 모듈(114)은 적어도 하나의 컴포넌트를 갖는 새로운 엔티티를 생성한다. 생성된 엔티티는 이벤트에 기초하여 엔티티를 생성하기 위한 한 세트의 규칙들(예를 들어, 게임 개발자에 의해 만들어진 규칙들)에 기초한 복수의 컴포넌트를 전형적으로 포함할 것이다. 예를 들어, 게임 캐릭터에 대한 새로운 엔티티의 생성은 캐릭터의 크기, 위치, 방향, 형상, 텍스처, 물리적 현상 등에 대한 데이터를 포함했던 컴포넌트들을 포함할 것이다. 컴포넌트들 내의 값들은 (예를 들어, 디폴트 값들 및 엔티티의 생성을 개시했던 프로세스(422)에서 이벤트에 의해 결정된 값들을 포함하는) 규칙들에 의해 결정될 것이다. 그 다음에 ECS 모듈(114)은 방법(400)을 사용하여 새로운 엔티티를 엔티티 아키타입에 통합한다.

실시예에 따르면, 도 4c에는 기존 엔티티를 수정하기 위한 방법(450)의 흐름도가 도시된다. 컴퓨터에 의해 구현되는 방법(450)(이하 "방법(450)"이라고 지칭함)은 적어도 하나의 하드웨어 프로세서 및 메모리(102)를 포함하는 (예를 들어, ECS 디바이스(101)와 같은) 컴퓨팅 디바이스에 의해 수행된다. 동작 동안(예를 들어, 게임 진행 동안), 게임 내의 이벤트(422)는 (예를 들어, 객체가 이동되고 변환 컴포넌트가 수정될 때와 같이 컴포넌트 데이터 또는 그 안에서의 거동들이 추가, 삭제 또는 수정을 통해 수정된다면) 기존의 엔티티의 수정을 요구할 수 있다. 프로세스(452 및 454)에서, ECS 모듈(114)은 수정된 엔티티에 대한 아키타입이 컴포넌트 타입의 추가 또는 삭제로 인해 변경되었는지를 결정한다. 프로세스(456)에서, 아키타입이 변경되지 않은 것에 기초하여, ECS 모듈(114)은 게임 진행 이벤트로부터의 새로운 데이터를 사용하여 수정된 엔티티와 관련된 기존의 컴포넌트 어레이들 내의 데이터를 업데이트한다. 데이터를 업데이트하기 위해, ECS 모듈(114)은 메모리(102)로부터 캐시(105)로 데이터를 로딩하고, 이를 수정한 다음, 이를 메모리(102)에 다시 기입한다. 프로세스(460)에서, 수정된 엔티티의 아키타입이 변경되는 것에 기초하여, ECS 모듈(114)은 수정된 엔티티와 관련된 데이터를 원래의 아키타입(예를 들어, 수정되기 이전 엔티티의 아키타입) 컴포넌트 데이터 어레이들로부터 삭제한다. 프로세스(462)에서, ECS 모듈(114)은 (예를 들어, 도 6a, 도 6b 및 도 6c와 관련하여 설명되는 바와 같이) 구(old) 아키타입 내의 나머지 엔티티 데이터를 이동시켜 삭제로 인해 생성된 컴포넌트 데이터 어레이들 내의 임의의 빈 공간을 채운다. 프로세스(400)에서, 수정된 엔티티의 아키타입이 변경되는 것에 기초하여, ECS 모듈(114)은 수정된 엔티티를 엔티티 아키타입에 통합한다.

실시예에 따르면, 엔티티의 거동은 하나 이상의 컴포넌트 내의 데이터에 액세스하여 수정하는 프로그래밍 코드 (또는 시스템 코드)에 의해 결정된다. ECS 시스템에서 엔티티의 거동은 함수들을 사용하여 컴포넌트 데이터에 작용시킴으로써 수행된다. 함수들은 하나 이상의 컴포넌트 데이터 어레이의 요소들에 대해 (예를 들어, 루프들을 사용하여) 반복하는 것을 포함한다.

실시예에 따르면, 도 5의 흐름도에는 ECS 모듈(114)이 복수의 엔티티를 발견하고 복수의 엔티티의 컴포넌트들 내의 데이터를 수정 또는 판독하기 위해 복수의 엔티티의 컴포넌트들에 대해 반복하는 컴퓨터에 의해 구현되는 방법(500)이 도시된다. 컴퓨터에 의해 구현되는 방법(500)(이하 "방법(500)"이라고 지칭함)은 적어도 하나의 하드웨어 프로세서 및 메모리(102)를 포함하는 (예를 들어, ECS 디바이스(101)와 같은) 컴퓨팅 디바이스에 의해 수행된다. 방법(500)은 ECS 모듈(114)이 (예를 들어, 엔티티에 대한 컴포넌트들 내의 데이터를 변경함으로써) 복수의 엔티티의 특성들을 수정 또는 판독하라는 명령어들을 (예를 들어, 게임 엔진(112)을 통해 게임의 사용자로부터) 수신할 때 시작한다. 실시예에 따르면, 프로세스(502)에서, ECS 모듈(114)은 컴포넌트들의 제1 리스트, 컴포넌트들의 제2 리스트 및 명령어들을 (예를 들어, 게임 엔진으로부터 또는 사용자로부터) 수신한다. 컴포넌트들의 제1 리스트는 명령어들에 따라 수정할 하나 이상의 컴포넌트(예를 들어, 변환 컴포넌트, 콜라이더 컴포넌트 등)의 이름들 (또는 레이블들)을 포함한다. 명령어들은 컴포넌트들의 제1 리스트 상의 하나 이상의 컴포넌트 내의 데이터를 변경하기 위한 세부 내용들(예를 들면, 수학 공식들을 사용하여 수학 값들을 변경하는 것 및 리스트로부터 값들을 선택하는 것을 포함함)을 포함한다. 컴포넌트들의 제2 리스트는 수정될 복수의 엔티티를 찾기 위한 기준들을 제공한다. 제2 리스트는 찾아서 수정될 복수의 엔티티에 포함되어야 하는 하나 이상의 컴포넌트의 이름들 (또는 레이블들)을 포함한다. 프로세스(504)에서, ECS 모듈(114)은 게임 세계 환경 (또는 시뮬레이션 환경) 내의 모든 아키타입을 처음부터 끝까지 검색하여 컴포넌트들의 제2 리스트 내의 하나 이상의 모든 컴포넌트를 포함하는 컴포넌트들을 갖는 한 세트의 아키타입들을 찾는다. 이러한 검색은 청크에 대한 엔티티 ID 데이터(202, 206)를 통해 검색하는 것을 포함할 수 있다. 세트 내의 아키타입들은 각각 제2 리스트 상의 모든 컴포넌트들을 적어도 가지고 있어야 한다. 프로세스(506)에서, 발견된 각 아키타입에 대해, ECS 모듈(114)은 발견된 아키타입과 연관된 하나 이상의 청크를 찾고, 발견된 각 청크에 대해, 명령어들에 따라 청크 내의 컴포넌트들의 제1 리스트로부터의 하나 이상의 컴포넌트를 처음부터 끝까지 반복하여 수정한다. 컴포넌트는 ECS 모듈(114)에 의해 컴포넌트의 요소들을 처음부터 끝까지 반복함으로써 수정되며, 수정될 각각의 요소는 메모리(102)로부터 캐시(105)로 판독되고, 캐시에서 각각의 요소는 수정된 다음 메모리(102)에 다시 기입된다. 일부 실시예들에서, 프로세스(506)에서 각 아키타입 내의 컴포넌트들의 수정은 병렬로 수행되는데, 그럼으로써 제1 아키타입에 대해 수정하는 것들은 제2 아키타입에 대해 수정하는 것들과 무관하다(예를 들면, 제1 아키타입에 대해 수정하는 것들은 제1 CPU 코어에서 수행되고 제2 아키타입에 대해 수정하는 것들은 제2 CPU 코어에서 수행된다). 일부 실시예들에서, 프로세스(506)의 일부로서, ECS 모듈(114)은 컴포넌트들의 제1 리스트 상의 각 컴포넌트에 대한 모든 데이터의 링크된 리스트(예를 들어, 각 컴포넌트마다 하나의 링크된 리스트)를 생성하며, 링크된 리스트는 각 청크에 대한 데이터의 어레이를 포함한다. 링크된 리스트 내의 데이터는 메모리 내에서 이동되지 않으며, 그 대신에 링크된 리스트는 데이터가 복수의 청크 사이에서 분할된다는 사실을 숨기기 위해 하나의 청크로부터 다른 청크까지 메모리를 통한 경로를 제공한다.

도 5의 흐름도에 도시된 방법의 예로서, 게임 엔진이 제1 컴포넌트를 수정하기 위해 ECS 모듈(114)에게 지시하여 제1 컴포넌트(예를 들어, 컴포넌트(A)) 및 제2 컴포넌트(예를 들어, 컴포넌트(B))를 포함하는 모든 엔티티를 찾게 하는 상황을 고려해 보자. 이 예에서 제1 컴포넌트 리스트는 컴포넌트(A)를 포함하고 있고, 반면에 제2 컴포넌트 리스트는 컴포넌트(A) 및 컴포넌트(B)를 포함하고 있다. 아마도 컴포넌트(A)는 변환 컴포넌트이고 컴포넌트(B)는 콜라이드 컴포넌트이다. 이 예에서, 4 개의 아키타입 내에 복수의 엔티티를 포함하는 게임 환경(또는 시뮬레이션 환경)을 고려해 본다. 제1 아키타입(예를 들어, 아키타입 1)은 단일 컴포넌트: 컴포넌트(A))만 갖는 모든 엔티티를 포함한다. 제2 아키타입(예를 들어, 아키타입 2)은 두 개의 특정 컴포넌트: 컴포넌트(A) 및 컴포넌트(B)를 포함하는 모든 엔티티를 포함한다. 제3 아키타입(예를 들어, 아키타입 3)은 세 개의 특정 컴포넌트: 컴포넌트(A), 컴포넌트(B) 및 컴포넌트(C)를 포함하는 모든 엔티티를 포함한다. 제4 아키타입(예를 들어, 아키타입 4)은 세 개의 특정 컴포넌트: 컴포넌트(D), 컴포넌트(E) 및 컴포넌트(F)를 포함하는 모든 엔티티를 포함한다.

아키타입 1: [A]

아키타입 2: [A, B]

아키타입 3: [A, B, C]

아키타입 4: [D, E, F]

예를 계속 참조하면, 게임 환경은 네 개의 아키타입 각각 내에 복수의 엔티티를 포함한다. 예를 들어, 아키타입 1에는 5 개의 엔티티가 있고, 아키타입 2에는 300 개의 엔티티가 있고, 아키타입 3에는 2,000 개의 엔티티가 있으며, 아키타입 4에는 10,000 개의 엔티티가 있는 상황을 고려해 본다. 이 예의 일부로서, 아키타입 1의 5 개 엔티티는 제1 청크에 있고, 아키타입 2의 300 개 엔티티는 제2 청크에 있고, 아키타입 3의 2,000 개 엔티티는 제3 청크와 제4 청크 사이에 나뉘어져 있으며, 아키타입 4의 10,000 개 엔티티는 다른 5 개 청크 사이에 나뉘어져 있다는 것을 고려해 본다. 이 예에서, ECS 모듈(114)은 게임 엔진에 의해 지시를 받아 컴포넌트(A)(예를 들어, 변환 컴포넌트)에 대해 반복한다. 이 예에서, ECS 모듈(114)은 다음과 같이 수행할 것이다:

1) ECS 모듈(114)은 컴포넌트(A) 및 컴포넌트(B)(예를 들어, 컴포넌트들의 제2 리스트로부터의 모든 컴포넌트) 둘 모두를 포함하는 특정 아키타입들을 찾기 위해 모든 아키타입에 대해 검색한다. 이 예에서, 컴포넌트(A) 및 컴포넌트(B) 둘 모두를 포함하는 2 개의 아키타입: 아키타입 2 및 아키타입 3이 있다(예를 들어, 아키타입 1은 컴포넌트(B)가 누락되어 있기 때문에 양립 가능하지 않고, 아키타입 4는 컴포넌트(A) 및 컴포넌트(B)가 둘 모두 누락되어 있기 때문에 양립 가능하지 않다)).

2) 찾아낸 각 아키타입(예를 들어, 아키타입 2 및 아키타입 3)에 대해, ECS 모듈(114)은 아키타입과 연관된 하나 이상의 청크를 찾는다. 이 예에서, ECS 모듈(114)은 반복할 3 개의 청크: 아키타입 II와 연관된 제2 청크 및 아키타입 III과 연관된 제3 청크 및 제4 청크를 가질 것이다.

3) 찾아낸 각 청크 내에서, ECS 모듈(114)은 수신된 명령어들에 기초하여 청크의 한쪽 끝부터 다른 쪽 끝까지 모든 엔티티들에 대한 컴포넌트(A) 내의 데이터를 순차적으로 수정한다(예를 들면, 각각의 엔티티는 상이하게 수정될 수 있다). 컴포넌트는 ECS 모듈(114)에 의해 컴포넌트의 요소들을 처음부터 끝까지 반복함으로써 수정되며, 수정될 각각의 요소는 메모리(102)로부터 캐시(105)로 판독되고, 캐시에서 수정된 다음 메모리(102)에 다시 기입된다. 이 예에서, ECS 모듈(114)은 먼저 아키타입 2와 연관된 청크에 대해 반복하고 수정 명령어들의 세부 내용들에 따라 아키타입 2 내 300 개의 엔티티에 대한 컴포넌트(A)를 수정할 수 있다. 동시에 또는 순차적으로, ECS 모듈(114)은 아키타입 3 내 2,000 개 엔티티에 대한 컴포넌트(A)를 청크의 한쪽 끝에서 다른 쪽 끝까지 순차적으로 수정함으로써 아키타입 3과 연관된 제3 청크 및 제4 청크를 수정한다. 엔티티들 내의 데이터는 (예를 들어, 도 3에 도시된 것과 유사하게) 각각의 청크 내에서 선형적으로 콤팩트하게 (예를 들어, 인접하게) 패킹되기 때문에 수정은 매우 빠르며, 이는 하드웨어 프리페칭 사용을 극대화할 수 있게 해준다.

게임/사용자가 종종 아키타입 내의 모든 엔티티 전체에 걸쳐 동일한 타입의 데이터(예를 들어, 동일한 컴포넌트)를 대량으로 액세스하기를 원하기 때문에, ECS에 의한 메모리의 인접한 패킹은 큰 그룹의 유사한 엔티티들(예를 들면, 아키타입)을 다룰 때 유용하다. 예를 들어, 위의 예에서 아키타입 3 내의 2,000 개 엔티티는 논플레이어 캐릭터(Non-Player Character)(NPC)들을 나타내며, 게임/사용자는 (예를 들어, 근방에서의 폭발로 인해) 엔티티들 모두의 위치 데이터를 변경하고 싶어 한다고 가정한다. ECS 모듈(114)은 데이터가 (예를 들어, 도 3에 도시되고 설명된 바와 같이) 하나의 긴 인접한 메모리 블록에 있기 때문에 모든 2000 개의 NPC 엔티티들에 대한 (예를 들어, 변환 컴포넌트의 일부인) 위치 데이터를 신속하게 변경할 수 있다.

엔티티의 삭제

실시예에 따르면 ECS 모듈(114)은 메모리(102)에 액세스할 때 높은 효율을 유지하기 위해 (예를 들어, 삭제된 엔티티에 의해 야기되는 공백들을 제거함으로써) 아키타입 청크 내의 모든 생생한 엔티티들을 메모리에서 빼곡히 패킹된 상태로 유지하도록 작동한다. ECS 모듈(114)은 (예를 들어, 캐릭터 또는 다른 객체와 같은 엔티티가 게임 중에 폭파되어 더 이상 존재하지 않으면) 삭제된 엔티티로부터의 엔티티 데이터를 높은 우선순위로 청크로부터 제거한다. 게임 진행 중에 (예를 들어, 게임 진행 이벤트로 인해) 엔티티가 삭제될 때, 삭제된 엔티티에 할당되었던 각 컴포넌트 데이터 어레이 내의 메모리 공간은 다른 유사한 생생한 엔티티(예를 들어, 삭제되지 않는 동일한 아키타입으로부터의 다른 엔티티)의 컴포넌트 데이터로 채워질 수 있다. ECS에서 엔티티 삭제의 예는 도 6a 및 도 6b에 도시된다. 도 6a는 엔티티를 삭제하기 이전에, 도 3에서 설명한 것과 유사한 두 개의 컴포넌트 데이터 어레이를 도시하고, 도 6b는 엔티티를 삭제한 이후의 동일한 두 개의 컴포넌트 데이터 어레이를 도시한다. 실시예에 따르면, 예에서 도시된 바와 같이, 엔티티 데이터가 컴포넌트 데이터 어레이 내부로부터 (예를 들어, 어레이의 중간)에서 삭제될 때, ECS 모듈(114)은 컴포넌트 데이터 어레이 내 마지막 엔티티(예를 들어, 어레이 끝에 있는 엔티티)와 연관된 데이터를 삭제된 엔티티 데이터에 의해 만들어진 빈 메모리 공간으로 이동시킨다. 삭제된 엔티티는 (예를 들어, 컴포넌트 데이터 어레이들 각각에 동일한 인덱스 번호에 있는) 아키타입 내 어레이들 각각에 있는 데이터를 갖기 때문에, 아키타입 내의 모든 컴포넌트 데이터 어레이들에 대해서는 동일한 데이터 이동이 수행된다. 예를 들면, 도 6a에 도시된 바와 같이, 게임 진행 이벤트는 엔티티 2가 게임으로부터 삭제(예를 들어, 제거)되게 하였다. 도 6a는 (인덱스 1에 대한 섹션(302)에 있는) 컴포넌트(A) 데이터 어레이(204A) 내의 데이터 및 (인덱스 1에 대한 섹션(314)에 있는) 컴포넌트(B) 데이터 어레이(204B) 내의 데이터를 포함하는 엔티티 2에 대한 모든 데이터가 도면에서 도시된 바와 같이 각 섹션들 위에 'X'에 의해 삭제되는 것을 도시한다. 도 6a 및 도 6b에서 도시되지 않은 다른 컴포넌트 데이터 어레이들(예를 들어, 컴포넌트(C) 데이터 어레이(204C)) 내의 엔티티 2에 대한 다른 데이터도 역시 삭제될 것이다. 도 6b는 컴포넌트(A) 데이터 어레이(204A)에 대한 메모리(102) 내의 빈 섹션(302) 및 컴포넌트(B) 데이터 어레이(204B)에 대한 메모리(102) 내의 빈 섹션(314)을 도시한다. 이 예에 따르면, ECS 모듈(114)은 삭제로 인해 유발된 메모리 내의 빈 섹션들을 채우기 위해 청크에 대한 모든 컴포넌트 데이터 어레이 내 마지막 엔티티(예를 들어, 도면에서 인덱스 4로 도시된 마지막 위치)의 데이터를 이동시킬 것이다. 따라서, ECS 모듈(114)은 컴포넌트(A) 데이터 어레이(204A) 내의 (예를 들어, 인덱스 4에 있는) 마지막 섹션(308)으로부터의 엔티티 5에 대한 데이터를 인덱스 1에 대한 섹션(302)으로 이동시켜 삭제된 엔티티 데이터를 대체할 것이다. 유사하게, ECS 모듈(114)은 (예를 들어, 인덱스 4에 있는) 컴포넌트(B) 데이터 어레이(204B) 내의 마지막 섹션(320)으로부터의 엔티티 5에 대한 데이터를 인덱스 1에 대한 섹션(314)으로 이동시켜 삭제된 엔티티 데이터를 대체할 것이다. 데이터의 이동은 도 6b에서 섹션(308)으로부터 섹션(302)으로 그리고 섹션(320)으로부터 섹션(314)으로 두 개의 화살표로 상징적으로 도시된다. 도 6c는 데이터 엔티티 5에 대한 데이터가 이동된 이후의 두 컴포넌트(A) 데이터 어레이(204A) 및 컴포넌트(B) 데이터 어레이(204b)를 도시하는데, 여기서 엔티티 5에 대한 데이터는 삭제에 의해 야기된 메모리 내의 공백들을 채웠으며, 컴포넌트 데이터 어레이들(204A 및 204B)은 콤팩트하고, 인접하며 선형적인 메모리 밀도 레이아웃을 되찾았다. 일부 실시예에 따르면, (예를 들어, 컴포넌트(A) 데이터 어레이(204A)의 끝에 있는 인덱스 4에 대한 섹션(308) 및 컴포넌트(B) 데이터 어레이(204B)의 끝에 있는 인덱스 4에 대한 섹션(320)과 같이) 컴포넌트 데이터 어레이의 끝에 있는 빈 메모리 공간들은 아키타입에 추가될 수 있는 새로운 엔티티들에 필요한 공간을 절약하기 위해 ECS 모듈(114)에 의해 비워둘 수 있다. 엔티티 ID 데이터는 삭제된 엔티티 데이터의 제거 및 삭제로 인해 이동된 엔티티 데이터의 위치의 변경을 반영하도록 수정될 수 있다(예를 들어, 청크 내의 엔티티들의 수를 삭제 전보다 하나 적게 변경하는 것을 포함할 수 있다). 따라서, ECS 모듈(114)은 컴포넌트 데이터 어레이 (및 청크) 내의 메모리를 생생한 엔티티들로 빼곡히 패킹되는 상태로 능동적으로 유지하기 때문에, 컴포넌트 데이터 어레이 내에서 영구적인 메모리 홀(memory hole)들은 존재하지 않는다.

실시예에 따르면 도 7a 및 도 7b의 흐름도에는 ECS 모듈(114)이 (예를 들어, 클래스 구조를 갖는) 객체 지향 프로그래밍(OOP) 게임 객체를 엔티티로 변환하는 컴퓨터에 의해 구현되는 방법(600)이 도시된다. 컴퓨터에 의해 구현되는 방법(600) (이하, "방법(600)"이라고 지칭함)은 적어도 하나의 하드웨어 프로세서 및 메모리(102)를 포함하는 (예를 들어, ECS 디바이스(101)와 같은) 컴퓨팅 디바이스에 의해 수행된다. 실시예에 따르면, 프로세스(602)에서, ECS 모듈(114)은 엔티티로 변환될 (예를 들어, 외부 모듈로부터) OOP 게임 객체를 수신한다. 프로세스(604)에서, ECS 모듈(114)은 그 내부의 데이터를 분석한다. 분석 중에, ECS 모듈은 OOP 게임 객체로부터 OOP 컴포넌트들의 리스트 및 리스트상의 컴포넌트들 각각을 정의하는 OOP 데이터를 추출한다. OOP 데이터는 OOP 프로그래밍할 때의 변수들을 나타낸다. 프로세스(606)에서, ECS 모듈(114)은 리스트상의 컴포넌트에 대한 OOP 데이터(예를 들어, 변수들)를 추출한다. 예를 들어, OOP 게임 객체는 4 개의 컴포넌트를 가질 수 있고, 4 개의 컴포넌트 각각은 ECS 모듈(114)이 4 개의 컴포넌트 각각의 변수를 추출하도록 별개의 변수들을 갖고 있다. 프로세스(608)에서, ECS 모듈(114)은 추출된 컴포넌트들의 리스트를 사용하여 리스트 내의 컴포넌트들을 ECS 환경의 기존의 아키타입들 내의 컴포넌트들과 비교함으로써 OOP 객체를 기존의 엔티티 아키타입(예를 들어, 이전에 메모리(102)에서 생성된 엔티티 아키타입)으로 분류한다. OOP 객체로부터의 컴포넌트들의 리스트가 기존의 아키타입들 중 하나에 대한 컴포넌트들의 리스트와 정확히 매칭하면, OOP 객체는 매칭된 기존의 아키타입과 양립 가능하다. OOP 객체 컴포넌트 리스트가 기존의 아키타입 컴포넌트 리스트와 매칭하는 것에 기초하여, 프로세스(612)에서, OOP 게임 객체 내의 각 컴포넌트에 대해, ECS 모듈(114)은 OOP 컴포넌트로부터의 데이터를 매칭된 기존의 아키타입과 연관된 청크 내의 연관된 ECS 컴포넌트 데이터 어레이에 추가한다. 실시예에 따르면, 데이터는 (예를 들어, 컴포넌트 데이터 어레이가 항상 데이터로 완전히 패킹되기 때문에) 컴포넌트 데이터 어레이의 끝에 추가된다. 또한 컴포넌트 데이터 어레이에 대한 엔티티 ID 데이터는 추가된 컴포넌트 데이터를 포함하도록 업데이트된다. OOP 객체 컴포넌트 리스트가 기존의 아키타입 컴포넌트 리스트와 매칭하지 않는 것에 기초하여, 프로세스(616)에서, ECS 모듈(114)은 엔티티에 대한 새로운 아키타입 청크를 생성한다. 프로세스(618)에서, OOP 게임 객체 내의 각 컴포넌트 타입에 대해, ECS 모듈(114)은 컴포넌트 데이터 어레이를 생성하고 OOP 컴포넌트로부터의 데이터를 새로 생성된 청크 내의 컴포넌트 데이터 어레이에 추가한다.

블록도들에서는 별개의 컴포넌트 그룹들이 별개의 데이터 신호 연결들을 통해 서로 통신하는 것으로 도시되어 있지만, 관련 기술분야에서 통상의 기술자라면 바람직한 실시예들은 하드웨어 및 소프트웨어 컴포넌트들의 조합에 의해 제공되며, 이 때 일부 컴포넌트는 하드웨어 또는 소프트웨어 시스템의 주어진 기능 또는 동작에 의해 구현되고, 도시된 많은 데이터 경로는 컴퓨터 애플리케이션 또는 운영 체제 내에서 데이터 통신에 의해 구현된다는 것임을 이해할 것이다. 따라서 도시된 구조는 본 바람직한 실시예를 효율적으로 교시하기 위해 제공된다.

본 개시 내용은 방법으로서 수행될 수 있고, 시스템에서, 컴퓨터 판독 가능한 매체 또는 전기 또는 전자기 신호로 구현될 수 있음을 알아야 한다. 위에서 설명되고 첨부 도면들에서 도시된 실시예들은 단지 예시적인 것으로 의도된다. 관련 기술분야에서 통상의 기술자에게는 본 개시 내용을 벗어나지 않으면서 수정들이 이루어질 수 있음이 명백할 것이다. 이러한 수정들은 가능한 변형들이라고 간주되며 본 발명의 범위 내에 있다.

특정 실시예들은 본 명세서에서 로직 또는 다수의 컴포넌트, 모듈 또는 메커니즘을 포함하는 것으로 설명된다. 모듈들은 소프트웨어 모듈들(예를 들어, 머신 판독 가능한 매체상에서 구현되거나 또는 전송 신호 내에서 구현된 코드) 또는 하드웨어 모듈 중 어느 하나를 구성할 수 있다. "하드웨어 모듈"은 특정 동작들을 수행할 수 있는 유형의 유닛이며 특정한 물리적인 방식으로 구성되거나 정렬될 수 있다. 다양한 예시적인 실시예에서, 하나 이상의 컴퓨터 시스템(예를 들면, 스탠드얼론 컴퓨터 시스템, 클라이언트 컴퓨터 시스템 또는 서버 컴퓨터 시스템) 또는 컴퓨터 시스템(예를 들어, 프로세서 또는 프로세서들의 그룹)의 하나 이상의 하드웨어 모듈은 본 명세서에 설명된 바와 같은 특정 동작들을 수행하도록 동작하는 하드웨어 모듈로서 소프트웨어(예를 들어, 애플리케이션 또는 애플리케이션 부분)에 의해 구성될 수 있다.

일부 실시예에서, 하드웨어 모듈은 기계적으로, 전자적으로 또는 이들의 임의의 적합한 조합으로 구현될 수 있다. 예를 들어, 하드웨어 모듈은 특정 동작들을 수행하도록 영구적으로 구성된 전용 회로 또는 로직을 포함할 수 있다. 예를 들어, 하드웨어 모듈은 필드 프로그램 가능한 게이트 어레이(Field-Programmable Gate Array)(FPGA) 또는 주문형 집적 회로(application specific integrated circuit(ASIC)와 같은 특수 목적 프로세서일 수 있다. 하드웨어 모듈은 또한 특정 동작들을 수행하기 위해 일시적으로 소프트웨어에 의해 구성되는 프로그램 가능한 로직 또는 회로를 포함할 수 있다. 예를 들어, 하드웨어 모듈은 범용 프로세서 또는 다른 프로그램 가능한 프로세서 내에 포함된 소프트웨어를 포함할 수 있다. 전용의 영구적으로 구성된 회로에서, 또는 일시적으로 구성된 (예를 들어, 소프트웨어에 의해 구성된) 회로에서 하드웨어 모듈을 기계적으로 구현하려는 결정은 비용 및 시간을 고려함으로써 결정이 내려질 수 있다는 것이 인식될 것이다.

따라서, "하드웨어 모듈"이라는 문구는 물리적으로 구성되거나, 영구적으로 구성되거나(예를 들어, 하드웨어에 내장되거나) 일시적으로 구성(예를 들어, 프로그래밍)되어, 특정 방식으로 동작하거나 본 명세서에서 설명된 특정 동작들을 수행하는 엔티티인 유형의 엔티티를 포함하는 것으로 이해되어야 한다. 본 명세서에 사용된 바와 같이, "하드웨어에 의해 구현되는 모듈"은 하드웨어 모듈을 지칭한다. 하드웨어 모듈들이 일시적으로 구성되는(예를 들어, 프로그래밍되는) 실시예들을 고려하면, 하드웨어 모듈들 각각은 임의의 하나의 시점에서 구성되거나 인스턴스화될 필요가 없다. 예를 들어, 하드웨어 모듈이 소프트웨어에 의해 특수 목적 프로세서가 되도록 구성된 범용 프로세서를 포함하는 경우, 범용 프로세서는 상이한 시간에 (예를 들어, 상이한 하드웨어 모듈들을 포함하는) 제각기 상이한 특수 목적 프로세서들로서 구성될 수 있다. 따라서, 소프트웨어는 특정 프로세서 또는 프로세서들을 구성하여, 예를 들어 하나의 시간 인스턴스에서 특정 하드웨어 모듈을 구성하고 다른 시간 인스턴스에서 상이한 하드웨어 모듈을 구성할 수 있다.

하드웨어 모듈들은 다른 하드웨어 모듈들에 정보를 제공하고 다른 하드웨어 모듈들로부터 정보를 수신할 수 있다. 따라서, 설명된 하드웨어 모듈들은 통신 가능하게 연결되는 것으로 간주될 수 있다. 동시에 다수의 하드웨어 모듈이 존재하는 경우, 통신은 두 개 이상의 하드웨어 모듈 사이에서 또는 이들끼리 신호 전송을 통해 (예를 들어, 적절한 회로들 및 버스들을 통해) 달성될 수 있다. 다수의 하드웨어 모듈이 상이한 시간에 구성되거나 인스턴스화되는 실시예에서, 그러한 하드웨어 모듈들 간의 통신은, 예를 들어, 다수의 하드웨어 모듈이 액세스하는 메모리 구조들에 정보를 저장하고 검색하는 것을 통해 달성될 수 있다. 예를 들어, 하나의 하드웨어 모듈은 동작을 수행하고 그 동작의 출력을 통신 가능하게 연결된 메모리 디바이스에 저장할 수 있다. 그러면 추가의 하드웨어 모듈은 나중에 메모리 디바이스에 액세스하여 저장된 출력을 검색하고 처리할 수 있다. 하드웨어 모듈들은 또한 입력 또는 출력 디바이스들과의 통신을 개시할 수도 있고, 자원(예를 들어, 정보의 모음)에 대해 동작할 수 있다.

본 명세서에 설명된 예시적인 방법들의 다양한 동작들은 관련 동작들을 수행하도록 (예를 들어, 소프트웨어에 의해) 일시적으로 구성되거나 영구적으로 구성된 하나 이상의 프로세서에 의해 적어도 부분적으로 수행될 수 있다. 일시적으로 또는 영구적으로 구성되더라도, 그러한 프로세서들은 본 명세서에서 설명된 하나 이상의 동작 또는 기능을 수행하도록 동작하는 프로세서에 의해 구현되는 모듈들을 구성할 수 있다. 본 명세서에서 사용되는 바와 같은, "프로세서에 의해 구현되는 모듈"은 하나 이상의 프로세서를 사용하여 구현되는 하드웨어 모듈을 지칭한다.

유사하게, 본 명세서에 설명된 방법들은 하드웨어의 일례인 특정 프로세서 또는 프로세서들을 이용하여, 적어도 부분적으로 프로세서에 의해 구현될 수 있다. 예를 들어, 방법의 동작들 중 적어도 일부는 하나 이상의 프로세서 또는 프로세서에 의해 구현되는 모듈들에 의해 수행될 수 있다. 더욱이, 하나 이상의 프로세서는 "클라우드 컴퓨팅" 환경에서 또는 "서비스형 소프트웨어(Software as a Service)" (SaaS)로서 관련 동작들의 성능을 지원하도록 동작할 수 있다. 예를 들어, 동작들 중 적어도 일부 동작은 (프로세서들을 포함하는 머신들의 예들로서) 컴퓨터들의 그룹에 의해 수행될 수 있으며, 이러한 동작들은 네트워크(예를 들어, 인터넷)를 통해 그리고 하나 이상의 적절한 인터페이스(예를 들어, 애플리케이션 프로그램 인터페이스(application program interface) (API))를 통해 액세스될 수 있다.

특정 성능들은 단일 머신 내에 상주할 뿐만 아니라 다수의 머신들 전체에 배치되는 프로세서들 사이에 분산되어 수행될 수 있다. 일부 예시적인 실시예에서, 프로세서들 또는 프로세서에 의해 구현되는 모듈들은 단일의 지리적 위치에 (예를 들어, 가정 환경, 사무실 환경 또는 서버 팜 내에) 위치할 수 있다. 다른 예시적인 실시예들에서, 프로세서들 또는 프로세서에 의해 구현되는 모듈들은 다수의 지리적 위치 전체에 걸쳐 분산될 수 있다.

도 8은 본 명세서에 설명된 다양한 하드웨어 아키텍처와 관련하여 사용되어 엔티티 컴포넌트 시스템(100)의 게임 엔진(701) 및/또는 컴포넌트들을 제공할 수 있는 예시적인 소프트웨어 아키텍처(702)를 도시하는 블록도(700)이다. 도 8은 소프트웨어 아키텍처의 비 제한적인 예이며, 본 명세서에 설명된 기능성을 용이하게 하기 위해 많은 다른 아키텍처가 구현될 수 있다는 것이 인식될 것이다. 소프트웨어 아키텍처(702)는 도 9의 머신(800)과 같은 하드웨어 상에서 실행될 수 있으며, 머신(800)은 다른 것들 중에서도, 프로세서들(810), 메모리(830), 및/또는 입력/출력(input/output)(I/O) 컴포넌트들(850)을 포함한다. 대표적인 하드웨어 계층(704)이 도시되며 예를 들어 도 9의 머신(800)을 나타낸다. 대표적인 하드웨어 계층(704)은 연관된 실행 가능한 명령어들(708)을 갖는 처리 유닛(706)을 포함한다. 실행 가능한 명령어들(708)은 본 명세서에 설명된 방법들, 모듈들 등의 구현을 비롯한, 소프트웨어 아키텍처(702)의 실행 가능한 명령어들을 나타낸다. 하드웨어 계층(704)은 또한 실행 가능 명령어들(708)을 또한 포함하는 메모리/저장소(710)를 포함한다. 하드웨어 계층(704)은 또한 다른 하드웨어(712)를 포함할 수 있다.

도 8의 예시적인 아키텍처에서, 소프트웨어 아키텍처(702)는 각 계층이 특정 기능성을 제공하는 계층들의 스택으로서 개념화될 수 있다. 예를 들어, 소프트웨어 아키텍처(702)는 운영 체제(714), 라이브러리들(716), 프레임워크들 또는 미들웨어(718), 애플리케이션들(720) 및 프레젠테이션 계층(744)과 같은 계층들을 포함할 수 있다. 동작적으로, 계층들 내의 애플리케이션들(720) 및/또는 다른 컴포넌트들은 소프트웨어 스택을 통해 애플리케이션 프로그래밍 인터페이스(API) 호출들(724)을 불러오고 메시지들(726)서 응답을 수신한다. 도시된 계층들은 본질적으로 대표적인 것이며 모든 소프트웨어 아키텍처가 모두 계층들을 갖는 것은 아니다. 예를 들어, 일부의 모바일 운영 체제 또는 특수 목적 운영 체제는 프레임워크들/미들웨어(718)를 제공하지 않을 수도 있고, 반면에 다른 것들은 그러한 계층을 제공할 수도 있다. 다른 소프트웨어 아키텍처들은 부수적인 또는 상이한 계층들을 포함할 수 있다.

운영 체제(714)는 하드웨어 자원들을 관리하고 공통 서비스들을 제공할 수 있다. 운영 체제(714)는 예를 들어, 커널(728), 서비스들(730) 및 드라이버들(732)을 포함할 수 있다. 커널(728)은 하드웨어 계층과 다른 소프트웨어 계층 사이의 추상화 계층으로서 작용할 수 있다. 예를 들면, 커널(728)은 메모리 관리, 프로세서 관리(예를 들어, 스케줄링), 컴포넌트 관리, 네트워킹, 보안 설정 등을 담당할 수 있다. 서비스들(730)은 다른 소프트웨어 계층들에 다른 공통 서비스들을 제공할 수 있다. 드라이버들(732)은 기본 하드웨어를 제어하거나 인터페이스하는 것을 담당할 수 있다. 예를 들어, 드라이버들(732)은 하드웨어 구성에 따라 디스플레이 드라이버들, 카메라 드라이버들, 블루투스® 드라이버들, 플래시 메모리 드라이버들, 직렬 통신 드라이버들(예를 들어, 범용 직렬 버스(Universal Serial Bus)(USB) 드라이버들), Wi-Fi® 드라이버들, 오디오 드라이버들, 전력 관리 드라이버들 등을 포함할 수 있다.

라이브러리들(716)은 애플리케이션들(720) 및/또는 다른 컴포넌트들 및/또는 계층들에 의해 사용될 수 있는 공통의 기반 구조를 제공할 수 있다. 라이브러리들(716)은 전형적으로 다른 소프트웨어 모듈들이 기본 운영 체제(714) 기능성(예를 들어, 커널(728), 서비스들(730) 및/또는 드라이버들(732))과 직접 인터페이스하는 것보다 쉬운 방식으로 작업들을 수행할 수 있게 하는 기능성을 제공한다. 라이브러리들(816)은 메모리 할당 기능들, 문자열 조작 기능들, 수학 기능들 등과 같은 기능들을 제공할 수 있는 시스템 라이브러리들(734)(예를 들어, C 표준 라이브러리)를 포함할 수 있다. 또한, 라이브러리들(716)은 미디어 라이브러리들(예를 들어, MPEG4, H.264, MP3, AAC, AMR, JPG, PNG와 같은 다양한 미디어 포맷의 프레젠테이션 및 조작을 지원하는 라이브러리들), 그래픽 라이브러리들(예를 들어, 디스플레이 상에 2D 및 3D 그래픽 콘텐츠를 렌더링하는데 사용될 수 있는 OpenGL 프레임워크), 데이터베이스 라이브러리들(예를 들어, 다양한 관계형 데이터베이스 기능들을 제공할 수 있는 SQLite), 웹 라이브러리들(예를 들어, 웹 브라우징 기능성을 제공할 수 있는 WebKit) 등과 같은 API 라이브러리들(736)을 포함할 수 있다. 라이브러리들(716)은 또한 애플리케이션들(720) 및 다른 소프트웨어 컴포넌트들/모듈들에 다른 많은 API를 제공하기 위해 다양한 다른 라이브러리(738)를 포함할 수 있다.

프레임워크들(718)(때로는 미들웨어라고도 지칭됨)은 애플리케이션들(720) 및/또는 다른 소프트웨어 컴포넌트들/모듈들에 의해 사용될 수 있는 상급의 공통 기반 구조를 제공한다. 예를 들어, 프레임워크들/미들웨어(718)는 다양한 그래픽 사용자 인터페이스(GUI) 기능들, 고급 자원 관리, 고급 위치확인 서비스들 등을 제공할 수 있다. 프레임워크들/미들웨어(718)는 애플리케이션들(720) 및/또는 다른 소프트웨어 컴포넌트들/모듈들에 의해 이용될 수 있는 광범위한 스펙트럼의 다른 API들을 제공할 수 있으며, 그 중 일부는 특정 운영 체제 또는 플랫폼에 특유할 수 있다.

애플리케이션들(720)은 빌트인 애플리케이션들(740) 및/또는 제3 자 애플리케이션들(742)을 포함한다. 대표적인 빌트인 애플리케이션들(740)의 예들은 이것으로 제한되는 것은 아니지만, 주소록 애플리케이션, 브라우저 애플리케이션, 북 리더 애플리케이션, 위치확인 애플리케이션, 미디어 애플리케이션, 메시징 애플리케이션 및/또는 게임 애플리케이션을 포함할 수 있다. 제3 자 애플리케이션들(742)은 특정 플랫폼의 벤더 이외의 주체가 안드로이드(Android^TM) 또는 iOS^TM 소프트웨어 개발 킷(software development kit)(SDK)을 사용하여 개발한 모든 애플리케이션을 포함할 수 있으며, iOS^TM, Android^TM, Windows®Phone 또는 기타 모바일 운영 체제들과 같은 모바일 운영 체제에서 실행되는 모바일 소프트웨어일 수 있다. 제3 자 애플리케이션들(742)은 본 명세서에서 설명된 기능성을 용이하게 하기 위해 운영 체제(714)와 같은 모바일 운영 체제에 의해 제공되는 API 호출들(724)을 불러올 수 있다.

애플리케이션들(720)은 빌트인 운영 체제 기능들(예를 들어, 커널(728), 서비스들(730) 및/또는 드라이버들(732)), 라이브러리들(716) 또는 프레임워크들/미들웨어(718)를 사용하여 시스템의 사용자들과 상호 작용하는 사용자 인터페이스들을 생성할 수 있다. 대안적으로 또는 부가적으로, 일부 시스템들에서, 사용자와의 상호 작용들은 표현 계층(744)과 같은 표현 계층을 통해 이루어질 수 있다. 이러한 시스템들에서, 애플리케이션/모듈 "로직"은 사용자와 상호 작용하는 애플리케이션/모듈의 양태들과 분리될 수 있다.

일부 소프트웨어 아키텍처는 가상 머신들을 사용한다. 도 8의 예에서, 이것은 가상 머신(748)에 의해 도시된다. 가상 머신(748)은 애플리케이션들/모듈들이 마치 (예를 들어, 도 9의 머신(800)과 같은) 하드웨어 머신 상에서 실행 중인 것처럼 실행될 수 있는 소프트웨어 환경을 만들어낸다. 가상 머신(748)은 호스트 운영 체제(예를 들어, 운영 체제(714))에 의해 호스팅되고, 항상 그러한 것은 아니지만, 전형적으로는 호스트 운영 체제(즉, 운영 체제(714))와의 인터페이스뿐만 아니라 가상 머신(748)의 동작을 관리하는 가상 머신 모니터(746)를 갖는다. 소프트웨어 아키텍처는 운영 체제(operating system)(OS)(750), 라이브러리들(752), 프레임워크들(754), 애플리케이션들(756) 및/또는 프레젠테이션 계층(758)과 같은 가상 머신(748) 내에서 실행된다. 가상 머신(748) 내에서 실행되는 소프트웨어 아키텍처의 이러한 계층들은 앞에서 설명한 대응하는 계층들과 동일하거나 아니면 상이할 수도 있다.

도 9는 머신 판독 가능한 매체(예를 들어, 머신 판독 가능한 저장 매체)로부터 명령어들을 판독하고 본 명세서에서 논의된 임의의 하나 이상의 방법론을 수행하도록 구성된 일부 예시적인 실시예에 따른 머신(800)의 컴포넌트들을 도시하는 블록도이다. 일부 실시예에서, 머신(800)은 ECS 디바이스(101)과 유사하다. 특히, 도 9는 머신(800)으로 하여금 본 명세서에서 논의된 임의의 하나 이상의 방법론을 수행하게 하기 위한 명령어들(816)(예를 들어, 소프트웨어, 프로그램, 애플리케이션, 애플릿, 앱 또는 다른 실행 가능한 코드)이 실행될 수 있는, 컴퓨터 시스템의 예시적인 형태의 머신(800)의 개략도를 도시한다. 이와 같이, 명령어들(816)은 본 명세서에 설명된 모듈들 또는 컴포넌트들을 구현하는데 사용될 수 있다. 명령어들은 프로그램되지 않은 일반적인 머신을 설명된 방식으로 기재되고 도시된 기능들을 수행하도록 프로그램된 특정 머신으로 변환한다. 대안적인 실시예들에서, 머신(800)은 스탠드얼론 디바이스로서 동작하거나 다른 머신들에 연결될 수 있다(예를 들어, 네트워크화될 수 있다). 네트워크화된 배치에서, 머신(800)은 서버-클라이언트 네트워크 환경에서 서버 머신 또는 클라이언트 머신의 자격으로서 동작할 수 있거나, 피어-투-피어(또는 분산형) 네트워크 환경에서는 피어 머신으로서 동작할 수 있다. 머신(800)은 이것으로 제한되는 것은 아니지만, 서버 컴퓨터, 클라이언트 컴퓨터, 퍼스널 컴퓨터(personal computer)(PC), 태블릿 컴퓨터, 랩톱 컴퓨터, 넷북, 셋탑 박스(set-top box)(STB), 개인 휴대 정보 단말기(personal digital assistant)(PDA), 엔터테인먼트 미디어 시스템, 셀룰러 텔레폰, 스마트 폰, 모바일 디바이스, 착용형 디바이스(예를 들어, 스마트 워치), 스마트 홈 디바이스(예를 들어, 스마트 어플라이언스), 기타 스마트 디바이스들, 웹 어플라이언스, 네트워크 스위치, 네트워크 브릿지, 또는 머신(800)에 의해 행해질 작동들을 지정하는 명령어들(816)을 순차적으로 또는 다른 방식으로 실행할 수 있는 임의의 머신을 포함할 수 있다. 또한, 단지 단일의 머신(800)이 도시되지만, "머신"이라는 용어는 본 명세서에서 논의된 임의의 하나 이상의 방법론을 수행하기 위해 개별적으로 또는 공동으로 명령어들(816)을 실행하는 머신들의 모음을 포함하는 것으로 취급될 것이다.

머신(800)은 예컨대 버스(802)를 통해 서로 통신하도록 구성될 수 있는 프로세서들(810), 메모리(830), 및 입력/출력(I/O) 컴포넌트들(850)을 포함할 수 있다. 예시적인 실시예에서, 프로세서들(810)(예를 들어, 중앙 처리 유닛(CPU), 축소 명령어 집합 컴퓨팅(Reduced Instruction Set Computing)(RISC) 프로세서, 복잡 명령어 집합 컴퓨팅(Complex Instruction Set Computing)(CISC) 프로세서, 그래픽 처리 유닛(GPU), 디지털 신호 프로세서(Digital Signal Processor)(DSP), 주문형 집적 회로(Application Specific Integrated Circuit)(ASIC), 무선 주파수 집적 회로(radio-frequency integrated circuit)(RFIC), 다른 프로세서, 또는 이들의 임의의 적합한 조합)은 예를 들어, 명령어들(816)을 실행할 수 있는 프로세서(812) 및 프로세서(814)를 포함할 수 있다. "프로세서"라는 용어는 명령어들을 동시에 실행할 수 있는 두 개 이상의 독립적인 프로세서(때로는 "코어들"이라고도 지칭함)를 포함할 수 있는 멀티 코어 프로세서를 포함하는 것으로 의도된다. 도 9는 다수의 프로세서를 도시하지만, 머신(800)은 단일 코어를 갖는 단일 프로세서, 다수의 코어를 갖는 단일 프로세서(예를 들어, 멀티 코어 프로세서), 단일 코어를 갖는 다수의 프로세서들, 다수의 코어를 갖는 다수의 프로세서들, 또는 이들의 임의의 조합을 포함할 수 있다.

메모리/저장소(830)는 메인 메모리(832), 스태틱 메모리(834) 또는 다른 메모리와 같은 메모리 및 저장 유닛(836)을 포함할 수 있으며, 이들 둘 모두는 예컨대 버스(802)를 통해 프로세서(810)에 액세스할 수 있다. 저장 유닛(836) 및 메모리(832, 834)는 본 명세서에 설명된 임의의 하나 이상의 방법론 또는 기능을 구현하는 명령어들(816)을 저장한다. 명령어들(816)은 또한 머신(800)에 의한 실행 동안, 메모리(832, 834) 내에서, 저장 유닛(836) 내에서, 프로세서들(810) 중 적어도 하나의 프로세서 내에서 (예를 들어, 프로세서의 캐시 메모리 내에서), 또는 이들의 임의의 적합한 조합 내에서 완전히 또는 부분적으로 상주할 수 있다. 따라서, 메모리(832, 834), 저장 유닛(836) 및 프로세서들(810)의 메모리는 머신 판독 가능한 매체(838)의 예들이다.

본 명세서에 사용된 바와 같이, "머신 판독 가능한 매체"는 명령어들 및 데이터를 일시적으로 또는 영구적으로 저장할 수 있는 디바이스를 의미하며, 이것으로 제한되는 것은 아니지만 랜덤 액세스 메모리(random-access memory)(RAM), 판독 전용 메모리(read-only memory)(ROM), 버퍼 메모리, 플래시 메모리, 광학 매체, 자기 매체, 캐시 메모리, 다른 유형들의 저장소(예를 들면, 소거 가능한 프로그램 가능 판독 전용 메모리(Erasable Programmable Read-Only Memory)(EEPROM)) 및/또는 이들의 임의의 적합한 조합을 포함할 수 있다. "머신 판독 가능한 매체"라는 용어는 명령어들(816)을 저장할 수 있는 단일 매체 또는 다중 매체(예를 들어, 중앙 집중형 또는 분산형 데이터베이스, 또는 연관된 캐시들 및 서버들)를 포함하는 것으로 취급되어야 한다. "머신 판독 가능한 매체"라는 용어는 또한 머신(800)의 하나 이상의 프로세서(예를 들어, 프로세서들(810))에 의해 실행될 때, 머신(800)으로 하여금 본 명세서에 설명된 임의의 하나 이상의 방법론을 수행하게 하도록, 머신(예를 들어, 머신(800))에 의해 실행하기 위한 명령어들(예를 들어, 명령어들(816))을 저장할 수 있는 임의의 매체 또는 다중 매체의 조합을 포함하는 것으로 취급되어야 한다. 따라서, "머신 판독 가능한 매체"는 단일의 저장 장치 또는 디바이스는 물론이고, 다수의 저장 장치 또는 디바이스들을 포함하는 "클라우드 기반" 저장 시스템들 또는 저장 네트워크들을 지칭한다. "머신 판독 가능한 매체"라는 용어는 신호 자체를 배제한다.

입력/출력(I/O) 컴포넌트들(850)은 입력을 수신하고, 출력을 제공하고, 출력을 생성하고, 정보를 전송하고, 정보를 교환하고, 측정치들을 포착하는 등의 다양한 컴포넌트를 포함할 수 있다. 특정 머신에 포함되는 특정 입력/출력(I/O) 컴포넌트들(850)은 머신의 유형에 따라 좌우될 것이다. 예를 들어, 휴대형 전화들과 같은 휴대용 머신들은 터치 입력 디바이스 또는 다른 그러한 입력 메커니즘들을 포함할 것 같지만 헤드리스 서버 머신은 그러한 터치 입력 디바이스를 포함할 것 같지 않다. 입력/출력(I/O) 컴포넌트들(850)은 도 9에 도시되지 않은 많은 다른 컴포넌트들을 포함할 수 있다는 것이 인식될 것이다. 입력/출력(I/O) 컴포넌트들(850)은 다음과 같은 논의를 간략화하기 위해 단지 기능성에 따라 그룹화되며, 그룹화는 결코 제한적인 것이 아니다. 다양한 실시예에서, 입력/출력(I/O) 컴포넌트들(850)은 출력 컴포넌트들(852) 및 입력 컴포넌트들(854)을 포함할 수 있다. 출력 컴포넌트들(852)은 시각 컴포넌트들(예를 들어, 플라즈마 디스플레이 패널(plasma display panel)(PDP)과 같은 디스플레이, 발광 다이오드(light emitting diode)(LED) 디스플레이, 액정 디스플레이(liquid crystal display)(LCD), 프로젝터 또는 음극선관(cathode ray tube)(CRT)), 음향 컴포넌트들(예를 들어, 스피커들), 햅틱 컴포넌트들(예를 들어, 진동 모터, 레지스턴스 메커니즘들), 다른 신호 발생기들 등을 포함할 수 있다. 입력 컴포넌트들(854)은 영숫자 입력 컴포넌트들(예를 들어, 키보드, 영숫자 입력을 수신하도록 구성된 터치 스크린, 광-광학 키보드 또는 다른 영숫자 입력 컴포넌트들), 포인트 기반 입력 컴포넌트들(예를 들어, 마우스, 터치 패드, 트랙볼, 조이스틱, 움직임 센서 또는 다른 포인팅 장비), 촉각 입력 컴포넌트들(예를 들어, 물리적 버튼, 터치들 또는 터치 제스처들의 위치 및/또는 힘을 제공하는 터치 스크린 또는 기타 촉각 입력 컴포넌트들), 오디오 입력 컴포넌트들(예를 들어, 마이크로폰) 등을 포함할 수 있다.

추가의 예시적인 실시예들에서, 입력/출력(I/O) 컴포넌트들(850)은 광범위한 무리의 다른 컴포넌트들 중에서도, 생체 인식 컴포넌트들(856), 모션 컴포넌트들(858), 환경 컴포넌트들(860) 또는 위치확인 컴포넌트들(862)을 포함할 수 있다. 예를 들면, 생체 인식 컴포넌트들(856)은 표현들(예를 들어, 손 표현들, 얼굴 표현들, 음성 표현들, 몸짓들 또는 눈 추적)을 검출하고, 생체 신호들(예를 들어, 혈압, 심박동수, 체온, 땀 또는 뇌파들)을 측정하고, 사람 등을 식별하는 (예를 들어, 음성 식별, 망막 식별, 안면 식별, 지문 식별 또는 뇌전도 기반 식별) 컴포넌트들을 포함할 수 있다. 모션 컴포넌트들(858)은 가속 센서 컴포넌트들(예를 들어, 가속도계), 중력 센서 컴포넌트들, 회전 센서 컴포넌트들(예를 들어, 자이로스코프) 등을 포함할 수 있다. 환경 컴포넌트들(860)은 예를 들어, 조명 센서 컴포넌트들(예를 들어, 광도계), 온도 센서 컴포넌트들(예를 들어, 주변 온도를 검출하는 하나 이상의 온도계), 습도 센서 컴포넌트들, 압력 센서 컴포넌트들(예를 들어, 기압계), 음향 센서 컴포넌트들(예를 들어, 배경 잡음을 검출하는 하나 이상의 마이크로폰들), 근접 센서 컴포넌트들(예를 들어, 인근 객체들을 검출하는 적외선 센서들), 가스 센서들(예를 들어, 안전을 위해 유해 가스들의 농도들을 검출하거나 또는 대기 내 오염 물질들을 측정하는 가스 검출 센서들), 또는 주변의 물리적 환경에 상응하는 표시들, 측정치들 또는 신호들을 제공할 수 있는 다른 컴포넌트들을 포함할 수 있다. 위치확인 컴포넌트들(862)은 위치 센서 컴포넌트들(예를 들어, 위성 위치확인 시스템(Global Position System)(GPS) 수신기 컴포넌트), 고도 센서 컴포넌트들(예를 들어, 고도가 도출될 수 있는 공기압을 검출하는 고도계들 또는 기압계들), 방향 센서 컴포넌트들(예를 들어, 자력계들) 등을 포함할 수 있다.

통신은 다양한 기술을 사용하여 구현될 수 있다. 입력/출력(I/O) 컴포넌트들(850)은 커플링(882) 및 커플링(872) 각각을 통해 머신(800)을 네트워크(880) 또는 디바이스들(870)에 연결하도록 동작 가능한 통신 컴포넌트들(864)을 포함할 수 있다. 예를 들어, 통신 컴포넌트들(864)은 네트워크 인터페이스 컴포넌트 또는 네트워크(880)와 인터페이스하는 다른 적합한 디바이스를 포함할 수 있다. 추가의 예들에서, 통신 컴포넌트들(864)은 유선 통신 컴포넌트들, 무선 통신 컴포넌트들, 셀룰러 통신 컴포넌트들, 근접장 통신(Near Field Communication)(NFC) 컴포넌트들, Bluetooth®컴포넌트들(예를 들어, Bluetooth®저전력 에너지), Wi-Fi®컴포넌트들 및 다른 모달리트들을 통해 통신을 제공하는 다른 통신 컴포넌트들을 포함할 수 있다. 디바이스들(870)은 다른 머신 또는 임의의 다양한 주변 디바이스들(예를 들어, 범용 직렬 버스(USB)를 통해 연결된 주변 디바이스)일 수 있다.

더욱이, 통신 컴포넌트들(864)은 식별자들을 검출할 수 있거나, 식별자들을 검출하도록 동작 가능한 컴포넌트들을 포함할 수 있다. 예를 들어, 통신 컴포넌트들(864)은 무선 주파수 식별(Radio Frequency Identification)(RFID) 태그 판독기 컴포넌트들, NFC 스마트 태그 검출 컴포넌트들, 광학 판독기 컴포넌트들(예를 들어, 범용 제품 코드(Universal Product Code)(UPC) 바코드와 같은 일차원 바코드들, 퀵 리스폰스(Quick Response)(QR) 코드와 같은 다차원 바코드들, 아즈텍 코드(Aztec code), 데이터 매트릭스(Data Matrix), 데이터글리프(Dataglyph), 맥시코드(MaxiCode), PDF417, 울트라 코드(Ultra Code), UCC RSS-2D 바코드 및 기타 광학 코드들을 검출하는 광학 센서), 또는 음향 검출 컴포넌트들(예를 들어, 태깅된 오디오 신호들을 식별하는 마이크로폰들)을 포함할 수 있다. 또한, 인터넷 프로토콜(Internet Protocol)(IP) 지리적 위치를 통한 위치, Wi-Fi® 신호 삼각 측량법을 통한 위치, 특정 위치를 표시할 수 있는 NFC 비콘 신호의 검출을 통한 위치 등과 같은 다양한 정보가 통신 컴포넌트들(862)을 통해 도출될 수 있다.

본 명세서 전체에서, 복수의 인스턴스는 단일의 인스턴스로서 설명된 컴포넌트들, 동작들 또는 구조들을 구현할 수 있다. 하나 이상의 방법의 개개의 동작들이 별개의 동작들로 도시되고 설명되지만, 개개의 동작들 중 하나 이상은 동시에 수행될 수 있으며, 어떤 것도 동작들이 도시된 순서대로 수행될 것을 요구하지 않는다. 예시적인 구성들에서 별개의 컴포넌트들로서 제시된 구조들 및 기능성은 조합된 구조 또는 컴포넌트로서 구현될 수 있다. 유사하게, 단일의 컴포넌트로서 제시된 구조들 및 기능성은 별개의 컴포넌트들로서 구현될 수 있다. 이들 및 다른 변형들, 수정들, 추가들 및 개선들은 본 명세서의 주제의 범위 내에 속한다.

본 명세서에 도시된 실시예들은 관련 기술분야에서 통상의 기술자가 개시된 가르침을 실시할 수 있도록 충분히 상세하게 설명된다. 본 개시 내용의 범위를 벗어나지 않으면서 구조적이고 논리적인 대체들 및 변경들이 이루어질 수 있도록, 다른 실시예들이 사용될 수 있고 그로부터 도출될 수 있다. 그러므로 상세한 설명은 제한적인 의미로 취급되지 않으며, 다양한 실시예의 범위는 첨부된 청구 범위 및 더불어 그러한 청구 범위의 자격을 부여 받은 등가물들의 전체 범위에 의해서만 정의된다.

본 명세서에서 사용된 바와 같이, "또는"이라는 용어는 포괄적이거나 배타적인 의미로 해석될 수 있다. 더욱이, 본 명세서에서 단일의 인스턴스로서 설명된 자원들, 동작들 또는 구조들에 대해 복수의 인스턴스가 제공될 수 있다. 또한, 다양한 자원들, 동작들, 모듈들, 엔진들 및 데이터 저장소들 사이의 경계들은 다소 임의적이며, 특정 동작들은 특정의 예시적인 구성들의 맥락에서 설명된다. 기능성의 다른 할당들이 구상되며 본 개시 내용의 다양한 실시예의 범위 내에 속할 수 있다. 일반적으로, 예시적인 구성들에서 별개의 자원들로서 제시된 구조들 및 기능성은 조합된 구조 또는 자원으로서 구현될 수 있다. 유사하게, 단일의 자원으로서 제시된 구조들 및 기능성은 별개의 자원들로서 구현될 수 있다. 이들 및 다른 변형들, 수정들, 추가들 및 개선들은 첨부의 특허청구범위에 의해 나타낸 바와 같은 본 개시 내용의 실시예들의 범위 내에 속한다. 따라서, 명세서 및 도면들은 제한적인 의미라기보다는 예시적인 것으로 간주되어야 한다.

Claims

시스템으로서,
하나 이상의 컴퓨터 프로세서;
하나 이상의 컴퓨터 메모리;
상기 하나 이상의 컴퓨터 메모리에 통합된 한 세트의 명령어들
을 포함하고,
상기 명령어들의 세트는 상기 하나 이상의 컴퓨터 프로세서를, 컴퓨터 애플리케이션을 위한 런타임에서 상기 하나 이상의 컴퓨터 메모리 내의 한 세트의 메모리 청크들을 자동으로 관리하기 위한 동작들을 수행하도록 구성하고,
상기 동작들은,
상기 컴퓨터 애플리케이션으로부터 한 세트의 엔티티들을 수신하는 것 - 상기 엔티티들의 세트의 각각은 한 세트의 컴포넌트들을 포함함 -;
상기 엔티티들의 세트를 상기 컴포넌트들의 세트의 카운트 및 상기 엔티티들의 세트의 각각에 포함된 상기 컴포넌트들의 세트의 타입에 기초하여 한 세트의 아키타입들로 분류하는 것;
상기 아키타입들의 세트 중 하나가 새로운 아키타입에 대응한다는 결정에 기초하여, 새로운 메모리 청크를 구축하고, 상기 새로운 메모리 청크를 상기 메모리 청크들의 세트에 추가하며, 상기 새로운 메모리 청크를 채우는 것
을 포함하며,
상기 새로운 메모리 청크를 채우는 것은 상기 새로운 아키타입 하에서 분류된 상기 엔티티들의 세트 중의 하나 이상의 엔티티에 포함된 상기 컴포넌트들의 세트로부터의 데이터를 추가하는 것을 포함하고, 상기 데이터를 추가하는 것은 상기 새로운 메모리 청크에 포함된 한 세트의 컴포넌트 데이터 어레이들의 끝들에다 상기 데이터를 인접하게 추가하는 것을 포함하고, 상기 새로운 메모리 청크에 포함된 상기 데이터 어레이들의 세트의 각각은 상기 새로운 아키타입 하에서 분류된 상기 하나 이상의 엔티티에 포함된 상기 컴포넌트들의 세트의 각 컴포넌트에 대응하는, 시스템.
제1항에 있어서, 상기 컴포넌트 데이터 어레이들의 세트의 각 컴포넌트 데이터 어레이는 상기 컴포넌트 데이터 어레이들의 세트의 다음 컴포넌트 데이터 어레이와 인접하는, 시스템.
제1항에 있어서, 상기 동작들은 상기 아키타입들의 세트 중 상기 하나가 기존의 아키타입에 대응한다는 결정에 기초하여, 상기 메모리 청크들의 세트의 기존의 메모리 청크를 채우는 것을 더 포함하며, 상기 기존의 메모리 청크를 채우는 것은 상기 기존의 아키타입 하에서 분류된 상기 엔티티들의 세트 중의 하나 이상의 엔티티에 포함된 상기 컴포넌트들의 세트로부터의 데이터를 추가하는 것을 포함하고, 상기 데이터를 추가하는 것은 상기 기존의 메모리 청크에 포함된 한 세트의 컴포넌트 데이터 어레이들의 끝들에다 상기 데이터를 인접하게 추가하는 것을 포함하고, 상기 기존의 메모리 청크에 포함된 상기 데이터 어레이들의 세트의 각각은 상기 기존의 아키타입 하에서 분류된 상기 하나 이상의 엔티티에 포함된 상기 컴포넌트들의 세트의 각 컴포넌트에 대응하는, 시스템.
제1항에 있어서, 상기 새로운 메모리 청크를 상기 메모리 청크들의 세트에 추가하는 것은 상기 메모리 청크들의 세트가 상기 아키타입들의 세트 각각에 대해 적어도 하나의 메모리 청크를 포함하는 것을 보장하는, 시스템.
제1항에 있어서, 상기 컴포넌트들의 세트는 컴포넌트들의 제1 리스트, 컴포넌트들의 제2 리스트 및 명령어들의 추가 세트를 포함하고,
상기 동작들은,
상기 아키타입들의 세트를 검색하여 상기 컴포넌트들의 제2 리스트로부터의 모든 컴포넌트들을 포함하는 하나 이상의 매칭하는 아키타입을 찾는 것; 및
상기 하나 이상의 컴포넌트와 상기 컴포넌트들의 제1 리스트 간의 대응 관계에 기초하여, 상기 추가 명령어들의 세트를 사용하여 상기 하나 이상의 매칭하는 아키타입에 포함된 상기 컴포넌트들 중 하나 이상을 수정하는 것
을 더 포함하는, 시스템.
제1항에 있어서, 상기 엔티티들의 세트의 각각은 상기 애플리케이션 내에서 발생하는 게임 이벤트의 결과로서 생성되는, 시스템.
제1항에 있어서, 상기 동작들은,
상기 엔티티들의 세트의 엔티티의 삭제의 통지를 수신하는 것;
상기 엔티티에 대응하는 상기 메모리 청크들의 세트의 메모리 청크에 포함된 상기 데이터 어레이들의 세트의 각각으로부터 상기 엔티티에 대응하는 데이터를 제거하는 것; 및
추가의 엔티티에 대응하는 데이터를 상기 데이터 어레이들의 세트의 각각의 끝으로부터 상기 엔티티에 대응하는 상기 제거된 데이터의 위치들로 이동시킴으로써 상기 메모리 청크가 인접하게 패킹되는 것을 보장하는 것
을 더 포함하는, 시스템.
제1항에 있어서, 상기 동작들은,
제1 아키타입 내의 상기 엔티티들의 세트의 엔티티가 수정되었음을 결정하는 것;
상기 수정된 엔티티가 추가의 새로운 아키타입에 대응한다는 결정에 기초하여, 상기 추가의 새로운 아키타입을 상기 아키타입들의 세트에 추가하고, 상기 추가의 새로운 아키타입에 대한 추가의 새로운 메모리 청크를 구축하고, 상기 추가의 새로운 메모리 청크를 상기 수정된 엔티티에 포함된 상기 컴포넌트들의 세트로부터의 데이터로 채우며, 상기 수정된 엔티티에 대응하는 데이터를 상기 제1 아키타입으로부터 삭제하는 것;
상기 수정된 엔티티가 기존의 메모리 청크 내의 기존의 제2 아키타입에 대응한다는 결정에 기초하여, 상기 기존의 메모리 청크를 상기 수정된 엔티티에 포함된 상기 컴포넌트들의 세트로부터의 데이터로 채우고, 상기 수정된 엔티티에 대응하는 데이터를 상기 제1 아키타입으로부터 삭제하는 것
을 더 포함하는, 시스템.
제1항에 있어서, 상기 새로운 아키타입 하에서 분류되는 상기 엔티티들의 세트 중의 상기 하나 이상의 엔티티에 포함된 상기 컴포넌트들의 세트의 각각으로부터의 상기 데이터는 상기 컴포넌트를 나타내는 객체 지향 프로그래밍 객체의 변수들로부터 추출되는, 시스템.
컴퓨터에 의해 구현되는 방법으로서,
컴퓨터 애플리케이션으로부터 한 세트의 엔티티들을 수신하는 단계 - 상기 엔티티들의 세트의 각각은 한 세트의 컴포넌트들을 포함함 -;
상기 엔티티들의 세트를 상기 컴포넌트들의 세트의 카운트 및 상기 엔티티들의 세트의 각각에 포함된 상기 컴포넌트들의 세트의 타입에 기초하여 한 세트의 아키타입들로 분류하는 단계;
상기 아키타입들의 세트 중 하나가 새로운 아키타입에 대응한다는 결정에 기초하여, 새로운 메모리 청크를 구축하고, 상기 새로운 메모리 청크를 상기 메모리 청크들의 세트에 추가하며, 상기 새로운 메모리 청크를 채우는 단계
를 포함하며,
상기 새로운 메모리 청크를 채우는 단계는 상기 새로운 아키타입 하에서 분류된 상기 엔티티들의 세트 중의 하나 이상의 엔티티에 포함된 상기 컴포넌트들의 세트로부터의 데이터를 추가하는 단계를 포함하고, 상기 데이터를 추가하는 단계는 상기 새로운 메모리 청크에 포함된 한 세트의 컴포넌트 데이터 어레이들의 끝들에다 상기 데이터를 인접하게 추가하는 단계를 포함하고, 상기 새로운 메모리 청크에 포함된 상기 데이터 어레이들의 세트의 각각은 상기 새로운 아키타입 하에서 분류된 상기 하나 이상의 엔티티에 포함된 상기 컴포넌트들의 세트의 각 컴포넌트에 대응하는, 컴퓨터에 의해 구현되는 방법.
제10항에 있어서, 상기 컴포넌트 데이터 어레이들의 세트의 각 컴포넌트 데이터 어레이는 상기 컴포넌트 데이터 어레이들의 세트의 다음 컴포넌트 데이터 어레이와 인접하는, 컴퓨터에 의해 구현되는 방법.
제10항에 있어서, 상기 아키타입들의 세트 중 상기 하나가 기존의 아키타입에 대응한다는 결정에 기초하여, 상기 메모리 청크들의 세트의 기존의 메모리 청크를 채우는 단계를 더 포함하며, 상기 기존의 메모리 청크를 채우는 단계는 상기 기존의 아키타입 하에서 분류된 상기 엔티티들의 세트 중의 하나 이상의 엔티티에 포함된 상기 컴포넌트들의 세트로부터의 데이터를 추가하는 단계를 포함하고, 상기 데이터를 추가하는 단계는 상기 기존의 메모리 청크에 포함된 한 세트의 컴포넌트 데이터 어레이들의 끝들에다 상기 데이터를 인접하게 추가하는 단계를 포함하고, 상기 기존의 메모리 청크에 포함된 상기 데이터 어레이들의 세트의 각각은 상기 기존의 아키타입 하에서 분류된 상기 하나 이상의 엔티티에 포함된 상기 컴포넌트들의 세트의 각 컴포넌트에 대응하는, 컴퓨터에 의해 구현되는 방법.
제10항에 있어서, 상기 새로운 메모리 청크를 상기 메모리 청크들의 세트에 추가하는 단계는 상기 메모리 청크들의 세트가 상기 아키타입들의 세트의 각각에 대해 적어도 하나의 메모리 청크를 포함하는 것을 보장하는, 컴퓨터에 의해 구현되는 방법.
제10항에 있어서, 상기 컴포넌트들의 세트는 컴포넌트들의 제1 리스트, 컴포넌트들의 제2 리스트 및 명령어들의 추가 세트를 포함하고,
동작들은,
상기 아키타입들의 세트를 검색하여 상기 컴포넌트들의 제2 리스트로부터의 모든 컴포넌트들을 포함하는 하나 이상의 매칭하는 아키타입을 찾는 단계; 및
상기 하나 이상의 컴포넌트와 상기 컴포넌트들의 제1 리스트 간의 대응 관계에 기초하여, 상기 추가 명령어들의 세트를 사용하여 상기 하나 이상의 매칭하는 아키타입에 포함된 상기 컴포넌트들 중 하나 이상을 수정하는 단계
를 더 포함하는, 컴퓨터에 의해 구현되는 방법.
제10항에 있어서, 상기 엔티티들의 세트의 각각은 상기 애플리케이션 내에서 발생하는 게임 이벤트의 결과로서 생성되는, 컴퓨터에 의해 구현되는 방법.
제10항에 있어서, 동작들은,
상기 엔티티들의 세트의 엔티티의 삭제의 통지를 수신하는 단계;
상기 엔티티에 대응하는 상기 메모리 청크들의 세트의 메모리 청크에 포함된 상기 데이터 어레이들의 세트의 각각으로부터 상기 엔티티에 대응하는 데이터를 제거하는 단계; 및
추가의 엔티티에 대응하는 데이터를 상기 데이터 어레이들의 세트의 각각의 끝으로부터 상기 엔티티에 대응하는 상기 제거된 데이터의 위치들로 이동시킴으로써 상기 메모리 청크가 인접하게 패킹되는 것을 보장하는 단계
를 더 포함하는, 컴퓨터에 의해 구현되는 방법.
제10항에 있어서, 동작들은,
제1 아키타입 내의 상기 엔티티들의 세트의 엔티티가 수정되었음을 결정하는 단계;
상기 수정된 엔티티가 추가의 새로운 아키타입에 대응한다는 결정에 기초하여, 상기 추가의 새로운 아키타입을 상기 아키타입들의 세트에 추가하고, 상기 추가의 새로운 아키타입에 대한 추가의 새로운 메모리 청크를 구축하고, 상기 추가의 새로운 메모리 청크를 상기 수정된 엔티티에 포함된 상기 컴포넌트들의 세트로부터의 데이터로 채우며, 상기 수정된 엔티티에 대응하는 데이터를 상기 제1 아키타입으로부터 삭제하는 단계;
상기 수정된 엔티티가 기존의 메모리 청크 내의 제2 아키타입에 대응한다는 결정에 기초하여, 상기 기존의 메모리 청크를 상기 수정된 엔티티에 포함된 상기 컴포넌트들의 세트로부터의 데이터로 채우고, 상기 수정된 엔티티에 대응하는 데이터를 상기 제1 아키타입으로부터 삭제하는 단계
를 더 포함하는, 컴퓨터에 의해 구현되는 방법.
제10항에 있어서, 상기 새로운 아키타입 하에서 분류되는 상기 엔티티들의 세트 중의 상기 하나 이상의 엔티티에 포함된 상기 컴포넌트들의 세트의 각각으로부터의 상기 데이터는 상기 컴포넌트를 나타내는 객체 지향 프로그래밍 객체의 변수들로부터 추출되는, 컴퓨터에 의해 구현되는 방법.
프로세서에 의해 실행될 때, 상기 프로세서로 하여금 동작들을 수행하게 하는 한 세트의 명령어들을 저장하는 비일시적인 머신 판독 가능한 매체로서,
상기 동작들은,
컴퓨터 애플리케이션으로부터 한 세트의 엔티티들을 수신하는 것 - 상기 엔티티들의 세트의 각각은 한 세트의 컴포넌트들을 포함함 -;
상기 컴포넌트들의 세트의 카운트 및 상기 엔티티들의 세트의 각각에 포함된 상기 컴포넌트들의 세트의 타입에 기초하여 상기 엔티티들의 세트를 한 세트의 아키타입들로 분류하는 것;
상기 아키타입들의 세트 중 하나가 새로운 아키타입에 대응한다는 결정에 기초하여, 새로운 메모리 청크를 구축하고, 상기 새로운 메모리 청크를 상기 메모리 청크들의 세트에 추가하며, 상기 새로운 메모리 청크를 채우는 것
을 포함하며,
상기 새로운 메모리 청크를 채우는 것은 상기 새로운 아키타입 하에서 분류된 상기 엔티티들의 세트 중의 하나 이상의 엔티티에 포함된 상기 컴포넌트들의 세트로부터의 데이터를 추가하는 것을 포함하고, 상기 데이터를 추가하는 것은 상기 새로운 메모리 청크에 포함된 한 세트의 컴포넌트 데이터 어레이들의 끝들에다 상기 데이터를 인접하게 추가하는 것을 포함하고, 상기 새로운 메모리 청크에 포함된 상기 데이터 어레이들의 세트의 각각은 상기 새로운 아키타입 하에서 분류된 상기 하나 이상의 엔티티에 포함된 상기 컴포넌트들의 세트의 각 컴포넌트에 대응하는, 비일시적인 머신 판독 가능한 매체.
제19항에 있어서, 상기 컴포넌트 데이터 어레이들의 세트의 각 컴포넌트 데이터 어레이는 상기 컴포넌트 데이터 어레이들의 세트의 다음 컴포넌트 데이터 어레이와 인접하는, 비일시적인 머신 판독 가능한 매체.