after one year of interruption in game development I am about to restart my work. Before starting however I would like to clarify some questions about software architecture which are unclear to me and led to some confusion/uncertanity in the past.
My goal here is not only to code a game but also to learn about Software architecture in the context of game development.
In my last project I implemented the behaviors of my spatials in scene by using controls almost exclusively (For example: NewtonianControl, DamageControl, ProjectileLauncherControl, PlayerControl âŚ). I did so because I was defining my spatials as game objects what is obviously wrong. However it worked for me at the beginning. I could use the SceneComposer, attach the controls to the spatials and add the behaviors I intended. But at a point of complexity this concept broke down because doing so started feeling like breaking with the control concept. For example the basic requirement of adding new scene content (for example a bullet, nozzle fire etcâŚ) required additional workaround which made me feeling like abusing the Control interface. The reasons were:
Controls do not include AssetManager and RootNode by default So scene modification is cumbersome and obviously out of scope of the control interface. You have to attach an AppState as a system object for this and to connect the controls with it or: Take the assetManger/rootNode from the load/onRender method.
But even worse:
Controls are not executed if the spatial is detached from the scene (e.g. vessel in hangar or out of sight). So the game objects cannot be taken away from scene without interrupting the update. ==> Artificial node with an artificial update thread?? No way!
â Obviously the game logic had to be decoupled from the spatial update. What about AppStates?
On the other hand when I define AppStates as game objects there are different problems.
AppStates are not savable by nature so they are not supposed to be made persistent (loading/saving, sure I know about implements Savable but it also feels like breaking with the concept by adding additional responsibility)
Where do I then store the internal state of the Game object to make it persistent?
How do I then load the models build with SceneComposer (containing data like HP/HPMax) and attach them to the correct AppStates (because I cannot attach AppStates to Spatials bcz. they do not implement Control interface by nature).
Can/Shall I have savable âextends AbstractControl implements AppStateâ objects with redundant update loop? Or savable appState delegates?
So I came along defining one singleton SceneAppState/Control observer object managing all dynamic objects (Ships, Bullets, moving turrets etc⌠equipped with the correct control composition in SceneComposer), one PlayerAppState (with the input) and ContentAppStates for individual non persistent procedural element (like planets, stars etcâŚ).
In order to increase the fun: There shall be nested game objects like Vessels with fully controllable turrets, engines, antennas⌠Or procedurally generated planetary systems with planets, orbits, moons, with surface tiles and collision etc⌠To link them with the scene seems to be a challenge.
Do you have any suggestions? Because I think what I really need is something like a cooking reciple for architecture and design decisions like:
You want to use XXX then you should implement/extend YYY class/interface.
If your project is that big did you bwrote or draft down a concept of game mechanics etc.? Could be helpfull to have it right in front of you. If you know about the usage of Appstates and Controls you may then decide what and how to use it. Sorry i dont feel secure enough with the architecture to tell you do xxx for yyy. But writing it down helps.
Controls do not include AssetManager and RootNode by default
sure, and controls should only modify spatial, nothing more trully.
Controls are not executed if the spatial is detached from the scene
Yes, but i have one where i wrote tricky âonDetachâ method, because i required it for physics control that works perfectly and add physics where spatial appears, and remove it when required.
On the other hand when I define AppStates as game objects there are different problems.
Not a bad solution, please remember, you dont need save only scene(you can save as separate serialization file too), and better - you can make own savable object, that you will just attach to scene(for example to rootNode) that will contain all entity informations.
Myself i prefer save not just scene, but my own serialized files and even zip them. So i got entities out of box (when game load i create scene based on entities, not entities based on scene).
But imo it depends what your game will be like. Please note better if scenegraph have only required Spatials, so if your world gonna be big, then you should make entites that can load scene graph spatials for you when need. (for example when player is close) You should save memory and hold only few of informations like location or any other important for entity to know what to load.
A general software development âruleâ is to prefer composition over inheritance. In that light, as a concept: controls extend Spatials through âcomposition over inheritanceâ. AppStates extend Applications through âcomposition over inheritanceâ. Neither of those are âgame objectsâ.
In an MVC-like architecture, your game objects would be the M, Spatials + controls are the VC. App states coordinate it all.
For simple games, itâs possible to treat your spatials like game objects⌠and certainly all of the JME examples seem to behave that way. In the long run, as youâve discovered, itâs very limiting.
In the end, your game objects are defined by you. They can be anything. You can write regular Java objects that have what you want or you can use a standard architecture like an âEntity Systemâ. (The common JME entity system framework would be Zay-ES: Home ¡ jMonkeyEngine-Contributions/zay-es Wiki ¡ GitHub)
App states and controls are then responsible for making the view match the âmodelâ and feeding back user-interaction to your game logic/game objects as appropriate.
From a conceptual level, it can be useful to think about the case where your game objects and game logic are running on a âserverâ and the app states and controls must communicate with that âserverâ to implement the game user interface. It can be a useful way to think about the separation.
Ideally in my opinion one would never save the scene. Scene would be 100% reconstructable from the actual game objects/map information you have. In this way also updating the game visuals wont affect the load/save.
The scene is a representation of data. Just as a website is a representation of a database.
You donât store the website, you store the data and the website displays it however you decide.
A player has a location, health, weapon, etc. and those pieces of information are saveable. You would then create objects that represent that data visually. (Hint: they have-a spatial, they are not is-a spatial).
An easy way to understand how to keep your code clean is the âhas-aâ (field) and âis-aâ (inheritance) relationship.
A gun is a weapon. A player has-a weapon. A player would not inherit from Weapon because it is not a weapon. So in that context it would have-a (field) weapon. A bullet is-a ammo. A arrow is-a ammo. It would inherit from ammo. A weapon would not inherit Ammo. It has-a ammo so ammo would be a field in Weapon. And so onâŚ
Thank you very much for your answers. This discussion is really helpful for me.
What I take from the answer is that I should leave my wild Control/AppState/GameObject mixture by defining an own structure outside of JME3 by considering e.g. MVC or even ECS pattern. I was always trying to match my dev-approach and process to the JME3 toolchain and class structure in order to make my life easier. What I need is a structured way to do so.
I understand (and like) this point but why has JME3 so extensive mechanisms for loading and saving? It doesnât need them at all. To skip managing jme3 scene would make dev process more efficient because I do not have to fit my project structure to jme3.
Sure. Composition over inheritance in gaming is the most natural design decision but unil now I only used it on Spatial/Control context.
Really good answer. Now it becomes more clear. I want custom Ms not only but mainly because I need to implement big scales (Fp128 vectors) and FTL flights (for both approaches float32 is not suitable). MVC (with Spatial/Controls == view, AppStates == C and Custom stuff == M) makes sense to me. But there is also ECS as an alternative architectural pattern. What is the difference between both of them? At the moment I have no idea how to make a spacecraft flying around with ECS.
I think I will work myself through the ZayES framework, documentation and example projects for a better understanding of the game architecture. I think the understanding here will come with practice and reading
I was very careful when I named the main entry point âEntityDataâ⌠because entities are the data of your game. The logic that manipulates them are âsystemsâ in the âECSâ nomenclature⌠but the systems you make are up to you.
The neat thing about entities is that âinheritanceâ (which is kind of a broken idea for game objects) is non-existent. Itâs more like âduck typingâ. Things are what they are because of the attributes (components) that they have. If it has a position and model info then itâs displayed. If it has a name and position then itâs a label on the map⌠or whatever. It doesnât matter whether itâs an Ogre or a Tank or a map-marker. The code that uses these things doesnât care. It just gathers the âducksâ that it is interested in.
âDuck typingâ background: Duck typing - Wikipedia (though thatâs not the best write-up⌠âduck typingâ is kind of a core idea in entity systems.)
So then when the next step would be to specify the use cases (to discuss my understanding of the process):
Start game.
When starting the game the C-Controller (the GameAppState) is attached to the state manager. They initialize the M = the ECS components with the Systems (M.S = AppStates) and its Components (M.C = immutable data objects).
There would also be a system called ViewAppState (also M.S block(?)) dealing with spatial/control (=V) generation/attachment/detachment:
Example:
SerializableFunction<AssetManager,Spatial> = asm â asm.loadModel("âŚ") for scene or
SerializableFunction<AssetManager,Spatial> = asm â UnivserseGenerator(seed).newInstance(asm); for procedural content
Each attached factory would fire a show event for the ViewAppState
Update loop: The game is running
The systems provide updates each frame and perform calculations. If the components were immutable (as it seems to be) the operations can even be performed asynchronously.
Pause/continue:
The Systems (M.S blocks) are disabled/enabled.
Shutdown
Detaching the GameAppState will trigger all Systems so shut down. Because all information of the game is located in the GameAppState devastation of game world would be complete.
Save/load
I would specify a visitor traversing all the components and storing them inside a file/data base. The spatials can be skipped because the information to generate them is already managed by the factories. Only the factories or factory containers have to be stored and reloaded in the components. Loading the views would mean to go through the entities, load the V-Factores triggering showUp events on the ViewAppState.
I have now successfully implemented my first ES-Hello world using Zay-ES.
It seems to work correctly: A model is placed into the scene which disappears after 10 seconds.
The point is that I intend to understand the new concept correctly so please find the code below for review. This is for me to determine wether I ave understood the concept correctly.
Step1: First I have implemented the view component which is mainly a Spatial factory (assetManager â Spatial)
The view component class:
public class ViewComponent implements EntityComponent {
private volatile Spatial spatial;
public Spatial getView(AssetManager assetManager) {
Spatial spatialTmp = spatial;
if (spatialTmp == null) {
synchronized (this) {
if (spatialTmp == null) {
spatialTmp = assetManager.loadModel("Models/Test.j3o");
this.spatial = spatialTmp;
}
}
}
return spatialTmp;
}
}
Step2: The view system polls the viewComponents and adds them to the scene. It first resets the scene before adding the new content.
public class ViewState extends AbstractAppState {
private final EntityData entityData;
private final Node viewNode = new Node("viewNode");
private AssetManager assetmanager;
private Node rootNode;
public ViewState(EntityData entityData) {
this.entityData = entityData;
}
@Override
public void cleanup() {
rootNode.detachChild(viewNode);
}
@Override
public void update(float tpf) {
super.update(tpf); //To change body of generated methods, choose Tools | Templates.
viewNode.detachAllChildren();
entityData.getEntities(ViewComponent.class).stream()
.map(e -> e.get(ViewComponent.class))
.map(vc -> vc.getView(assetmanager))
.forEach(viewNode::attachChild);
}
@Override
public void initialize(AppStateManager stateManager, Application app) {
rootNode = ((SimpleApplication) app).getRootNode();
this.assetmanager = app.getAssetManager();
rootNode.attachChild(viewNode);
}
}
Final Step: The SimpleApplication initializes the EntityData and the ViewState
public class Main extends SimpleApplication {
private boolean firstRun = true;
private EntityData ed = new DefaultEntityData();
float time = 0F;
@Override
public void simpleInitApp() {
ViewState viewState = new ViewState(ed);
EntityId id = ed.createEntity();
ed.setComponent(id, new Name("Test"));
ed.setComponent(id, new ViewComponent());
stateManager.attach(viewState);
}
@Override
public void simpleUpdate(float tpf) {
time += tpf;
if (time > 10F) {
ed.getEntities(ViewComponent.class)
.stream()
.map(Entity::getId)
.forEach(ed::removeEntity);
}
}
public static void main(String[] args) {
new Main().start();
}
}
In any case I am pretty sure that ECS architecture is the way for me to go with my new project.
Regards and thank you very much.
As a general rule, components should not contain spatials. Itâs like storing a text entry field in your database. You will see that if you stop doing this you can avoid the synchronization completely.
Create an abstract idea of what a âmodel infoâ is⌠whether just a string or some other description. Then your view state will translate that into a spatial. Maybe it loads it as an asset, maybe it just creates a box or sphere. This has saved me so many dozens of times being able to put stand-in meshes in or debug meshes just be checking for specific info and loading an asset for everything else.
For examples you can look at the asteroid panic demo or the sim-ethereal es demo.
âŚthough this version still does it the manual way. The SiO2 game base library has some nicer features for more easily doing this sort of entity mapping.
Sim-eth-es:
This one uses SiO2âs entity container which makes it a little more straight-forward:
This example uses a general ObjectType component to decide which assets to load or create.
In a lot of my games/demos, I tend to have a ModelInfo component that takes a String and then I either use that to manually create something (.equals(âboxâ)) or load an asset using that string.
It seems that I have to get rid of some bad habits bcz I again could not resist to store Spatials inside the components This was exactly the reason why I started this discussion on this level. My goal is to avoid such bad habits (for me and for others) by defining a clear idea of how a good game architecture has to look like and it seems that I got a lot closer to that goal the last two days.
So the ViewAppState cares alone about spatial generation and attachment while using the components as construction manuals. To take this idea even farther one could even develop a ConsoleOutAppState which displays the components as console output without using jme3 at all. And all of this can be done just by exchanging two AppStates? It sounds too good to be true. Is there a catch on it?
Again back to the spatials:
When talking about loading Spatials I have exactly two use cases:
Load a predefined model with all the bells and whistles or
Generate asset procedurally.
Both cases resulted in a spatial attached to the scene so the output is the same. But both operations need different input: 1. is a string and 2. is a set of parameters/instructions necessary for the constructor/builder (seed, color, math function etcâŚ). This information has to be stored inside at least two different types of ViewComponent to be supplied to the corresponding view factories.
I think I will try it. But I will go step by step. Just loading colorful boxes to scene until I get confident with ECS before again dealing with space battleships with turrets and crew and so on
No catch⌠thatâs the way. Or you could create a 2D map view, for example. These things are quite common.
One must be careful with the second approach not to venture too far down the âeverything is configurableâ path. In the end you might be able to have a string name that refers to a common set of parameters, after all.
I just realized that communication among the system/event handling in ZayES seems to be very straightforward. I just want to share my understanding with you in order to ensure that my picture is correct:
0. Each system is an instance of an AppState
Each system takes a filtered EntitySet from the complete entity data during initialization/constructor/⌠Only entities with a relevant set of component types (e.g. position, health, âŚ) are taken into the EntitySet (Analogy: Entity=key, Component=shape of the key, System=the key hole).
By calling applyChanges() the change events on the filtered entity data are polled. Only the changes between tow applyChanges() are taken into the collection. The content is then split into three entity subsets (Added entities, Changed entities and removed entities). Every entity can only belong to maximum one of these three groups. So initialization/update/removal operations can be performed on each entity dependent to which group it belongs.
The System can then perform operations on the entities by writing components. The other systems continue listening to the changes on their specific entity set performing the same operations as described above.
Consequence ==> The systems do no care about each other because they seem to be completely decoupled. They are only reacting to component changes of the entities in their filtered sets. If a system (e.g. health/damage system) is missing no NullPointerException can arise. You will realize it during game play (e.g. damage system not present ==> indestructible objects)
Note: the added, changed, removed entities are one of the nice things that Zay-ES provides but there are some systems that wonât use them at all⌠as they just iterate over whatever is current. (For example, a damage system that just iterates over all entities with a Damage component and applies damage might not care about the adds/removes/updates.) Obviously, applyChanges() still needs to be called in these cases.
after working with ZayES for some weeks, I came along with two solution from which I would like to know whether they are feasible or not. For now I have two points. Further points will follow.
Hierarchical game objects (like spacecrafts and turrets/antennas etcâŚ
The child objects have to know about their parents (the entities to which they are attached to).
IN the entity component systems architecture I handle the children the same way like their parents except they have a parent component containing a long indicating the entity to which they are attached to.
In the position update system I traverse all entities which have absolute position and who do not have a parent. I perform update of the entities by writing the absolute transformation (position and rotation) into the entity.
Then I search for all child entities (all entities which have the current entity as a parent). All child entities have a local transformation component with respect to the parents. I calculate then the absolute transformation and store them in the entity.
With the absolute transformation of all entities available the other systems can use the absolute transformation without caring about the hierarchy. This results in attaching the views (spatials) of the parents and the children directly on the root node without having to deal with the scene graph hierarchy.
Loading of game objects
When loading game objects to the scene it is required to load the complete entity structure to the scene. This structure has to be stored and loaded somehow. For me it is quite unclear how to deal with this. Where and how would you store the the entity structure which is necessary to load a space cruiser with turrets/antennas according to point 1?
Well if you followed the ECS principles, this should be no problem, as your entity data is stored and loaded back, your systems construct the previous state, donât they?
Eg, a component named Parent with parent entity id stores the children parent relationship
but it also feels like breaking with the concept by adding additional responsibility)
