Embow's Blog

[michael-embow]

Robots vs Bigger Robots - quick game design

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

A developer buddy, Cash, wanted to learn a new JavaScript framework (MobX) by building a little clicker game with it. He had a 'coin toss’ system, where you had to click a button to toss a coin. You either win or lose the toss and are awarded a point if you beat your imaginary opponent over 10 tosses.

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.

Design concerns

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:

User Interface

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.

Future implementations

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!

[michael-embow]

Crocodile Cat: Got some art in

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.

Checklist:

☑ 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.

Find more of her work at http://www.rebeccadeakin.com/

[michael-embow]

Game Flow and Control

Further thoughts on level design

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!

Game flow

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.

[michael-embow]

Level Design: Arranging Coins

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.

[michael-embow]

Introducing: Crocodile Cat

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!

[michael-embow]

Develop Jam 2017: Risky Business

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!

[michael-embow]

Bleat The Wolf

With the scary rise of populist fascist sentiment in the west, many of us are confused, scared and unsure how to act. An unusual opening line for a blog post about a game jam, but Resist Jam sought to unite game makers in a stand against fascism: to create games exploring issues around civil rights, freedom of expression and resisting the abuse of power. I wanted to contribute a game to this jam, so I asked my friends Nat, Jim, Jules and Joe if they wanted to work together on a project. We all wanted to get involved and so we formed a team! I’ve worked with these people before and this unit is my game dev dream team - we had a great time working together. One of the first things that surprised me about this game jam is that it encouraged us to discuss our political ideas and stances together as a group. I’m not sure about other countries and cultures, but on the South coast of England we don’t discuss the subject of politics in public very often. An opportunity to hear the opinions of your friends (and people overhearing in the pub) is really enlightening. Freedom of expression during a game jam brainstorm is not unusual, but the amount of learning that came from listening to other people in stage was notable. Our discussion around the game jam brief was mostly political, so we were likely to make a political game. Inspired by games like Papers Please, we were looking for a game that gave players incentive to make decisions that were against their natural political opinion, to encourage players to look at issues from another point of view. After brainstorming a few ideas, we ended up circling around the concept of playing as a politician and appealing to a crowd. Political margins are slim, and UK politics are all about appealing to the centre ground. I believe that most politicians are doing what they think is right, but they seem to contradict and betray core voters around election time, compromising their core values for populist policies. We thought that this area of politics might be fun to turn into a game, with the key question:

Will you compromise your own values to win votes?

In many ways it’s asking sympathy for the Devil, encouraging the player to empathise with a politician. Still, we hoped that by encouraging players to consider what politicians phrase as “difficult choices”, we’d encourage our players to me more aware of the pressures that underpin the nature of our democracy. The first design of this game saw players operating sliders to adjust their policy, then broadcasting their stance to the crowd. All the characters were human at this point! A little bit like a game of mastermind, players had to tease out a policy that appealed to the broadest range of voters. This design lacked a little depth, so we came up with this idea of newspaper headlines that change the issues that the voters care about, forcing the player to adapt and respond. This essentially puts the player as a politician against the press!

Under the hood, each voter had a value from -50 to 50 as to their left and right political lean on each issue. Adjusting the sliders on our policy areas generated the lean of the player’s message. Through maths (kindly provided by Susanna) the voters moved towards the politician they agreed with most on a sliding scale. There were lots of problems with this design. Firstly, most of our voters had to be centrist in order for our ‘message’ to work, and subtle changes to policy actually had very little visual effect on the crowd. Perhaps this version was too accurate a simulation! Additionally, explaining the UI, the notion of policy, the synchronous turn taking, the cause and effect - basically the whole game - was much harder than expected. We had key policy areas and descriptions, put players never really engaged with these ideas in order to win over the crowd, so we weren’t challenging the player’s values as intended. Time to rethink the game design.

During our brainstorm session, we’d had an idea whereby the player was given a statement and then asked how they wanted to respond. We realised that interacting with policy areas in this way was powerful, and we can feed this into our existing game design. This led to the current design of the game - the player is presented with three statements, and has to choose the one they most agree with.

