Author: Valeria Voronkova

First of all I’ve completely rebuilt the prototype according to the alterations from the first playtest.

• 

• 

• 

I adjusted the branches, which are now clearly divided by levels. Colours are spread according to the scheme from the previous entry. I also created 2 types of final positions, which I’m going to test.

The second playtest went much better with the main mechanics established and major issues resolved. Playtest went with 2 attempts where various situations were encountered.

Attempt 1 established the following movement mechanics:

• Player can claim any current colour position on the level 

If player claims the final position of a branch (not depending which player claims most of positions on that branch), they are allowed to proceed to UP position.  

• If there is time left player can make one more bird for the UP position 
• If there is no time left and colours switched, player starts with making the bird for UP and then can continue with the current colour on the next level 

Situation 1: What if all the positions of one colour on the level are claimed? 

A skip button to the app was introduced. It helps skipping the colour till a playable one appears. 

Situation 2: What if one player proceeded to the next level, but current colour is all taken on the previous time for the second player? 

Skip colour till it’s available for both players. (Otherwise, the second player can do nothing and will have to wait from 30 to 60 seconds. The first player still has their advantage of being able to claim more positions with new colour) 

Situation 3: What do we do on level 4 (Ladder variant)?  

Level 4 consists of 2 parts: regular and “ladder”. It’s allowed to start claiming position on the ladder if all the positions on the regular part have been claimed.  Unfortunately, playtest showed that ladder variant has no sence due to small distance between players. The game has turned from strategy to quantity, so in most cases that will not make any significant defference to the amount of birds. Kt works only if the distance is major, and the first player has opportunuty to overtake the amount of positions.

What do we do on level 4 (Flower variant)? 

The challenge – be the first one to claim a colour. This is a pure speed and finger agility challenge. When colour starts, both players make a bird. Who makes it first claims the colour. The second player puts their bird (finished or not away). Same applies to all other colours. If for some reason both players fail to make a bird in the time given, colour switches and players must start anew. Previous birds are put away. Colours in the app can be skipped if necessary. Win position is claimed in the remaining time of the current colour. Again, who makes it first. 

Who wins?  

The main goal of the game is to get to the top, but it doesn’t guarantee victory. When the top position is claimed, players count their birds. The one who has more birds, i.e. positions claimed, wins. 

So after the first attempt, it became obvious that the game shifts from strategy to speed and quantity one. I don’t mind this turn as I didn’t have any strict restrictions over game genre or mechanics.

Attempt 2 

Second attempt added some more situations to resolve.

Situation 1: what if there is only 1 position of a particular colour left on the level? 

Same as for level 4. Who makes and placed the bird first, claims the position. Losing bird is put away and will not take part in the game anymore. 

Problem: If we aim for quantity, how to motivate players still do up?  

There are special UP positions that have no colour. They can function as a sub or bonus level. As long as the last colour position on the level is claimed. Players claim these 4 positions one by one. Same as for level 4. The app is still running. Player can choose whether to claim as many UP positions as possible or claim only one and continue with the current colour in the app. Timer still apples. If colour switches before the bird is finished and placed, the bird is put away and player starts anew with the new colour. (This works as a motivation because gives additional birds to the total count of a player) Even if one of the players doesn’t manage to claim any UP position, they still proceed to the next level. 

Summing up: final game goal: 

This is a game to: claim as many positions as possible by making origami birds as fast as possible. The game is suitable for developing fine motor skills (suitable for both children and adults. For children, time range can be increased – difficulty levels in the app) 

Among other issues to resolve are technical ones like I still have to improve the paper type as the ones that we’ve used are still too thick and uncomfortable to use. Might try sheets of simple coloured paper. Another technicality is how to fix the bird on its position, because they keep falling off and interrupting the game. As an idea those might be some kind of nest-like objects with hollows, which will hold the bird in place.

What’s next?

