It's Ludum Dare time again! - for the uninitiated, Ludum Dare is 'an accelerated video game development competition' where you have to build a game from the ground up, including music, sound effects and graphics - in just 48 hours.
Now, even if you can use the full 48 hours it's still a challenge - which means it's an ideal time to crack out two of the big guns of agile software delivery - iterative development and the Minimum Viable Product.
I know from experience that realistically I'm only going to have four 2-hour 'sprints' in a Ludum Dare weekend. That's quite a limitation. The traditional way of building software would be to create the sprites in one sprint, sound in another, gameplay in a third sprint, and bring them all together at the end (an 'integration sprint')
The problem with that approach is that you never get to test anything right until the very end, by which time it's too late to fix any learnings you gain from playing the game (eg you might need to slow the gameplay down, adjust the controls etc).
Another, better, approach emerges from one of the key agile principles - prioritising the delivery of working software. So to get anything close to a completed game in that time I need to get a thin slice of a complete game working quickly (MVP) and then build upon it in subsequent sprints (iterative development).
This image illustrates the different approaches:
After the initial sprint I'll have a complete, playable game. It won't be polished, and probably won't have all the graphics and sounds in place. The main thing though is this - I will be able to play the game, learn something, and apply those learnings in the next sprint.
Those learnings might be confirming things that I already think I know (eg 'needs a menu screen'), but I'll also find out some unexpected things (eg 'the character needs to be able to jump'). I'll continue iterating, and gaining new insights at the end of each sprint.
So this is the key to a successful Ludum Dare, and any sort of delivery - get an MVP in the hands of users - just a thin slice of functionality, then learn, prioritise and iterate until your budget, or time, runs out.
Image (c) Henrik Knibery https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp
My previous Ludum Dare entries:
Trump's Trump: https://andrewl.github.io/trumps_trump/docroot
I'm Andrew - a Tech Architect and Agile Delivery Consultant. Find out more about the services I offer here