Tuesday, January 29, 2013

Developers Log. Development Date 72. Animations and Profiling

Woops, forgot to blog last week. I blame the respiratory virus that had me in bed all week.

The first issue I addressed was animations. Our animations have been really glitchy. They would reset halfway through and/or flicker. I finally allocated time to go figure out why. It was a simple fix once the bugs were found (related to a poor implementation of a student last semester of my animation code and some blending animation code from the Microsoft education catalog.) Essentially some animations would be called to play twice or reset mid play-through. 

Second I found a profiler to help us identify where our draw and update calls are spending most of their time. It seems pretty solid but has awkward interface controls, so I lightly wrapped the controls to allow us to toggle the display on and off, enabling us to turn it on when we need to check what is going on when we start to see performance hits.

Lastly I worked on some scripts to help convert a level created by one of our artists in Unity to fit the format we have designed to be accepted into our content pipeline. Within a few clicks all of the prefabs become converted to the format now.

Tuesday, January 15, 2013

Developers Log. Development Date 58. A New Year!

With the end of alpha I never found time to return to the blog before the semester had ended, and had no ambition for blogging amid the Holiday break. With the spring semester of my Senior year here, it is time to rekindle the blog for our XBLIG game (current code name: "Ninja Avatar: The Trials.") Despite being MIA in from the blog over the past few months, I continued to work on the game.

I took advantage of the break to work on a some Unity3D scripts for the editor allowing us to harness the power of control and ease-of-use unity offers for level and prefab creation for our XNA level creation. The artists can now create a model, then use unity to set up custom collision walls, and save it as a custom xna prefab. They can even use the same model (and different ones) to build a collage of models into one prefab. (When loaded in xna it still only has to load the fbx just once, however.) These models are used for the level creation. Both the models and prefabs use xml serialization. On the XNA side we will simply reconstruct the prefabs as we build each level. This will greatly improve our performance and ideally our level creation/maintenance time. It was also key for quest/objective design for the levels.

Since the semester started back up ago last week, I have been adding some functionality to the tool such as an opacity slider for the display/collision models. I've also fixed several bugs and cleaned up the process the user has to go through to make it a more smooth experience.

In addition to working with the tool, I've been working on tightening the controls for the game. This game absolutely needs tight controls, and they just aren't there yet. I've spent some time with Overgrowth (an indie game under development involving light parkour) observing the controls hoping to get a better feel for what makes something feel so good and tight.

Additionally, in my spare time, I began doing some research for prediction and smoothing for out networking side of the game.

Monday, November 26, 2012

Developers Log. Development Date 41 - Networking

I'm behind a few days, but that is for good reason. Alpha is approaching (10 days and counting! Yikes!) and there is so much to do. With the restriction that every system must be in place, we are, obviously, getting every system in place, and that is taking a lot of time and commitment! From a collection system to a UI, my team has really stepped up to get a lot done this sprint. I started off the sprint helping Adam to get the corner-wall shimmy maneuver working, as well as helping Mavin with the limbo state transition the player enters when jumping off of walls (a limbo state is a state where the player has no movement, either for a set amount of time, or until he/she hits the ground, grabs a ledge, etc.)

Post helping the team, I finished the problems we were having getting the game to work on the Xbox. Which reminds me: sadly, you still get a wall of text this week rather than the promised video. That will come next week, but my progress this week isn't quite ready to be shown in a video.

After fixing the xbox deployment, I set out to integrate multiplayer. First, I set up a screen system to allow us to have a lobby screen, a matchmaking screen, a game search screen, and, of course, the game screen. The player starts off, is forced to sign in if not signed in (currently only noticeable on pc, but once the game is launched this will be important too) then they can choose to host a game (local or live) or search for a game (local or live.) This all works rather well. Once in the lobby, the players signal they are ready and the game starts. A lot of this code framework came from step 4 of the xna Microsoft tutorial found here. However, I built my own network controller class that helps manage the creation of the different types of networks, and different actions the user can perform. Additionally I added a player class that helps keep the players Character entity paired up with actions such as transmitting the data to the other sessions.

I'm not entirely done with the last part, but it's getting pretty close. Once I'm done with the basics of multiplayer, I will be working on the abilities to the end of the sprint. The final sprint will be helping the team finish their respective tasks, and working on controls. The controls have gotten wonky, and need much love before I'll be happy to call it Alpha.