Second and 3rd playtest showed that basic mechanics are now playable and the prototype works. So I can proceed with polishing and compiling the rules as well as making a decent quality mock-up. App needs work too with design and including instruction together with a tutorial how to make an origami bird. Design and backstory also need work, even though it’s not the focus of this project.

By now I’ve developed initial rules that you can see below:

Birds table top game 

Speed duel game 

2 players 

Using: mobile app, origami paper 

Goal: be the first one to get to the top of the tree 

Description: the game requires a mobile app to play. The app switches colour, which indicates the positions players can take during a period of time. Colours shift randomly and random time in the range from 40 to 120 seconds. During this time players act simultaneously.  

Time: For the time period given players must fold a bird and/or place them in the desired position of a highlighted colour. It is allowed to take 2 strategies: 

1. Use the time period only to make as many birds as possible. In that case you can’t claim positions. The next time period will allow you only to take positions with the birds made previously  

2. Make-place-make. Make a bird and place it immediately. If there’s time left the cycle can be repeated. If time runs out before the bird is placed, it doesn’t participate in the game any more and can be put away.  

Starting position: players make a tutorial bird to acquaint themselves with the scheme and place it to any position on branch edges of level 1. This will be your starting position. 

Movement: Players can claim position of appropriate colour only next to their already placed bird (reduce time to make colours shift faster? 60 sec max) If there is same colour nearby and player gas enough time to make another bird, it is allowed to take as many positions of that colour in that way. 

Levels: There are 4 levels in the game, each of them having several stems. Level of a particular branch is defined by the position of its stem. Branch can be higher or lower, but till is counted as the level of its stem.   

The UP branches: There are special branches that can take you to the next layer. There are several of these on each level. One can claim it if: 

A) they managed to claim one of (3?) surrounding positions. Another bird is placed on the UP position and can proceed with positions of next level 

B) If all other position on the level have been claimed  

The WIN position: doesn’t have a particular colour and can be claimed if: 

1. All positions on level 4 have been claimed. The one who manages to make and place the bird first wins 

2. If a player manages to claim a sequence of position, leading to the winning position

As I’ve mentioned in the previous entries, I’m trying a bit another approach in generating rules and ideas from the current game situation (like inventing gameplay options in real time).

I could already see potential problem with the prototype: I didn’t have any plan for colour code and marked positions with colour randomly. So I didn’t know whether that will work at all.I tired to rely on the idea that colour in the app will be switching, and give time to claim appropriate amount of positions, and the game will function.

Unfortunately, almost immediately I saw that time strategies don’t work at all. Colours were too slow to switch for such type of (strategy) movement and some king of colour spread over the level must be introduced.

Very quickly I ran into an issue of defining what is a “nearby/neighbouring position”, because it’s hard to tell judging by their physical position. So since there are clear and separare branches, it’s possible to use them as a defining criterium. So a neighbouring position is any position of any colour situated on a branch. Player can claim any position on a branch per turn*.

*turn is the time period when a colour in the app is active. Players act simultaniously during a turn.

This helped me to develop further ideas to substitute the failed concept of movement and UP positions.

Initially UP position should be available when all positions on a branch have been claimed, i.e. player will be the last one to claim a position on that branch (it doesn’t depend on which of the players claimed more positions on that branch. It’s important just to be the last one). This is already an altered rule for UP positions. As you can see from the rules above, I wasn’t sure at all how that would work. Playtest showed that the new version kind of worked, but global change in colour code changed this concept one more time.

Now any position of a particular colour (shown in the app) on the level can be claimed, and gradualy players will fill up the branches. The component of strategy kind of shifted to just being attentive, when one position on a branch is left and claim it as soon as possible to continue to the next level.

Shifts in colour code:

So, quite quickly playtest showed that total randomness doesn’t contribute to game playability, so I applied a more mathematical approach. First of all, branches must have equal amount of positions what must bring equal opportunities for players to claim branches and go up.

