Developers Log. Development Date 13 - Components and Entities

The project is moving along nicely. Lots of game defining this past week. Locking down the goals of the game is really important, and we have had great strides in that department. Additionally we have been tossing out names for the team/business and are now voting on them. Exciting times!

The rabbit hole I journeyed down this past week, and then clambered back up once I reached the bottom, was a code restructure for a component driven entity system. I wanted to get this done so that the team could begin work on some AI systems and allow the creation of different NPCs with different components.

I decided to keep the entity system pretty basic and ride the coat tails of the components already a part of the XNA framework. This required me to simply have an abstract entity class that handled adding, removing, and checking for components while restricting them to be a GameComponent. Here is the basics of an Entity:

 Dictionary<Type, GameComponent> components;  
 public Entity() {  
    components = new Dictionary<Type, GameComponent>();  
 }  
 public bool HasComponent<T>() where T : GameComponent {  
    return components.ContainsKey(typeof(T));  
 }  
 public T GetComponent<T>() where T : GameComponent {  
    if (HasComponent<T>())  
       return components[typeof(T)] as T;  
    return null;  
 }  
 public T AddComponent<T>(T component) where T : GameComponent {  
    components.Add(typeof(T), component);  
    return component;  
 }  
 public void RemoveComponent<T>() where T : GameComponent {  
    if (HasComponent<T>())  
       components.Remove(typeof(T));  
 }  

Using the GameComponent from the XNA framework handles component management for us. The game thread will already update each component, so all we have to worry about is getting components from entities, which is stored in a dictionary so the add/remove/look-up are all essentially O(1).

Outside of that, I moved onto refining controls. The in air controls are much more smooth. The velocity is captured upon entering the in-air state. Each update it progresses from its movement to the desired movement (the max move speed multiplied by the input vector.) This allows the player to jump while standing, and achieve full move speed in the air, but it takes longer than it would on the ground. Additionally, the player can let go of the thumbstick mid air and after a very brief delay come to a stop. It feels much better this way, and I am pretty satisfied with the results.

After having in air controls working, I was able to move onto wall jumps. This was previously problematic as the in air controls would either remove all velocity, or do weird things to it (depending on which version I was using.) Once the controls were working, everything else was cake.

Lastly I did a cleanups of removing friction from walls, fixing the timestep in the physics engine to stop the player from passing through walls at high velocity.

I intend to move forward adding some time between rotation (as it is currently instantaneous.) While we want it to be near instantaneous, there needs some time for animations to make everything look smooth and believable-- but still fast and agile as only a true ninja can move. That will carry me through the sprint after which I will be working on the combat system framework so that we can start to get that ball rolling!