Crocodile Cat is a game where you control a cat that has become trapped between the jaws of an infinite crocodile.
It is a reflex game where you must tap the screen before the cat reaches the jaw of the crocodile. Once you tap, the jaw moves to the location the cat was when you tapped. This makes the play area smaller with each input, so consistent skill is important to reach a high score.
The player collects power coins to open the jaws. The power coin distracts the player’s attention and encourages to make a decision: risk collecting the coin to extend the run or make a mistake and greatly increase the difficulty.
The player can unlock cats by collecting gems to spend in order to free them and use them. Each cat has a unique power: extending or increasing the chance of seeing a different power coin type. Spending gems gives cats nine lives. Buying a key from the store gives cats infinite lives.
The artwork for this title was created by Rebecca Deakin. Rebecca is an obviously talented artist and illustrator who I had the pleasure of working with back at Plug-in Media.
The last blog was about pattern design. After testing even more patterns, I found that players enjoy patterns that take the height of the screen, giving them lots of choice and targets to hit. These also allow players to focus on avoiding the jaws if they need to, whilst still collecting coins!
This is all well and good, but I decided on designing segments in this way because I wanted to take control of the game’s difficulty, something I’d have difficulty balancing if it was left to chance. Controlling the difficulty is helping me to encourage the players into a flow state, where they are given both challenge and reward over an extended play session.
I’m able to sort my coin patterns into groups and present them to the player in sequence. To allow for an enjoyable experience, I can group them into difficulty – allowing struggling players to practice on patterns that are designed to teach the game. Likewise I can offer greater rewards to players who are willing to play in a riskier style.
Currently, I’m experimenting with a game flow which presets players with two ‘easy’ segments first, to get then up to speed. Then it will present one of a group of preset ‘scenarios’ – a group of segments designed and grouped together to elicit a particular play style. Maybe you’re tempted close to danger, perhaps you have to aim for the centre of the level, maybe you have plans to follow. Completing one scenario will move you on to the next.
The next related system I hope to develop will give me more control over the presentation of these scenarios, so players are rewarded with the opportunity to relax and score big after completing a difficult segment.
The game is becoming more fun by the moment, which is great! The core concept has always tested well, but by approaching the overall flow design in this way I hope the game will be engaging for a longer time and the different ways to play will be more apparent to the player at an earlier stage.
In my last blog post, I introduced Crocodile Cat, the one touch mobile game I’ve started working on. The gameplay flow is that of an infinite high score chaser, players see how long they can last without being eaten by a crocodile.
During the game, that player collects coins. When I show the game to my friends I say “yeah, there’s floating coins to collect because why not, it’s a videogame”, but in reality the coins serve an important purpose in the gameplay – they give the player a moment-to-moment objective beyond basic survival and they offer a reward in exchange for some risk.
It’s risky to coin chase in this game, for reasons I’ll go into in a later blog post, but right now I want to talk about the design of coin trails and how they can be used to instruct, tempt and delight the player.
I started creating some coin paths for the players to follow, trails of coins to be collected in sequence. I thought that this was where the core of the game would lie. Coin paths lead the player and feel good to follow, but early play tests showed them to be too difficult for new players who haven’t yet learned how to stay alive! I realised that placing coins near the edges of the screen might be more useful to teach new players survival skills, but play tests showed that new players were even less accurate without a path to follow.
My next step was to create some ‘elbow’ patterns to teach the player. Part coin trail, part survival instruction. This worked well when I played in the editor, but as soon as a tester made a mistake, the design fell apart! My design was too prescriptive, assuming the player would play a certain way, meaning that a slight error caused the game to make very little sense. Adjusting these designs to accommodate different user behaviors resulted in designs that were difficult to ‘read’, the player would not know what to do when presented with entwining coin trails.
Through observing and testing, I realised I was wrong about what constituted a fun level. I realised that even my simple designs were too difficult, and difficult is not fun if you don’t understand your objective yet. I designed larger coin arrangements that were easier to collect at least part of, and changed their behaviour so that they always stick to the edges of the screen. I hope these are good ‘beginner’ levels: they help the player learn the controls relatively safely and offer easy rewards for performance.
These are playtesting much better, patterns being larger means that players are more likely to be on target and get a reward, and players are picking up the survival mechanic much easier as they are more naturally travelling to the edges of the screen.
Playtesting with a variety of different patterns and ideas, I’m now designing ‘difficult’ patterns that present more options to the player as to the path they want to take through the level. Fitting in with the overall game design, I need to make sure that the value of the coins is balanced with the risk involved in obtaining them, and to give the player meaningful choices through these level designs.
This level design process of playtesting and observation has helped me to really understand where the difficulty in my game truly lies, and where the fun lies too. Both of these elements are key to designing a ‘flow’ state, which is the next step in my level design task. I’ll write more about designing a flow state in a future blog post.
I was lucky enough to be part of the Develop Conference Game Jam 2017! The theme was Risky Business, since the Develop Conference is all about the business of games.
Talking the theme over with the team, we all wanted to go for a game design focussed around risk and reward – greater risks lead to greater rewards! Some of the first concepts were “Business Buckaroo”, “Tom Cruise Simulator”, and “What’s The Time Mr. Wolf?”
This last idea was the starting point for the game’s design. At one end of the level would be a threat, ‘the wolf’, and around the level would be coins – the higher value items being nearer the threat! Being closer to the wolf meant less chance to escape when it awoke!
We worked through some ideas around having the speed of player movement disturbing the wolf – perhaps the player had to creep? I was concerned how quickly we could relay this mechanic to the player, and the amount of time needed to implement a satisfying control scheme and camera for this.
I knew that that the game had to be very accessible and easy to pick up and play – the jam was being judged so we had only 3 minutes to sell it to the judges. We looked for ways to make the controls as simple as possible: ‘press A to move’ rather than full 3D movement. We quickly iterated over the idea of having a racetrack that the player travels around, to having the player move backwards when no button is pressed, as if on a bungee chord.
The other mechanic was to be awaking the wolf. We all knew we wanted to make a multiplayer game, so I suggested that this could be an opportunity to introduce a social element to the gameplay. The player can choose either to race to collect the high value coins, or they can choose to squeak and wake up the wolf if they see their friends getting close! We were all excited about the in room tensions this could cause among the players.
Finally, the control system was set down. We opted for button mashing rather than press-and-hold in order to keep the players moving, active and as engaged at possible!
This was the first game jam I attended with a 3D artist – Matt did a superb job of interpreting and animating Jules’ wonderfully colourful designs of a game of cat and mouse. Throughout the development we were frequently delighted and astonished by the quality of work they were putting out in such a small amount of time. I mean, just look at this sleeping kitty!
The jam went really smoothly although we made the error of getting a bit merry at the GI.biz party on the first night and getting to bed after sunrise. We only had a few opportunities to playtest and tweak the game feel, but I think we did a great job of balancing the systems. Jak coded a really robust system and spent the last hour of the jam cramming the control and feedback systems so full of juice his computer started leaking. Screenshake, particles, everything!
Meanwhile I was making sound effects and implementing them in the code base. I kept telling everyone how pleased I was with the musical system I implemented that mimics a Tom and Jerry creeping cartoon score as the mouse gets closer. It’s really funny and gives user feedback so that’s a win!
We all had a brilliant couple of days at the jam and need to thank David and Jo for organising, hosting and running such a brilliant event. They really made us feel welcome and were very patient and helpful when our equipment started breaking! It was great seeing our game on the big screen at the conference’s final session and we’re so grateful for our honourable mention – the judges said we had “a well designed risk mechanic and it was very polished”. We’re very happy with that!
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 a solo, hobbyist game designer I have made some dreadful games. I have made some OK games. I have seldom followed a game through to its fullest potential. I think this is because we seldom do our best work alone.
I’ll often show people my prototypes at Brighton Indies if the mood is right. So many people’s opinions and ideas have contributed to RememBear, some which have been directly added, some which have been tweaked, and others which have been ignored. In fact, the game was almost finished when someone pointed out that the design itself was broken. That was embarrassing, but this is how we learn.
More importantly than showing your game to people is working closely with others. This is the first time that I have worked a project through to release with other people (professional employment aside). It has taken me a while to realise the importance of this, which is a further embarrassment. You love your game, you think it’s ace. You’re probably not conceited enough to think it’s the best game ever, but still you don’t realise how important other people’s input is.
With that in mind, I really, really need to thank Faye for her work on RememBear. I needed someone to fill in my coder art and she did so much more – coming up with amazing ideas like the bear-mugshot for the score counter, and literally helping me think outside the box with the bear attack effects. The game would not be worth even looking at without her talent and ideas and she is awesome.
I spend a lot of time looking at the art on her website, tintreas.co.uk and I encourage you to. Also please follow her twitter and tumblr accounts.
Secondly, Joe is an amazing writer, who gave the game a voice. The tutorial text in game was a bland “press x to y” instructional text, and by rewriting it in a Drill-Sergeant Ranger character it became so much more engaging and just as instructional. He also advised and revised the tutorial design, because RememBear is a pretty difficult game to explain to someone – as easy as it is to play. Joe also helped when writing the verse for the trailer (and came up with the idea), tidying my terrible rhymes into something more sensible.
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!
My last entry was about how I created the trailer for the RememBear. This post focuses on the trailer’s music composition. If you’ve not seen the trailer yet, I’ll let you catch up below:
In my last post I talked about my storyboarding process and how I blocked out the story I wanted to tell. I approached the music composition with the same mindset, such as I could have written to the final storyboard without any video! I always talk about how important storytelling is in music, as in all art, and a videogame trailer is no exception.
We open with an establishing countryside theme, which is quickly interrupted by a sneaky, atonal bear melody. This is what the entire game is about in musical form – there is no respite from the incoming flood of bears! Since I’m using a woodwind quartet, The bear melody is in my lowest available register on the bassoon – a classic villain trope!
After building tension with a rising semitonal pattern, we switch to the Ranger’s theme, rather American sounding with it’s tuned percussion, military tone and homophonic arrangement. As the voiceover says, the player is the commander of a troop of park rangers and so a disciplined musical score reinforces this idea.
The ranger’s theme is finally interrupted by a bassoon, loudly playing its lowest note, as the bears appear to savage one of the rangers. This is intended to be a shock moment in the trailer and so the bassoon’s return is apt, and narratively this reinforces the concept of the bears interrupting the picnic. The lowest note on the bassoon is also out of key, which heightens the unpleasantness of the savaging.
Writing this score was great fun. Getting the tone right was surprisingly easy, but figuring out the clearest voicings for the different parts was occasionally tricky – I’ve not written much for woodwind quartets in the past! The instrumentation in the game’s title music was chosen to imitate Banjo-Kazooie, so I thought it best to use a similar timbre in the trailer for consistency. Creativity loves boundaries so being unable to introduce a French horn, for example, was both annoying and constructive – I hope you like the music!