Last week for my graphics class, we had to turn in an assignment involving using a camera, and loading a tile-based map. All our projects are built using Microsoft’s XNA framework, and I wanted to build off of my project from the previous week, in order to save time. Here’s what the project ended up looking like:
Not very impressive, right? The project’s intent was to just implement several animations and a menu system using an enumerated data type. The main menu involved is seen up above, and it’s remained pretty constant these past couple of weeks. In short, using enum-based menus requires a switch statement and a case for each menu that exists, in both the update and draw functions. As you might predict, this can get messy very quickly. The code in this project was all in the Game1.cs file, which is less than optimal. Though still navigable, the file ended up being around 525 lines of code.
So, the next week, when I wanted to add even more code, I started getting lost really easily. The Game1 file ended up being about 650 lines, which, while not a large increase, was way more stressful than it needed to be. I can’t say I’m displeased with the results, since I got it working:
Now there’s a tile-based map for the player to run around on, and a camera that follows them. After getting it working, I decided to make the code more manageable. I did this in a couple of ways:
1) Set up a Sprite Class
This is something I should have done from the beginning. When implementing the tile map, I had set up a class called TileSet in order to help. It didn’t do much, since it had only three variables in it (Source Texture, Source Rectangle, and the Draw location at runtime). The horse information, however, was still in the main code. After setting up a separate class called PlayerClass, I realized that the class had the same three variables as TileSet. I then combined the two into one class, simply called Sprite, and just didn’t use the animation variables for the tiles. Short and simple, this little file helped clean up quite a bit:
It also proved useful to convert the arrow used on the menus into an instance of sprite, furthering the clean up.
2) Create Subfunctions
This was something I was more cognizant of from the beginning: when specifying what code to run on what screen, the enum switch statements were creating these really large update and draw functions that I had to search through. As such, I put the particularly large screen updates into their own functions, UpdatePlayScreen() and UpdateMainMenu(). This made the main file a bit more navigable.
3) Eliminate Redundant Code
Going through my project, I actually found quite a few variables that I had set up and initialized, but never used anywhere else in the code. Looking at files with a fresh mindset really helps, and I ended up deleting quite a few lines of unnecessary code.
After everything, the file was shrunk down to 625 lines, and a large number of variables were accessible as members of the sprite class. Maybe not a large step forward, but my project is much more manageable now.
Jared Mitchell 