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!
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’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!