Tag Archives: Game

A Zine in Design Research

Restricted Parlour Games Zine PDF

I recently created a zine containing six games for part of the London Design Festival 2016. The zine forms part of the Design Research exhibition at London College of Communication.

The games explore specific rule types visible in parlour games, board games and card games. This rule types are choice, randomness and interaction which are found in varying combinations in most rule books.

Choices give players control over the navigation of a game’s possibility space. By selecting which state to move to next, the player governs play, they are in charge.

Randomness in games removes control from the players. By moving through the game’s probability space in unknown ways, unexpected situations can occur.

Interaction in games draws the players together into a shared experience. By interacting with each other the players navigate the possibility space together, pushing and pulling on each other changing the outcomes for everyone.

Each of these six games was designed to only use rules of one these three forms. The desire was to see what pure rule type games would look like and what the functions of these rule types are.

Each game is short both in rule length and play time and are presented with images of the components required to play the game.

Here is the conclusion drawn from the zine:

By isolating each of the three core aspects of parlour, board, and card games and creating short games it was possible to gain deeper understanding of choice, randomness and interaction and their potential uses when combined.

In the first two games, Race Track and Letter Spaghetti, only choice aspects were utilised. With the absence of randomness and interaction between players, it was only possible to create solitaire style experiences that functioned like puzzles. The weakness in this type of game is that once an optimal solution is found the game stops being engaging.

Both Lucky Chef and The Longest Cow utilised only randomness. Games like this take the control from the player but do provide a sense of surprise or mystery, which has potential to create interesting unforeseen events. The issue is the lack of agency given to the player that without careful foresight could create a shallow experience.

Finally two interaction only games are included, Hear Say and Tower. When interaction is used by itself there is no deviation occurring, creating a feeling of a well rehearsed theatrical play. There is a sense of action moving throughout the players, each player committing their own performance.

If you would like to read the zine in full you can download the PDF.

I would like to expand this process of creating games to explore specific themes found in rules to create a greater understanding of how it is that game rules functions and the effects that they can have on the player.


Restricted Parlour Games Zine PDF


Making a puzzle game: ORDER


Play ORDER here.

Playing with Polygons

ORDER was born from a little experiment in manipulating polygons in Unity. I wanted to see how I could create coded animations which would allow a polygon to change its number of sides.


Initially, I created a polygon with multiple triangle meshes that created a spoke effect. I could manipulate the length of each polygon to change the polygons shape. I then created a little piece of code which checked if each of these spokes was the same length as the boundary of the desired shape. This worked ok, the animation between shapes didn’t look very nice (especially between triangle and square), there was some edge detection problems, and when a number of shapes were manipulated at the same time, the frame rate severely dropped.

So in order to reduce the stress on the frame rate, I had to simplify the system.


The best thing I could do was reduce the number of triangles to that equal to the number of sides. Although there are possibly even more efficient ways of doing this, this would likely work for my process.

All ‘unused’ triangles, were bunched together to create a ‘line’, therefore creating the appearance of different sized polygons. The initial limitations of this system is that it could only be used to create regular polygons.

For the animation of the points I used half a sin wave, the rate of change is roughly slow-fast-slow.

Making the Game

I knew I had two things that I could do with the polygons, I could change their number of sides and I could rotate them relatively easy.

Initially the first version of the game, used three sets of controls.

  1. Select the polygon that you wanted.
  2. Change the number of sides of the selected polygon.
  3. Change the rotation of the selected polygon.

Each action would also affect the neighbouring polygons in some manner. Either also rotating them or changing their number of sides.

The issue was very clear, this was horrible to do. It did not feel good in anyway.


I changed the control method so that changing the polygon that is selected, also manipulated that polygon and it’s neighbours. The newly selected polygon has it’s number of sides increased and the neighbours are rotated. This felt better, but was a lot to visually take in. This reduced the controls to one of movement only.

I added a colour change to show which polygon is selected, a small pulse animation to the newly selected polygon, and a delayed rotation animation to give a sense of cause and effect. This definitely helped.

Beating the Game

Finally I needed a winning condition. Ideally I wanted the player to win whenever all the shapes were matching both in rotation and the number of sides. However, I was not able to prove that this was possible for all the different permutations of this. This issue, meant that I could not fairly set it as a goal.

