Lol, you’re quite right about people having great processes in reality! I dare say many LD participants could teach industry software devs a thing or two! To this day I still constantly see *facepalm*-worthy incompetence in blue-chip companies, esp when it comes to process (and maturity).

Thanks for the trello link – I can’t believe it’s free! It’s simple but looks very functional.
At work we’re using something similar called Atlassian Greenhopper – which is in my opinion a pile of dog doo.

When I made A Super Mario Summary for LD23 I first made the basic platforming and win/lose criterias, then I added features one by one. Enemies and level progression. Level selection screen. The gold coins for pro players. Replay functionality. Even if I had run out of time halfway through, it would still be a very complete game and no one would have known what other things I had planned. I used Trello ( https://trello.com/ ) for scrum board (it’s more like kanban which maybe is more suited for jams). That made it very easy to keep track of tasks, make mini sprints, and make sure nothing fell between chairs.

I also find it interesting (concerning some of the points above) that a lot of people think they have “no process” when in fact they have an extremely well defined order they do things in, it’s just not externalized or documented.

Is it possible some of the overhead of SCRUM you mention is, well, overhead? I.e., it might have meaning for SCRUM in the corporate environment but you probably don’t need it for Ludum Dare. So, maybe what johanp is doing isn’t technically “SCRUM” anymore but follows the gist of it.

I think what johanp is saying is that a general, implement — test — fix — re-evaluate — refactor pattern, will suit you better for Ludum Dare than a “plan everything ahead” strategy. Not that planning everything ahead is bad, but it’s often difficult to put your vision into code in the time allotted. Moreover, most of us have a hard time figuring out what would be most fun in our heads, and sometimes more fun things just come up unexpectedly! Did you know that the GTA series was basically all the result of a simple, instructional driving simulation having some buggy police AI that would (unintentionally) try to run the player off the road? Running from the police turned out to be fun! Who knew? :p

Planning ahead is certainly better than just an adhoc approach but if you are able to integrate some kind of iterative design strategy things can go even more smoothly still. This let’s your game, *AHEM* evolve as it’s being developed.

@sorceress: Love the Chaos model – it’s very well organised! What you’ve described fits the mould in many areas for agile development. Your list of functionality equates to a product backlog, which is essentially a prioritized to-do list (it also changes constantly on the fly).

The urgent issues, like in the scrum methodology, get put back into the product backlog, and are prioritized along with any remaining tasks.

I like what you’ve done here, essentially you’ve taken the best elements of SCRUM that work best in a “short burst” environment like this.

@Milo – You’re much more organised than you realize The critical thing is you’ve put generous effort into the concept, which is arguably one of the most important parts of this process. With steps 2 to 4, I’m guessing you blend together development, testing, and debugging (i.e. part of the waterfall model) into a continuous on going cycle. Interestingly this kind of cycle is the backbone of many agile methods.

Effectively for me on the Sunday testing and refinement was also a cycle. I’d find bugs, then fix them, play/test then oh wait! Found some more fix them again I played the whole game from start to finish quite a few times (was a bit sick of it in the end lol).

@ButtercupSaiyan – If you have a look through the blogs, from what I’ve read from a few teams (and individuals), lack of direction and running out of time was a key post-mortem learning. I’ve never in my life observed devs “automatically knowing what to do” – it’s usually the complete opposite even with established processes in place.

The workflow shouldn’t be a massive overhead, I think deciding on how much time I’d allocate to each phase took 5-10 minutes.

Also I don’t quite understand how having a process automatically makes a game boring? Having more bugs definitely doesn’t make a game (or software) more novel, in fact it actually detracts from the fun.
I’ve played a couple of games that break as soon as I did something quite normal. Quality and originality aren’t at all mutually exclusive.

So what I’m driving at here is there’s no right or wrong process, there are so many ways to do it right! Sorceress and Milo above actually have great processes that work very well for them. This blog was more for people who may not realise that the whole weekend probably shouldn’t be devoted 99% to development and 1% of everything else (i.e. concept, design, testing etc).

Anyway, I’m really keen to hear other people’s accounts of worked well for them in LD, I’m keen to take away some more gems

Sometimes, it’s better to have a working prototype of a gem than a polished bland stone. I’ll have way more fun with the slightly-buggy gem than a working—but BORING—game.

1. Think of a concept. Be fairly specific about what the gameplay will be and have somewhat of an idea of how to program it. (~2 hours)

2. Program everything relating to gameplay. Ideally graphics at this point consist of writing 10-ish lines of code. Since this is going to involve a lot of debugging, test to see if it’s fun too. Try to start with code that could be used for a variety of games. Ideally, finish this by the end of the first day, but this is important, so take however much time is necessary.

3. Work on some assets, any code needed to integrate the assets into the game.

4. Is anything left to make the game more fun? Do that.

This doesn’t recognise a specific design phase, or testing phase, or construction phase. It just sees “issues” that need to be solved. So at frequent intervals, identify: (i) what is robust, (ii) what is a big issue, and (iii) what is an urgent issue.

– Robust is what is done, decided, or working.

– Big issues need to be solved to deliver functionality. These define your medium term goals, and can be thought of as milestones on the road to project completion. The issue that delivers the most functionality should be the higher priority. The landscape will undoubtedly change as you progress through the project and discover/understand issues better.

– Urgent issues are logical precedents, or components. They need to be solved before some other issue can be solved. So take precedence, and define your immediate goals.

It’s called chaos because as the landscape changes, you will find yourself lurching about all over the project attending to shifting priorities.

It would be a bit hard to justify for LD however. With such a short time frame, SCRUM would just become a needless overhead. The minimum sprint duration typically is recommended at 2-4 weeks – you wouldn’t want to have have hourly standups (status reports) for instance. Nor would you want to spend time putting together all the scrum assets (e.g. burndowns, kanban board, etc) for 3 days of work.

Plus without the potential for further sprints, you don’t reap the benefits of iterative development – in this case you’d only have one to get it right.

If you took the project beyond LD and wanted to develop it further, in that case SCRUM would definitely be appropriate.

I’m not that familiar with other agile techniques, but possibly principles from some of them would work well here like XP which includes peer-programming or test-driven development perhaps.

I believe that for non-software dev professionals, a simplified waterfall is still best. At its core, it really just comes down to having a basic plan, setting some milestones with time frames, and the execution of said plan.