To make the voters more responsive, we changed the underlying mathematics so that they move toward the politician they agree with on the most amount of issues. There are 5 issues in the game, so if a voter agrees with the player on at least three issues, they will be on their side. This solved most of the problems, but the voters were still moving around with some mystery. The player was just clicking issues and seeing a response - we wanted to challenge how willing they are to trade their beliefs for political gain. Allowing the player a little peek under the hood, telling them “55% of voters will agree with this”, lets them see how their choice might affect the game and makes them consider how strongly they believe in it. The newspapers were kept in this design to mix up the voter profiles and force the player to respond to the changing whims of the crowd. These flip the opinions of a random set of voters on a certain issue - changing the public support for an issue. At this point, the game still featured some nebulous concept of a political debate - there were voters, campaigners, newspapers… but no setting. We wanted an English feel to the game, so decided upon a village fete: a right wing speaker pitches up and you have to present alternative arguments. Upon seeing the field designed, we asked “What if the voters are literal sheep?” This gave us a unique setting for our political argument, and a name - “Bleat the Wolf”. Having a farmyard theme meant we were ready to pin down our policy areas and ask Joe, our writer, to come up with some specific policies to challenge our players! Joe did a great job creating a mix of farrmyard puns, references and policies that make sense on the farmyard but have a place in the real world too. This made the game lighthearted and fun to play, but still fulfilled the aim of questioning the player’s political beliefs.

The final touches were added in pretty UI, animations, music and SFX. I wrote a function that causes the sheep to baa() every 4 seconds (I’m pretty happy about it) and we were ready to submit! Everyone on the team worked really hard on the project. It was an intense time, putting long evenings into game dev after our day jobs making games. Working again with Nat, Jules, Joe and Jim, I was reminded how lucky I am to work with such talent, and what it takes to make a game in such a short space of time. Please give the game a go! It’s not perfect, such is the nature of jam games, but it achieves what we set out to do. For this reason, I am incredibly proud of the work we put in together. In case you're looking to hire me, please can I highlight the two main imperfections of the game. 1) You really need to invest time to read all the cards before you make a decision, but the time limit is too short. The time limit was added to make you feel under pressure, like a politician, but it's too much. 2) The newspapers appear at random times, rather than between rounds, and dismiss all the cards played in the round, often disappointing the player. We also don't make it clear enough as to what causes newspapers to appear because we ran out of time to get the animation in. Game jams, eh? Press here to play!

[michael-embow]

RememBear goes free

Somebody's got a birthday coming up and wants you all to party! (It's me). 

When I released RememBear last autumn, it was after quite a lot of hard work. I'm not usually a computer programmer, so creating and releasing my own game was a big deal! I was mostly shocked at how much work went into contacting the press and promoting the game around launch. First time developers: you can only underestimate this. 

Sales and interest in the game have tailed - as is to be expected with the masses of competition and tiny marketing budget! Also it's my birthday and I want to do something nice for all of you. 

So as of Friday, RememBear will be free to download wherever it is available. No ads (why would I spoil Faye’s gorgeous artwork?) no IAP, just a gift from me to you. 

Thank you all for your support on my game dev journey, double thank you if that support translates to a sales figure on my spreadsheet, and I'd love to buy you a beer some time! 

My birthday is on the 18th of April, so if you want to send me a birthday message, my Twitter is @Mikey_PB and I’d love to hear from you!

iOS link

Android link

[michael-embow]

Dances With The Elder Gods: Global Game Jam

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 that my team made was called Dances With The Elder Gods. Take a look through the link or watch this gif! 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!

I drew this Venn diagram to help explain my idea #GGJ16 (fao @TheMightyGit) pic.twitter.com/ibOkoZSmX8

— Michael Bowerman (@Mikey_PB) January 30, 2016

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! See you at the next jam!

[michael-embow]

Pun Driven Game Design: Witchgarden Leafiosa