Colours are now repeated in cyles, amount of which depends on the amount of positions on the level. Amount of positions decreases as levels go up.

Level 1: 5 positions + 1 UP equals to 4 colour cycles

Level 2: 4 pos + 1 UP equals to 3 colour cycles + 1 colour

Level 3: 3 pos + 1 UP equals to 2 colour cycles + 2 colours

Level 4: 3 pos equals to 2 colour cycles + 2 colours (alternative to level 3)

These calculations are theoretical for now, but I can predict they are workable. Of course this must be tested, what means I’ll have to rebuild the prototype with these alterations.

Playtest 2 upcoming

I’m a bit struggling with working out the strategy of defining the initial rules, so I felt the need to do some further research. Previously I defined combination theory as a possible area of research, so I took that path. First of all I must mention that is a pretty hard area of maths, especially for me, who has always had problems with it.

Nevertheless, Berlekamp’s et al (2001) extensive work in 2 volumes “Winning ways for your marhematical plays” might help me to get on track. They work out methematical strategies to win in some types of games with the use of combinatorial game theory. Thus they provide a pretty complicated methods of calculating these strategies, but there is some information I can extract to help me with my game.

In chapter 1 they define several conditions (p. 16) that a game should satisfy in order to calculate combination strategies described in the main body of the chapter. Since my game is similar to the games they’ve been analyzing (Ski-jumps, Toads-and-frogs), these might be helpful to clarify the objectives my game should focus on as well.

1. There are just 2 players – I thought about my game to be for 2-4 players, but as I was making the prototype, I realized that current amount of positions might be not enough for more than 2 players. So I will go with the 2 player option.
2. There are several, usually finitely many positions, and often a particular starting position – Positions are the core idea of my game, but I might think about a starting position. The initial idea is that players can take any position (and amount of positions) on the branches of level 1. If I introduce a starting position, random appearance of colour in the app might work as player may get advantage in the situation if there is no current colour nearby. What will second player do in case there’s no available colour near starting potition? There might be an option to use this time to make birds and the next one to take up colour positions.
3. There are clearly defined rules that specify the moves that either player can make from a given position to its options – This is the main question to resolve now – the rules.
4. Left and Right [e.g. players] move alternately in the game as a whole – already considered.
5. In the normal play convention a player unable to move loses – This is the thing highly possible to be implemented as closer to the end of the game there might be a situation, when one of the players overtakes most of positions (as their number reduces over time), the second one will not have opportunity to move any more. To resolve this issue, this ending condition might help.
6. Ending condition. The rules are such that play will always come to an end because some player will be unable to move – see above
7. Both players know what’s going on, i.e. there’s complete information – In my game players act simultaniously and openly choose positions
8. No chance moves – This condition will not be satisfied as there is an element of random from the colour app

So, these conditions gave me several good ideas: starting positon and idea to restrict movement to nearby positions of current colour, ending condition if no positions left for a player. And I worked out 2 movement strategies to test:

• option 1: players can take any position of a highlighted colour within one level
• option2: players can take a position of a highlighted colour only if there are such positions nearby from their already placed birds

Case study: Snakes and Ladders

As a quick case study I want to look at Snakes and Ladders, as my game turns out to be very similar to it. Particularly I’m interested in the “up and down” mechanics. They have a chance to get the “lift” to target goal, but at the same time threat to go down by the same chance.

As the game is very old, I began looking at variants (which there are quite many) in hope that some of them may have gameplay alterations. I even found a 3D version

But this search didn’t bring much outcomes as there were no substantial changes to gameplay.

