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!
I ended my previous post noting that I have more to say about Digital Minimalism. This is a follow up post with some more personal thoughts about the approach and a general catch-up.
Firstly, I’ve not done a brilliant job of acting in the spirit of a digital minimalist. I started on a good path but have noticed bad habits creeping back in. After unfollowing >1000 accounts, Twitter quickly worked out how keep me hooked, showing me distractions from my friends’ ‘likes’, or just random ‘popular tweets’. I’m being extra mindful of my rules and am spending another 30 days being incredibly strict with them. If my feed keeps being filled with trash, I may have to abandon the service altogether.
Secondly, I’ve recently hit a bump in my relationship with technology in the form of mobile gaming. In a surprising development, I’ve started to replace social media downtime with Clash Royale. (And other games but seriously CR is great).
This presents a potential problem for me. I create mobile games in my day job, so cutting mobile gaming out of my life altogether is not a path I want to go down. It is important for me to examine how games evolve over the course of many months. Many games now have years worth of content.
This is a symptom of a wider problem with mobile games – one I try to actively avoid in my own work. Many mobile games addict and manipulate in the same way as social media apps. As a game designer, I do not consider many of them to be nourishing, or even to be a force for good. There are many that I don’t consider to be games, merely funnels.
I want to write more about these problems, but I feel that many other commentators are much more qualified than I am and are already making brilliant points. After release, I will describe how my current project is designed to be engaging, rather than addicting.
For now, I am using this next 30 days to hiatus from all mobile games – even my favourite picross puzzles! Our development team selects one mobile game per week to play together and analyse, which is my only exception. Replacing this time with writing blog posts or focusing more on music, I hope to find new ideas from other disciplines.
Until then, I encourage you, too, to look at how you’re using technology and how technology is using your time. I’m drinking a lot more espresso and writing a lot more songs. Procrastinating just as much but with more creative outcomes.
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!
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!
I published a blog recently about pun driven game design. This started, mostly, as a joke between friends, and since then we’ve been coming up with pun-led game concepts. There are many fine developers already working in this area, and so I thought a few blog posts acknowledging their work would be a welcome addition to this blog whilst I decide which game I’m going to make next.
This post is dedicated to Cat-a-pault: Toss 8-bit kittens, the wonderful single mechanic mobile game in which you fire cats across the screen in order to stack them. You want to download it already, right? Here are some links:
The game is as simple as it sounds. Pull back on the cat to launch it, Angry Birds style, and with some skill you’ll be able to land it on the podium. Any following cat must land on the cat pile, to which it will adhere as if it’s fur were made of velcro.
The game is as tricky as it is addictive. If you’re lucky enough to reach the top of the screen without the tower falling, your game view will rise and you’ll be able to keep on building. Be warned, creating a sturdy structure on just one cat is a huge challenge!
But back to the puns. Assuming the developer started with the pun and went from there, there is one disappointment in this game. There isn’t a catapult on screen. The cats just launch themselves using an invisible force. Luckily, the game is hooky enough that you don’t care, but come on. Good puns need good follow through, and this is the one area which leaves you wanting.
I’ve decided, as is my whim, to award some arbitrary scores to this and any upcoming pun-based blogs.
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.