Software engineering on a Game Jam
Published 17 days ago
A post-mortem analysis of my Ludum Dare submission
Last month I took part in Ludum Dare 42 ( Running out of space). This was my first Game Jam and I have to say it was a great experience. I participated with my girlfriend, I took care of the code and she made all the 2D art / sounds.
As we had only three days to ship a complete game, a pretty difficult task. After we decided the theme I immediately started coding the basic components and creating a game system. No planning was involved.
“I don’t have time to lay down the game architecture and plan everything.. “
“What if I change my mind about how the game should look…”
“72 hours? I will never finish”
With those thoughts polluting my mind I basically I ignored everything that I learned about software engineering. No planning was involved. No kind of game iteration was made. I was just meshing some code and hoping that in the end I would be able to put everything together.
As you can guess, looking back now this clearly wasn’t the best option. But hey, you need to make mistakes in order to learn, right?
We finished our game and had a decent rating, but I think if I had followed some design principles a lot of things could had gone smoother.
Number 1: Create User Stories
You decided your theme? Great! Now sit down with your group and prioritize which aspects of your game need more attention. Discussing these aspects also help you visualize your final game and make sure you don’t get lost mid-project.
Number 2: Use Design Patterns
They exist for a reason. Yes time is short and creating an Observer / Subscriber take a few more lines of code. But at the end of your project those few lines of code can make the difference between a last minute feature taking 15 minutes / 1 hour to implement. And hey, if you are jamming with another programmer, it doesn’t hurt to have some conventions.
Number 3: Don’t use Design Patterns
Wait what? I thought you just said… Yeah I know, bear with me. Remember the time when you created the User Stories of your game? That would be a good time to just plan on your mind which aspects of your game need to be robust. Striking a balance between Singletons and modular systems is a skill which can save you a lot of time. Not every feature need to have a complex logic, but only having global variables will bite you at the end of your project.
Number 4: Take full advantage of unity Component Based System
Unity Component Design facilitates you to add / remove functionalities of object with ease. This is one of Unity strongest points and if you design components to be modular, you can do multiple play tests with ease. Don’t create a Player with a gun object, instead create two different components and add / remove them as you like.
Time is a factor on game Jams and following Software Engineering principles can take some. However you should find a balance and determine what is right for your project.

Pedro Azevedo
Indie Developer - Programmer