FrogForce Postmortem

I guess it’s about time for me to write a postmortem for this thing.

I’m really glad I actually finished this game jam. I’ve done only one other 7-day game jam before, 7DRTS, and I failed. I thought it was a good idea to write my game in C++, a language I didn’t know well at the time. Protip. Don’t ever do that.

Yeah though. This was my third successful game jam game, and it came out way better than my second one. I learned so much. Let’s break it down, yo.

FrogForce was written in C#/XNA. The sounds were made with Famitracker, and the music was made in FL Studio.

What went right:

Pathfinding:

To my surprise, the pathfinding went really well. I could have and maybe should have designed my game around not needing pathfinding, because I’ve never used it before, but it went better than I could have hoped. I grabbed some pathfinding code for C# and learned about it quickly. Every time I came across a small problem I had to fix with it, I isolated it and focused on it, tried different things, and it was inevitably fixed. One issue was that if you had units selected and right clicked really fast, before the units can move a single tile, they would just stand in place. I had no idea how I was going to fix it at the time, but I came up with the solution very quickly. I just had to make units ignore the first path node (the one they were standing on) when a path was assigned to them.

Graphics

The graphics also went really well. I designed the units so that everything only needs one sprite. No attack animations, no directions, just a basic roguelike-ish style of one sprite. I added some wiggling and interpolation though for juice (which took like five minutes tops), and as a way to show something is getting hurt. While brainstorming out loud to my devbros in the Steam group chat, and deciding to make everything frogs, my friend offered to make a bunch of frog sprites. Since I designed my initial frog sprite (the one the player controls) to have only a few colors, he was able to whip together ten frog sprites. I was only able to use four due to time constraints though (but you can always mod the Professions.xml file if you want to change the sprites for the professions and see those secret sprites that didn’t make it into the game!).

On the final day, the graphics/polish day, the terrain looked awful. Instead of a dungeon, it was some sort of ugly grass/swamp with stone walls everywhere. It looked yucky, and the progression didn’t make any sense. While experimenting, I came up with a nice dungeon look. Inherently, that made progression make sense, because exits could be randomly placed as stairs to the next level.

I wanted to make the walls pop out a bit more, but I was running out of time quickly, so they’re sort of flat, but I still like how everything came out.

Gameplay:

I didn’t want to make the gameplay overly complex. It would end up being hard to understand and take a long time to implement. Actors automatically attacked other actors when nearby. The damage formula is literally something like damage = power 3. Increasing difficulty was as simple as storing how many floors you went down, and distributing more enemy stats randomly based on how many floors you’ve been through. It’s something like 3 + areasCleared 5. It was easy to implement and adjust. Remember, keep it simple.

Feedback:

Feedback is the most valuable thing to have with game jam games, or any game in general, or any THING that you’re creating. I made sure I put aside some time to distribute a demo to people and get feedback on how it played/felt. The feedback helped me a ton. I was told the controls were a bit confusing and the combat was too fast-paced. I streamlined the controls and made combat slower, more intense and heavy-hitting, and added a cooldown to heals. It helped a ton. Also, near the final day, my brother wanted to play my game. I watched him play to see how balance worked out. He played for like a whole hour and he liked it a lot. While watching him play I learned exactly what things I should balance. Heals became useless at higher levels because they healed a constant value, so I made them heal a percentage of unit health. Fly drops didn’t scale at later levels, so it was impossible to keep your units upgraded past ~level 5, so I made flies scale too. It helped me improve the game a lot. Always set aside time for feedback and testing, guys.

What didn’t go too well:

Gameplay:

My initial plan for the game was to combine dungeon crawler and RTS, which came out how I planned, but it’s flawed due to time constraints. What worried me a bit too was that my game wasn’t really fun until around the 5th day, because I had to deal with the core RTS element implementation first. Because I only had about two days left (one being dedicated to polish and balance) when I was just finishing up the main gameplay, your units weren’t persistent between floors, because my GenerateMap function cleared all actor/item/tilemap lists, so for each floor you go down, you get a fresh set of frogs at level 1. While this wasn’t a game-breaking issue, the game would have been much better if frogs were persistent. By the time I wanted to do it, I only had one day left, and it would have taken a lot of time to test/balance it, so I didn’t. This hurts the core gameplay quite a bit, but it still seems pretty fun.

Planning/Development:

Well, it went well enough for me to finish the game on time pretty much. I wanted to give myself a lot of spare time for polish, and spare time in case I mess something up or have to do something outside of dev. It turns out those things happened! On the third or fourth day, I had to go to my mom’s house and hang out/eat somewhere because she was going out of town for a while. On top of that, I initially planned my game to be non-gridbased. Protip, don’t use grid-based pathfinding with non-grid-based movement. It doesn’t work well.

It gave me so many issues that I just changed the movement to grid-based. I had to throw out everything that wouldn’t make sense in a grid-based game, including a cool radius-based attack system that would be very easy to implement and use, where all attacks, even melee ones, were like radius-based AOE attacks. I want to use it for something one day though. Also, I overslept A LOT. Don’t deprive yourself of sleep during game jams, but don’t oversleep either. I slept for around 12 hours for a few days, giving me a lot less time to work on my game. At least I was well-rested though. I even slacked off and browsed the internet a lot, all while keeping my tweety and tumbly updated with my development progress.

There were a lot of other features I was planning too that didn’t make it into the game. Choosing the map seed, a “campaign mode” where you can choose the amount of floors a dungeon is, then fight a boss at the end, and some more.

Overall though, it went really well. There are more goods than bads. Even though I don’t even play RTS games that much, but I had a lot of fun exploring the genre a bit, while incorporating things that I personally enjoy. I might work on FrogForce more evenutally, to make it more complete and fun, clean up that nasty code, and add the content/features I planned before. Who knows.

Here’s a link to my entry by the way: http://www.ludumdare.com/compo/minild-44/?action=preview&uid=3935