Originally posted on my blog.
When I started working full-time on indie games at Dashing Strike, I vowed to participate in every Ludum Dare if possible, and this past one marks my 10th Ludum Dare in a row!
For those that haven't played my entry yet, it's a spaceship management game where you alternate between phases of fighting a wave of enemies and choosing which piece of equipment to remove from your ship, making you weaker but able to carry more refugees to safety, with a few little special events that influence your choices.
You can play and rate the game here
What Went Right
- Scope - My game idea was fairly complicated, had very ambitious coding goals to finish it in time. I managed to implement most of what I planned, making a fairly complicated game (for a Ludum Dare entry), and after the tech work, I just barely ended with enough time to do sound, music, and add a little polish.
- Music theming - Though I wish I had been able to spend more time on it, I think the music turned out pretty good (or, at least, pretty OK?), and I even received some compliments on it, which is a first for me. For the Main Theme I think it worked out because I had a plan when I started - I chose an inspiration (music from Firefly in this case), spent a couple minutes listening to it, identified a couple key instruments, and then started by trying to mimic that. I ended up going off and doing a bit of my own thing, but having a place to start worked much better than staring at a blank staff and wondering what to make. For the Battle Music, when choosing instruments for the main theme, I stumbled upon the "effect bass" voice in Bosca Coeil, and that seemed nice and sci-fi sounding and pretty good all on its own for ambient music. I then added a little very quiet melody, that you probably don't hear over the explosions and other battle sounds, and it turned out pretty good. Upon reflection, if I spent more than 1 hour exactly every 4 months using my music software, maybe I'd already know which sets of instruments work well =).
- Simplification of the power mechanic - My original design/implementation had each panel in 1 of 3 states - off, on, or over-powered, letting you have more fine control to boost something quickly, but have it quickly overheat. But, UX-wise, it really felt good to let you just click on the whole panel to toggle states, and my initial 3-way toggle didn't work well at all - when playing, it was on "on", and as a player I needed it off, so I clicked it, now it's on "over" and things are worse, oh no!, what's going on?! So, I temporarily simplified it to 2, and it turned out that just having the "on" state generate heat and be required to be turned off from time to time generated more than enough scramble to make managing the ship engaging.
- Story/Writing - I've not had much more than a single line of text (other than tutorials) in any of my previous Ludum Dare entries, as, usually I like to just focus on the gameplay, but I have been wanting to try a little game writing, since it's a skill I've not had chance to exercise. Though I don't think the story was anything particularly good (it's mostly references to other Sci-Fi properties or tropes), I received a lot of comments that it helped engage them and feel like there was a reason to rescue these refugees - and I guess some people need more motivation than just a high score to intentionally make their ship worse as the game progresses.
- Something New - Some famous game designer, I forget who, said in a talk that if you're going to make a game, it's great to re-use what works from previous games, but make sure it has at least one new thing in it, or it's not worth doing. Though it's safe to say just about every thing that seems "new" in a Ludum Dare entry has probably been done sometime before in the tens of thousands of game jam games, I, at least, haven't seen a game that does the item/power progression mostly backwards, and that did end up being more interesting, and less frustrating, than I originally expected. Seeing this mechanic work out, and not getting any negative feedback on it, felt really good. I think that, perhaps, the theme of my game helped the mechanic feel good - you're not "crippling your ship" but "making space for more refugees", so you still feel "good".
What Went Wrong
- Scope - Though I put this in the "What Went Right" category because it let me explore a more complicated game design, I suspect my overall entry would have been better if the scope was a little simpler. Because I spent so much time on coding, I had little time for other important things. I ended up not doing a single user test, and I think watching just one person play it would have helped a lot. More time balancing would have helped. As always, I started by cranking out some initial sprites which "would be replaced by real ones later", which I never got around to, only spent a few minutes touching up the originals - a little more time on polishing art would have gone a long way.
- Difficulty curve - Looking at the full high score list, it's clear that most people either die or quit after 3 or 5 levels. After 3 levels is, I think, the first place you can die if you're not playing well (letting the shields constantly overheat). It would have been good to add something to stop the "spiral of death" that occurs as soon as your shields are destroyed - there's not much a player can do to recover if they mistakenly ruined their shields early on. I think that I could have let the ship get entirely repaired after each battle and that would have been fine - when a person is playing well, they don't take damage anyway, and the encounters were relatively balanced to that.
- Needed another tutorial or two - After the end of the competition, I got to watch a stream of Saoigames playing, and it was very clear they didn't understand 2 of the more complicated nodes in the ship (the power node and repair node), and I think adding a tutorial pop-up for those might have helped the people who failed or quit early. This would have only taken a couple minutes to add, but without watching someone play it didn't occur to me that it was needed.
Reception & Analytics
At the time of this writing, the rating period is still going on, so I don't know what people are rating my entry, but the game has a high score list and I can look at how far people made it from that data (assuming they completed at least the first level). From previous entries, I've learned having a high score list is a great way to get very rough analytics on how engaged people are with the game, and inspire competition among friends, so it's something my engine supports easily.
As of now, I've had 42 people play my game, and received 29 ratings on the Ludum Dare site. At least 7 of the players are from my social shares (I recognize their names on the high score list), so that just leaves 6 unknowns - either from my social scores (but didn't put in a name), or from the Ludum Dare site but they didn't leave a rating after playing.
Looking at progression, I had roughly 7 people stop playing after completing level 1 - they either died on level 2 (not likely, unless they really messed up), or they decided they'd played enough. Similarly 7 more dropped off after levels 2 and 3. Interestingly, no one dropped off after level 4 (everyone who made it that far also beat level 5). Looking at other data, level 4 is the shortest level (took people an average of 54 seconds, vs 2-3 minutes for each of the first 3 levels), so perhaps balancing more of the waves to be of a similar length would have kept people engaged longer. I can see how more than 2 minutes is a bit long for a level in the casual setting of playing Ludum Dare games, and the gameplay of my game gets pretty repetitive once you get the hang of it. After those levels, had an average of 1 person quit after each of levels 5-10, and then a total of 15 (35%) who played and survived until the end, however, this cohort was about 50% from my social shares (they all made it to the end) and 50% Ludum Dare players - my friends had a lot more patience (or were better at this kind of game) than the general audience.
Average time to beat all 11 levels of the game was 19 minutes, which is a little longer than I expected, and a little long for a Ludum Dare entry, but not too bad. However, the median playtime for all players was just 10 minutes, so most people got bored (or died and did not retry) at about half that. I think 10 minutes is a reasonable gameplay length to aim for for a Ludum Dare entry.
It would be really interesting to know if people died or quit. A player losing and then moving on to rate the next game shows a different kind of disengagement than someone getting bored and quitting. I think for my next game I'll add in a little more analytics - it's just one line of code when I throw up the "you lose" screen, and would give more meaningful data.
Future Work
Ludum Dare is great for personal growth, but it's also a great sounding board for game design ideas, and forces me to bring a prototype all the way through the development process to something complete in a short time. So, the big question then is: Can this game, or part of this game, be used in a larger project? I've been toying with the idea of a cooperative ship-piloting game, where people work puzzles to power the ship (similar to Puzzle Pirates, but with a bit more tangible outputs from puzzles to ship performance), and this kind of game needs some good mechanics for the "scramble" gameplay - when you're not doing puzzles but running around the ship flipping levers trying to survive an encounter. I had this kind of game in mind when making Escape from the Alliance, of course. So, would this gameplay work as part of something bigger? I'd love to hear your thoughts in the comments =). I think part of it would - I really liked the way overheating mechanic played out. In my previous prototypes, the gameplay usually degenerated to "we've got enough power output now, just leave the shields/engines/everything on full for the rest of the journey", making encounters less interesting. Having components start overheating means the player needs to be more active in managing the ship, but also means there's a bit of a schedule you can understand - you flip the switch to turn on the shields, and you know you've got X amount of time to work on a puzzle before you need to go and deal with shields again. I think I like how that would play out. The fact that components overheat for a bit and then automatically turn off also works pretty good so you don't always have to be on top of things, and also opens possibilities for interesting ship upgrades/variations: quick overheat detection auto-off upgrades or ships that take less damage from overheating, or more damage but cool faster, for the micro-managers.
The encounter pacing here also provided some interesting insights - in my "perfect score" run through the game, a couple of the encounters played differently than others - even though the only difference was how many ships were attacking, because destroying a ship was a very discrete event (power weapons to full, one ship dies), I could plan an optimal strategy in each battle - in some it was worth a little overheating on weapons to more quickly take out more (or all) enemies right away, and in others it was going to be a long fight and was more about heat management on the shields and putting some power into engines to provide just enough relief so the shields could cool. The take-away here is that it's best that the encounter mechanics be easily understood, and allowing the player multiple ways (each with their tradeoffs) of dealing with them provides some interesting gameplay. In my previous prototypes I leaned more towards encounters with different mechanics - "this encounter is asteroids, so you need power to engines, this next one is enemy fighters, so you need power to shields", but I see here that just having one mechanic with multiple systems that affect is will lead to much better gameplay - instead I can have "this encounter is asteroids - small count of large damage - implicitly encourages you to use engines for evasion; this next one is enemy fighters - constant flow of small damage - implicitly encourages you to use shields". As usual, simpler, better understood mechanics with player choice = better gameplay!
Thanks for reading this far! If you want to support my future game development, go check out Splody, it's coming out on PS4 on September 18th, and is available on Steam now.
What do you think about the gameplay in Escape from the Alliance? What did you like or dislike and what might you like to see in a deeper cooperative ship-piloting game?
