Menu Screen and Trajectory Mapping

This week I worked with James in getting the Menu screen to work better.  I moved the "Delete Game State" into the Options bar and also re-factored the menu screen so that they can be made more simple and easier to read by other programmers.  The open source data we found online had the menu code but it was in the worst form to read and would take hours to just understand a menu screen before being able to add to it or create a similar game screen.

I also worked on trajectory plannings of static objects.  I sat down and wrote out the physics equations to get the trajectories to work the way I would want them to.  I was able to add constraints to the trajectory of objects using a cubic interpolation.  The equation I came up with to make smooth transitions used the constraints:

• Initial Position = q_0
• End Position = q_1
• Initial Velocity = End Velocity = 0
• Time Table = 0 .. 1
• Position at time 0.5 = (q_0 + q_1)/2
• Acceleration at time 0.5 = 0

The final equation solving for these constraints is:

q(t) = q_0 + (q_1 - q_0(3t^3 - 2t^3)

I'm excited to use these next few days to make dynamic moving objects in the game using this equation inside of the game.

Raycasting Group Collidables

This week I was able to implement and finish a system that BEPU supports called GroupCollisions.  I made different groups like buildings, enemies, characters, etc. that kept track of its collidable objects which would make it easier and more efficient to compute collisions between objects.  Before, our game frame-rates were being killed by looking through each collidable and having if statements that checked between collidables.  Now, we don't have to have a bunch of code that checks these flags and now we can check items by raycasting to specific groups or ignore specific groups.  I spent all of my time this week cleaning the code this week and making static methods that will make it easier on programmers to implement checks.

Here is my interesting piece of code.

List<RayCastResult> results = new List<RayCastResult>();

return physicsSystem.RayCast(ray, dist, entry => entry.CollisionRules.Group == Game1.Instance.BuildingCollisionGroup, out result);

As you see this interesting piece of code, "entry => entry.CollisionRules.Group == Game1.Instance.BuildingCollisionGroup", you will notice that it is doing everything we need to do in one line of code.  This is called lambda inline statements.  Before, we had to call an entire function that would take care of a bunch of collision checks before returning the result.  Now, we only have to call a simple group test  which uses a binary tree to speed up the process as well as reading ability.  I then made simple method calls in a RayCastManager which is a static class where programmers don't have to worry about learning lambda calls and can easily call RayCastCollideWithGroup(Buildings) instead.

Saving / Avatar in Main Menu

This week I had a lot of fun working on the saving aspect of the game.  Xbox Games have a series of "Evil List" elements that make a game not passable.  Saving can be a big issue if the game looses power or the memory stick is pulled out while saving to the hard drive.  I spent a lot of time researching online to do my best in getting this right the first time and was able to get saving to work right the first time.  My implementation includes a bunch of states that are telling the game where it is at when it tries to perform an action.
        public enum SavingState
        {
            ReadyToSelectStorageDevice,
            SelectingStorageDevice,
            ReadyToOpenStorageContainer,  // Everything starting here is after receiving storage device
            OpeningStorageContainer,
            ReadyToSave,
            WorkingWithSaveData
        }

Depending what state the saving state is, the backend saving machine would act accordingly so that the game doesn't freeze.  The implementation I went with is so that the game can use auto-saving throughout each objective collected within.  The team is in the process of figuring out what we want to save so my implementation is on the side until we find out what we want to do with techniques of saving.

I also helped James debug his system of getting an Avatar show up on the screen.  He was struggling for a few hours and asked for my help since I have experience in Visual Perception.  The issue turned out to be that the scale of the camera and viewing box was so large that any item in front of the camera was shrunk to less than a pixel which made it appear as though it wasn't there.  I taught James of these parameters and what they meant and the avatar appeared beautifully in front of the camera in the main menu screen.

Graphic Effects Never Disposing Correctly

So Blake from my team recently made up a system called the Tracker where we can be able and see what objects are constantly being called in the game at any point.  With this system opened up a view to a bunch of bugs that were inside the backend of the game and eating memory.  This wouldn't effect the gameplay of the game until you have played for a few minutes or even hours and then noticing the lag inside of the gameplay.  The biggest issue was that particle effects were being created and as the particles alpha went to zero making the particles not viewable, the particle still existed in the game.

Every time the avatar jumps or lands the particle system would be instantiated and after a couple minutes of gameplay, you would notice the list just gets longer and longer of calling updates in each and every frame.  I was put in charge of getting rid of this effect.  To do so, I studied how each effect was being created and the particles that were being created inside of the effect.  I then checked to see if all the particles were done playing with and had the dispose command called if the conditions were met.  In the dispose command, it properly got rid of all the children owned by the object and then disposed of itself from the game mechanics as well as the display manager.