Creating a new entity starts with the idea of what is needed. If the developer is loading up the engine tools without any clear indication of what they should be doing then they are wasting their time. Sometimes this can be useful when learning a new engine or figuring out the best way to implement something.
However, when we are working on the game and trying to get actual work done it is important to have proper game design documents to support the work you are doing so time is not wasted and the best game possible can emerge from the development process. As one stop shop indie development studio time is our most valuable asset, we must make proper use of every hour we use to maximize our offering to the players.
We will go through the motions of creating the fusion reactor that is used on the player's ship in Space Trucker. It is a familiar object, is seen often, and can be interacted with. There is a model component, a GUI component, and this object will also be plugging into the grid network we constructed to pass messages around between machines. Below is an example of a mostly completed reactor, and what it would look like when it is powered on and running. There would be another state for when the machine is offline also.
The next part is where prior design and research really can save us time. For Space Trucker all of the machines and their GUI components were designed ahead of time in programs unrelated to the actual game engine such as Pencil; which is a program to plot out GUI's in this sketch like format without any code to get a purely visual idea of what a GUI might look like based on requirements gathered from whiteboard sessions that determined interactions between the machines.
Below is a graphic that shows the sketch prototype that was made on the left, and on the right the completed GUI in the resource editor used by the engine. It is nice when expectations can match what is possible this closely, sometimes you might not be able to get as close to this but what matters is that we had a clear direction about what we wanted before we even got started.
With the entity and GUI designed now it is possible to perform initial placement of the object on the map. In the screenshot below we have the players ship with the hull made invisible so the guts of the ship are clearly visible and easy to work on. Our fusion reactor is in the back near the middle, there is another machine that sits in front of it which holds the reactor monitoring GUI we built in the previous step.
Moving on to the next phase of entity creation we need to plug the machine into a special alarm panel called an annunciator panel. This is basically just a fancy word for an elaborate alarm clock that is tied to various machines and triggers when a particular event happens that is pre-programmed into a module used by that given light.
So for example, the REACTOR DAMAGED plate in the annunciator would not turn on or activate when the reactor was damaged unless it had a reference to the one in the game world and was able to periodically query the machine's current state in a way that would not waste performance every tick in the game engine. The same conditions would apply for plates like REACTOR OFFLINE, and of course REACTOR ONLINE in the case of the reactor and similar conditions would apply for any other machine that would like some special type of alarm like this.
The colors on this panel represent different levels of warning. White panels are purely for informational purposes and do not trigger alarm state on the ship. Yellow is something the player should keep in mind for the near future but typically does not indicate immediate danger unless the warning is for something like low oxygen. Red is the most severe plate color, meaning action must be taken right away to prevent damage to the ship or the player themselves such as the case as running out of oxygen to breath or being left stranded in space because the player ran out of water to fuel their ship.
Now we have many of the parts that make up our machine completed and in the game in one form or another which is a great step up from just having them on paper as conceptual ideas. The reactor can be seen in the shot below in the right side behind the monitoring tool for it which is not active in this shot because none of the GUI's are active while in the map editor and only get loaded when the game is running because that is when the logic for the machine is instanced and running and can actually do it's job.
An entity in the engine is a text based affair. The use of things like binary formats or special encryption will only make it harder for you to work on your own game in the future and it also makes it harder for players to make modifications to the game which might actually make it better! In this regard there is no reason to prevent access to these files, or use some convoluted system that cannot be read with something as simple as notepad.
It is not important to know every property in this file, it is more about how the structure of an entity in the engine is nothing more than a plain text document which removes some of the mystery from how something like this gets constructed in the first place. It contains all of the information we need to render the object and create a class to control it in the game world. Other properties like static indicate that the object doesn't move and will stay fixed.
This file is created automatically by the resource editor when we create a new entity using the built-in wizards. It is then very straightforward to add attached objects to that entity which can each potentially have their own class controlling them along with the base initializer class which the entity will be casted as during runtime. Editing an entity will update this text file with the latest definitions which the engine can then use to create the entity at runtime.
The last part of our journey to create a new entity ends with the tasks of programming the custom logic for the machine itself and the GUI proxy wrapper that will look at that machine entity on the map during runtime and update itself whenever the data it changes.
Another way to explain that paragraph above would be that the machine has logic to power interactions with other machines on the grid network, and the GUI is not a machine but rather more like an elaborate sensor. However, it is possible for the sensor to take energy also. This is meant to simulate conditions in reality where a digital sensor requires electric power in order to perform it's function.
The GUI for the fusion reactor is pretty straight forward once you understand what is happening for it to actually create the energy. Water is split into base molecules, then refined with greater amounts and split into a 50/50 mix that becomes the fuel for the reactor. This deuterium-tritium gas mixture is flooded into the reaction chamber and then spark ignited using a massive amount of energy from the ship's battery reserves.
Once the fusion reaction has started, the gas is pumped in slowly to keep it burning and supercritical. The heat generated from this is harvested as steam which is created from intense heat of the fusion reactor boiling the ship's water reserves and allowing that to turn a turbine which generates electrical energy that is then stored in the ship's battery for consumption by other machines.
The buttons are functional and allow the player to stop and start the reaction, however if there is no water reservoirs or not enough power to spark the fusion reactor then it will not be able to create the initial spark to get things going which would leave the player stranded meaning they will have to keep careful watch over their water reserves as they travel around the galaxy.
Next post we are going to talk about dynamic music and how it is used in the engine to set mood and tone for a given part of a level.