When I set aside time to work on Conga, before hitting the keys I normally sit down, skim through the all-important project design document to see what's left to work on, then pick a few meaty chunks to tackle. Usually I'm over-ambitious and select WAY more than I'll ever manage, but it does help to add a bit of focus and provides me with a rough plan for the days ahead. Doing this also gives James a chance to feed some ideas in ahead of implementation, as more often than not we've ended up scribbling something down during one of our weekly meet-ups and it's never actually made it into the documents (luckily his memory is better than mine!)
So, with three days booked off from real-life work, I set out my battle plan. On day one I'd tackle the entire front end, right the way through to Conga's 'Casual' play mode, then take on the scores and achievements on day two and round off with multi-player on day three! Oh well, one out of three isn't too bad!
Here at RGCD.DEV one of the areas of game design we feel is really important is the front-end and the way that it feeds back information to the player. This is one of the reasons why we always try to give our games some appealing transitions from state to state, screen to screen, layout to layout. It's frustrating to load up what looks like a great game only to find the front end is really plain, static and uninteresting - after all, this is normally the first impression players will get of your game. It's also a good testing ground to experiment and play with some fun ideas. Why is it that the interface always seems to be the last thing any game dev wants to work on? I guess there's not much that's sexy about menus!? Or perhaps it's just because most developers are suffering from project-burn-out by the time they get around to coding them?
Currently the menu path for 'Casual' mode is: TITLE -> MAIN MENU -> PLAY MENU -> DIMENSION SELECT -> PLAY. This seems like a lot of button presses before you can actually play, but this is why we're adding a quick 'TRY AGAIN / EXIT TO MENU' option after each game-over. Fortunately it's a bit quicker for 'Arcade', as there's no need to select dimension (you always start from the beginning), but it's likely to be a similar length or even longer for 'Multiplayer'.
We had some rough ideas for a title screen and well... after a few attempts they are still a work-in-progress but we kind of know where we're going with it now (or at least we have a concept that all of us are finally happy with). Development of these ideas was an iterative process conducted using a combination of Vine and Twitter - I'd upload a seven-second video of one idea, James would like it and Folmer would suggest some changes. I'd then tweak it, upload again and Folmer would be happy but James would complain about something else. Rinse and repeat. The current screen still (probably) isn't final, but you can track its evolution in full ghetto-cam glory over on my Vine channel.
Ultimately we all wanted some of the interface components to elastically spring into place as they move around the screen so I used the classic Euler's spring mass system with a little dampening. This is most noticeable on our PANDIMENSIONAL and CONGA COMBAT logo components when they break apart at the same time as the menu bar splits the screen. I'm pretty sure GameMaker must have some in-built physics that may have helped here (I might have to revisit the manual and look). Native GMS functions are probably way more efficient than my own GM script but it's handy to know how these things work sometimes. We also used a little masking shader to white out the logo when the RGB split is called to better show off the effect - RGB looks wicked on white objects!
The method by which we create the initial menu bar uses the same blockout system as the screen transitions; the black background is tiled-in using a randomly selected path across the middle of the screen. Folmer came up with a neat concept-gif that featured the player sprite acting as a cursor on the menu system, so I took it a step further and made the sprite fluidly jump around each item and shoot the laser for item selection, drawing the text with a little additive blend so that they glow white hot!
All was going well until I came to the level select menu, where we needed to free up the centre of the screen to make room for the dimension select carousel. My first thought was to dissolve the menu bar using the blockout system whilst simultaneously tiling-in another bar further down the screen, but James was really against this and instead suggested that we use the same elasticity effect as before to simply bump the menu bar further down the screen at the same time everything else swooshes in. It's amazing how long it takes to discuss and resolve these minor little details sometimes - I wonder if it's just James being super anally retentive or if this is really something that all other collaborative projects go through! Anyway, in this particular case James got his way, and to be honest it all looks pretty smooth now and feels really fast and tight. Again, there's a load of Vines on my channel if you want to see how it looks, complete with temporary coder art ;)
Finally, another area that's seen a lot of work recently is the tutorial, an area we completely failed to cover in r0x. Watching people struggle to 'get it' on YouTube gameplay videos and reviews was an experience we never want to repeat! It's not finished yet, but the main framework to introduce the core mechanics is in place. We're probably going to do something clever to replace the temporary grid background at some point too - but that's a discussion for another day.
Next on the agenda is local high score saving, Amazon Game Circle and achievements... This could be interesting! As always, interested to read your comments.
No comments:
Post a Comment