Category Archives: Practice

Making: Argh, who am I?! – A game of truth, lies and deduction


Argh Who Am?! Print and Play.pdf

I’ve had an idea floating round my head for a while, being a fan of Werewolf and other hidden role games, and having at that point recently played Hanabi by Antoine Bauza (@Toinito) I wanted to make a hidden role game but where the players are aware of everyone else’s role but not their own.

The only other game I’ve seen look at this is Pair of Ducks by Tuesday Knight Games (@TuesKnightGames), the creators behind the fantastic Two Rooms and Boom. In Pair of Ducks each role that the players can see changes how they play, whether they answer ‘yes or no’ questions silently, audibly, truthfully or with lies.

I wanted to avoid covering the same ground so I put the game on the back burner for a while. This was probably about a year or two a go.

Over the last couple of weeks, the idea bubbled up to the top of my mind again and I started mulling it over once more.

For a game like this it seemed to me that the players would need to deduce who they were. The major question in designing the game, is what mechanisms are in place for them to do this. I had a number of thoughts/concepts I was puzzling over.

  • Have pairs of roles, and they need to work out who their partner is.
  • You win if you are the only person who is alone, i.e. no one else has the same role card as you.
  • Certain roles can perform certain actions, other players can stop you from attempting actions that you cannot perform.
  • Having to ask players to perform actions that only they can do.

Taking some influence from Coup by Rikki Tahta I started to think about the passing of tokens, and certain roles being able to do certain things. Players would balance moving tokens around as they needed with giving other players information about their character. So, what could the players do with tokens:

  • Take a token from someone.
  • Give a token to someone.
  • Take a token from a shared pool.
  • Give a token to a shared pool.
  • Swap two piles of tokens.

The thought being at this point, that not only would you need to work out what role you are/if you’re alone/in a pair, you would also need to meet certain conditions, like have the more than/less than/equal number of tokens than another player.

The problem with all of this was the amount of complication and all the information the players would have to deal with, they would need to know which characters could do which actions, without actually knowing the character they currently are. It just all seemed too much. I needed to simplify things.

I still liked the idea of having two of each role, and felt this needed more exploring. Then I was hit with a thought, what if one of each of the pairs had to tell the truth and the other had to lie. Things then started coming together.

Players would ask questions about their character of another player and they would respond truthfully or not depending on the card they had, information that could be shown by text on the back of the playing cards like this:

The issue with this rule alone is that, as soon as you have determined that a player is telling the truth all players would ask that player question rather than anyone else. There needed to be some sort of price for asking a question, something that would stop this happening.

The solution was to have those players give the player they ask some information about their card. In this situation, if everyone keeps asking the same person questions they will get more and more information about their card, giving them a big advantage, which you would want to avoid.

After a little more work and thought, here it is:


Argh Who Am?! Print and Play.pdf

How to Look at Your Card

In this game of truth, lies and deduction you do not see the Monster on your own card, but you can see the Monster on everyone else’s.

  • There is both a truth and a lies card for each of the eight Monsters. By orientating your Monster portrait correctly, the text on the back of your card will show you which of the two you have.
  • If your card is a truth card then you must tell the truth during the Exchange phase, if it is a lies card you must lie during the Exchange phase.


  • Shuffle all the Monster Cards together.
  • Deal one card to each player and one card face down into a discard pile.
  • Place the remaining cards face down where everyone can reach them, this is the stack.
  • Hold your card so everyone but you can see the Monster you are.
  • Help everyone orientate their Monster portrait correctly.


Starting with the player explaining the rules, then continuing clockwise, players take turns to either Exchange or Declare.

Exchange has two stages, statement and query, both which must be done with players telling truth or lies depending on their current card.

  • Statement: Tell another player something about their Monster.
  • Query: Then ask the same player a question related to your Monster that they will answer with either a “yes” or a “no”. You cannot directly ask if you are a specific Monster.

– or –

Declare, state the Monster you believe yourself to be, then place the card face up in front of yourself:

  • If correct keep the card in a pile in front of you.
  • If wrong place the card in the discard pile.

Then take another card from the stack.

End of the Game