Thursday, November 15, 2012

Developers Log. Development Date 30 - AI Refactoring, Abilities, and Pair Programming

I learned the value of pair programming this week, at least i learned a new value to pair programming. I worked with Ron, who is the lead for out AI, and we did a lot of pair programming. When we first started to have some of our programmers work on AI, I mentioned the approach I felt would be best for implementing the AI character; however, I wasn't working on AI at all and so they ended up taking it a different direction. I think that even though I originally showed everyone the code and the way it was structured, the programmers didn't fully understand the strengths of the entities and components, and some might have even felt intimidated by the code base. But doing some pair programming helps to align everyone to the same vision of the game and the engine. I hope to do more of this to help instill more confidence in all of the programmers in going out into uncharted territories and build new systems needed for the game.

Having worked with Ron we ended up pretty much where I had originally envisioned the AI systems, being that there is a base Character entity that is used for both the player and NPCs.  This Character object then has different components for handling movement, state changing, ability control, etc. The player has a PlayerInputController and the AI has an AiInputController that the movement state machine uses to move the player around. This may or may not be the ideal way to do this, as I'm no expert on AI, but I felt this would be a good approach as harnesses our movement state machine which was in place for the player with no code duplication. The AI will now not be able to move when he is knocked off his feet by the player, without the AI code needing to know that. Each AI state (the AI also uses states to manage which task is at hand, such as patrolling, chasing the player, searching for the player, capturing the player, etc.) The AI can just continually "press" the thumbstick the direction he needs to go to get to his target, and if his movement state is affected by some external force, it won't break the game. His movement wont override the forces, as the movement is completely separate in a different component.

Aside from the refactioring I also finished setting up the AbilityController allowing abilities to easily be mapped to different buttons. When the button is pressed, the controller will spawn a new entity for the ability. Each ability will have it's own components (if needed) if it is a projectile, a mine, or an AOE. By being an entity the ability can exist for just a moment to apply the effect and disappear, or it can persist for however long.

Currently I am working on some new movement states for putting the player in Limbo. I intend to work with Mavin on this as it will help him manage player jumps off of walls and such. There are times when the player needs to lose control of movement, and these limbo states will accomplish that. This will enable us to allow the player to move exactly how he wants, even in the air, -most of the time.- If, however, the player is thrown into the air by another player/guard, or jumps off of a wall, we may want to restrict or remove his/her control all together. These limbo states can then serve to manage the control restrictions, while still transitioning the player to a new state (perhaps a SittingOnGroundLimboState, when landing after being thrown, which requires the player's avatar to stand up before he can start running again.)

On a different note, I'm hoping to start doing video blogs in the future, that should help kill the Great Wall of Text that appears on all of my posts. :)

Tuesday, November 6, 2012

Developers Log. Development Date 21 - Abilities and Combat

This week I had to do some of the awkward parts of being team lead, namely having a discussion with a team member about their time management in regards to the class work. Overall I feel it went rather well, we were both able to express some concerns and gain a better understanding of each other. It was a good experience.

Within the realm of programming I have been working on a combat system. We have decided to have an ability based combat, rather than a Ninja Gaiden style of hack and slash style using a physical weapon. We still lack a concrete vision for the controls for the combat- so I leaned on Ross, our design lead, a lot this week to help find the direction in which to implement the system.

Currently we have an AbilityController component that spawns an Ability Entity. This allows each ability to have multiple components. Using an Entity allows the spell to either follow the player, or be projected out.

I've only integrated just one ability so far. It's a gravity pulse that, when triggered, finds all of the non allied characters around the player in X radius and flings them in the direction between them and the player, but with a much larger force, so that they go flying past the player. This simulates the player drawing gravity in towards him/her with great force for a split second. It's quite fun to blast two guards on either side of you and watch them fly past each other in the air. 

I had to make some changes to the AI that Ron has been working on, as he wasn't using the physics body component, and was absolutely setting the position each update. This prevented me from being able to throw the characters, since they would just instantly revert their position and no longer have any forces applied to them. 

Moving forward I will be creating a character class that will serve to be a player, citizen, guard, etc. Simply adding different components, such as an input component or ai component, will make all of the difference for what the character is.

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!