I settled on a fixed goal of having all shapes return to triangles and all pointing down after being randomised.

The next issue, is how do you show that this is what the player needs to do.

I kept adding a range of information in different forms until I think I got it right:

  1. The starting condition of the polygons is the required position.
  2. Text tells the player that “this is ORDER.” and once randomised “return to ORDER”.
  3. Polygons in the correct position pulse, those that are not are static.
  4. A counter indicates the level of order.



I am happy how the game turned out, it was a fun experiment in Unity and did not take too long to complete. It is perhaps not the most novel of ideas, but I think it at least adds an additional level of complexity to a common grid puzzle structure (changing something changes the neighbours – return to an ordered pattern), by having two methods of manipulation and fixed selection movement between neighbouring polygons.

If you want to play ORDER you can do so here. it may require a Unity plug in to run as well as permission to run.

Argh, who am I?! – Revision and Playtest 2

I made some revisions to both the cards and rules for Argh, who am I?!

Previous Posts: Argh, who am I?! v1 rulesMaking of, Playtest 1.


Changing the Card List

The card list has been expanded and changed from all Hollywood monsters:

  • Frankenstein’s Monster
  • Mummy
  • Skeleton
  • Vampire
  • Werewolf
  • Fish Person
  • Zombie
  • Ghost

To a range of people/things:

  • Alien
  • Robot
  • Pirate
  • Ninja
  • Cowboy
  • Demon
  • Angel
  • Zombie
  • Vampire
  • Werewolf
  • Santa Clause
  • Tooth Fairy
  • Easter Bunny

This should now allow the players to narrow down their potential character card in a larger range of ways, similar to 20 Questions.

Changing the Rules

The first set of rules I wanted to change from version 1 of the game, was the question and statement section. The answering back and forth was messy.

The main issue I was trying to avoid with the original rules was that as soon as the players realise that one player is telling the truth (or lies) they become the most reliable source and there is no reason to ever ask anyone else a question. By giving the player who is asked a question some power, it reduces the chance of this happening. In changing this aspect I did not want to lose the freedom of the players to ask whoever they wanted a question.

There were a number of possible work arounds which I considered:

  1. Every player must be asked at least one question before, players can be asked another question. This at first seems a fair method however it has a downside in terms of elegance. The players will require an additional token or card to remember who has and has not been asked a question. Additionally, the first player will get to ask their choice of all other players whilst the last player will not get a choice, every round. This could be solved by skipping the first player of the previous round to change the first player for the current round. Balancing out in the end. All this adds a lot of additional components and rules for a relatively small game.
  2. Players who are asked a question get to ask the next question, and must ask someone else. Players in this case have to balance asking someone who they know is telling truth/lies with giving them the power to ask another question about their own card. In this manner the game should self balance. One issue might be that players may realise the point at which someone has worked out their own card and therefore not ask them a question again, so they cannot declare. To get round this a player could declare at any point.

Of these I selected the second option.

Changing the Setup

Another issue that needed resolving was the length of the game, which for its type was possibly too long. Also there was difficulty in knowing what the cards were in the deck, so you could work out who are or are not. A problem exacerbated by the newly increased character list.

This was solved with a simple setup rule change.

  • The entire deck of cards is shuffled.
  • Cards are laid face up, one at a time, in a grid.
  • Any time a card matching an existing grid card is found it is added to the play-deck. Therefore, mixing the matching truth and lies cards between grid and play-deck randomly.
  • Once the grid and play-deck both contain one of each character type, the play-deck is shuffled again.
  • Each player takes one card from the play-deck.
  • Players help each other orientate their cards correctly.
  • The game begins.

So, although the list of characters is longer, the actual play-deck is smaller than the original version. Additionally there is no need for reference cards for the player as setting up the game creates a grid reference for all the players. There is also now no repeating of the same characters.

Playtest 2

I took the new cards and rules to my monthly board game meet-up and played a couple of games.

The first game went ok, but there was a weakness found in the system. Once someone had identified who they were once, and therefore had the most cards, they could keep randomly guessing to diminish the deck and win with their single card.

The second game we removed this issue, if you’re wrong when you declare you are removed from the game. However if you’re the first person to declare correctly you win. This added a nice layer of tension, do you risk guessing early without all the information but with good odds, or do you risk waiting and someone else guessing first. It also reduced the playtime to a nice length for the style of game.