So I came back to theoretical research where I found an interesting paper by K. M. Badruddin et. al. (2009), who were focusing on altering Snakes and Ladders, and analyzed the effectiveness of 4 types of possible strategies. They offer the following alteration: “If the roll of die leads to square i which has bottom of ladder on it, the agent is allowed either to seize opportunity or to avoid the jump and remain at the square i for some strategic reasons” (p.2) So that they add an element of strategic skill to an originally game of luck. They analyze 4 strategies: Greedy (Always jump), Avoid snakes, Optimist (avoid jump if there is a more beneficial ladder ahead), and No-jump. They have concluded that Optimist “outperforms all the other startegies” (p.4), which fully correlates with one of my initial ideas to make players decide to skip an opportunity to get a bigger benefit later. Since I’m supported by mathematical evidence now, that the strategy works, I’ll take that path of development route and work out a mechanics that will encourage players for this strategy.

But my game differs in the aspect of there are no “snakes”, which means players can’t go down. So the strategy can conscern taking up the time opportunity to take positions. Players can choose to use the whole amount of time to make birds and the next set to place them on positions of next colour. So that they will think ahead on which position otions of that paerticular colour they have. Or make less or even just one bird to quickly claim a desired position, which may block or somehow interrupt the opponent.

This arises the question of randomness of colours in the app. Randomness can bring more risk taking to this strategy, but may discourage players from taking it too often as they won’t be sure about what colour will be next. So I think order is preferable here, but I’ll try both options.

Having taken additional time for research now gives me much more understanding and some particular ideas try try out in play test. So now I’m polishing the rules and strategies to take out to test.

Sources:

Berlekamp, E.R., Elwyn, R., Conway, J. H., Guy, R. K. (1982) Winning Ways for your Mathematical Plays, Academic Press.

K. M. Badruddin, T. Yamada and T. Terano (2009) “Comparison of different decision making strategies by simulation on variant of “Snakes and Ladders Board Game”, ICCAS-SICE, pp. 5370-5375.

First of all I continued experiments with paper types. I didn’t manage to find the right type of paper yet, but for now found something to substitute. I was looking for a thin but colourful chinese paper that, I think, could be the best option. I still opt for a 6×6 cm square, because I tried the 8×8 square of a substitute paper one, which still I find too big. I was not satisfied with 80 gpsm density, so this one was 60. But it’s still not something I’m looking for. But still I managed to reduce folding time to 25 seconds. What gave me approximate minimum time for the app for 30 seconds.

I made the app as well, which is for now basically a timer with a coloured background, that will show colour of available positions for some time. For now I’ve set random time in the range from 40 seconds (I decided to increase minimum time) to 2 minutes. So that players will have time not only to fold, but to decide and place a bird. I already know a pause button is needed here just in case something happens or players need a break. I even managed to export it to Android, which is my first time ever to make a mobile app.

• 

• 

Next what I did is the physical game prototype.

• 

• 

Positions are white for now, but I’ll colour them later. I’m doing everything randomly and will alter it later after the playtest. I placed the branches quite randomly, but as long as I was finishing, I came to the conclusion, that roots of the branches should be placed in clear layers in order to identify them. But end of branches can be placed on different levels. That will bring some order and help to work out more clear rules.

While I was making it, I thought about a rule, controlling how a player can take upper positions and move up. I thought about special branches that go down from an upper level. There can be one or several from one layer to another. And to take a position on that branch, player must take a position next to it of the same colour as the special branch. As an alternative, these branches can be marked in a special way, but in this case, I’m not sure what the rule can be yet.

Also because I was making it with wire (I case I need to alter or rearrange branches easily), I had an idea that there can be a possibility for players to alter positions themselves. Special branches can be fixed, while others can be rearranged and the game can be replayed with more interest.

As for colours, I think, I’ll distribute them randomly for now and see if that works. I’m thinking the same about app. Now it’s totally random colour pops up, but it might be relevant to make them appear in a particular order in a loop, so that players know, which one will be next and will decide, what strategy to choose.

At this stage I’m almost ready for the first playtest. I’ll try a bit another approach this time and work out the rules as long as the playtest goes. I only have some basic thoughts on rules and controls, additional ones I hope to work out in the process.