Time for another installment of my oft-hastily written blog on game design / puns. This time we focus on a Ludum Dare entry with a pun which made me chuckle. This season’s game jam was focussed on growing, and Witchgarden Leafiosa is a game in which you play as a witch in a garden and make things grow. It has gorgeous art from Faye Simms (who you may remember drew 2015’s smash hit game RememBear), a lush chillout soundtrack, and a cool bit of game design! Play it through the link below! Witchgarden Leafiosa But enough about the game, what about the pun? I think this is a near perfect pun. You’re a witch, in a garden… what do witches use? Spells! Boom! And just when you thought it couldn’t get any better we throw a leaf in there too. Superb. ./applaud. If you made a game for LD34, this surely is worthy of your votes! If not, it is certainly worthy of your time. The Witchgarden is a nice place to explore whilst you attempt to craft potions and it’s incredible to think it was made in just 3 days. Arbitrary scores inbound. Game: 8/10 Pun: 8/10 Pun Implementation: 9/10

[theguide2life]

What advice do you have for dealing with computers and IT people?

Are we talking IT helpdesk? As in your tech has stopped working? If so, always begin the phone call with ‘I’ve turned it off and on’ so what else can you advise? Whilst they mull over your problem, make helicopter noises down the phone and ask how they got into the exciting world of computers. Believe me, they’ll be so eager to get you off the phone that your IT/computer query will be bumped to the front of the queue.

[michael-embow]

Pun Driven Game Design: Square Rave

Time for another installment of my infrequent blog on pun driven game design. This time I turn the focus to Square Rave, an absolutely superb music game with a very punny title! For those who don’t know, Square Rave is a game in which you must drag your finger across different coloured squares, and make sure your finger is in a blue square at the end of each bar of music. Sounds easy, but of course there is a twist in that you drop red squares behind you which block your path. Uhm… take a look:

So it’s a bit like Chime and a bit like Snake but not very much like either. It’s its own thing, and it is superb! Enough about that, what about the pun? Well, Square Rave is a game that contains squares, dance music and square waves, so it’s pretty descriptive. The title of the game does not disclose the gameplay concept, but the user knows they are in for a music led square-party! I asked, and this game’s was not completely driven by pun, though it’s art style and musical direction has clearly benefitted from it! The game is great pun and you can nab yourself a copy here (iOS) Time for some arbitrary scores: Game: 9/10 Pun: 9/10 Pun implementation: 7/10

[michael-embow]

Pun Driven Design: Cat-a-pult

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: Android iOS 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. Game: 8/10 Pun: 9/10 Pun Implementation: 2.5/10

[michael-embow]

My favourite thing written about RememBear so far:

Children picnic Bears in the park There is death A haiku by theguide2life

[michael-embow]

The origins of RememBear are lost in mystery. They are happy that way, such as bears can be happily lost in a forest. Just like bears, the origins of the game can occasionally be spotted, examined, and remembered long enough for a blog post to be written on them. I make quite a lot of game prototypes. Game design is my hobby, and so being bogged down with one idea for too long will make me cranky and fidgety. I am not unique. Like most developers, I have a folder full of prototypes that either didn’t work, required too much balancing, or were clearly just a reheash of 1987’s Skull Warriors 3. RememBear was just one of the projects which I was working on during my daily commute, but it had something that my other games didn’t have. A fantastic name. I’m proud of so many aspects of RememBear, but perhaps my favourite thing is still the name. RememBear. It tells you what to do, and what the game is called, and it’s a pun. If I were to take any game further, it would be this one. RememBear is out today. I wonder whether it would have gotten this far if it wasn’t for the name. Around the same time I’ve been working on a tappy shooty thing, a pressy holdy thing and a game about a cat in a bubble floating inside the jaws of an infinite crocodile. I don’t have any great names for these, and I don’t see them coming to the app store any time soon. Carrying a game through to release is a huge task. No, I mean HUGE. Motivation and discipline are attitudes that can be held with a tenuous grasp. Sometimes you need a unique idea. Sometimes you need some beautiful art. It seems all I need a really good pun. RememBear is out today on iOS and Android

[michael-embow]

Aww haha no problem! When the game is live on the app store I'll post about it a load more! Looking forward to it x

TOMORROW! AHHHHH!

[michael-embow]

Mood and Tone in RememBear

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.