Some time ago I wrote about an interesting take on game architecture, Entity-Component-Systems, and just a few week ago I took the occasion of the publication of the Diablo pitch document to remember how much it is important to study and self improve. True to my world I decided to delve a bit more into ECS by studying one of the most famous game engine available today: Unity 3D.
When we started this project I decided to use it first and foremost as a platform for self-improvement, I have thus decided to create the game almost from scratch. My background in engineering helped, of course, plus a passion for videogames that started when I was little and also an overall decent knowledge of 3D math. I am not, however, a software developer. I worked a bit as one out of College and it have always been a passion for me, but my formal education in the field is really limited (I am a telecom major) and I always knew that I had to work a bit more to achieve certain goals.
Today I consider myselff a proficient programmer, I am able to “speak” a dozen programming languages and I have at least a rudimentary grasp of all the basis needed for game development. Still, I have a long way to go. This week, for no specific reason, I decided to take a look at a commercial grade implementation of a game engine architecture and Unity looked to me as the natural choice: it is free for personal use, very well documented, uses C# as one of the main languages and it is overall one of the most suggested choices for indie teams.
The first thing that I learned is that Unity actually implements an “Entity-Component” architecture. There are no actual “Systems” involved: the components are structured in such a way to act as their own system, that is, they contain both data and implementation inside the same object.
It makes sense, in this way it is very easy to present everything that is needed in a graphical way (I found the interface design quite good) and designers can get productive really quickly without having to think too hard about software architectures and design. I believe it also makes very easy to build the solution. There are, as always, downsides. For example I believe there is a small loss in optimization (you lose the locality of the data and the order of execution becomes per entity instead of per component, at least that is what I understood) and the overall structure is a bit less clean (you mix data with functionality).
It made me think that this approach may be a good compromise to not over-engineer to much our architecture while keeping a good structure that may provide a great help as things get more complicated with the inclusion of certain exceptional behaviors, like the ones for bosses.
Now, the next think that I would like to study is how they implement particle effects. This should be interesting!
Stay curious and keep learning.
Thanks for reading.