Continue taking turns until a player attempts to take a card from the stack but cannot because the stack is empty.

Count how many cards you have correctly identified, the player with the most cards wins.

At the moment the cards have classic monsters on them (and very basic art), but that may change with playtesting, in theory they could be any thing which gives a lot of options for making custom decks for different player preferences. Here are snapshots of the font and backs of some of the cards.

If the game goes well, I’ll look into producing some better art work for it. If you manage to play it or have any thoughts or suggestions please let me know.

I think the game will work with between 3-10 players, but this needs further testing to see if this is true.

Argh Who Am?! Print and Play.pdf


Nineworld’s Roleplay Game Jam

Final Chase of Winter’s Wolves

A pack of wolves rest in their den, tired and hungry the winter has been cruel to them. Outside is the wilderness, cruel and relentless but filled with memories of times they have shared. At deaths door they need to have a successful hunt to get through the rest of winter. Nostrils widen, ears twitch and hairs bristle on the back of their necks. The scent of prey is in the air, all or nothing, they make their way out of the den.

Final rules here: Final Chase of Winter’s Wolves


Earlier this month I attended the Nineworld’s (@London_Geekfest) Convention in London. It was a fantastic event filled with really interesting talks and activities, it was also a incredibly friendly and considerate place to be.

At the event, I attended a Roleplay Game Jam which was run by Ben Meredith (@BenRLMeredith) and Tom Hatfield (@WordMercenary). Each participant was given two words/concepts and asked to make a roleplay game in the theme of wilderness.

The two concepts I got to work with were Blizzard and Wild Animals. With the approximately two hours we were given I was quite pleased with what I developed. Here are the original hand written notes.



I’ve only had chance to write up the notes fully, and in doing so I have made a few changes. So instead of the wolves finding their way home, they are adventuring out. I changed the location card variables to follow heart, club, spade, diamond to keep them in keeping with the other two parts. There were a couple of other minor changes and I tried to improve the explanations in the rules to make them clearer. Finally I settled on the title and added a little pre-ramble to set the scene.

If you would like to read the rules in full they are available here: Final Chase of Winter’s Wolves

Dwolma – Feedback and Update

Screen Shot 2015-07-12 at 12.56.06

I got my reviews for Dwolma (original post), my GameChef entry today.

Review 1:

Overall, it’s a very interesting concept…I can see if going in multiple ways: creepy-ish, psychological and/or hypnotizing. I’m not really sure how the tokens works, but I could just be reading that wrong. Are the Ushers taking tokens randomly? Are the ushers taking certain numbers of token to manipulate the outcome? I’m not saying that the token should be changed (at this point) , I’m not really sure if it’s fully explained. Which I think is important because that’s really the deciding point of if the subject is moving forward past obstacles.

Review 2:

I really like this game. The structure is great, and the design of how the Abandoned is fleshed out as the game progresses is fantastic. Some minor flavor things are nice too- I appreciated “willing” players.

I feel that the mechanic of Bēodan needs some fleshing out. An example of play is definitely needed! I’m also confused as to the point of the tokens. What’s the goal of the Ushers? Is it to guide the Abandoned past the obstacle, or prevent them from moving on?

Review 3:

Dwolma is an imaginative game that makes good use of the ingredients.

I particularly like the blindfolding aspect, which adds a unique dimension to the game. The bidding mechanic works well and breaks up the game phases nicely.

I would have liked to see a way for the Abandoned to fail as this would have added a dimension of tension to the game, but overall this is a well done, if surreal, storytelling game.

Review 4:

There is something surreal and mysterious about this game. A solid entry that addresses the criteria of the contest in an interesting way. I’d like to see a bit more competition between the ushers who guide the ‘Abandoned’, or even a way for the ‘Abandoned’ to completely fail rather than simply getting more chances to succeed until they finally get through…which basically destroys the tension of the whole thing.

An extended review for Dwolma by Michael Wenman is available here.

Thanks to this insightful feedback, I’ve made a few tweaks to try and clarify the rules for the game.

The updated version of the rules for Dwolma.

Game Chef 2015 Entry – Dwolma


