Week 3 Wrap-Up

Week 3 has had a lot of challenges placed before our team. These challenges were including a finished level with a start location, end location that goes to level two, an item, and an enemy, as well as some fixes to the physics code.

The fixes to the Physics engine were my main responsibility so far and it has been quite the nightmare. Our original engine involves a lot of (regretful) code that was hacked in last minute for the Alpha demo due to falling behind on our Physics engine. Integrating that with an OOP based engine that lacks a messaging system or DOD (Data Oriented Design) lead to a nightmarish coupling. I am paying for my sins tenfold now as any change in one area of the codebase involves jumping around. By the Beta version I hope to have this all fixed as it looks bleak right now.

Apart from nightmares we have the seven layers of hell. This is a friendly stroll down memory lane... (pun intended with utmost enthusiasm.) The game is suffering from a tiny 640 and 28 byte memory leak... that is 20 bytes larger than last week. Stepping through the code - no missed new/delete pairs could be found - yet. Without an appropriate logging system (or any what-so-ever) it is even more difficult to find the issues that are causing memory leaks. Another issue that decided to come out of Wonderland and into reality with the advent of my parallax backgrounds is a Heap corruption at the closing of every run of the game. I have no idea where to start on that one. So far that means I have two major memory issues that need addressing and I am at full throttle researching for an appropriate (free) memory profiler. So far Very Sleepy and the AMD memory profiler have looked okay but not promising as of yet. Perhaps a trial of IBM's or Intel's memory profilers would be a good choice.

To stop the bad news buffet - I do have a plateful of good news dessert. I have successfully implemented a primitive level editor in the guise of a text file. It suspiciously looks like binary - well, why wouldn't it. 0 means no tile (off) and 1 means tile (on). Each byte of ASCII code in a text file represents (or is ignored if it does not) a game object for a level. The .txt file is parsed into the game using a simple function call and getlined() to a temporary string that then is added to a final string that contains the entire level. From there, each ASCII symbol in the string is processed and creates the appropriate game object at the correct location. At this point it just does rows and columns of tiles but will soon implement all GameObjects and its children as well as start and finish locations of each level.

Here is an example of the geometry of level one:
1000000000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000#
1000000000100000000111111111111111000000000110000000000000000000000000000000000000000000000000000000#
1000000000000000000000000000000000000000000110000000001111111111100000000000000000000000000000100000#
1000000000000000000000000000000000000000001110000000001000010000100000000000000000000000000000100000#
1000000000100000000000000000000000000000000110000000001000010000100000000000000000000000000000100000#
1000000000100000000000000000000000000000000110000000001000010000100000000000000000000000000000100000#
1111111111100000011110000000000000000000000000000000001000010000100000000000000000000000000000100000#
1000000000100001111110000000000111000000011111100000000000000000000000000000000000000000000000100000#
1000000000100000000011000000100000000000000110000000000000000000000100000001000000010000000000100000#
1000000000100000000000000000000000000000000110000000000000000001000100010001000100010001000000100000#
1000000000100000000000000010000000000000000110000000000000000001000100010001000100010001000000100000#
1000000000100000000000000000000000000000000110000000000000000001111111111111111111111111000100100000#
1000000000100000000000000000000000000000000110000000000000100000000000000000000000010000000100100000#
1000000000100000000000000000000000000000000110000000000000100000000000000000001000010000000100100000#
1000000000100000000000000000000000000000000110000000000000000000000000000000001000010000000100100000#
1000000000100000000000011000011111100000000110000000000000000000000000000000001000000000000000100000#
1000000000000000000000011000000000000000000110000000001100000000000011111111111111111111111101100000#
1000000000100000000000011000000000000000000110000000000000000000000000000000000000000000000000000000#
1000000000100000000001111000000000000000000000000000000000000010000000000000000000000000000000000000#
1111111111111110000000000000001111111111111111111100000000000000000000000000000000000000000010001111;

I hope I haven't scared you off with my woeful cries of memory loss as I do hope to see you next time. I also pray that when we do meet again I will be singing songs of praise as I triumph over computer memory management once and for all!

Week 2 of Part II

This week was busy as we had to code a lot of extra aesthetic features. One important feature I had to work on was a parallax background. The biggest issue was figuring out how to properly translate the background in accordance to the camera. This involved me making a function that found the change in camera position so that the background would not continuously update its position to weird coordinates off screen. Another feature that I implemented was the all important hook-shot. This game mechanic gives the player the ability to shoot an object and use it to pull the player to that location. The only thing left in that field are the sound effects and the chain.

Part II: Making an Actual Game

Part two of my Applied Project Development class has begun and we have a lot to do. The first part of our class was spending a semester getting an architecture up and running. This, we did successfully.

To recap, the game will be native to the Windows OS, written in C++, using the DirectX9.0c June 2010 API and FMOD API for the sound engine. The DirectX API, In game Camera, DirectInput, and FMOD were all successfully wrapped in our architecture and basic game object classes were created. On top of that a method for creating, interacting with, and rendering a world was implemented. We also implemented a HUD and a menu system for the game controlled by a game state manager.

What does this all mean?

It means there is a ton of more work to do. On top of the architecture we must not implement Game Specific Subsystems - obstacles, actors, triggers, etc. From there we will also be changing our architecture to include a font engine to render text to screen as well as a new rendering method for our backgrounds.

Most of the work after that will all be implementing gameplay features for the player. I was left to be in charge of the following:

Weapon System
HUD (improved mechanics)
Background
Font Engine

As well as some art assets

Ambient Music
Player Animations
Some Sound FX (Player, Weapon)

We have achieved a lot the past 8 weeks and now must achieve more for a beta in the next 8. Here is a look at what we have graphically so far:

Until next time, enjoy!