LD Smith Games

The enemy HP values have been removed from above the enemies on the game screen, and a damage value that floats over the enemy when hit has been added.  I created a new class for overlay text, which is used by both the 2D and 3D game screen.  This prevents the code from being duplicated for things like the status text and enemy damage.  I added a new property to the enemy that is the dying state and counter.  This was needed because the damage value does not display if the enemy is not alive.  This kept the last damage number from displaying.  Now I’ve changed it so that the damage value displays if the enemy is alive or dying, so the final damage number now correctly displays.  The dying counter will also be needed to display a death/blowup animation.  On the 2D game display, I added logic so that the enemy just fades away using an alpha color value based on the percentage of the dying animation passed.

I created a simple graphic for the projectile.  I mapped this graphic to a simple 2D plane in Blender.  It’s important to remember that all points of the Blender model must have a Z coordinate equal or less than 0 (non-positive) to appear.  This may be backwards for my game, since I am rendering the 3D world with the Y axis facing downward, which makes translating from the 2D to 3D coordinates simpler.  Remember, the model coordinates are relative to the small orange dot, which is not necessarily the location where the axes cross in Blender.  It is a good idea to put the orange dot at coordinate 0,0,0 in Blender to keep from getting confused.  Therefore, all vertices must be moved in edit mode (not object mode) for the changes to appear in the game.  Similarly, scaling an object in Blender’s object mode will have not effect on the model in the game.  The model must be scaled in edit mode with all vertices selected for the size change to appear in the game.

Also, I converted the List of loaded Model objects to a Dictionary object.  I thought that a Dictionary was the same as a hash table, but Chris Gardner (@freestylecoder) explained to me that Dictionaries don’t allow multiple values to be assigned to a key like a hash table.  He said that Dictionaries should be used like symbolic links, which is what I am doing with my constants which represent each model in the game.  The previous method I was using was kludgy and bad style, which was adding the Model to the List and setting the constant ID of that object to the order number which it was added to the list.  That process was a hassle to maintain and a recipe for disaster later.

Not much coding was done over the past few days, since I have been working on rebuilding a PC.  I also upgraded my main PC to Windows 8, which required a complete wipe of my primary drive, which means I had to install Visual C Sharp 2010 Express, XNA Game Studio, Blender, Gimp, TortoiseHg/Mecurial, and other programs again.  One issue with installing GameStudio in Windows 8 is that the Games for Marketplace Client must be installed for the Game Studio installer to succeed.

Spent some time cleaning up the project directory.  I got rid of all references to the old game name, so now the name in the repository is now BlastingBits.  Just changing the name required all files in my project directory to be recommited and uploaded to the repository.  Unfortunately, due to the directory structure, my repository had four levels of BlastingBits folders (BlastingBits/BlastingBits/BlastingBits/BlastingBits).  Using the TortoiseHg rename option, I changed it to one level of BlastingBits and the rest in an “src” directory.  Again, the repository saw the moved files as files being deleted and added, so it required a full upload of my entire project directory again.  Not sure if there is any way around that, since I used the TortoiseHg rename option.

After the cleanup, I reimported all of the source files and assets.  The project was still trying to create an executable with the old name, so it was easier to just recreate the project and import the sources.

One issue that I was able to resolve was the warning about the textures associated with the models.  This is the “Asset was built two times with different settings” warning when running the game.  I figured out that this warning was due to the image being compiled for the model and then again as a regular texture.  I was able to get this warning to go away by setting the “Build Action” option to “None” for the textures used by the models.  This apparently prevents these images from being used as regular sprites in the game.

I’ve been working on updating the second armor set.  I added some additional changes to the helmet, and I started working on the body piece.  One lesson I learned the hard way is to model both the front and side at the same time.  I only modeled the front at first, so now it is really difficult to model the sides since there are so many vertices now.

Using some of the graphics that I have already created, I made a promotional graphic that I used on my main homepage.  This looks much better than the in-game screenshot that I had before.  I had to render the helmet again in Blender to add the circle plane below with the helmet’s shadow.  One important tip that I learned is that shadow in Blender are only displayed when using a “Spot” light source.  This same graphic and background were also used to update the theme for this development blog.