Making a game is plan and execution, and with the time constrains of a game jam it's easy to fall into developing too early trying to get things done fast.

But experience shown me that precisely because of the time constrains of a game jam, planning is even more important, because every error you make will be a dead weight, losing lots of time trying to overpass the limits of an erroneous design approach.

That's why I tend to spend nearly all the first day only thinking, writing and looking for a balance between a good game for the jam and a doable game for the jam. I tend to put objectives that will guide my decisions, because you'll have to cut your game for sure, and then, you'll thank any help.

This Ludum I was alone. I have friends that we usually join together from Ludum to Ludum, but this time was impossible to meet due to work and personal reasons. When that happens, I tend to use the jam as an excuse to learn something new rather than trying to make a great contender. Last time I participated I joined forces with Carlos Coronado, a friend and something like an Unreal Preacher, and was a great opportunity to learn the basics of the engine. Please take some time to take a look to Almost One Room. This time, I though that would be great to repeat with UE4, but without the safety net that's a person next to you that will do what you can't.

Now you have some context, I want to share with you the simplified GDD I wrote for Don't Fram 'em All.

As you will read, I started trying to figure ideas for the "major" genres and the theme of the Jam, and then I started evaluating how much difficult would be for me to develop each one. Take into consideration I'm a coder, but I was working mainly in the web-app industry and now I work in marketing and communication for videogames, in summary, I'm not an artist and my coding skills are not trained for how game engines work. So I needed to think carefully about the time needed to make each part.

Finally I decided to go with something where I don't start from zero. Unreal Engine has a top-down-shooter template that will be a good start point because it let me focus into the thematic game mechanics. So next was writing about the Top Down SHooter idea.

I try to cover as many points of the development as possible, but I think it's better to avoid going into details. The idea behind the exercise of writing the simplified GDD is to identify possible bottlenecks and where the major efforts would be needed to plan a good development order.

For example, I was pretty sure the game will need more than one nerf, but to go with a minimum viable product it's enough with one nerf. But taking into consideration that, I coded the system to be extendable from the beginning. Finally I was not able to code a second nerf, but the base was solid enough.

Writing it also helped me to know that the horde system will be the most important part because it needs to control more entities than the other features and also it needs to communicate messages between entities, something I never did before in Unreal Engine and thus, it was a probable source of problems. That's why I started creating the enemy and then, focused all my efforts in the Horde Manager.

Well, I think it's enough. That post is long enough. I think I'll add some cat images to make it more interesting. Many thanks for reading.