Timeline for Entity Component Architecture - initialization between multiple components
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 27, 2014 at 5:22 | comment | added | Patrick Hughes | I have to agree with this here. ECS is a solution to some kinds of OOP problems that game programmers were experiencing; this is more of a world definition problem, still data driven but your ECS just collapses into the one system handled by Sean's explanation above and so it's not needed. | |
| Jun 27, 2014 at 16:30 | comment | added | Sean Middleditch | Then perhaps you don't want an ECS for this case at all. The tile map is just a list of integers that are indices into an array (or several arrays) of data that indicate everything about a particular tile, like image, type, etc. Data still defines the contents of those arrays. You don't want each tile to be its own complete object. | |
| Jun 27, 2014 at 12:41 | comment | added | Ben Slinger | OK, I understand not wanting to couple two components too tightly, but this is actually going to be a simulation/building game where the player will be putting down types of flooring, walls, objects, etc, so I need some way to handle when the FloorType changes. You're right that I don't want to couple a FloorType value to a particular image, but I probably will want to couple a Floortype to how that FloorType is eventually rendered, even if it's choosing a random grass tile or layering multiple images or whatever. This logic needs to go somewhere, right? | |
| Jun 27, 2014 at 4:37 | history | answered | Sean Middleditch | CC BY-SA 3.0 |