Game Chef (@game_chef) is an annual Game Design Competition which started running in 2002. Entrants have 9 days to use at least two of four ingredients to create a game around a given theme.

This year the theme was A Different Audience, and the ingredients were abandon, dragonfly, stillness and dream

I was particularly taken with the ingredients abandon and dream and at looking to find a way that different players of the game could be considered different audiences. The answer to this was to have some of the players fight over narrative control for the game, attempting to meet specific moods.

I was also interested with heightening the experience for at least one of the players. I have often found when I play story or role-play games I often close my eyes to imagine in detail my surrounding and what is happening. By forcing one of the players to wear a blindfold and have the other players describing the world to them, that player could potentially have a much richer experience.

Bringing these ideas together after some helpful discussions with Adam (@adtidixon) and Sean (@seanFsmith) I finally settled on the mechanics and theme for the game.

Somewhere between here and there lies the Dwolma, a dream world filled with abandoned souls seeking their escape. Blind to the incomprehensible world around them the Abandoned have little hope. 

A few of the first to be lost in Dwolma have found ways to understand and manipulate the world around them, they are known as Ushers. As the Ushers are cursed to be trapped in Dwolma forever, they seek pleasure in playing with the souls of the newly abandoned.

Ushers will often play Bēodan, a bidding game, and make wagers with each other, attempting to elicit moods from any Abandoned that they find. Appearing to act as guides they will attempt to influence the Abandoned’s mood to create a story to their individual taste, each Usher a different audience to the Abandoned’s misfortune.

The full rules are available as pdf here.



Play Optisocubes

I’ve just finished (or at least made publicly available) my next game, optisocubes.

This idea started when I saw a sticker on a friend’s skateboard, it was an optical illusion where two isometric cubes drawn on top of each other can appear to be both solid and hollow. It looked a little like this:


From there I started playing with drawing simple isometric shapes, and trying to get a cube to rotate and animate.

As you can see my first efforts where not perfect. The cube appears to distort and change shape when it rotates.

After reading up a little more on isometric game art and having another think about how I handled my shapes, I managed to improve the rotation some more and started on the between level animations.

From here it was a matter of designing the levels and making tweaks.

Early feedback I got from Zhan (@ZhanCat) helped me balance the early levels, really slowing them down to ease players into the control scheme and the methods for solving the puzzles.

I got some really useful control feedback from Aubrey (@HilariousCow) . You’ll notice if you tap the movement button the cube will rotate back to its starting position. This allows the player the change their mind if they press the wrong button.

I took the game to a London Indie Pub meet, where a few people gave the game a go. I think I’ve definitely found it’s not for everyone. Some people can’t see their way around the optical illusion as well as others. This was even with the additional gradients I added to give a greater perception of depth:

I really go bugged down designing the levels. My method was to generate random patterns and then try to move round the cubes in interesting ways. Once I got them to a specific point, I then put the targets there and attempted to level again to see how difficult it was.

Having to go over the levels again and again to test them was not the most exciting, but it’s interesting to see that there are still a couple of the later levels that I have to re-workout how to solve.

The final piece of feedback I implemented was allowing the game to keep track of the players progress. This means that players can leave the game and come back without feeling they have to do everything all over again.

If you do try it, let me know, I’d love to hear some feedback. Also if you manage to finish it send me a screen shot, I’m interested to see how many moves it takes.

Play the game here.

Tweet #optisocubes

Making Bright:Night:Kite:Fight

To start, if you want to play Bright:Night:Kite:Fight as it currently stands, you can do so here, but I’d advise grabbing some friends to do so first, as it’s a local multiplayer game.


A Little Seed

A couple of weeks ago my partner phoned to tell me amongst other things that she had bought a stunt kite. I immediately felt jealous that I was not there to fly it with her. I had to do the next best thing and make a game about flying kites. So that was the seed of this idea.

It was quite late and I decided to break my current rule about working on more than one digital game at a time, staying up till the early hours to get the basic turning mechanics sorted. If you look carefully when the kite rotates it does so around the outer corners, as if the kite is controlled by two strings.

That Problem

