Monday, October 29, 2012

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!

Tuesday, October 16, 2012

Developers Log. Development Date 2 - State machine

Despite the exciting news of Ninja Royale being selected (!) I opted to enjoy my fall break and stay away from the blog. That doesn't mean, however, that I didn't stay away from coding, as I had much to get ready before letting the group run wild with the code. I wanted to make sure what we were keeping was in a solid state and would be a good and reliable architecture for us moving forward.

This past week I worked on completely removing all of the abilities we had, and converting them to states, with a state machine. Each state has a animation that is playing and a movement controller. States are responsible for animating the player, and changing states (from being in the air, to on the ground, to running up a wall, to hanging, to climbing, etc.) Movement controllers however are responsible for movement, obviously. We currently have 5 movement controllers: OnGround, InAir, Hanging, HorizontalWallRun, and VerticalWallRun. I'm sure we will add a few more, but that is those are the core movement controllers, and each state uses just one, depending on the state, obviously.

The biggest concern right now is "What is the game?" We got shut down pretty hard for making a multiplayer game. That doesn't mean we won't have multiplayer in the end, but that can't be the game, or the focus. Right now I'm leaning towards a single player/co-op experience. The thing that scares me about that is story, I'm terrible at creating a story. Luckily I have a group of ten other individuals who will be able to be the creative driving force for that. Once we narrow down what the game is we want to create, we will really be able to start deciding what is most important to get done first, set modular mile stones and start pumping out a game!


Monday, October 1, 2012

Developers Log. Prototype Date 28 - Final Prototype Date

Today is the last day to work on the prototype. This weekend I fixed multiplayer, and it's awesome. There is a short clip of it working in our video we will be showing in the presentation. I also fixed the animations glitches we were seeing. Lastly I added the ability to run up a wall, and either flip off (to dodge an incoming attack) or grab a ledge-- it's pretty sexy.

We had a big discussion friday night/saturday morning about the gameplay, and ended up in a really great place, I feel. This was a big milestone, as we hadn't really set out to define the game rules, just the mechanics. After a lot of discussion we found something that we all would love to play.

I'm not sure if this will be read before the game is picked, but I must admit that I understand the ambition this project carries. It will no doubt require a lot of work from everyone involved to make it awesome, but I think it is absolutely do-able. I would very much enjoy working on this for the next year with dedicated and talented students who also desire to make an amazing game. Most of my team has worked their tails off these past few weeks to make the best prototype we could in the short time we had, and we are pretty happy with where the prototype is. It shows off Avatars working in a 3D environment, using custom animations, with multiple players, parkouring around. So much for 28 days with just four guys! Give us a full team and a year and this will be a polished, beautiful game that will give us great experience and a fantastic portfolio piece!

And with that, I guess I will see you on the other side.*


* Other side refers to the time in which the 3 games have been chosen and I have been assigned to the game I will work on for the next year. [Hopefully still Ninja Royale!] :)