The first part just dealed with the setup and some rough skeletons and a meager ship on the screen, but still no entity system. Well we did setup one, but did not use so far. In this part we will really use it. Promise.
We want invaders
Indeed an invader game without invaders is not an invader game, so fire up again your blender and model your invader. Of course I have one for you on my google drive to share with you. I called it BasicInvader.
And now my friend we will use the entity system to hold the data of the a bunch of invaders and a star ship on the base. What do we need to specify the ship and the invaders to appear on the screen? We need a position and a model to be able to print it on the screen. Ok normaly you would now start with some kind of game object and inherit from that your ship and your invader and so on and so on. Maybe you would abuse the JME Spatial to even hold some game logic on it and start pretty soon a messy spagetti like architecture. At least this happens to me. So it is a very good idea to separate logic from visualisation. With an entity system you do this in it's extrem. With the entity system we can extend our ship at any time with what ever component we think we need without touching much of the existing code, mostly none at all. Even the data and the methods are separated which is completly agains object oriented programming and if you deep in object oriented programming this approach may or may not confuse you. But be patient with me and with your self.
What's my position
Our ship but as well our invaders need a position and that is done with a position component.
You see the component is immutual and pure data, that helps to run systems in different threads without bodering about synchronization. We will deal with multithreading later.
Who the heck am I
Of course that we now which model we should load we need a model component as well. Looks pretty much like the position component above and is pure data.
To avoid typos I introduced some static strings for space ship and basic invader ships. Now how does this come into play?
Finally we will use the entity system to store the data of the invaders and the ship currently no graphical representation.
Entities are just ids nothing more. You have to add components to this entity to give it a meaning. And then you query entities with specific components, in our case Position and Model. It's like a database.
So what we need now is a GameAppState where we build up our levels, do the transitions from start to play, from play to dead and from dead to reborn and all that kind of stuff. But let's keep it stupid simple for the first and flesh it out later.
So we only generate the ships that's all, enought to show you the first ES system.
Show what you have
And here it comes .... the first entity system to display the generated invaders. And our ship of course. Just replace your current VisualAppState with the following one.
this is by the way some kind of the first design pattern in entity system programming, as you will use this in all your games for sure at least on the client side.
So what do we have here. First we define the set of entities we want to operate on
We are interested in all entities with a position and a model. This works for invaders and for our space ship as both have those components.
The next part is the update loop, the heart of every game. JME offers that for every application state you register.
We check if there are changes in the entity set and then handle the removed entities, the added entities and the changed entities. All spatials and the corresponding entity id is managed with a "local" hash map
That way we can remove an added entity from the visual node later. Let's directly jump into removeModels method.
The spatial is hold in the models hash map and get with the removed entity id, so I can remove it from the visual node. That's all.
Ok befor we can remove something it should be added some time befor of course. Added entites are handled with addModels method
You can see that we hold all created spatials in the models hash map and add them as well to the root node to make them visual.
The updateModel is quite simple and just update the position of a spatial which corresponding entity id signals changes.
In the end you have to register all those new app states to Main like this
That's it. Your first ES driven piece of software. I will come up with more additional stuff to make the entites move and the ship controllable. In the next part then. Stay tuned.