One huge issue I came across was trying to get the swooping effect of the kites flying. I spent about 5 hours trying different iterations of, gravity, velocity, drag, wind speed, kinetic energy, potential energy all to no avail. Nothing felt right. It was not until I simplified what I wanted to do that the answer came to me.

As the kite swoops down it gains velocity, as it goes up it loses velocity. The simple and elegant solution was to make velocity directly related to the current height of the kite. Hours of complex physics thinking and multiple lines of code all disappear into a single line of code:

magVel = 1-((canvas.height – p.y)/(canvas.height));

Most importantly it felt nice to swoop around.

Start of a Game

Once I had got this sorted, it was time to add the tail. It was nice watching the kite fly about and looking at the tail follow its path, gently rippling in the wind, but it was not quite a game. Unlike real kite fighting where you cut the line (as it require tension), it was better in this case to start cutting the tails of the kite. To do this required more kites, which was easy enough to add.

More of a Game

So the flying and the tail cutting mechanics were sorted but it was still a interactive play box rather than a game. This is an activity about cutting down the other players, your punishment being a smaller kite tail; your kite looks less impressive without a long tail following it.

The two easiest things to add, were time and points. Time adds a beginning and end to the game, it also allows for replay, especially with 1 minute matches. Rather than removing someone from the game completely, by death for example, all players also hopefully remain engaged. The point system I’m not 100% about but I think scoring more points based on the current length of your tail is more interesting than simply adding and losing points based on hits. I hope it works for this game anyway.

Finishing Touches

So to the finishing touches. After watching an interesting video by Mark Brown (@britishgaming) titled Secrets of Game Feel and Juice I wanted to make the impact of the kites hitting each other a little meatier. I added a very brief 50ms delay when an impact is detected in order to allow players to register it clearly. Also on an impact the stars in the background brighten in a wave outwards from the point of impact. I think these two little elements add a lot to the game in terms of how it feels to play, and improves the sensation of cutting up someone else’s kite.

(You should check out all of Mark’s Game Maker’s Toolkit videos, they’re really useful.)

Not Quite Finished Yet

Not many people have played the game yet, and there is still plenty of improvement that can be made based on feedback. When designing a multiplayer game by yourself the hardest thing is testing it.

Based on the feedback I receive on this early release I will keep improving the game until it becomes something I am truly proud of.

Until then, have a go and let me know what you think.

A big thanks to Zhan (@zhancat) for spotting a bug which meant some collisions weren’t detecting. This was due to the way I’d implemented the game world looping from left to right and having multiple kites for each player to do this. But that’s hopefully solved now. I also tightened up the controls thanks to his imput.

Making FoxStar for Jam Game


Play FoxStar

Making FoxStar

I decided to take part in one of the game jams on Jam Game – The Backwards Game Jam’s theme was really inspiring for me, take the title of an existing game and invert it to create a new title as a starting point for the game you want to create.

The first thing I did was create a short list of games and their potential inverted titles.

  • Alan Wake – Wake Alan
  • Tom Clancy’s Ghost Recon – Clancy’s Recon Ghost Tom
  • Sleeping Dogs – Dogs Sleeping
  • Watch Dogs – Dogs Watch
  • Dragon Age – Age Dragon
  • Fallout – Outfall
  • Star Fox – Fox Star

I looked to see what other people were creating to try to make sure I was not treading the same ground, and narrowed my selection to two.

Clancy’s Recon Ghost Tom – This game would involve a ghost called Tom who would use his ghost abilities to run reconnaissance missions for his friend Clancy.

FoxStar – A game involving creating constellations in the shape of fox faces.

The problem with Clancy’s Recon Ghost Tom was I was not sure what the mechanics of the game would be and exactly what it was that the Ghost Tom was searching for. FoxStar to me seemed to have a clearer player goal, and an interesting learning curve where large constellations would be easier to create but take up more space, and smaller one’s harder but take up less space. Allowing the user to potentially find more constellations.

Rough Sketches

One of the first things I had to determine was what sort of shape would I want the player to create and how would I get the system to understand if it was right or wrong. I spent a little time doodling fox faces of different shapes with different number of points to get a feeling of both what looked pleasing and would be distinguishable.


