Component Scripting and 3D Rendering

It has been a while since I have posted an update in regards to my Game Engine Design. Well, for the most part, my Component-Entity Design and manager are completed and compile without errors. The nice thing is that it also shuts down without any memory leaks as well.

So, in the long haul, it looks like creating entities will be a breeze after I incorporate a file parser for a standard text file that will create entities. How will this work? Well, I plan on creating a class that will handle the importing and parsing of the file, send that data mined from the file and send it to the World (a class that contains all the entities, managers, and processors). From there the World will create Entities with the given components that the file dictated.

An example of what I want to do is as follows:

(In .txt file)
new Entity "PhysicalObject"
{
    has <Movement>
    {
        Position(1.0, 1.0, 1.0);
        Rotation(0.0, 0.0, 0.0);
     }
     has <Physics>
     {
         Acceleration(0.0, 0.0, 0.0);
         Mass(25);
      }
}

So, to explain this, I would have a buffer of the file contents loaded into the program and then have each symbol interpreted based on what I declare data relevant to the creation of Entities. For instance, in the above example new Entity would declare the intention to create an entity with the given name in quotation marks. From here, all data in the brackets lists the components it has. That is what the keyword 'has' is for. When the parser finds the 'has' keyword, it will search the brackets ('<' and '>') for a relevant identifier of an identity. It will then convert this to a bit field that identifies entity components for registration with the entity manager. The, inside of the brackets after the declaration of the component, is the definition of the components properties. If one was to look at <Movement> they would see that in the brackets is defined Position() and Rotation() with values separated by commas. This determines the initial position and rotation of the entity in question.

This is just some of what I wish to do with a custom text importer for the creation of entities in my world. What I hope to achieve with this is rapid development of games or simulations without the need to recompile every time I want to add a new type of entity.

Now that I have explained what I wish to do going forward, I have to talk about what has to get done first. In order for me to actually see if my methods are working and this program works, I need to get something rendered to the screen. Now, since this is primarily a game engine, I need to incorporate 3D models, 2D textures, Rendering to a texture for effects, and shadow mapping. This would be the core of my rendering engine.

So far, I have finished a file parser for static .OBJ files for 3D objects. The only hitch is that it only imports the models geometry, normal, and UVs. The texture would have to be imported separately and then applied. Speaking of which, my texture importer is also done.

The only things left on my TODO list for the 3D rendering engine is as follows:

Class and interface for .FX files.
Class and interface for Shadowmaps.
Interface for 2D textures of models.
Class and Interface for Render to Texture for effects.

From there I will have all of those interfaces accessible through the DXManager that I have already completed. I plan on completing this within the next two weeks, so feel free to check in within that time period for some updates!

Engine Design: Components, Managers, and Entities

I have spent quite some time on my engine trying to figure out a name. But what I have spent more time on is the infrastructure of the engine.

The component based design I have been going for has been coming together very well.

The layout of the design follows this pattern: Base Component class with necessary virtual functions such as type identifiers and a default constructor that requires any new component derived from the base Component to identify itself. There is a list of Component Types contained within a namespace and globally accessible. This list contains identifier names associated to a bit within a 32-bit field - each one must be different. This allows for only 32 types of components.

In conjunction with the Components is a component manager that holds vectors of all the different types of components. Now, one thing to note that there are n vectors in the Component Manager, where n represents the number of components. This is preferred to avoid searching one giant vector of components in order to collect components of a certain type. The Component Manager is responsible for storing all components in the game and giving them out to processes that require the component data.

Containing components is the Entity class. It is small, containing merely a vector of dynamically allocated Components and a name. When it is created, the components that it has are defined in the constructor and allocated into the Component vector. Then they components are registered to the component manager.

So far that is all that I have accomplished so far but it was a lot of fun implementing such a system into my game engine architecture. Soon, I hope to have video to show the design and methods behind the engine.