01-16-2016, 03:37 AM
(This post was last modified: 01-16-2016, 03:47 AM by LogicParrot.)
(01-16-2016, 12:13 AM)xoft Wrote: We were already discussing this some time ago and we agreed the best architecture for the mobs to be Components:
http://gameprogrammingpatterns.com/component.html
http://ai.eecs.umich.edu/soar/Classes/49...umaker.pdf (unfortunately no longer available, use google cache to read: https://www.google.com/search?q=http://a...umaker.pdf )
Here's a link to the relevant forum thread: https://forum.cuberite.org/showthread.ph...2#pid10912
I've always had a terminology confusion here which I hope someone can clear up.
1. The gameprogrammingpatterns.com guide describes "Entity-Component-systems". It talks about splitting entities into components based on *systems* - graphics, physics, logic, etc.
2. The PDF at 49 is similar to what I had in mind. It is titled "Component-based architecture". It deals with a single system (the logic/behavior) and splits *that system* into components. This seems to match what we need.
Are these two patterns the same? They do not look the same to me, but I've never seen an article explicitly distinguishing between them.
In other words, I see a big difference between "component per each system the entity is using(logic, graphics, etc.)" and "component for each behavior/trait the entity has (health, agression, etc.)"
Also, which form are you suggesting we need to use, 1 or 2?