I did however get confused with the truth and lies, and double negatives at one point, giving a player some incorrect information.I handled it in that moment with a friendly apology, however, this is something that needs consideration in the future.

We played with a relatively large group of people and at times I noticed that some were being left out more than others, so further testing is required for different group sizes.

Once the game was reduced to two/three players the game play changed. For two players it is impossible to have the don’t question back rule.

Thanks to the Playtesters: Ricky, Robin, Patrick, Jonathon, Jazz, David & Peter.

What’s next?

  • I am going to have another look at balancing the character list, so it doesn’t swing too heavy in any sub-genre’s favour.
  • I need to test it a lot more times with different group sizes, and different deck sizes.
  • I’m interested to see if I can expand the deck, but add an additional stage to the set-up which removes a number of cards depending on how many players and how difficult the players want the game to be. This might need a little bit of math to get to a nice starting point but will be ultimately balanced in playtesting.
  • Consider testing the other rules variation with the additional tokens, to see how it feels.

Can I get the new cards?

I’m going to hold off uploading the new cards for a little while until the game has settled and I have time to do some more placeholder art rather than just text titles.

Argh! Who am I? – Playtest


Finally got round to playtesting Argh! Who am I?! this week, you can read about the making of it here. Although the general feel and mechanics of the game was good there were some issues which need improving on.

1. The playtime was a little long for the type of game it is.

This could be relatively easy to solve on it’s own, the answer would be to simply reduce the number cards in the play session. So instead of removing only 1 card at the beginning of the game, you could remove three. However, I feel there is more to this issue.

2. The fish-man was the least interesting character to talk about.

This is likely because there is less popular culture about the fish-man monster when compared to vampires, werewolves, ghosts, etc. The answer is remove it, or find a replacement. Doing this would actually help neatly with issue 1.

3. It is difficult to keep coming up with interestingly differences between the characters.

One issue might be the range of characters, in the first version of the game they are all classic monster tropes. This means all of them are already grouped by one sort of characterisation, removing the opportunity to explore. This could be resolved by increasing the number of groups in the set, i.e. sci-fi characters, fantasy characters, monsters, etc and reducing the number from each set.

4. Giving a true information, is very precise. Giving a false information is vague.

Once someone was found to be giving the true statements, players who had lying cards could abuse the imbalance of power between the two. There’s 8 characters, so the player eliminating the options through negative comments are at a distinct disadvantage. In short, the difference between having a truth card and a liar card are too great. By reconsidering the objects/characters on the card this could be improved. For example if instead of characters there were objects which were a set of binary choices:

  • Black / White
  • Round / Square
  • Edible / Non-edible


  • 8 ball – black, round, non-edible
  • slice of bread – white, square, edible

If I ask am I round, and I know if you are lying or telling the truth, then I can deduce the truth relatively easily. However, this really reduces the number of questions which are usable, and the game is significantly reduced in terms of creativity and free thinking. This idea is part way to a potential solution but not the full answer. Each character card needs similarity with some of the other cards but not with all the other cards.

Other ideas for variations

Whilst thinking about these issues I came up with a few ideas for the game that I need to consider for a little bit before making the next version. Some of them should be easy to test, just by varying the rules.

  • When you ask a question everyone else answers. Removes the need for a statement.
  • Players with liar cards, can both lie and tell the truth. Add some chance for deviance, will depend on what the items are on the cards whether or not this is suitable.
  • After a player is asked a question, they cannot be asked another question until everyone else has been asked. Removes the need to give a statement. Requires a neat way of keeping track of this.
  • Have players create their own cards, i.e. the backs follow truth and lies but the characters / items are decided by the group who play. This adds another element of creativity to the game.

The big question – what or who do I put on the cards?

The main issue I need to consider is what it is that goes on the cards in the first place. Monsters was a quick idea I had and it worked well enough for the playtest, but I feel that this is the thing that needs changing, it’s also the most time consuming thing to do, both in thinking and time spent creating cards that are nice enough to play with.

Thinking about the theme of the game might help, mechanically it’s about truth, lies and deduction, which sounds a little like a murder mystery. Perhaps you’re removing suspects, finding locations and looking for specific objects. Not sure how all this ties in with not being able to see what you’re holding, but their could be an answer somewhere.

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

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 itch.io. 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