Ludum Dare #27 Post Mortem
I attempted to participate in Ludum Dare #27, but things did not work out well as I was taking care of both kids on Saturday and I ended up having to work on Sunday. I did get a very solid base going for a top down shooter though.
First off, the storyline: I decided to use the alternative form of the word Second, mainly the form of "second in command." The summary of the story is that you live in a destitute town that is being ruled by a bloody thirsty man and his personal guards, the 10 Seconds. They are named this because they are all considered to be his second in command, if he were to die they would have to fight over who would become the new leader (a little bit of a stretch on the theme, but I think it works.)
For technology I chose to use XNA and C#, which wasn't necessarily good or bad. I know both of these, so it was a better choice (in my opinion) than HTML5 or something similar. For the next jam/game, I'm contemplating hitting up a free game engine like Love or maybe a program like Construct 2.
I decided to use hard coded data so that I didn't have to worry about file formats or creating an editor. However, since I planned on converting it over to my personal game engine once I was done, I implemented this in a fashion which would easily translate.
The majority of the time I put in was split between buffered input (for mouse, keyboard and gamepad) and collision detection. Sadly both of these were a major waste; buffered input is nice to have for UI/game screens, but could have very easily been handled by a system that didn't take two hours to implement: isLeftButtonPressed, isRightButtonPressed, isUpPressed, isDownPressed, isActivatePressed and isCancelPressed.
I then spent (read: wasted) three hours on collision detection. "A top down shooter needs oriented bounding boxes, right!?" I thought...but I was wrong. For one, I have never implemented a proper oriented bounding box system, so this didn't end very well. I erased that and started implementing sphere based collision, but this is a horrible idea for square objects (i.e. tables, crates, the majority of scenery in games, etc.) So, in the end I went with a simple rectangle based collision and just made sure to limit the rotation I set for an object. So basically I spent three hours on a collision system that I scrapped and replaced with a 30 minute job.
For the combat I implemented a very simple system to handle guns. Each gun has the standard stats: fire rate, reload speed, damage and clip size. I used an "instance" system so that, if I wanted to, players could modify their guns (or I could generate random versions of the same gun that had slightly different stats.) The stat system was based on a 1-5 rating, which I am thinking needs to be expanded to a 1-10; 5 just doesn'to offer enough room for difference.
When trigger is pulled the system checks to see if any bullets are in the clip if not it checks to see if any ammo is in the reserve and if that is empty nothing happens (once sound is in, it'll play a click sound.) If there are bullets in the reserve it triggers a reload. Once therer are bullets in the chamber, the engine removes one and then a script that is attached to the gun generates any necessary projectiles (again, when sound is in the script will generate the sound effects.)
This spurred one of the things I've never thought about: how to measure accuracy in a situation like this. If I do it on a projectile base, we're going to be a little off as it's not really a good measure for multiple projectile guns (like the shotgun.) I could generate a "shot id" number that every projectile gets in a single shot, but that seems like a giant hack. The last idea I had was to generate a parent "shot class" that, once notified, would modify the accuracy numbers in the engine; this seemed like the best course to me.
The current status of the engine is kind of a mashup of different ideas. Originally it was going to be a simple run and gunner, so I had damage on guns, stats, etc. However, midway through I started thinking maybe something similar to Hotline Miami as it really kind of fits. Go to a location, murderize some people, move up a level and repeat. Find a boss or clear everyone out and move on to the next area. If you die you return to the entrance to the current area and that area resets. So enemies will currently die in one shot, unless they are marked as having armor on in which case they'll die in two hits.
So, at the very least I now have a nice solid start for a top down shooter. It will take very little effort to convert over to my code base (which I actually need to update now, as some of the code I did for the LD entry is better than what my library has.) The major change will need to be the map system - it is currently running on a normal tile map, which doesn't really suit the game that well. I think I might convert it over and throw together a small bullet hell game...
I also had a lot better experience with the competition this time around; I've "attempted" entries for Ludum Dare before, but I usually give up after a couple of hours because I'm not getting much done. This engine is fairly close to being done and I believe if I had been able to participate for the whole weekend I may have finished on time (most likely not very polished though.)
Here are some screenshots of the game: