OK, so here I am again! Time to give some details on what I’ve been up to.
Lately, I’ve been working with pure Haxe and OpenFL to make an Entity Component System for game development purposes. In a nutshell, ECS is in part about avoiding heavy encapsulation and inheritance by forsaking traditional object-oriented methodologies and splitting the data (components) and logic (systems) up. So systems, more or less, pull in components and act upon the data as opposed to data objects having their own member functions. Entities (i.e. actors and objects in one’s game) own components and hand them over to systems when they require their services. As a simple example, an entity might hand a position and sprite component over to a drawing system, and the drawing system will update the sprite coordinates based on the position data.
The advantages may not be readily apparent; it might take a little thought. Consider this: how often does one object/entity looking at another object/entity need every shred of data attached to it? Probably not very often. Gluing large, copious amounts of data together into one class or object comes with potential problems, as many seasoned programmers know. It also means that data coexists as a single blob, not necessarily as individual pieces of data. Ever tried to “kill” an object but still need some of its data for aftereffects, enemy reactions, and so on and so forth? This can often involve “ungluing” multiple pieces of data and cluster-firing them into other objects so the dead object’s data is not forgotten prematurely. Not normally an elegant or gleeful process. That or you keep everything and track all the little odds and ends until you can dispose of the object as a whole. But then you also have to keep track of what should be running and what shouldn’t be… which is a problem not just exclusive to death sequences. Complexities to deal with abound in programming, but things can get out of hand in situations like these.
With the ECS, its different. An entity is composed of components. These components are in turn each responsible for a (typically small) chunk of data. This is all done without inheritance, using something like a map instead. It means that an entity can acquire multiple features without having massive inheritance chains or even having to know ahead of time everything it might possibly need. Add what you need and go from there. Cool, huh? Imagine making stronger variants of enemies simply by adding a few components to them in an arcade game. On top of that, each component and its data are free to move about without having to necessarily concern itself about any other component. Now when you kill your object, you can keep what you need and simply pull the rest of it from their corresponding systems as a quick and easy shutoff.
In theory, of course. ECS isn’t without its quirks. Something has to keep track of all those hundreds–maybe thousands–of cute little data pieces flying all over the place. There IS a certain comfort in knowing your data is all accounted for in one pretty (if not big) basket. But remember that we sacrifice some encapsulation for the sake of fluidity. You can put the OO-glue away and build complex objects out of a series of building blocks rather than making them into one inseparable blob. It still takes some work, but the benefit may well be worth it.
So that’s a quick introduction. This is what I plan to run with for Ludum Dare 31. I’m still working out some kinks, but hopefully I’ll be ready. I think I’ve given a substantial primer for now, so I’ll save some of the more in-depth details for a later post. If you want to know more about ECS, click the link above. Stay tuned and thanks for reading!
Photon Game Development 
Leave a Reply