Menu Sounds

So I've been improving the experience of the menu screens.  I have made sure that sounds sync up to menu choices along with music looping when exiting game or starting the game.  I made the game so that you can now mute the music sound or sound effects.  There was also a bug where you press the "A" button on certain menu buttons and it asks if you want to delete the game when it shouldn't.  Finally, I found bugs that were lagging the game because some sounds that were being loaded into the game were not being preloaded which caused glitches the first time you jump or roll, or slide, etc.

Game Sounds

One of the biggest things that the game lacked this week was sounds.  There were a couple sounds but there needs to be so many more.  I coordinated with Max, the art lead, where he found all of the sounds and I put them into the game at the right spots.  Some of the coolest stuff that I worked on was implementing the sounds for the menu screen.  I wanted to make sure that you knew quickly what buttons do what so I made sure that I made a sound for all errors as well as transitions between what you want to tell the menu screen what to do.

I also did a lot of evil testing in the game and found many bugs that were very small.  I was able to fix all of them on the spot including:

• A way to make sure you know that you are dead.
• Making nothing workable when an important message is showing on the screen
• Unloading and Loading each level properly with proper disposal of elements
• Deleting the Game progress error that shows up
• The music playing on top of one another every time a new level is loaded

and many other bugs.  When creating a game, you have to be the devils advocate and try to destroy the game in any situation.  That way someone doesn't detects the bug when they buy the game.

Loading Screen Between Levels

So now that we are creating multiple levels instead of one big world, I needed to get every level to have a loading screen before it loads into the game.  To do this we needed the loading screen to appear dynamically instead of statically.  I had to modify a lot of the code from before and make it work with our new level system.  It was a cool setup because I was able to queue a level into the level manager.  I would then load the loading screen until everything is loaded, finally when everything is finished I load the level completely at the end before the game screen appears.

I also did many little tweaks to the menu screen.  I made it so that the menu screens are more user friendly than developer friendly for first time viewers.  I also prevented accidental exits in the in game start menu so that if you accidentally press a button, it would go back into the game when pressed by a child or accidentally.  Finally, I found another method to pause the game when the "Guide" is showing so I took away our static approaches to pausing the world on pause and now it pauses the camera and everything connected to the character when pausing the game.

Save Manager Loading Abilities

This week, I worked heavily on getting the save manager work completely with loading of the game also.  I had to change some of the methods of the save according to the game and get it so that it would save the checkpoint you were at, the abilities you have and your health and mana.

The save game data worked very well and I was able to get the loading of the player data working so that if you quit the game and come back in, you will still have the same abilities as before.  Since we are using Unity for our level object importer, it is tough to set the elements on the map to certain loaded events.  Currently, we have to statically manual-script checks to see if it is a certain ability and add it if it is.

The game looks superb and is making on its way.  We have a new level and new abilities that makes our game look a lot more lively.

The image below is our new start screen that shows your avatar before entering the menu screen.

We also have a trail technique that follows behind you so you know where you came from.  We call it the ribbon effect.

My favorite is the new scroll layout that is in the bottom left corner of the game.  It tells you what to do and what you can do.

Knit Picky Bugs

This entire week, I worked mainly on knit-picky issues.  They were issues that needed to be addressed but have not been fixed yet.  I worked on

Main Menu

• Inside of the main menu, there was an issue that whenever you pressed the "Guide" key, the Xbox would allow you to log-in.  The issue is that everything in the background was still listening to inputs so by the time you enter two-inputs, the game may have started.  I modified a Screen Wrapper that checks for this condition and disallows any inputs in the background while in the "Guide".

Level Exiting

• When exiting the level, it would show a "LOADING" Screen, I changed the text and also made it so that the game unloaded correctly.
• It turned out that our Draw Manager looses pointers to some of our objects which cause the objects to be drawn as static objects, including a clone of the player.  To disable the draw manager from drawing these lost objects when exiting the game and reentering the game again, I wrote a script that would check for all objects in the draw manager that didn't have a pointer to it and cleared it from the draw manager.

Scroll Up

• The weird issue with the scrolls being ups is that you can control the player in the background while the scroll is up.  I disabled his movement while he is on the ground.  I've also disabled camera movements, shadow bolts, and jumping movements with the condition that the game should be paused.

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.

Progress Bar

This week I worked on the Progress Bar for loading the game.  Before we had a template version of an animated flashing icon until everything was loaded.  The team didn't like it since the user didn't know how much longer to expect before the game is loaded.  I made a progress bar that would estimate how much longer you have before your game is done loading and you can start playing.

There continues to be flashy text that animates below the progression bar that says "LOADING".

Unloading a Game

For the last week, I've been working on unloading the video game if someone tries to exit the game back to the main screen.  To do so, I had to first understand the template of how Screens are created in the menu setup so that I could make an in-game pause menu and understand how each method works off of the library template we use called XUI.  Understanding their template which makes the game very cool, I was able to understand how to create options that would exit the game.  While exiting the game, it calls an unloading script before placing the main screen placeholder.  The unloading script is setup extremely simple so that any one of our game developers can easily call methods as we find new bugs while unloading the game.

I unloaded all of the main details of the game like the character from the level and the sound effects.  The hardest thing with this is that the team never implemented unloading methods for drawing images or stopping the sounds since their main goal was to just get the drawings and player charactermatics loaded into the game.  This taught an important lesson to our team in which we should all implement unloading techniques as we're implementing loading techniques so that we don't have to go back and relearn the code in implementations we create which would save a lot of time.

Menu Screen Refactoring

Starting the new semester, we got right back into work with the game.  I was immediately assigned to work on the menu system in getting back and forth to the game and exiting the game back to the menu screen.  A lot of the code for the menu screen was poorly created so a major part of my week was understanding what the code was doing as well as refactoring the code so that it was loading the game in the correct areas.  I also was involved in a lot of the discussions of what we needed to do to turn the alpha into a full-on game.