I may have some useful tips on getting games in on time without dying for other LD entrants.

First here’s some background to add a bit of context:

This has been my first game compo ever, and my first real foray into the world of game development.  As a lifelong gamer, it’s been a total blast!  My dream is to be able to make a real living out of making games, and leave the (mostly) mundane world of enterprise testing well behind! :)

I’ve never had the good fortune to test any game apps in the IT industry, and my roles have never been full blown development – at most, they’re largely restricted to automated testing which only requires beginner-intermediate JS, Java, VB scripting skills.  For this reason, I’ve never had the motivation to   pick up advanced dev-skills – it just seemed like too much effort.  Fortunately, technology has progressed quite a bit lately, and there are options open to less technical geeks like myself.

Although less technical, one useful skill I’ve picked up has been understanding best practice for software development, which I think can apply here.  From all the blogs I’ve read, esp. jam ones, the common theme is that people constantly run out of time or submit an incomplete game or mentally burnout.

Funnily enough, the IT industry is not much different!  If you have a look around at some metrics, most large scale software dev projects usually end up failing for exactly the same reasons.  From experience, this is because of the same old Sh!t* most of the time, i.e.:

  1. Not having a clear software dev lifecycle (which requires a heavy dose of testing)
  2. Not defining or being clear about the requirements (or game design) up front and consequently not planning realistic time frames
  3. Not enough testing
  4. Constantly changing requirements (or game design) otherwise known as scope creep

As a software tester who ends up at the ass-end of every project, not having the above factors locked down is a real freaking headache.  In LD, what this means is that you’ll probably have a half-complete game or you might decide to pull out, which is a real shame.

How I may be able to give back a little to this community is to provide some tips I’ve picked up that I think applies here:

1. Have Clear Stages in Your Game Development Lifecycle

The Grand-Daddy of all software dev processes is called “The Waterfall Model”.  Arguably most modern software dev processes are adaptations of this, but the original and simplified version is good enough here.

The stages I’d suggest for an LD game would be:

a. Concept – What’s your game?

b. Design – What’s the gameplay?

c. Development – making/coding the game

d. Testing – play the game, try to break it

e. Bug-fixing (Refinement) – fix the most important problems (some times step d&e blended into one)

f. “Tidy Up” or admin type tasks

Timeframes will vary depending on the game, team technology you’re using , skill, etc.., but it’s a good idea to decide roughly up front how much time each stage will take up.

In my case I had in total about 12 hrs for Saturday  and 12 hrs for Sunday available to finish the game, so I divided it up like so:

a. Concept – 1 hr

b. Design – 3 hrs

c. Dev – 8 hrs (End of Day 1)

d. & e.Testing and Bug Fixing – 10 hrs

f. Tidy up tasks (for me this included submitting the game to LD and Kong, writing the instructions, making menus etc) – 2hrs

I didn’t really want to kill myself getting the game out, so I aimed to be finished and in bed by midnight Sunday.  Even so I ended up getting to sleep at 1am.

2 Spend Enough Time on Concept and Design

You might be wondering why I decided to put so much time up front on the concept and design.  The concept is super important, you’ve got to brain storm millions of ideas until you get the right one.  If you just did this in 5 mins, it’s possible you won’t come up with your best idea, if you had more time.

In terms of design, it’s much, much easier to fix game play ideas in your head or on paper, than when it’s actually coded.  Pretend to ‘play’ the game in your head – visualize the game, then do it on paper. Interestingly this is arguably one of the critical reasons why most enterprise software projects fail – businesses didn’t think enough up front about what they wanted to build.

3 Do Lots of Testing!

You might think I’m weird for dedicating almost all of Sunday to Testing and Bug Fixing.  That’s because once the core game has been done, it’s most likely not being tested and played from Beginning to End.

It’s hard to get perspective on gameplay balancing, bugs in the game, usability,  and just overall “fun-ness” of the game without thoroughly playing it a lot.  If possible get as many other people as you can possibly can to play the game and give feedback during this time.

Make a list of the bugs (defects) and pick the top ones that you can realistically fix in the testing/refinement phase.

