-
Notifications
You must be signed in to change notification settings - Fork 14
/
description.txt
114 lines (71 loc) · 3.32 KB
/
description.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
A system that maintains the state of the game as a database like structure.
The data stored is encapsulated in "Components", which have only data-members.
The interface of the various parts is defined below.
EntityManager {
addComponent(entity_id, component_instance)
Adds a component object to the database, associated with the entity_id
removeComponent(entity_id, component_type)
Removes a component object from the database if the entity_id has such a component
Does not do any kind of data tear-down. This method simply makes that component
unavailable from the database.
getPairs(component_type)
Returns a list of pairs of entity_id's and components for a given component type.
Alleviates the need of doing a reverse look-up to get the id of an entity with
a certain kind of component.
getComponentForEntity(entity_id, component_type)
Returns the component_type component for the given entity_id. Returns None if there
is no component of that type associated with that id.
}
Entity {
guid
A unique number that identifies this identity.
The entity class is simply a way to logically encapsulate an identifier.
}
Component {
data1
data2
data3
Arbitrary data members. May contain a custom initializer but should not
have any other methods, especially any that modify state beyond simple getters/setters
with validation.
Might be good to define factory methods at the class level for each component type.
}
All of these types are used by a separate set of classes called "Systems". Systems are bits of code that operate on items from the EntityManager database.
System {
update(dt, entity_manager)
Called every frame by the SystemManager.
The system can query the database for components and operate on them.
This is where the logic of the game is implemented.
Each System subclass is responsible for a narrow set of operations. Should only do the minimum necessary to make a certain feature work.
No persistent references should be made to things from the database unless you have a really, really good reason. Things are likely to come and go from the database.
}
SystemManager {
initializer(entity_manager)
Creates a new SystemManager. Requires a reference to an EntityManager so that the systems can get the required components.
addSystem(system_instance, priority)
Adds a system instance to the manager. It will be updated according the priority passed in.
Will throw an Error if a system of that type is already present.
removeSystem(system_type)
Removes a given system type from the manager.
update(dt)
The SystemManager goes through its list of Systems and calls their update methods.
The list is sorted so systems get updated in their intended priority.
This method is called externally by the game-loop machinery.
}
database format:
Indexable by comp_type:
d = {
comp_type_1 : {
id_1 : comp_instance_1,
id_2 : comp_instance_2
},
comp_type_2 : {
id_1 : comp_instance_3,
id_2 : comp_instance_4
},
}
So to get all components of a certain type, it's simply
all_comps = d[comp_type].values()
To get the comp for an entity,
comp_1 = d[comp_type][entity_id]
Both types of access are pretty fast and shouldn't cause any speed problems.