Pinterest is your friend when it comes to discovering great UI ideas. Google images is great too but Pinterest provides the ability to save (pin) all the interesting images rather than having to actually download them and store them somewhere yourself. This week I’ve spent time looking up map UI, tactical map, airstrike and hud and collating a modest collection of ideas for the visual aesthetic of Failed State.
Just to prove that good ideas can come from all sorts of diverse places, I happened to see a video about Auckland International Airport showing off their expansion plans up to the year 2044. I found it thanks to transportblog.co.nz which is a great source of all things NZ tranport infrastructure related.
What was interesting about it (with the exception of its content and great graphics) was some of the coloured overlays that were being used to define locations and areas on the map. Also of interest was the camera angle, but that’s an altogether different topic.
The overlays in question looked something like this…
…and what was especially of interest was the way the labelled overlays ‘pinned’ to the terrain. I was trying to think of a way of anchoring an overlay representing a in-game unit (e.g. a tank) to a map location. This is not a 3D game as such and the zoom level is too high so there is not going to be a concept of an actual 3D tank model on the map, it will probably just be a circle with a label. The problem is conveying enough info with something like this. I don’t want to use a google maps type pin or anything else synonymous with mapping apps so seeing this AIA video was a lucky break; I’m not above copying it.
Making higher res mock ups is in violation of my idea of quickly getting a first draft done but hi-res is good for eliciting different type of feedback than hand drawn sketches do. It also helps me visualise screen real-estate and how one might interact with units (e.g. tanks).
I’m still trying to find unit identifiers similar to what World in Conflict and Wargame European Escalation use when the map is zoomed out (gosh did my Mac Book Pro just go absolutely nuts running European Escalation just so I could get a screenshot. Meh, I don’t even need it; just take my word for it that those games look amazing). I’d like to use icons to represent units but for now I’ll just use plain text, e.g. a M1-A1 tank will just use that very text on the overlay unit label.
Regardless, here’s something to show off. There is an expectation that touch devices require bold UI elements and simple game play. Failed State is certainly not going to be a Eugen Systems game but one has to start from somewhere, right.
At 2 am this morning I concluded my wrestling match with iOS certificates and distribution provisioning profiles and finally submitted Breezy Bubbles to the app store.
Breezy Bubbles is a colourful and fun little bubble popping game where the player has to pop coloured bubbles in a prescribed order against the clock. Watch or for the butterflies though, because they don’t like getting prodded; and the breeze, it will push those bubbles around, making things a lot more difficult as the levels progress.
The release of Breezy Bubbles is a great opportunity to start writing again. The goal was to create and ship a simple and fun game as quickly as possible, yet in the end it still took 6 months. My next writeups will be about tips, tricks and experiences to get to this point so to kick this off, the first thing worth writing about is scope.
The Greatest Lesson
Development never goes to plan. Never, ever, ever. It’s crazy to think how complicated even the most simple of games can become, which makes me wonder how on earth one ever completes those 48 hour game jam competitions. What could be so hard about pushing bubbles across the screen? Well, giving early builds to friends to have a play revealed obvious gameplay flaws, then there were implementations that seem simple until one starts coding them. Here is a list of things that pushed out the release date.
Flawed Game Play Mechanic
Initially, the original game play didn’t use simple touch-to-pop mechanism which it does now. The original idea was to have a touch-swipe mechanic where the user could keep their finger on the screen to pop many bubbles at a time (allowing the potential for a ‘vapour trail’ that could inadvertently pop bubbles you weren’t supposed to). As much as I liked that idea, one doesn’t intuitively think of popping via a swipe. Seeing friends naturally want to touch/tap each bubble made it clear that bubbles and swipes was not an intuitive mix.
Intuition – Forgoing the Tutorial
Segueing from this was another user interaction issue. The player has to pop bubbles in a particular bubble order but I wanted to make this obvious and thus forgo the need for instructions. A game this simple shouldn’t require a tutorial or help screen, so I needed gameplay that, even if not understood immediately, should be blatantly obvious to the player when they start doing the ‘wrong thing’. For this game, the ‘wrong thing’ is not popping bubbles in the correct order. In the top left of the screen there is a HUD element that shows the required colour pop order of the bubbles, ordered right to left. When I gave early builds to friends and colleagues (and the odd music student), I had 50% of people get it almost straight away, the other 50% just didn’t get it fast enough. Issues included:
Trying to interact with the bubble in that HUD element
Ignoring the colour queue completely and just popping bubbles willy-nilly.
Popping from left to right rather than right to left.
The solution was two-fold. Provide a prominent border to the HUD element, and animate the HUD bubbles every time a bubble was unsuccessfully popped so that it created this little right to left wave (achieved by some scaling effects). The right most bubble, when popped, had always disappeared, so usually once the player saw this, they were away.
I used Cocos2d-x for this project. I’m no longer in the habit of writing engine code anymore, so the fact that Cocos2d-x has most of the tools required to make great 2D game is such a huge win. That being said, I still had to learn an entirely new framework with all its own little quirks. I had heaps of misadventure supporting different screen sizes and even now the result is going to be a game that is definitely easier to play on a tablet.
I’m certainly no artist, so creating images is not a strength. That being said, where the heck is the photoshop equivalent of Gimp’s colorfy and colour to alpha? If it wasn’t for the fact that I’m a huge fan of photoshop’s Layer Style tool, I’d be using Gimp for all my needs. I ended up using both image programs to do the bubble images.
Assuming the iOS submission goes without a hitch and there aren’t any obvious stuff ups that need my attention, here’s a list of what I’d like to do next.
I chose Cocos2d-x so I could support multiple platforms, but I was also hugely aware that I wanted to ship something as soon as possible and had never done any meaningful Android dev work before. Trying to make an Android version in parallel, not knowing the unknown, was just not worthy of my consideration. I didn’t want to be in a situation where I felt compelled to keep having to go back and fix a broken Android build, thus consuming more of my valuable time.
Playing around Android SDKs and whatever passes for a Game Center on Android is going to take time and there was no way I wanted to push back a release date for the sake of a simultaneous release.
I have a huge appreciation of languages and will try and get this working. Again, this takes a lot of effort. MyGengo is a great tool for managing translations, but working all the translation data into the code was something I didn’t want to have to think about in the first stage of this project.
Encrypt the plist
This is not something I can be bothered doing, but some cheeky bugger is going to mess with my score board sooner or later. It’s not difficult to tamper with and there is bound to be someone that will get their jollies by hacking in a score of 999,999,999. Encryption seems like something one should know for future projects though, and Breezy Bubbles seems like a good test case.
What I don’t intend to do
There are certain things that are just too much for such a simple game. In game purchases is one. Short of perhaps making the game shareware and have the player run out of ‘bubble soap’ after a certain period of time, and having an in app purchase of 99c remove the restriction, there seemed little reason to have this. The whole point of this project was to make a game as quickly as possible and spending my spare time messing around with in-app purchases (and remember, I want to do an Android version too) would just keep pushing back the release date.
There are certainly some game play features that would be great to do. I had all these ideas for power ups and power downs (perhaps in-app purchasable), unlockable content and achievements. Again though, all these nice to haves just push back the release date.
Breezy Bubbles took about 6 months to write in my spare time, spare time that is hotly contested thanks to social circles outside of a computer screen. I managed to ship a game that is simple and fun to play and despite the fact there is the potential for more to come, those desirables didn’t affect the ability to release or diminish the gameplay. It’s going to be great having another game alongside Mobile Assault on the app store.
The handheld space is hotly contested now, and I’ll admit that Breezy Bubbles doesn’t add anything revolutionary in terms of gameplay. One might say that Breezy Bubbles is merely a cross between Fly Loop and Fruit Ninja. I’m not expecting to find the software developer’s equivalent of the pot of gold at the end of the rainbow, but it would be great to recover costs (I had to buy licenses to software, art and music, but I’ll leave that for a different post). But who knows, it’s a simple game and maybe the young kids will love it.