I’m starting to think through the mechnics of placing and/or moving the birds along positions. For now I have 2 ideas in mind:
whith levels and random.

Option 1: levels

Branches and positions are structured to form circular levels, that have more and more reduced positions from lower levels to upper ones.
The final level has just one winning position.

Levels influence on the potential combination mechanics and here are some initial thoughts on rules points that I can see for now for this layout:

• amount of available positions reduce as players progress upwards. So the mechanics must take into account this reduction and be functional
  even with a small amount of positions.
• there must be a rule (or particular combination) that controls and allows proceeding to the upper level
• It can be possible to surround opponent’s bird and make it yours (what can lead to processing to the next level. Maybe players can form clusters
  of their birds, particular amount of which allows proceeding further. But this strategy may cause problems when the number of positions reduce. So there
  must be a way to either make opponent free a position or, again, make his birds yours, but in restricted space. Will think about that)

In general this option challenges not only agility, but strategy as well.

Option 2: No strict layering

First of all there must be a principle on when it’s allowed to claim higher positions. Idea of colour-code may be of use here and play major role.

Idea a) each “level” is marked with one colour and players can proceed to next color if all positions of the previous one are taken (UPD: the game will just turn into “fill the layer as fast as you can” with no significant challenge. I will playtest it, but even now I don’t think that will work out)

Idea b) positions are marked with different colours, and player can take a higer position of a particular clolur if all the lower ones of this colour
have been claimed. (For now I think it’s the most potentially workable idea as it simplifies the game understanding. Because it to compare it with strict layering system, the rules will be easier to master as they won’t work on particular combinations. Thus, to add some strategit thinking, but not just challenge for hands ajility, some combinations can still be introduced to allow bonuses, and players will be encouraged to place birds in particular places and orders instead of doing it randomly)

What about the app and how positions will be distributed?

I’m still sticking to the project goal that new feature (origami folding) must be the main or significant element in gameplay. So the game must be not only about taking positions otherwise origami birds can be substituted with figurines. Players must work for obtainig the units to place on positions as well. And that’s where speed of making origami takes place as a challenge. Time to make them is restricted, and,
since I chose to reduce the impact of digital element on the game, the app can still play a supportive role. Of a timer, for example.

First I thoight about turn-taking, but almost immediately rejected the idea as it will take some time to fold even an easy origami, and at the same time there must be allowed even more time to fold several and place them. So the time of waiting will have to be significant at least for a couple of minutes, what will slow down the game immensely, and the second player will get bored. So time of action must be simultanious for both players for everyone to be engajed, and it general it will make the game more challenging.

So, the app can still take up the role of positions distribution, but in a much simpler way, than I thought before. Just a timer with a colour changing screen (random or not? and show time or not? – to consider). Color is active for a set period of time, during which players must fold as many birds as they can and place them on any position of that colour they like (according to rules restrictions). When colour changes, the process starts over.

To consider:

• the win position can be neutral, and before game starts, players can agree on what colour it will take
• are players obliged to take a position during the time period? Or can they use one time to make some amount of birds and the next one to place them?

If we consider criterias of hybrid element in board games such as !!!, the app can be replaced with a simple timer and a Twister-like method to randomise colous.

What about time?

I started measuring the amount of time needed for making an origami bird. First of all it’s the queston of scheme itself. Ideally I would take one from the image, that inspired me for the project idea. But I tried it myself first without a timer, and it turned out to take too much time and hard to master. So I opted for a much simpler one, that I could memorize from 2-3rd time of folding.

I took into consideration that the first time folding will take more time and less as players master it. First forlding took me about a minute, while further ones around 40 seconds. I used ordinary printing paper and big square 21×21 cm. The simple bird scheme worked very well, so I’m keeping it.

But firstly, I knew it’s possible to shorten the time and, secondly, these birds are too big to play. So I tried a much smaller square of 6×6 cm, which game me time of around 30 seconds and a small neat bird. I’m satisfied with it, but also I can think that I can use other types of paper – softer ones – because printing paper is quite dense and struggles slightly with folding.