Also, I won’t delve too far into it, but there are many other layers to testing, which are relevant here.  My game was web-based, and a lot of the features I used were new for Construct 2 (game engine) so I had to at least do a bit of Cross Browser Compatibility tests, i.e. test it on common browsers (Firefox, chrome, IE8, etc).  I found that some stuff didn’t work well on anything other than Chrome  or FF.  Consequently I had to build in a setting that allowed players to turn off many of the new shader effects built into the game.  This feature also helped with old laptops (Performance testing).

Ultimately this meant that I covered the widest audience possible in that short space of time.

4 Development and Managing Scope

Pure development funnily enough, is only part of the picture, but often times, all people and businesses will only focus all of their energy here.

This is the tricky bit – it’s always a developer’s habit to put every dang “bell & whistle” into their software/game and end up making such massive bloatware that is a big useless piece of crap, or could never be finished.  This common problem is called “scope creep“.  Usually it’s not the developers who are guilty of doing this, it’s normally the business, who want “just one more small thing”.  Drives me freaking up the wall!

It takes discpline to say “I’m gonna make this game” and stick to the plan.  Things can and will change, but at least it will be far more controlled.  This is why it’s critical to design the game with as much detail as you possibly can right up front.

It takes even more discipline to stop developing after the dev phase, I kept thinking to myself: “If only I could add this extra thingy into my game!”, but no I had to stop…

5 Conclusion

Overall it’s still been a big learning curve for me, and I still missed out on some major bugs (e.g. not having autofire), but I managed to complete a mostly working game in a total of 24 hrs and had an absolute blast doing it!  Hopefully some of the above knowledge will help some of you out for the next LD, so you don’t burn out in what should otherwise be one of the most invigorating, fun, creative challenges of all time!

See you at the next LD compo :)


p.s. if you’re interested you can have a peek at my game:



11 Responses to “How To Get Your Game in on Time without *Dying* – Notes from a (non-gaming) Software Tester”

  1. johanp says:

    Very nice write up! While I agree with many things I don’t think the waterfall model is a good one for game jams. Should you make errors (which you will) during the design/concept phase, then you’re stuck with them, or have to start over losing valuable time, or correct them losing valuable time. I’m much more in favor for scrum or any other agile development method or process. Making short iterations and constantly moving forward while having a playable game makes ituch more likely that you will submit something in time.

  2. eyehawk says:

    Thanks Johanp :) Yeah I absolutely agree with you on SCRUM – when it is done properly it’s very satisfying. It’s deceptively simple, but it requires a lot of practice, discipline, and communication to pull off.

    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.

    • Jedi says:

      Hmm, I thought I basically understood SCRUM before I heard you talking about it. :/

      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. :)

  3. sorceress says:

    For creating LD games I tend to use the chaos model of development.

    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.

  4. Milo says:

    I’ve found that that just doing stuff in a specific order works pretty well. I don’t like spending any time with organization.

    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.

  5. I also don’t think this model is good for Jams or Dare. Time is at a premium and all your fellow devs automatically know time was the thing everyone was short on.

    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.

  6. eyehawk says:

    Thanks for your feedback guys and sharing your experiences! :) I’m always fascinated by the processes that work successfully in specialized environments like this.

    @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 :)

  7. johanp says:

    Allow me to refine my comment. :) I shouldn’t have been so short. I totally agree that fully fledged scrum is a no-no for jams. However, the iterative concept are (at least for me) very good to use. I usually try to start with the core of the game, without knowing exactly how it will play out, and then build from there. Once the core is set, I add gameplay layers one by one. That way there is always a playable game and something to submit, no matter when the time is out.

    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.

  8. eyehawk says:

    @johanp – thanks for your refined answer! :) Yes I think taking certain elements of scrum is definitely a great idea. The kanban board is a great asset – esp with doing on the fly prioritizations. Sorceress above has taken that aspect and executed it quite well.

    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.

    • johanp says:

      Frankly, I think Trello rocks for smaller projects. We’ve tried it at work in larger groups but I found that I quickly lost my overview, and it didn’t go hand in hand with some of our other tools. Therefore we stick to classick wall mounted boards. :)

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]