Sketching with Code

The next step was to create open sketches in code. I’ve recently been learning HTML5 and javascript so I started to implement it in that. I set up a number of parameters to determine what was a fox, to do this a had to normalise the image for each of the seven points.


The steps to normalise are:

  • Find the starting point
  • Label the points from 0-6
  • Find the centre of all seven points.
  • Find the angle between the current starting point (point [0])
  • Rotate all the points this angle around point [0], such that point [0] and the centre point are aligned vertically.

The steps to check the shape:

  • Check the tips of the ears, point [2] and point[5] are the highest two points.
  • Check point [1], [2], and [3] are on the left of the centre point and points [4], [5], and [6] are on the right.
  • Check points [3] and [4] are higher than points [1] and [6].
  • Check the proportions between points on the left are within a suitable tolerance of those on the right.
  • Check the ratio of the height of the constellation to the width of the constellation.
  • Check that the ears are not too long relative to the face.
  • Check that the ears are not too short relative to the face.
  • Check that no points from other fox faces are within this fox face.

Once I was happy with this I moved to the next step.

Moving to Stars

I randomly generated stars by giving each a random x and y coordinate within the image. The pointed for the game would snap to the nearest star and these reference points would be sent to make up the constellation as before.

I found that I had to adjust a number of the parameters for accuracy to allow for the fact that the points that would make up the constellation could not be drawn exactly as wished. This made it easier for players to create correct constellations.

Drawing the Foxes Face

To draw the foxes face I used quadratic Bezier curves using the existing points, the centre point. The dark ear patches used the tips of the ears as the centre of the curve, and the lighter cheeks used the centre point as the centre.

I decided to widen the points for the bottom of the nose so that it would have thickness rather than just ending in a line. This additional point is at 1/10th the distance between the nose point [0] and the cheeks point [1] and the same for point [6].

The eyes required additional points to be added as well. First the half-way point between the centre and the cheeks was found. Then from this new point an additional point for each eye was found by moving it 1/3rd of the way to the nose.

An Interesting Bug

Whilst testing the code I found that small constellations were still not registering as suitable constellations despite loosening the parameters. After a little searching through the code I found that it was to do with the order the points were sent to the array. If I constructed the constellation clockwise points [1], [2] and [3] would be on the left, but if I constructed it anticlockwise they would be on the right, failing one of the checks. Strangely enough this showed me when drawing large constellations I drew them clockwise and small constellations I drew anticlockwise. This is something I do not think I would have noticed if not for this bug.

Allowing for Corrections

I implemented some code that allowed existing constellations, which did not match the criteria, to be adjusted. This would allow player to learn the type of shape required. The only minor issue is that it reduces the challenge, in that even if you go wrong you can correct yourself. I am still not 100% if this was the right decision.

Issues with Frame Rate

In the initial design each point of a successfully completed constellation would be a rotating star, just like the pointer. However, as you start to draw more constellations the frame rate dropped dramatically. This is likely due to the way I drew and updated them, something which could be solve most likely, but I removed the effect to keep a reasonable from rate with a large number of foxes.

Little Touches

Once I got the mechanics for the game working reasonably and the frame rate relatively consistent, I started to add some additional touches. The title bar and the text hints at the bottom were first. This would provide hints and instructions to the player based on what they are currently doing and if necessary at which check point for the constellation they failed at.


Next I made the fox faces blink when you place the cursor over them and gave them a light spot in their eyes that followed the currently selected star. This just gave them a little more dynamism.

The final touch was to add a meteor shower when the game was reset or when a fox face constellation was successfully found.

Some After Thoughts

Whilst designing the game I considered implementing a limited time span in which the player would have to find as many constellations as possible. I decided against doing so because it would remove the experience from that of stargazing, which is not a rushed activity.

The other aspect I considered was a points system, the less corrections it took to create a suitable constellation the more points the player would receive. Again this seemed to go against the theme of stargazing.

I am unsure whether the experience lacks something because these features were not implemented, or perhaps this just is not that kind of game. Overall I am pretty pleased with how it worked out.

Play FoxStar