Like tissue or Chinese rice paper. (Which arises the question of cost for potential product, but that’s not a question to consider on this stage). Than can reduce folding time even more.

So, what am I doing next?
It’s time to make a prototype to make some playtests, if gameplay ideas will work out and what problems it may have. I can already make the app, finish experiments with types of paper and decide on the timer time (which can be random in length, but to less than the time to fold one bird, which is for now 30 seconds). Then I’ll make the tree with branches that can be altered to test both gameplay options. Till next entry! 🙂

The pitch discussion confirmed my fears over making the app the main part of the game. My idea requires to much technology that I never used or explored, and for my current coding skills that would be too much. I was advised to decide on the route to take:

• digital game with board game features (like Hitman Go)
• pure board game with minor digital elements if necessary

I will opt for the board game in that case because first of all I really want to move my focus away from digital games for some time due to academic and personal welfare reasons.

These alterations mean a slight shift in research and project objectives. In terms of research I’ll add “craft in board game mechanics” to find some relevant case studies and, maybe, get some more ideas, and “combination mechanics”, as the game will be based on strategy, claiming positions and (potentially) birds’ combinations that may have some effects on gameplay. As an addition it might be worth looking at 3D layered tabletop games as well.

So, what is novelty and experiment of my game?

• This is a craft game based on origami as the main feature of gameplay
• experimenting can take place with types of positions combination and rules for claiming positions. For example, positions can be distributed by levels or randomly. This can affect on how origami mechnics will function in the game.
• I will still kepp digital part, but reduce it significantly to timer, showing folding scheme or colour code (if any).

To summ up all the decisions for the moment:

The pitch day is coming and I have nothing else decent in mind. I got disappointed in my ideas so far, that’s why the best can do now is to continue the most developed concept – the origami craft game.

I tried to use a more familiar approach and to start with a setting or a story, which can give me hints on gameplay. I thought about a famous russian tale “An old man Mazai and hares”, where this old man was saving hares in spring, when nearby river flooded surroundings.

Hares can be origami units and the game is based on collecting as many hares as possible without drowning the boat. This could have worked as a concept, but I didn’t like that the craft technique doesn’t correspond with the setting. There’s no correlation between japanese origami and russian fairy tale. So I put this idea on hold.

Then I came back to the birds idea and tried to get it further.

Here I was thinking about sectors, one per each player, where somehow players must get to the center. (Actually even the next day after drawing that I can’t already recollect clearly, what I meant on these scheme) But the most important outcome here is that I understood that the process of creating origami doesn’t play any role here. Origami figures can be substituted with classic figurines and nothing would change. So I need to think about how to make the folding process be significant for the game. And this scheme was transformed into this:

So now it’s a duel game, where the agility in folding origami birds lets you claim more positions and move to the top faster. This is something we can work with already.

I tried to play more with narrative and to use a story about koi fish becoming a dragon.

But this required change in the core of the game which is “create as many as you can”, which contrantradicts the story a little bit. Or I just liked the bird story better, because it just gives a slight context, but is mainly about mechanics.

But still I didn’t abandon the app idea and still want to implement it somehow. What I’m thinking about is that the app being functional can take up the role of marking available positions and setting time to fold birds and claim the positions. But I have some serious fears about implementing that. Because ideally it should be augmented reality, where player can see highlited positions via phone camera. But I’ve never worked with that. That can be substituted with the 3d version of the physical tree, which can be rotated 360 degrees to reveal all posiible position. But again I’m not sure if my skills will be enough to make that. And my aim to make digital element blended with the gameplay works against me as falure to make the app means falue of the whole game. So I hope to resolve this issue during the pitch and get some advice. But for now my pitch page looks like this, which I find quite satisfactory, taking into account my previous problems with ideas.