Saturday, 28 March 2015
A huge amount of progress has been made on our quasi-arena-shmup project over the past fortnight - and although there’s a long way to go, the end is definitely in sight. We’re still hoping for an early summer release (at least on PC and Android), mainly because we need to start making sales in order to pay our accountants, but also because it’s good to have a self-imposed deadline so as to prevent the project running on and on.
We’ve revised the game design somewhat; in single player ‘arcade’ mode - the proper way to play the game - Pan-Dimensonal Conga-Combat now features three stages for each of the four dimensions, and loops indefinitely. On each stage the kill quota to unlock the exit portal increases by 20, then drops by 20 at the completion of a dimension so as to give a little breathing space. This means that to reach dimension two, the player needs to kill 20 + 40 + 60 (120) of the geometric critters, then to reach dimension three they’ll need an additional 40 + 60 + 80 (180) more. To loop the game, the player will need to kill a total of 840 critters all on a single life - which sounds insane, but when you consider that enemy formations and waves often consist of 10+ enemies and you get 10 kills for every enemy portal you close, it’s certainly still achievable. Also, we learnt from r0x EP that it’s a mistake to underestimate how well some people play!
To make things a bit fairer, Conga also has a ‘casual’ mode. In casual mode you can play any of the dimensions you’ve reached so far, and there are no stages. You can also unlock dimensions by beating the kill quota - i.e. 120 kills to unlock dimension two - but the fact that you can reattempt this after every death without starting again from the beginning makes things a lot easier. To counter this, in this mode only your best score/time/kills are recorded - whereas in ‘arcade’ the overall score, time, kills, and stage/dimension/loop reached go onto the high score table.
One of the biggest changes implemented over the past couple of weeks is that everything in the game is now synchronised to the music. GameMaker Studio has this great ‘timeline’ feature, and by manually calculating how many frames are in a beat/bar for each track, it is possible to create a timeline approximately the same length as each piece of music and schedule events to occur perfectly on the beat. This is not something I’d recommend for beginners though - it took a lot of time to get right (particularly due to some of iLKke’s unusual beat structuring). For example, although 120BPM works out at a really nice 30 frames per beat (at 60FPS), 118BPM is around 30.5 - which meant I had to compensate for that half frame ‘slip’ throughout the timeline. Plus, with some of the tracks running in at three minutes length, editing the timelines in GMS was out of the question, so it was time for Notepad++ and a long process of cutting and pasting XML. I ended up having to create macro keys on my keyboard to prevent CTRL+C/V cramp!
Another problem I had to overcome was how to handle the music playing routine. Because of the frame slippage issue mentioned above, I couldn’t simply have the music loop automatically. Over repeated plays the associated timeline would gradually fall out of sync, so instead I had to write a routine that checked if the music had ended at the start of each frame, and if so, restart it and manually reset the timeline back to position zero. It sounds simple, but with all the other handling and routines required by the audio system, it soon became one of the most complex Game Maker objects I’ve ever created. As always, by the time I finished hacking all the stuff in (and fixing memory leaks), I realised that there are probably more efficient ways of achieving the same result, but there’s no way I’m going to rebuild it from scratch now... although I do still need to think about adding some sort of compensation or check for if it does drop out of sync on less powerful hardware(!)
I did look at seeing if this process could be automated without timelines - and it to a degree it could by using standard alarm calls with variable-assigned periods between them, but the end result was a game that felt noticeably repetitive rather than rhythmic. Lesson learned: you can’t automate funk!
Jamie hugely helped improve the visual aspect of this synchronisation by creating a simple shader-level RGB splitting script. Using this effect at key points in the music really improved the game play experience - especially in the breaks and more ‘acid’ parts of the soundtrack. But the main addition he provided to the game was the finalised version of ‘tube.exe’ - a simple yet extremely effective 3D cutscene currently used between each dimension jump (as well as on the placeholder title screen).
So what’s left on the to-do list? Apart from the easy-yet-time-consuming stuff like the last two timelines and a ton more background animations, the main focus over the next few weeks is to build up the framework for the front end and implement the various game modes. Jamie has begun experimenting with touch control for tablets, which is something we particularly want to implement for this project, but we currently only have a phone to test on. Conga was never designed with a tiny mobile phone screen in mind, so it currently looks as though I might need to buy the tablet my daughter wants for her Birthday a bit earlier than I’d previously planned.
For those of you who recall my post-release write-up on r0x EP, Conga currently looks set to cost us around the same amount (in assets alone) so we’ve started looking at how we might get a return on what we’ve paid out so far, and ideally make enough profit to pay our bills at the end of the year. Our intention is to launch a Greenlight for the game on Steam at the same time that we re-release r0x EP on the platform in order in increase our chances of exposure, and ideally have the game ready for launch on itch.io soon after (if not simultaneously). As Conga is a mini/budget style game, we’re not crazily optimistic about the chances of it getting onto Steam, but then we said the same thing about r0x, so who knows.
Of course, we’ll most certainly target Android - particularly the Amazon ecosystem, due to having a good relationship with their indie outreach guys, and hopefully we’ll also get it on to iOS too (as long as that doesn’t involve jumping through too many hoops). As much as Jamie and I love making games, we can’t continue to just give them away, so based on the development cost, we’re probably going to offer the game for sale on PC at around the £5 mark and £2-3 on mobile/micro-consoles. This might seem comparatively high, but this equates to roughly 400 sales on PC or 800 on mobile to break even. From past experience, I know that even sales figures as low as that are optimistic for a new game development studio in today’s market, so we’re going to have to really push it if Jamie and I want to see any of our investment back.
But I’m not going to worry about all of that just yet. In fact, I’ve got a load of other stuff I need to catch up with before working on Conga again - including selling the C64 side of RGCD to RGCD.DEV (which sounds like a scam, but it really isn’t) and preparing two new C64 games. Oh, and not forgetting sending out the competition prizes (finally) and organising the next round. Arrgghh! There’s just not enough hours in a week.