This project is read-only.

Design Pattern

The engine was designed using the component based design. That means the hierarchy model is no longer the first option, instead the aggregation model is. Every entity in the game’s world is a game object; each object has no meaning by itself, instead its attached components (aggregation model) gave that meaning. This presents several advantages, it allows having a far better modularization, the code it is simpler and more parallelizable and the data locality (in RAM) is better. Giving the success of Unity 3D, XNA Final Engine was organized following a similar component organization but making changes wherever it’s necessary.

Making a game is not easy for several reasons and performance is one of them. An excessive number of cache misses is one cause why games sometimes run slowly and is very hard to track and even harder to improve. There is one excellent paradigm that is starting to be used in game developing, the data oriented programming. The wonderful about this paradigm is that not only produces faster code in data oriented applications (like games), it also produce more readable and maintainable code. Both, the component based design and the data oriented programming are complementary (actually components are necessary to produce a good data oriented game) and it is the tendency in AAA games. Moreover, both are complementary with the object oriented programming and the hierarchy model. Not everything needs to be done in one way or the other, it is up to the engine designer know where to apply one or the other. XNA Final Engine follows this design pattern.

The engine manages all the main system, ideally the developer only needs to take care of the logic. The device, assets and managers are completely administrated by the system and even exceptional cases like a device disposing where taking care automatically. The developer does not need to know where and how to call the different functionality, it only needs to attach and configure components and entities, and sometimes manager parameters.

It is also designed taking the XBOX 360 limitations in mind. The .NET runtime implementation on the XBOX 360 is not perfect. For start it only performance level 0 garbage collections, that means it performs the collection in all the game data and that is terrible for performance and frame stability. Moreover the arithmetic implementation is not fast. XNA Final Engine is garbage free (except the editor) and it takes in consideration the arithmetic performance. Furthermore the XBOX 360 only has 512Mb of shared memory so the engine tries to reduce memory consumption, especially in render targets. The EDRAM (a cache for render targets) of the XBOX 360 has only 10Mb of memory as a result the G-Buffer is confined in this area (obviously the user has to use a resolution smaller than 1200x675). And of course there are other XBOX 360 hardware limitations that were considered.

Last edited Jan 22, 2013 at 1:29 PM by jischneider, version 3


No comments yet.