This time around, I wanted to be better prepared for the theme, and tried not to get too caught-up in the want for one theme. There's a lot of psychology as to why you shouldn't hope too much for one theme, and I tried to break this early on. However, I think my brain got the better of me, and I started trying to predict which theme was the most likely to win. I picked the top-4 from the previous 4 rounds of voting, and brainstormed on them. The theme came out to be "You Are The Monster", and I made an effort to do something that wasn't painfully obvious or super-likely to be done a ton of times. In my game, which I titled "Boss Fight Simulator 2015", you are a robot that is the boss fight for "the Bros" in their quest for more beer and weights to lift. I didn't spend much time on the story, obviously, but there really wasn't much to focus on with it, given the game concept.
The graphics were retro-style 2d side-scroller. I'm not much of an artist, but I think they came out okay. I spent quite a bit of time working on them, probably to the detriment of the game. However, I didn't want to completely skimp out with something truly, horrifyingly bad. The player character has a good bit of detail, and a lot more frames of animation than the enemies you fight. Not all of the animations line up correctly, so in some frames, there's a small bit of jumping around. It's only noticeable when attacking, as the idle and run animations line up correctly. I'm proud of my first attempt at animating every frame, but this is where we come back to me being a programmer, and not an artist...
The run/walk animation for the player, looks more like a weird leg spasm than walking. The enemies aren't all that much better, but at least they sort of look like they're running. Punches for the melee enemies causes them to jump backwards to make up for the fact that the attack animation frame is larger than the rest of the sprite frames. This also applies to the various attack animations of the player. The sprite positions don't quite line up like you expect them to, which causes them to look jumpy. But, overall, they maintain a good appearance, even if they jump positionally a bit.
Sound wise, Artuir did great with the music track he provided. He had numerous things come up, and so he wasn't able to devote as much time as either of us would have liked, but that's okay. Artuir is a personal friend of mine, so I understood his situation and worked with him. The voices were his, and they were as comical as I expected him to be with it. The sound effects were produced with BFXR, and worked great. BFXR is a great tool for sound effects for jam games. SInce I'm not a sound effects engineer (and neither is Artuir), this is my go-to tool for those. The effects came out well, and worked with the art style.
In terms of code, there's a few things I'd say went right, and a few things that went wrong. Firstly, I have been writing a code library for use with game projects, built on the Monogame framework. Some of it feels like it would be Unity code, given that was where I started and learned. I started probably about 2-3 weeks before LD33 writing this library. I really put this framework to the test with jam. This let me find strengths, and weaknesses, in the codebase. However, I also wrote my animation system during the jam. Since I'd never written an animation system, and only had a vague idea of how any of it would work, this was both great, and a bit of a curse. Since it wasn't a major thing I'd never tackled any part of before (like the A* pathfinding in my last Ludum Dare, LD31) I was able to get it done somewhat quickly, though, not without some serious problems.
The animation system wasn't quite playing animations correctly, and required some weird timing and doubling-up of animation frames to account for. Some things were ultimately left in the final submission that have issues. I corrected these later after Ludum Dare was over, and released an updated version of the game. Many of these issues were due to the way I was managing both sprite components, and animation components, coupling with how I was handling calling the animation component for both playing animations, and changing animations. I corrected this later by abstracting both the SpriteComponent class and AnimationComponent class to inherit from a new "DrawableGameObjectComponent" class. There is now, however, a new issue with how updates are processed, which is causing some problems.
The physics code for the game is scraped and modified from several places, and was really a complete and total mess. It worked, but it was fairly convoluted, and shows that I'm not super-knowledgeable about handling physics in games. While it's fun to play with, having a proper physics system is a huge time and code commitment, and requires a non-trivial amount of knowledge. It also has to be efficient, which was something I wasn't going to cram into a jam weekend, and didn't start writing code for until just 3 days before hand. It worked, and worked fairly well in the jam release, but was a lot of code (for me), and wasn't very well centralized as it should have been. Each object ran its own physics calculations, instead of a proper broad-phase/narrow-phase system that was more centralized. Thankfully, there wasn't all that much to process on-screen. Additionally, a quad-tree system was used to narrow down just what needed to be checked against what, and that saved a lot of CPU cycles.
What worked out fantastically, and I didn't have to modify even a character of code for, was the entity/component system itself. This system is fairly robust, and hasn't presented with any problems either before, or after, the jam. Since the jam has finished, I have gone through and commented the code completely, and intend to make it more robust, and have a little more error-checking and handling, which should make it very robust. I am very happy with that system, and I'm planning on expanding on it in the future.
In terms of design, I was much happier with the idea I had come up with this time. It was much simpler than my previous efforts, and showed a bit more restraint in features. The concept was more of a wave-based survival mode inspired by several retro-style games that had come out recently. I didn't want to focus too much on having too many enemy types, and didn't want to focus on enemies having complex AI, so I stuck with them being as simple as possible. This turned out fairly well, and haven't heard anyone complain about the enemies, which was fairly relieving.
The things that didn't turn out well were how the difficulty progressed, and there being more feedback for the player. It was difficult to register when you'd taken damage, and when the enemy had taken damage. It wasn't particularly obvious, and left it feeling a little empty. In terms of progression, the scaling was all kinds of wrong, and the attacks that the player could perform weren't particularly well balanced. This led to simple strategies for victory. Namely, going to one side of the map, and holding down the range attack (S) button, and killing all of the enemies with little effort. After about wave 20, it simply devolved into standing anywhere on the map and one-shotting everything with the super attack. I still haven't managed a good progression after the jam that allowed for difficulty that scales properly.
So, quick recap:
What went wrong:
- Too much time was spent on art
- Not enough time was spent on gameplay design/code
- Life issues of teammates caused some things to suffer
- Untested codebase was used, and should have been avoided for this jam
- Some design decisions hurt the enjoyment of the game
- Not enough time spent prepping my workspace
What went right:
- The art style came out much better than expected, and looked consistent/great (IMO)
- Portions of the codebase turned out to be stable and reliable
- The game concept was simple and fun, despite lacking better execution
- More breaks and changes in time management skills lead to better quality work
- I was less attached to a single theme prior to starting
- Had plenty of time to work until the deadline
What I learned:
- To make sure your codebase is used at least once prior to using it in a jam
- That more frequent, sometimes longer, breaks leads to better quality work
- That my art doesn't suck as much as I thought it did
- That I should spend less time on art and more on code
- How sprite animation systems work
- That more time spent preparing your workspace leads to less clutter
- To be more confident in my skill
Thanks for reading! Download links for this game are below:
Original LD33 Jam release: Jam Release
Most recently updated release: (9/4/2015) Post Jam Update