First of all, Happy New Year everyone! I hope you are feeling optimistic about the new year and feel relaxed after the holiday season.
In this blog post I’m going to talk about a new game prototype I have been working on. You can download an apk of my progress here: prototype.apk(18mb)
I’ve been working on this puzzle game idea sporadically over the past few months and I’m pleased to share some progress with you. I’ve programmed a few simple rules and a level editor, and have been doing most of my level design on paper. Over the last few days of the year, I finally programmed a few levels into the game.
I’d love to hear what you think. Particularly, I’d like to hear feedback on:
Were the rules clear? Did you get stuck on any of the early levels?
Which levels did you find particularly puzzling?
Did you find any levels boring?
Below is a list of known issues / work in progress
UI is very placeholder: coins and hint buttons do nothing
‘Zen’ levels not ready – button disabled
You will pass with a blue (pass) or purple (perfect) star. Occasionally, the game awards an incorrect star.
The archives of this blog show how long I have been working on Crocodile Cat. It was my “teaching myself unity” project for a while, it was a commuter project when I was a junior, and now I am a lead designer at a larger studio – I don’t have so much time for personal projects. After a few days of -actual- relaxation over the holidays, I decided to finish it.
The biggest unfinished task was the audio. I enjoy making sfx and music (and I’m quite good at it). Unfortunately, I left all of my audio gear behind in the UK when I moved to Canada. Still, I have done my best using freesound and a few synths I still have a licence for.
The game design challenges also needed attention. Digging into old code is hard. When that code was written by a beginner, harder still. Through some user testing, I believe my tutorial is better than it has been but the game does not do a perfect job of teaching itself. Chance affects the difficulty curve more than I would like. But the game is stable, playable, fun and it is complete.
It now sits on the app store and a weight is off my mind. I can move on. Perhaps foolishly, I’m excited to start on another Unity game. I should wait until I’m back at work to decide if I can handle this though, or I will be sitting on yet another unfinished project. Rebecca Deakin created the wonderful art for this game and I took too long to share it with the world!
After moving to Vancouver, I had perfectly natural concerns about removing myself from all my friends and colleagues in the UK and having to make new ties and bonds with people in a strange new city. I needn’t have worried – everyone on the game dev scene has been excellent and friendly and great company.
Looking for work has its perks. Sometimes, a friend will call you up in the middle of the day just to see if you want to go to the pub and make a game. A few cool things happened last Friday (hopefully more info on that later) and this was one of them.
A game of clicks and chance
When I joined him, he was working on a system that would let you buy an item to automatically flip a coin once every n seconds – the start of a classic idle game system.
Everyone has their favourite idle game (it’s probably A Dark Room), but I quickly launched up a couple of them to remind myself of the feel and progression of these titles. They range in pace from furious clickers to games that suggest a little more strategy. Of course, patience is always a factor in these games
Starting work on the game design, I decided to first work out what Cash wanted to get out of his learning activity with MobX. He was pretty open, so I listed out the mechanics we had and the factors that influence those. Coin tosses with a win or lose outcome will yield currency over time. The amount of currency per second is determined by how quickly coins can be tossed; how many coins can be tossed concurrently; and chance.
I drew out a flow chart of the main interaction, tossing a coin:
This helped visualise the existing features and exposed parts of the cycle that could be modified. We can increase the number of coins owned; the points won after the toss; the chance of winning; and decrease the points needed to win a round. We can add auto flippers that flip coins for the player or start matches automatically, making the game easier to manage.
Something that doesn’t suck
We discussed ideas for a narrative to frame the game with a story or setting that “doesn’t suck”. Flipping coins… game of chance… why?… how?… Wizards?.. No… Aliens?… Ummm… how about robots?
Discussing a more tangible setting sparked a few more ideas. You’re controlling a robot army by charging and firing their weapons to defeat… a bigger robot? Successfully landing hits yields cogs, that can be used to upgrade your own robots. I know, we’re narrative geniuses.
The game design now has two steps: charge and fire. The ‘coin flipping’ controls the rate at which your weapon charges and the firing occurs depending on whether you won your round (best of ten). I went through the process again, drawing out a flow of the mechanic and looking for things to mess with or upgrade. Some points were the same, but we can now add things like weapon accuracy or damage multipliers.
One concern I had about porting the coin flip system over to a weapon charge so literally is if the player presses a button to charge a weapon and loses the coin flip, nothing will happen. This is most unsatisfactory! The chance element seemed to have lost its relevance, which is a shame since this is a nice addition to the clicker mechanic. Your opponent is now at the end of the round (firing your weapon) rather than throughout the game (flipping a coin).
Rather than lose the chance element, I looked at my flow chart and decided on a new outcome for losing a toss – the player takes damage! Perhaps the weapon backfires or shorts out. This means there is now a risk attached to clicking the charge button – but this makes the reward of clicking feel greater.
Adding a damage system also provides more opportunities to control the upgrade speed too – perhaps robots on low health operate slower or stop operating altogether. It makes a simple clicker game feel more tactical.
I then updated the flow charts one more time so they look like this:
To explain these ideas quickly to Cash, I drew out a quick sketch on paper, then worked a little on a first pass wireframe for the game’s presentation. I find this the quickest way to explain and document my designs, usually with a few notes around the edge of the diagram. Of course, I checked Cash was happy with this design, since he’d be the one implementing it!
Since this is a first pass, there’s a few things I’d like to change – firstly the presentation of items in the shop! This should be simplified to read “upgrade weapons, upgrade defence, heal” rather than breaking down accuracy, charge speed, etc. So many options with a large army of robots could quickly become annoying.
Of course there’s so much we could add to this – different robot types (tank, infantry, healers) or changing the a risk/reward system of the weapons so that firing a shot before the weapon is fully charged deals less damage to the enemy, but reduces the risk of a missed shot. No matter what, it’ll be fun testing and iterating on this over the coming months.
So there you have it – this is where the design is at. Still working on getting something playable online, but I’ll provide a link when it’s up. It was a fun Friday afternoon quickly throwing this stuff down, hopefully we’ll get to work on it some more and flesh it out!
I’ve now passed a threshold on development of Crocodile Cat:
THE GAME IS NOW VISUALLY APPEALING
I’ve been really lucky to have Rebecca Deakin working on the art for the game.
Rebecca has been great at working with my slightly nonsensical ideas (It’s a cat in a bubble trapped between the jaws of an infinite crocodile) and making them appear practical and, most of all, gorgeous. The bubble has been replaced by a jetpack. See, I can’t draw a jetpack. But Rebecca can.
☑ Can draw cats
☑ Can draw jetpacks
☑ Can draw anything
I spent a bit of time last week incorporating some of these new assets, which meant working with (and adapting) Unity’s animation system and creating some parallax layers. It takes me away from game design, but it’s important and interesting work.
There’s still some placeholders in the above gif, so more to go in, more things to change, but it’s a great step towards sharing the project with more people.
The jaws are now at an angle with the screen, which makes it look amazing. This design change required a lot more behind-the-scenes work than you’d expect! The advantage of starting a project without an artist is that you can focus solely on game design, but the disadvantage is that by building things quickly, you can sometimes lock down things you don’t expect to change. I’m really pleased to be working with Rebecca since it’s little changes like this that really add to the visual appeal of the game, which will be really important in the coming months.
I’m at a stage in my current commuter project where I think I’m ready to start sharing and writing about what I’m making.
Introducing: Crocodile Cat
It is a very silly and simple one touch mobile game about a cat in a bubble who is trapped between the jaws of an infinite crocodile. Currently it features art made by myself in MS Paint, but it will look good one day.
The gameplay is basic, the player cat is moving up and down vertically between the crocodile’s jaws. The player must tap to change direction before they touch the jaws, and the jaws move to the position that the cat was at when the player tapped.
This encourages the player to test their nerve by changing direction as close as possible to the jaws, since the play area is shrunk with every tap.
The jaws are opened again by collecting special coins that fly through the scene, disrupting this game of chicken by offering a reward and brief respite from the increasing pressure.
A .gif below shows the game working in it’s current state. Early days yet but the mechanic is already testing well. I’m looking forward to seeing where I can take it!
Last weekend was Global Game Jam, which very quickly became my favourite event in the game dev calendar. I’ve done Ludum Dare a couple of times and a few local site jams, but the sheer scale of GGJ – the feeling of being part of something so huge on an international level – was just amazing! Thank you to Jo for organising our local site and providing so many good vibes over the weekend (also thanks to Brighton Uni for providing pizzas!).
The game is a mash up of two styles: Dance Dance Revolution and Mastermind. Players must find the correct combination of dance moves to please the elder god, alternately inputting guesses and watching the dancers to get feedback on their guess. It is a game of memory, ritual and watching cute characters get smooshed.
My wonderful team mate Joel beat me to the write up of the game, so I thought that for my blog post on the topic I’d focus a little more on the concept of our game and how we tried to make it fit into the jam’s theme of ritual.
The ideas forming stage is perhaps the best part of any game jam. The freedom to create ANYTHING you want, no constraints, just a spark of inspiration and a notepad soaked with ink. It’s easy to dream big, run with ideas as they come and discard them just as quickly. For me, the creative process is one of subtraction, not addition, so starting with big ideas and then refining is my favourite way to design. This jam has a theme, however. The theme of ritual.
We discussed many forms of ritual, from voodoo ceremony to superstition. I even drew this venn diagram to argue how closely linked superstition and ritual are!
The key ideas that we returned to over the course of our discussion were those of repetition and consequence. We talked about how ideas can be passed from person to person, through social compliance and tradition. We realised that this would be a great way to represent the theme in gameplay, a ritual being passed down and iterated upon. Originally esoteric comments and suggestions got condensed into more solid sounding gameplay mechanics until we realized that we’d just designed Mastermind.
The other thread that the ideas stage revolved around was that of ritual dance. Making a dancing game would be really cool, following the instructions of the ritual. Sticking these ideas together, a dance game where you must find the correct dance through deduction, was the idea that won the day. Perform a dance and then get feedback: ritual appears in the gameplay as players repeat moves (e.g. move 4 is always →). Rituals also spread amongst the players when played in multiplayer — as players copy each other, rituals are formed.
An early concept for the game had the dance and feedback given in real time, with moves having to be input on the beat, but this idea was still slightly nebulous. Condensing ideas to the scope of a weekend jam, compromises had to be made! With such a short amount of time to test gameplay and with player attention so short (assuming an audience of people browsing the jam website), the clearer we could make the game, the better. Likewise went our idea for a cooperative win condition where local players must decipher and pass the ritual amongst their group to please the Elder God, the game ending with all the dancers performing in sync.
I’m really proud of the game we made, which only works because of Joel and only looks awesome because of Jules and Kylie, so check those guys out. Making it in a weekend too, I couldn’t be happier!
This blog contains some thoughts about about mood and tone. In games, I’m arguing that mood is mostly created by design, whilst tone is created by art. Both have to be interpreted by a player.
For me, RememBear is mostly about mood. The feeling of being in a forest, the feeling of being creeped up on, and the reaction of being attacked. Panic.
The creeping feeling is perhaps the most important. Like creepy old fairytales that seem so sweet but quickly become so sinister. This is the mood that takes the lead.
Faye Simms drew RememBear and had to carry this mood across to tone. She got this spot on. Take a look at her work in action, and then we’ll have a look at how the bears came into being!
To look at the mood to tone journey, let’s take a few steps back and look at the early ptototype. The mood of the game comes through, even with coder art. You probably won’t get the from a screenshot. The game already has a creeping mood, but the antagonist is only menacing after I’ve told the player that they are being hunted by a bear. The tone is pretty much up to the player’s own fantasy.
The mechanic was there, and the feeling of creeping panic came as the game progressed. Adding the art, giving a form to the bears, defining the terror, is what brings the game to life.
Faye sent some early sketches to get a feel for the kind of bears I wanted. The bear needed to look cute and cuddly, but have a vicious side too. The transformation is important to the tone and it reinforces the mood.
Moving from cute and cuddly to big and imposing…
This shape shifting creature fits the mood perfectly. The contrast in the shape outlines is superb. The noses keep the continuity but the creature has transformed. The mood of RememBear is of sweet characters turning sinister. Uncertainty. Fear. Panic.
The tone of these characters matches that.
I’m speaking in general terms, of course. Mood can be set by elements of design outside of the mechanics, but the tone has to come from the art or audio – from the actual assets. This is part of creating a good ‘game feel’, identifying your mood and making sure the tone you are setting fits. I know I’ve made mistakes with this in the past and I’m sure you have too, if you’re honest. I encourage you to look over your project and check that everything – everything is building towards the correct mood.
As someone with a background in audio for games, SFX were always going to be an important part of RememBear. Audio for mobile games needs to be chosen carefully so as to not be intrusive, since players may be running background audio from other apps. Audio should not be vital to gameplay as many players will not have their device’s volume turned on.
With this in mind, the audio in RememBear is quite minimal, but, I hope, very effective. I’m going to have a quick look at how the SFX were put together, but in the meantime please watch the gameplay trailer to familiarise yourself with the soundscape:
With the visual art style I was trying to juxtapose the cute, cartoon, fairytale illustration with the bloody gruesomeness of being eaten by a bear. This is reflected in the sound palette too – the childish xylophone jingles clash with the fierce bear roars and blood splats. I’m going to talk about how the sounds were made and why I chose them.
The game opens into background ambience, some quiet birdsong. I wanted to set the player in a location of a forest and have set a slightly silly tone. I recorded the birdsong myself, using a whistle bought from this man. The whistles used in the game are the few successful takes from about 15 minutes of recording time!
The next sound is a rising semitone xylophone pattern, in the style of the opening music. It is a playful, childlike phrase and it mimics the animation of the approaching bears. Three seconds later it plays again, a semitone higher, as the bears get closer and the game gets harder.
This is the main audio in the game. It is useful, since it indicates where turns have ended, but it is not essential. It is hopefully not annoying either, being tied to the animation and level progression. I hope that users will want to play with it active, but I included the option to mute sfx since I can’t assume the user’s sole attention when playing on a mobile phone.
If the player is doing well, the next sound they will hear is the ‘tinkle’ of the ‘ranger awarded’ sfx. This is accompanied with a little icon flash to show that a ‘good thing’ has happened. The sound fits in place with the game, coming from the same xylophone source.
Most likely, before too long, the player will make an error and a ranger will be eaten by a bear. The audio for this is made up of a few layers, firstly the ROAR of a hungry bear.
How to record a bear roar? What do bears even sound like?
Terrifying. I needed a short sound with a quick attack, a quick impact to shock the player and let them know they’ve done something wrong. To recreate this sound, I snorted into a microphone and applied a layer of overdrive to the bass. This is in stark contrast to the other, more playful sounds in the game.
Another layer in this sound is the ranger screaming. This is mildly amusing (as the bloody visual effects are) but can be disturbing. I also added the sound of a fruit salad being destroyed, to represent the sound of blood and guts flying about the place. This adds a level of comedic violence or gruesomeness. I hope the player’s mind translates this into something disgusting. Audio is a wonderful tool to enhance a player’s imagination.
The final sound you’re likely to hear is that of the children being eaten. This is the same as the rangers, only the screams are of a boy and a girl and are pitch shifted up in order to sound like cartoon children. A final musical cadence refers back to the theme music and rounds off the experience nicely.
This covers all of the SFX in RememBear. There is not much to it, but it is all focused and functional. I hope you enjoy playing once it is released and let me know what you think of my bear roars!
Remember RememBear, the third of SeptemBear!
The new gameplay video shows the game in action – see if you can spot where I went wrong!