UPDATE - Download the finished game for free here!
I’d like to enter a Ludum Dare 48 hour competition one day, but I don’t think I’m ready yet. Create a finished game in a single weekend, sounds like a monster task!
This weekend I decided to give it a test run, see how far I can get in a couple of days. The answer is – further than I’d have guessed! Here’s a runthrough of the process…
Friday 6:30pm – 7pm:
Created a very simple design document in notepad – very basic story, aim of the game, how game changes as you progress, target resolution (and strategy for dealing with other resolutions), art style, outline control scheme, technical considerations (z-ordering sprites, benchmarking), app flow detailing screen transitions, extra detail on gameplay, optional features to add if there’s time, and finally a plan of action (prototype game mechanic – is it fun? > add animation > add non game screens > polish graphics and sound > add extra features). It sounds like a lot, but we’re talking less than one sheet of A4 here, and less than 30 minutes time spent, I think it was well worth doing. I may have deviated from the plan a little (mostly thanks to playtest feedback from my girlfriend Sue), but having some concrete ideas written down that can be referred to when needed is definitely a good thing.
Created a very simple design document in notepad – very basic story, aim of the game, how game changes as you progress, target resolution (and strategy for dealing with other resolutions), art style, outline control scheme, technical considerations (z-ordering sprites, benchmarking), app flow detailing screen transitions, extra detail on gameplay, optional features to add if there’s time, and finally a plan of action (prototype game mechanic – is it fun? > add animation > add non game screens > polish graphics and sound > add extra features). It sounds like a lot, but we’re talking less than one sheet of A4 here, and less than 30 minutes time spent, I think it was well worth doing. I may have deviated from the plan a little (mostly thanks to playtest feedback from my girlfriend Sue), but having some concrete ideas written down that can be referred to when needed is definitely a good thing.
Friday 7pm – 9pm:
Followed an earlier blog post I wrote to get a shell libgdx project setup. Created a character class, and child goodie and baddie classes that extend character. Drew a few random goodies and baddies to screen (red squares and blue squares).
Followed an earlier blog post I wrote to get a shell libgdx project setup. Created a character class, and child goodie and baddie classes that extend character. Drew a few random goodies and baddies to screen (red squares and blue squares).
Friday 9pm – 11pm:
After dinner, implemented player movement. This was fun as it was a new thing for me to learn – you set a target by touching the screen, and the player character makes a beeline for the target. I’ll share the code in a future blog post. Once player movement was sorted, did the same for the baddies. Then I replaced the hardcoded baddies with some code to automatically spawn baddies at regular intervals, lifted the aspect ratio handling from racing game and dropped it into this project, and swapped the red and blue squares for a couple of static images that looked a little nicer. At this point it already looked like a game, played nicely on laptop at various resolutions, and looked good and performed great on my xperia go, xperia play, and Sue’s xperia mini pro.
After dinner, implemented player movement. This was fun as it was a new thing for me to learn – you set a target by touching the screen, and the player character makes a beeline for the target. I’ll share the code in a future blog post. Once player movement was sorted, did the same for the baddies. Then I replaced the hardcoded baddies with some code to automatically spawn baddies at regular intervals, lifted the aspect ratio handling from racing game and dropped it into this project, and swapped the red and blue squares for a couple of static images that looked a little nicer. At this point it already looked like a game, played nicely on laptop at various resolutions, and looked good and performed great on my xperia go, xperia play, and Sue’s xperia mini pro.
Friday 11pm:
It took four hours to go from nought to a prototype running on desktop and three phones. Awesome! A little playtesting and feedback gathering, and then put it to bed for the night.
It took four hours to go from nought to a prototype running on desktop and three phones. Awesome! A little playtesting and feedback gathering, and then put it to bed for the night.
Saturday 9am – 11am:
Added some more baddie types (for visual variety only, they have no other differing properties, maybe they will do eventually though). Also worked out a way of making the characters face the direction they are targetting.
Added some more baddie types (for visual variety only, they have no other differing properties, maybe they will do eventually though). Also worked out a way of making the characters face the direction they are targetting.
Saturday 11am – 1pm:
Another new thing to learn – animating sprites! This was good fun, characters really come to life once the illusion of animation is added! Also played with texture filtering to get a nice smooth finish on non target resolution devices. I went for a costlier option in terms of processing, but will benchmark to see how it performs and scale it back if I have to.
Another new thing to learn – animating sprites! This was good fun, characters really come to life once the illusion of animation is added! Also played with texture filtering to get a nice smooth finish on non target resolution devices. I went for a costlier option in terms of processing, but will benchmark to see how it performs and scale it back if I have to.
Saturday 1pm – 3pm:
Another new thing to learn – z ordering sprites for correct rendering to screen. This initially seemed to go well, sprites were drawn in the right order, but a bug was introduced that would only become apparent when benchmarking later in the day…
Another new thing to learn – z ordering sprites for correct rendering to screen. This initially seemed to go well, sprites were drawn in the right order, but a bug was introduced that would only become apparent when benchmarking later in the day…
Saturday 3pm – 5pm:
After lunch I took a break from the game creation and started working on a nice logo (this game will eventually make it onto google play so it’ll need one). I also lifted the timer from racing game and dropped it into this project.
After lunch I took a break from the game creation and started working on a nice logo (this game will eventually make it onto google play so it’ll need one). I also lifted the timer from racing game and dropped it into this project.
Saturday 5pm – 7pm:
Improved the baddie spawning code, difficulty ramps up as you progress. Also added a functional placeholder hud displaying mostly debug info.
Improved the baddie spawning code, difficulty ramps up as you progress. Also added a functional placeholder hud displaying mostly debug info.
Saturday 7pm – 11pm:
After dinner, the game screen was pretty much there, so it was time to benchmark. I upped the baddie spawn rate (x1000!) to see how it coped. The answer – not so well. My sprite z ordering code had a bug in it that caused the game to crash after a few seconds. When I scaled the spawn rate back down to normal, the game performed great and I couldn’t get it to crash until after the player would have realistically died. I guess I could have chickened out and left the bug unfixed, and if this was a real Ludum Dare 48 with a hard deadline that’s what I would have done, but it didn’t sit right with me, and since there was no hard deadline I reached from my trusty shotgun and went on a bug hunt!
After dinner, the game screen was pretty much there, so it was time to benchmark. I upped the baddie spawn rate (x1000!) to see how it coped. The answer – not so well. My sprite z ordering code had a bug in it that caused the game to crash after a few seconds. When I scaled the spawn rate back down to normal, the game performed great and I couldn’t get it to crash until after the player would have realistically died. I guess I could have chickened out and left the bug unfixed, and if this was a real Ludum Dare 48 with a hard deadline that’s what I would have done, but it didn’t sit right with me, and since there was no hard deadline I reached from my trusty shotgun and went on a bug hunt!
Saturday 11pm:
The bug had me stumped for quite some time. I headed down some blind alleys, and made a bit of a mess. I learnt a new git command to force a hard reset back to a previous commit (git reset –hard <tag>), a handy command but not to be used lightly! And eventually stumbled across the solution (thank you internets!) My mistake was using comparable when I should have used comparator. I guess someone with more programming experience would have realised this immediately. A rookie mistake – no doubt one of many to come! Anyway, problem eventually solved, so now I could try benchmarking again – increased the baddie spawn rate massively again (x1000) and left the game running, half an hour later no crashes, and fps remained 40+ no matter what. Excellent result! Tried this monster of a brute force test on the phones, and they all eventually slowed to a crawl then crashed, at such ridiculous spawn rates though, it was to be expected. Scaled back the spawning to a reasonable level and tested on the phones, perfectly reliable with no noticable slowdown not even after my player character should have been loooong dead. I do need to find an old low spec phone though, I’m hoping that this game will run on android 1.6 or above, and although I can pretty much ensure that it will run on 1.6 by using the emulator it would be nice to see how it performs on such a device.
The bug had me stumped for quite some time. I headed down some blind alleys, and made a bit of a mess. I learnt a new git command to force a hard reset back to a previous commit (git reset –hard <tag>), a handy command but not to be used lightly! And eventually stumbled across the solution (thank you internets!) My mistake was using comparable when I should have used comparator. I guess someone with more programming experience would have realised this immediately. A rookie mistake – no doubt one of many to come! Anyway, problem eventually solved, so now I could try benchmarking again – increased the baddie spawn rate massively again (x1000) and left the game running, half an hour later no crashes, and fps remained 40+ no matter what. Excellent result! Tried this monster of a brute force test on the phones, and they all eventually slowed to a crawl then crashed, at such ridiculous spawn rates though, it was to be expected. Scaled back the spawning to a reasonable level and tested on the phones, perfectly reliable with no noticable slowdown not even after my player character should have been loooong dead. I do need to find an old low spec phone though, I’m hoping that this game will run on android 1.6 or above, and although I can pretty much ensure that it will run on 1.6 by using the emulator it would be nice to see how it performs on such a device.
Sunday 10am:
My plans are scuppered! My awesome understanding girlfriend was perfectly happy to humour me and not complain too much about me spending pretty much all my waking hours glued to the laptop and phones. However, today is another day, and real life beckons. I have to leave the house, go shopping, and visit family (don’t get me wrong that is never a chore!). Today I will post this blog post as a record of how my first 29 hours of a LD48-like challenge went, and maybe this evening I will get the opportunity to add some more features, but realistically I won’t end up with a finished product by 6pm. I do have something that is demonstrable and fun to play though, and I think quite often that’s as far as a lot of Ludum Dare entries get, the polish is added in the days and weeks that follow.
My plans are scuppered! My awesome understanding girlfriend was perfectly happy to humour me and not complain too much about me spending pretty much all my waking hours glued to the laptop and phones. However, today is another day, and real life beckons. I have to leave the house, go shopping, and visit family (don’t get me wrong that is never a chore!). Today I will post this blog post as a record of how my first 29 hours of a LD48-like challenge went, and maybe this evening I will get the opportunity to add some more features, but realistically I won’t end up with a finished product by 6pm. I do have something that is demonstrable and fun to play though, and I think quite often that’s as far as a lot of Ludum Dare entries get, the polish is added in the days and weeks that follow.
It has been a fun experiment, and I’ll post an update once the game is finished and available to download from Google Play!
No comments:
Post a Comment