The architecture of software design is a much-debated subject. Every developer has his own opinion about what is good software design and what is not. Most developers agree on what is bad design, on what is good design there are a wide variety of opinions. Unfortunately, due to the nature of software development, there is no silver bullet; there is no one design strategy that always works.
There are a couple of strategies that have proofed to be successful. These strategies have known strengths and weaknesses. The advantage of using such a strategy is allowing you to focus on building your game, instead of worrying if your codebase will implode after someone decided the game should function a bit different than how the code was originally written.
In game development, the entity-component-system is an architectural pattern that is used successfully in small, medium and large games. The main strength of this strategy is the usage of the composition over inheritance pattern. This pattern prevents the build-up of complex object inheritance tree’s, that will make your code impossible to refactor without a lot of side-effects.
So how does this pattern work, at its core, there are three elements; entity, components, and systems guess you didn’t see that coming. Let’s describe these one by one, I’m starting with the smallest and most simple one the “component”:
The component represents a single attribute of an entity. Some examples of entities can be:
Position Rotation Scale Physics body Texture Health Entity
Entities are the “game-object” some examples:
Ball Camera Player Enemy Bullet An entity can have multiple components, for example, a ball entity can have the following components: position, rotation, scale, texture and physics body. A camera entity might only have a position. Usually, all entities have a unique-id for fast access, but there can also be other ways of accessing entities.
The system is responsible for one aspect of the game, a simple game has can, for example, have the following systems:
Rendering Physics GUI Sound AI What a system does is iterating over all entities that have components of the types defined by the system. For example, the physics system will act only on entities with a physics-component and a position-component. The rendering system will only act on entities that have a position and texture component.
For example, if a ball entity has a position and physics and texture component. The physics system will pick up the ball entity, as it has a physics and position component. The physics-system control a physics-engine, that will do its magic and calculate a new position for the ball. The physics system will set this new position on the position component.
The rendering-system will also pick up the ball entity, as it acts on all entities that have a position and a texture component. The rendering system can render the ball using the texture and the position found with the ball entity (yes, the same component that was just updated by the physics-system).
Now imagine you spend some time implementing the architecture described above, and you after, running it, realize the ball is not really moving very realistic. That might be because you forgot to take rotation into account.
To fix it you now only have to create a rotation-component and add it to the ball entity. Now add in the physics system a check if the entity has a rotation component and if so just set the rotation on this component. In the rendering-system also add some code to check if there is a rotation component and if so render with this rotation.
This is where the power of this architecture emerges, imagine you have not one ball entity but have a lot of entities like the ball, wall, player, ground, etc. and you forgot about the rotation. You only have to modify the rendering system and the physics system. Then by simple adding a rotation component to the entities you want to have rotation on, magically all those objects have a rotation. Now adding rotation seems like a trivial thing to do, but what does this architecture enforces is the separation of concerns (e.g. rendering and physics) while still allows adding new functionality. And important; It does this without the usage of inheritance but rather by composition.
The architecture described above is in itself quite powerful. But there are some more interesting possibilities with this architecture. I will describe some of them below.
Creating a generic mechanic-tuning-utilities; as there are a limit number of component types, you can create a (developer) GUI-overlay that allows you to modify the values of a component. This will allow you to in real-time modify the values, e.g. the position, size, texture, acceleration, the weight of a certain entity his components. This will help you tremendously in fine-tuning game mechanics without the need to keep recompiling and reloading your game.
Taking this even a step further you could use the above system to load all entities and relevant components from a file, e.g. XML. This will also help you decrease compile and loading time, letting you focus more one tuning game mechanics. This could then be a very good start for creating a level-editor, letting a none technical team member (game-designers) tweak game mechanics.
Something else that can be managed using this system, is implementing an entity loading/unloading mechanism. You can define an interface with functions like initializing, loading, starting, stopping, unloading, destructing. Now you can implement a loading mechanism that guarantees the loading and initializing always happen asynchronously. This will allow you to load and unload entities in a uniform and controlled manner. You could also choose to run all the systems in a different thread you need to take some more care about modifying components, but this could allow you to do a lot of performance enhancements, as for example, the AI needs less frequent updates then a renderer.
Note this implementation is done in Java, as I’m using libGDX as the platform, but the architecture is certainly not limited to Java and can also be implemented in other languages like C++.
Enough of the theory, now for a real implementation. As a hobby project, I have been creating a small iOS/Android game, my first implementation of this game was naïve, with one source file containing all logic. No need to explain this is a bad implementation, but this did allow me to check if my idea was fun and create a quick prototype and do some fast iterations from there.
For reference, the “bad” implementation can still be found here: https://github.com/tgobbens/fluffybalance/blob/master/core/src/com/balanceball/Balanceball.java
After I created this implementation I decided I wanted to implement the same game using a better manageable implementation.
The “main” entry file can be found here: https://github.com/tgobbens/fluffybalance/blob/master/core/src/com/balanceball/BalanceBallSec.java.
So, I’ve created my own entity-component-system. If you want to create your own game using an entity-component-system, and want the game to be ready as soon as possible then I wouldn’t recommend writing one yourself. However, if you want to learn about programming or just create something for fun, implementing such a system is easy, and you will learn a lot from doing this. Another reason to implement this yourself is you get a lot of freedom allowing you to add specific tricks and features that can help you improve your codebase.
The entity component system can be found under https://github.com/tgobbens/fluffybalance/tree/master/core/src/com/sec and yes there are some optimisation and improvements opportunities in this code base. But it does show an easy to understand implementation. When trying to understand make sure you know what Java generic types are. It’s quite common you need to find a certain entity to update or get some info from. As there are a lot of components you know there will be only one instance from. I’ve added a method to get the first entity of a certain type. For example, give me the camera entity, or give me the first “game-world” entity. But there are also helper functions to get all entities of a certain type. The same trick is used for getting components of an entity.
You will also find a basic type called “engine”, used for binding everything together. This will trigger the updates and holding references to all systems and entities. If you look for a “starting” point for the architecture this is where to start looking.
By Kevin Pudlo
Airlock 22 is seeking a Sprite Artist to help create the art and animations for a video game we are developing. Artwork is currently just placeholders done by myself until we can get someone with much more experience to help out!
- Create Sprites that the Engineering team will be able to bring into the game under production.
- Assist with Sprite animations if it is something you are comfortable with.
- Collaborate with other team members to develop artwork for current and future projects.
- Ability to work independently
- Ability to focus while working remotely
- You are able to create your artwork in a well-lit environment
- Experience with Sprite Animation
- A very creative mind
- Excited to help build a studio from the ground up.
Please contact me at email@example.com
Hello all! I'm new to the forum and I'm glad to have found a lot of interesting discussions/topics!
Quick intro, I'm currently in school for Independent (indie) Video Game Design, on my last semester and the job search will start in less than 4 months (I'm nervous to say the least). I've learned a lot in school and I'm proud to say that I can make a decent game independently and market it properly. The problem is that I can do all of this, but I don't specialise in anything specific. I'm pretty good at modeling (but definitely not a pro, can only make simple clean models), okay at scripting, design isn't my strength but a big interest and I'm pretty okay at UI/UX but definitely not proficient at all.
I can't say I specialise in any of the above fields and I know that specialising in something is important in order to have a consistent portfolio and finding a job.
Should I focus on specialising on a specific field in the next 4 months (practice 24/7) in order to sell myself to employers or should I practice everything and sell myself as a Jack-of-all-trades? I really want to get a designer job as I enjoy writing GDDs and discussing design during Pre-Production but my Rational Design knowledge is weak and I've never been considered a designer in all my previous projects (always was responsible for art or UI).
Hi, I am new to Game Development and am currently making my first game in Unity using c#. I am a second year uni student studying computer science (internet security specialization). I am new to unity and have had trouble understanding how the game engine actually functions and how I should use the engine to my advantage when programming. Currently I am making a RPG and want to implement an efficient and scalable item database. My plan is to store all items in the game in an xml database using the built in unity xml serializer. I have an abstract class item -> weapon, armour, potion, ring etc. Each of these classes have respective values (damage, cost etc.). For a relatively generic and straightforward item system: How would you organize your code? What interfaces/classes/other would you implement; why? In your experience what kinds of issues have you run into and how did you work around them? Is there any other advice with regards to rpg design in general?