My goal was to make a game where people have to cooperate and that scales well with different amounts of players. To ensure cooperation, the game would feature two radically asymmetric roles: the Shooter, which can attack but dies to a single hit, and the Defender, which has no offensive capabilities, but whose shield can absorb any amount of damage. In the center of the games are the Cores which the players have to defend. Enemies come in from all around the screen and try to destroy the players and the Cores, whatever is nearest. The enemies’ projectiles are heat-seeking – they will always hit something, so without the Defenders, the Core and the Shooters will be destroyed rather sooner than later; but without the Shooters, the defenders could not destroy a single enemy.

This was a jam game done in about 12 hours and everyone around me was busy, so I there was no way I could balance it properly. I solved that dilemma by assuming the role of the game master: I would sit at the keyboard and spawn enemies.

Apart from troublesome connection problems, the game worked rather well for a jam game and the crowd loved it. Here is a video of the presentation:

The video was filmed by Iwan Gabovitch and the sound effects are from the fabulous Universal Sound Effects which I can very much recommend.

Connection problems aside, I am very content with how the mechanics worked out and I think there is a lot of potential there. I will probably revisit this prototype some day and make a proper game out of it.

Before I present the games, here is an awesome impression video from the jam. A huge thanks to the Gamestorm team for their filming and editing work!

Our first game: Dance it off!

The development of our first game started of really smooth: Juri suggested a dancing game (“I know nothing about dancing, but…”) where you get some kind of behaviour instructions and have to find your partner. After thinking of the board game Inkognito and pondering how to make partners identify themselves and what should happen if somebody wrongly thinks they found their partner, the game shifted a bit from “stealth/bluffing while finding the one partner” to just straight out “party”: Everybody gets 3 dance styles/moves (like “tango”, “picking apples” and “Michael Jackson”) and has to find their three partners as quickly as possible. The first one who achieves that wins the game!

Apart from a few hang-ups, the game worked really well. The only problem I can see is when one of the partners doesn’t know how a certain dance style looks like. This could be fixed by having a game master whose sole job is it to explain dance moves.

Developing this game teaches me once more not to give up too early. This is not a game we could test in our group of four, so I suggested we try to think in another direction instead (which resulted in the second game, so no regrets here!), but when we later had people to test it with, it turns out that it worked pretty much out of the box! The biggest thanks goes to Nina here – while we were pondering some details for the second game, she used the opportunity to playtest this one with the organizers and she singlehandedly created dozens of dance style cards.

Our second game: Slurp!

Again after a suggestion by Juri (“I know nothing about biology, but…”), our second game was roughly based on the idea of cells absorbing other cells.

At least 8 players are formed into two teams, and in each team, players are paired up. The two players in each pair hold hands, thereby forming a small circle – and then they try to enclose enemy players in it, either by throwing their arms over an enemy player or by briefly letting go of their hands and then closing them again around an opponent.

Once you caught somebody, you yell “Slurp!” and the caught enemy has to let go of their partner and stay inside your circle where they can try to hinder you by being uncooperative when moving. Caught players can be freed again when one of the enclosing players is slurped.

When one team has caught a certain amount of enemies at the same time, they win!

The rules are sometimes slightly confusing to execute in the heat of the battle and it’s not always clear who caught who first, but the ensuing chaos was still a lot of fun.

Cupcake Puppeteers

Apart from us, there were two other groups. The first one made Cupcake Pupeeteers, an improv game where players are paired into puppets and puppeteers. The puppeteers are given a scenario (for example “Hogwarts”) and characters (Harry Potter, Voldemort etc.). Then they have to play the scenario out by moving their puppets – and the puppets have to guess in which scenario they are.

It was a bit hard to direct puppets bigger than you and I feel like the game would be better with commonplace scenarios (like “in the kitchen” or “at a shop”) instead of pop culture scenarios which needed specific knowledge, but overall it was quite enjoyable for either party – “masterfully” directing somebody else on one side and trying to deduce what the heck your movements are supposed to be on the other.

YOGAme

And here comes my favourite of the evening made by yet another group: A “yoga game” with a master teacher that has transcended so far that they can freely levitate, while the players have to try to imitate the teacher as closely as possible with the help of assistants.

To make this game possible, the teacher is actually lying on the floor. They are filmed by a camera and projected on a wall to make it seem like the teacher is upright instead of lying down.

While the teacher is striking poses and the players strive to get as close as possible, a helper is going around and appoints players who are not doing well to be assistants. Those assistants help players who are still in the game. And that’s desperately needed, especially once the teacher begins “levitating”.

The last player who is still in the game wins and is the teacher for the next round.

I can’t even begin to describe how much fun this game was! The concept itself is already funny, the strange moves of the teacher quickly become absurdly hilarious and even when I dropped out and became an assistant it was equally enjoyable and satisfying to help other players. My favourite part was when the teacher gently levitated of the “floor” and started swimming – first up, and then sideways and down, a point in the game where the assistants had to work as hard as the remaining players.

All in all, this was an incredibly enjoyable Saturday and I’m really glad I participated! Thanks a lot to my team, to the organizers and the other participants!

I had a lot of fun with electronics in my last project, so I wanted to do more of that. And I still had a Touch Board that I never had time to use so far – an Arduino with capacitive sensing, which, among other things, can do this:

It worked quite well for very low ranges (<4cm), which was suitable for our purposes. At first we tried to make one crystal which players can touch from multiple directions, but players used to swirl their hands around it like it was a crystal ball and that didn’t make for very predictable controls. In the end, we settled for 5 cardboard crystals, each with only one function and aluminium foil inside. The capacitive sensing actually worked really well through the cardboard! Some crystals controlled movement, and the closer you got to them, the faster the movement got. (And not being able to see why cardboard can sense how close you get to it added a fun technological-magical aspect to the whole thing.)

Apart from that, we also wanted to have generative creatures – kind of like my Chimera Maker, but this time I also got to procedurally animate the creatures! Kailin Zhu drew them and created the crystals you see in the video and pictures below, Titouan Millet made beautiful generative cloud shaders and Peter van Haaften generative music and sounds.

Oh, and I also made the creature nest, a separate executable which showed the creatures flying away from and returning to earth, seen in the video on the monitor. It communicates with the main game via a server using the Yahoo Games Network (formerly PlayerIO). I tried to make it work with standard Unity peer-to-peer networking, but the University network didn’t like direct connections at all.

Finally, all this generativeness combined resulted in:

Magical creatures have escaped into the heavens,
and the player must sift through layers of clouds
to bring them back to the earth.

Using a set of five crystal touch/distance-sensing controllers,
the player wanders through a generative audio/visual cloud world
to catch these lost mythical beings and return them to their home.

Credits:

• Titouan Millet – Programming and generative visuals
• Kailin Zhu – Craft and illustration
• Tobias Wehrum – Programming, electronics, and generative creature engine/animation
• Peter van Haaften – Generative music and sound engine

The video footage was recorded by Mattias Graham and Tobias Wehrum.

This project was made possible through the Technoculture, Art and Games Research Center’s Critical Hit: Games Collaboratory and the support of Concordia University and Dawson College and financial contribution of the Ministère de l’Enseignement supérieur, de la Recherche, de la Science et de la Technologie.

Work in Progress and Playtest

After the brainstorming, we came up with (un)done, a story about love and break-up. Two players face each other, wearing ponchos with strings dangling from them. When they tie a string together, they hear a positive memory from the couple’s relationship, like the first date or kiss, moving in together or getting a pet. When they open a knot instead, a sad memory will play: a fight, a thing they hate about each other or just drifting apart. By players tying und untying different strings (and with the help of a little randomness), the story that unfolds is always different.

Additionally, a woven screen on which generative art is projected separates the players from an audience. The more strings are tied, the more colorful and intricate the projected art becomes; when knots are opened, the projection is slowly erased again. In the end, the projection is blank again and nothing remains but the memory of what once was there.

This project was a lot of fun and very interesting. I never made a theatrical experience before – and additionally, I wanted to learn how to deal with electronics and soldering and expand my knowledge about the Arduino. Thanks to my team and all the helpful other participants and mentors at Critical Hit that was a big success!

And now I proudly present:

Step in the shoes of a couple as they meet,
fall in love, fight, and fall apart again.

Embody a relationship as you tie and
untie yourself with the other player, in:

(un)done, an intimate non-linear audio game
made at Critical Hit 2015!

Credits:

• Amanda Tom: Writing, Sewing, Weaving
• Kara Stone: Writing, Sewing, Weaving, Sound
• Kailin Zhu: Electronics, Sewing, Weaving, Arduino Programming
• Tobias Wehrum: Electronics/Soldering, Game Programming, Generative Art
• Voice Acting by Ida Marie Toft and Jessica Rose Marcotte
• Music by Nicole Pacampara
• Font by typeSETit

This project was made possible through the Technoculture, Art and Games Research Center’s Critical Hit: Games Collaboratory and the support of Concordia University and Dawson College and financial contribution of the Ministère de l’Enseignement supérieur, de la Recherche, de la Science et de la Technologie.

Pictures of the work in progress and the final game

With 16 participants making 3 games in groups of 4, we had a lot of different approaches.

I remember:

• Communicating intent via naming the game.
• Instructing the players to move via rhythm.
• Demonstrating the game via theatrical improvisation with team members as game props.
• Singing a short song before the game begins which contains hints to how the game should be played.
• Trying to get across how the game is played by setting it up properly or having pieces whose usage should be clear.
• Leading the game by having team members interact with it, resetting the game if played improperly.
• Preparing an informative display out of props.

Some approaches were more successful, others… less. But all of them were pretty fun for both players and creators!

And now, here are the games I participated in:

Animal Jacks

Throw a stuffed hamster into the air, try to grab as many other animals as you can before it touches down. Then it’s the other player’s turn. We tried to communicate the instructions by alluding to the game Jacks.

Team: Owen Bell, Nicole Pacampara, Hope Erin Phillips and Tobias Wehrum

Blowing Spinners

Twirl your spinners, blow them into the goal area and try to knock other spinners out! We demonstrated the game via a theatrical improvisation using team members as game props.

Team: Grayson Earle, Dawn Hang Yue Wong and Amanda Tom and Tobias Wehrum

Human, Farm Animal, Dinosaur

Rock, Paper, Scissors in its most exciting variant! We tried to get that across by making a little display with props and arrows.

(Interestingly, players thought that the display was part of the game and manipulated the props. Thinking about it, that might make a fun game mechanic if used properly.)

Team: Jessica Blanchet, Peter van Haaften, Titouan Millet and Tobias Wehrum

The player is ill – their heart rate, body temperature and digestion are either two high or too low – and so the player tries to get healthy by eating foodstuffs. Each foodstuff raises or lowers one or two of the aforementioned properties. (To keep it replayable, those effects are randomly decided at the start of each round.) It’s a logic puzzle: The player has to find out what each foodstuff does by eating them, then look at the current status on their apron, and in the end figure out which foodstuffs to eat to get healthy.

The core concept didn’t change much except going from multi- to singleplayer – this week was mostly about finishing the hardware (last week we only had a digital prototype to test with) and figuring out how to teach the game to new players.

We came up with two ways:

1. Starting simple, upping the difficulty: First there is only “temperature slider and 2 foodstuffs”, then there is “temperature + heart and 3 foodstuffs” and finally we get to “temperature + heart + stomach and all 4 foodstuffs”.
2. Using a screen which displays hints for the effect of all 4 foodstuffs in the beginning (“Kiwi: -1 temperature”, etc.) and then reducing the amount of hints by one every round.

In the end, we couldn’t decide which one we prefer and implemented both: One version self-sufficent with just the apron/fork/Arduino, and one version with an additional screen.

And now, without further ado…

Malnutrition is making you sick.
Luckily, you have found some healthy-looking
food, but you don’t know what it does yet.

Pick up your fork and watch as what you eat changes
your body and figure out the right combination.

Munch your way to health in FruitFever!

Source code available at GitHub.

Made possible by Critical Hit 2015.

Credits:

• Owen Bell: Electronics
• Milin Li: Sewing, Soldering
• Mónica Rikic: Sewing, Programming
• Tobias Wehrum: Programming

This project was made possible through the Technoculture, Art and Games Research Center’s Critical Hit: Games Collaboratory and the support of Concordia University and Dawson College and financial contribution of the Ministère de l’Enseignement supérieur, de la Recherche, de la Science et de la Technologie.

More “Working on the Game” Photos

(You can find the images from last week here.)

I did make one game this week though: Chronic the Hedgehog, an Urban Game on escalators about persuading strangers, made in about 1 hour together with Jessica Blanchet, Grayson Earle and Titouan Millet.

(Video taken by Jessica Rose Marcotte)

The game is played with two teams, two escalators, two cups, a dice per team member and a lot of unsuspecting strangers.

One team starts at the upper position, the other one at the lower position. I will explain the game from the lower team perspective – the other team just does the same mirrored.

To prepare the game, the lower team places a cup in front of the downstream escalator. Then each team member takes a dice and they queue in front of the upstream escalator.

Once the game starts, the first team member steps on the upstream escalator. They cannot move their feet – they have to stand on it until they reach the top. In the meantime, they try to get a stranger on the parallel downstream escalator to take their dice and put it in the cup on the botton of the downstream escalator. If they succeed, this team member is done. If they don’t, they have to take the downstream escalator to go down again and queue for another try.

Once your team member reaches the top, the next queued team member can start.

The goal is to be the first team which has all their dice in their cup.

And yeah, that’s the game. It was a bit chaotic, but pretty fun.

If you want to read more about the first week, take a look at the recap post on the Critical Hit website!

PS: Here’s a picture to appease the preview thumbnail generation gods of Social Media.

Starship Command Center Pro

Deep in space, nobody hears you scream
when the trial version of your OS runs out.

Not that screaming would do much.
Instead, you and your two friends now need to
figure out what the randomized buttons of the
free version of your system do.

Together, operate thrusters, cannons,
shields and a mining magnet, collect
gold and buy a proper license!

A cooperative and confusing space adventure
for three players with gamepads.

Download for Windows
GGJ page

Credits:

• Brian Davis: Idea, Game Design, Music and Sound Design
• Mikko Lepistö: Art
• Tobias Müller: Programming
• Tobias Wehrum: Lead Programming

With sounds assets by Ricky Situ, CST 201 KaWilson and Jim Rogers.

The theme is used twice in our game – once in the game mechanic with players having to talk to each other what do to next because they need to work together, and secondly in the story: The trial version of our control system has ended and the result is a chaotic and unknown button layout, what do we do now?

We even satisfied a diversifier (sort of an achievements for the developers) this time: Noise Generator, “The mechanic of the game is based on players having to stay in constant communication with each other.”

Fun fact: Originally we wanted to do the controls Spaceteam-like with custom controls on multiple smartphones – buttons, sliders, rotatable knobs. It took us over a day to get it to connect and run smoothly between Android and PC, only to find out that using controls on a touch screen while looking at another monitor felt awful and (apart from buttons) was nearly unusable. So after that day of work, around 5 in the morning, I spent 30 minutes to program replacement gamepad controls. It worked perfectly and felt good.

A few weeks ago, I finished my studies at the HTW Berlin in International Media and Computing with the defense following my master’s thesis. I thought that its content might be interesting to others on the internet too, but I understand that not everyone wants to read 100+ pages. For that reason, I am now writing this “too long; didn’t read” summary. It is also a lot more informally written. If you like what you read, you are quite welcome to read the longer version too! Here are the links:

Master’s Thesis

Source Code (open source, MIT license), Screenshots, Photos, Videos etc.

You can also read this summary as a PDF, but you would miss out on the videos.

Introduction

I love board games just as much as I love digital games. With smartphones and tablets, digital board games are getting bigger and bigger. But those are mostly touch-based – and at the HTW I had the chance to make games with a MultiTaction Cell multitouch table which can recognize objects placed on top of it too. So now, in my thesis, I wanted to find out if I can create digital-physical tabletop hybrid games that provide better gameplay than a touch-only version could.

I didn’t want to do something like chess which could be played with physical tokens, as a touch-based digital game or as a hybrid game without changing gameplay at all. I set out to focus on game prototypes where neither the digital and physical elements could be removed without changing the gameplay – a “true hybrid”, only possible in combination. Core physical elements should be interactions with advantages in the physical world, for example using the sense of touch to quickly and intuitively manipulate objects without directly looking at them, real-world physical interactions between pieces or using other properties of physical artifacts – e.g. objects can look different depending on the viewing angle. Likewise, the digital aspect is not just used for the sake of technology, but to add gameplay elements that are only possible by using technology.

I quickly figured out that it is easy to make the digital side matter, but almost everything physical that the multi-touch table can still recognize can also be closely simulated digitally. This shifted the focus a bit: Instead of still trying to make “true hybrids”, I wanted to make tabletop game prototypes that I believe are improved by the physical/digital combination. Every prototype would get a hybrid and a touch-based-only version, and then I can compare those in user tests.

Physical/Digital Advantages

Before I started with the design of the prototypes, I analyzed board games and digital games to find out which advantages they have over the other side. Note that a lot of those have exceptions, e.g. digital games are more likely to have a tutorial, but there are also board games with tutorials – and flicking might have advantages in the physical world, but digital games have similar mechanics. Mechanics and properties that are listed here are not exclusive to either side; I just believe that one side does it easier or might do it better in some way.

My thesis also has a short chapter on pervasive games, but since the focus is on making a tabletop hybrid game, I’ll leave this out here.

Physical Advantages – with a focus on board games

Physical Interaction

The physical world provides tactile feedback and often allows for more fine-grained movement.

• Finger Flicking: Done in games like Carrom and Crokinole, sometimes also thematic games like the dungeon-crawler Catacombs. Can be simulated with quick swish-motions on touch screens or pull-back mechanics in the digital world.
• Gravity: Games like Bausack or Jenga are built around building, balancing or removing building blocks in 3d space. It is hard to simulate the small movements and the tactile feedback in a digital game, although many 2d physics games exist.
• Tools: Games like Operation or Gone Fishin’ are based around tools used to interact with the game to give it a certain feeling or mechanics. These are much easier and often cheaper to produce for a physical game; the digital equivalent would be custom controllers.

Hidden State in a Shared Space

Tabletop games use independently movable physical parts which allows players to look at information (for example the underside of a card or token) without the other player seeing the same information. This is not possible on a single shared digital screen on multi-touch table or tablet. Digitally, this can be solved by using multiple screens or having a player look away, so either the space is not shared anymore or the flow is often broken.

Player Interaction

Interacting and communicating with other people is much easier when the partner is in the same room, instead of through text and speech or even through a webcam.

• Communication and Party Games: Games like Taboo, Pictionary, Charades and Freeze are heavily reliant on communication – be it speaking, drawing, gesturing or full-blown acting. Speaking and drawing can be replicated in digital games as well and might just be more enjoyable in a setting with everybody in the same room; when more body language and atmosphere is involved though, making a good digital equivalent harder or even impossible to create.
• Reading People’s Faces: Games like Junta or those in the Werewolf/Mafia family are heavily based on observation, negotiation and/or calling people’s bluffs – “reading” people. This can be done digitally and online too, but it is a totally different experience.

Flexibility

Board games are fully executed by human players. This allows for a certain kind of flexibility.

• House Rules: Rules could be improved? Easily changed.
• Games about Making Rules: Games like Hex Hex or 1000 blank white cards take it one step further by allowing the players to make up new rules or even design all game components and interactions.

Other Advantages

• Components: Physical components are often cheap and dependable. Digital devices on the other hand need to be bought, and assuming that players have smartphones doesn’t hold true everywhere.
• Available Space: Big touch screen are often very expensive, while producing a table-sized board game might not be exactly cheap, but still much cheaper.

Digital Advantages

Tutorial

In the board game world, learning a new game usually means reading a rulebook – or being taught by somebody who already knows the game. In the digital world, the learning companion can be the game itself. Digital games can enforce rules, teach when appropriate and react to players faults more easily. (Although Legends of Andor does a pretty good job at having a board game tutorial – inspired by digital games, no less.)

Control

In digital games, the experience is fully controlled by a processor: Input is taken and used as seen fit instead of direct interaction with the game pieces like in board games.

• Setup Time: Even after learning the rules, physical games still have to be prepared manually. The worst you will usually get from a digital game is a bit of loading time.
• Automatic Data Processing: Menial counting tasks and figuring out action results can be taken care of swiftly and automatically.
• Information Display: The game can show predictions and context-sensitive information when needed.
• Distance Calculation: Instead of moving in a visible grid or graph, movement can instead be by distance – and still does not need external tools like a ruler.
• Real Time Play: Automatic data processing also allows real-time play since it can instantly compute outcomes and it can limit players action, for example via a cooldown delay or resource usage.
• No Room for Player Errors: The game executes all the rules itself. If players haven’t understood a rule, it will still happen like it was originally intended.
• Cheating Inhibition: While technical cheats are possible, those are far less casual than looking at enemy cards in a board game or switching pieces while an enemy has left the room briefly.
• Impartial Judgment: Knowing everything that happens perfectly at any time and favoring nobody, digital games can easily judge results.
• Artificial Intelligence: Processing power enables stronger and more interesting non-human enemies than board games.
• Hidden State Processing: Hidden state can be automatically worked with in a truly hidden way. Considering a shared screen space, a game could still process what a hidden card does, for example mining one gold nugget per turn which the player could already use without revealing its source.
• Hidden Actions/Communication: When a player has their own device available, they can take hidden actions with the game verifying that this action is actually possible – thereby allowing hidden actions without fear that another player cheats. In the same vein, this could allow communication between players without a third party knowing that this takes place at all, for example to form secret alliances and plan combined actions.
• Sensors and Input Devices: Digital processing allows games to use sensors and interesting/complex input devices and integrate them into the gameplay.

Content

• Storage Capacity: So many games on such a small disk.
• Procedural Generation: Levels and playing fields can be created by algorithms on demand – with agency and configurable.

Presentation

• Animation: Board games mostly have static visual elements that are moved around. Digital games can change or animate those elements according to actions and game state.
• Sound Feedback: Obviously, the real world has sound feedback too, for example when placing a token – but here, digital games can play sound specific to what a token or action symbolizes, for example a cat token that meows when it gets a fish token.
• Atmosphere: Changing visuals and added music can greatly increase the atmosphere for a game.

Logistics

• Location: Tablets have much smaller screens than a board game would need. Suddenly, a big board game might be playable in a coffee shop.
• Availability: No need to wait for a physical order to arrive – digital games can mostly just bought online and downloaded instantly.
• Updatability: Game content and rules can be updated later via online updates.
• Persistence: When a game takes too long to finish, it can be saved and later restored. Unlike most board games, that makes it very easy to move between playing locations too.

Online Play

Digital gaming devices are often connected to the internet which enables playing with people who are not sharing the same room. This enables playing with friends who cannot meet personally at the moment, but it also allows strangers to play together.

Real-time online play is obviously used in real-time games, although turn-based games often need everyone connected at the same time. On the other hand, the persistence of a server also allows asynchronous online play – players are not necessarily online at the same time, make a move, log out again and are notified once the other player made their move too.

The Prototypes

To find out whether having a physical/digital hybrid improves on gameplay, I made three game prototypes, each with a hybrid variant and a touch-only variant.

Finger-Flicking Game

    

The first prototype is a two-player versus flicking game with real-time scoring. Players flick discs into scoring areas, adding a new disk every few seconds. Sometimes it might be more advantageous to wait until the enemy goes first and then hit the enemy disk so it leaves the area it is in – and sometimes it might be better to quickly score in an easily accessible scoring area. The game ends after a fixed amount of time and the player with the higher score wins.

Physical Part

The game uses physical tokens the player’s can flick, which I believed to me more engaging than a purely touch-based version because it adds tactile sensations and real-life interactions. I also thought the players might easier learn how much force they need to flick properly because they know naïve physics and get haptic feedback.

Digital Part

The main digital parts are a) the real-time scoring and b) the timer which allows the placement of new tokens. The game also uses visual feedback: The background is tinted in the currently winning player’s color and tokens which are scoring higher amounts emit bigger visual “waves”.

Spaceship Game

    

In the Spaceship Game, two players cooperatively manipulate a spaceship with attached satellites in real-time. The satellites have different turrets, shields or supporting structures. The goal is to survive as many waves of enemies as possible.

Physical Part

The physical spaceship is a direct representation of the digital spaceship. Players get instant tactile feedback on their actions, and resistance and the feeling of tugging might make it easier to cooperate. Turning and moving should also be easier when working with a wheel instead of a touch screen.

Digital Part

The game simulates enemies coming at the player in real-time while also operating weapons, moving projectiles, resolving collisions and keeping track of hit points. This cannot be reasonably done in a non-digital tabletop version while keeping the real-time element.

Duel Game

    

The Duel Game is a turn-based two player versus game. Both players have five units with different roles: Berserker (does most damage), Guard (has most health, strong counterattack), Marksman (ranged attack), Ninja (can try to jump out of attacks and switch with a unit once per game) and Spy (can get direct information about enemy tokens). Their positions are secret and players also secretly assign power levels from 1 to 5 to them. In the following fight, players move and attack with the units, using their respective strengths and abilities, trying to find out what the enemy units are and to take them down. Once a player has lost all their units, the other player wins.

Physical Part

The tokens with the cardboard screens allow two players to play on the same screen space without any indirection and still have hidden information.

Digital Part

The game contains several parts would be very hard to remake in a purely physical tabletop version.

Firstly, the rule set of interactions and reactions is a bit complicated. Having this done automatically is quite helpful.

More importantly, the game contains several parts where you would need an external judge:

• Fights are done in a doubly blind way: The attacking player knows a range of damage they can deal (for example 1-6), but they don’t know how much damage they did in this attack. On the other hand, the attacked player only knows that how much damage they took (for example 3), but not how much the opponent could have done.
• The Spy can see information about enemy pieces without the enemy even knowing that they have been spied upon.
• The Ninja can switch once with a friendly unit without informing the enemy player.

Test Results

Approach and Caveats

First off, this thesis did not have any budget or people to organize the search and testing, so it had only 12 probands in total. Additionally all the probands knew the author, with some even knowing the title of the thesis and a bit more information about it. I am fully aware that makes the results not very representative and less trustworthy, hence this caveat. The following is written in the hope that you still find it useful, if only for pointing in a general direction.

Each test session consisted of two players playing against each other. Many people played multiple games. A typical evaluation session looked like this:

1. The author of the thesis explains the game (5-10 minutes, depending on complexity)
2. The participants play a version of the game (5-20 minutes)
3. The participants separately fill out an AttrakDiff form for this version (5 minutes)
4. The participants play the other version of the game (5-20 minutes)
5. The participants separately fill out an AttrakDiff form for this version (5 minutes)
6. The participants separately answer the comparison questionnaire (5 minutes)

The AttrakDiff A/B test resulted in barely any difference between the two versions of each prototype, so I won’t mention it here.

In the comparison questionnaire, players rated 7 questions from 0 to 6, with “0” being “Hybrid” and “6” being “Touch-only”. The italic text explains the motivation of certain questions and was not part of the questionnaire sheet.

1. “Which version was easier to use?”
2. “In which version did you feel more in control?” (In games, less control does not always equal less ease of use. The Finger-Flicking Game might be easier to target in the touch-only version, which might make feel people more in control there, but the hybrid version might be easier to use due to less indirection of input.)
3. “Which version was more fun?”
4. “Which version was more interesting?” (This question tries to find out whether the hybrid version provides novelty value beyond pure gameplay.)
5. “Which version felt better?” (This question tries to capture whether the sensations provided by the tactile feedback add to the experience. It is deliberately vague to refrain from influencing people towards the hybrid version.)
6. “In which version did you feel closer to the other player?” (This tries to contribute to two questions: Do digital games feel more like playing “with the screen” instead of “with another player”? Does playing together on one screen in the hybrid version of the Duel Game make a noticeable difference?)
7. “If you had to play again, which version would you choose?”

Finger-Flicking Game

Hypothesis

In the hybrid version of the Finger-Flicking Game, the physical tokens are easier to handle as people can quickly figure out how they behave physically. The tactile feedback and the physical interactions between tokens feel gratifying and make the game interesting, but also a bit unpredictable. Only a limited amount of tokens needs to be introduced and recognized by the table at any time, so the friction between physical and digital world is kept to a minimum.

The moves in the digital version are a bit more predictable. Flicking by swiping is easy to figure out and easy to execute, but it takes more tries to learn how far a swipe will take the token. Moving a token by tapping it first is a bit harder to learn because it is not intuitive.

Depending on the players’ preference, they might prefer the tactile feedback and unpredictability of the hybrid version or the predictability of the digital version. The hypothesis was that the games will be fairly evenly rated with a preference for the hybrid version.

Results

The Finger-Flicking game had 8 testers. All average values tend slightly towards the hybrid variant in various degrees. Especially interesting was the wide range of answers – for example in the “Feeling of Control” category, 3 of the 8 players answered that the Hybrid version is clearly superior while 3 tended slightly and 2 strongly towards the touch-only version. Here it seems to come down to preference, which is in line with the hypothesis for this prototype.

It is worth noting that both of the versions proved to be imperfect. The physical tokens in the hybrid version could be weightier and slide better and especially two testers had recognition problems; meanwhile, the digital version has a lag (by recognition algorithm design) when flicking, with the token not moving until the flicking gesture ended. I believe that if the recognition was stable and the physical properties of the hybrid version were more optimized that the hybrid version would be more strongly preferred. It would have been interesting to do more iterations of each version to finally compare “idealized” versions where each is as good as possible.

Spaceship Game

Hypothesis

In the Spaceship Game, the physical feedback provided by the components in the hybrid version is essential. The tangibility allows for faster targeting than in the digital version (albeit it sometimes lags slightly behind), and grabbing and turning a wheel is easier to execute than constantly rubbing two fingers over the glass to turn and move a token. The physical constraints help players feel the movement restrictions and coordinate activities – for example when a player tries to evade a bullet by tugging, the other player might loosen their touch to allow the movement to happen. Additionally, the Spaceship Game has only 5 physical tokens in total – the mother ship and 4 satellites. These tokens can be made unique/persistent which improves the chance to recover from recognition errors, and they only move slowly compared to the Finger-Flicking Game. This should help to reduce the friction between the physical and digital worlds.

The hypothesis here was that the hybrid version of the game will be strongly preferred.

Results

The Spaceship Game also had 8 testers. Here, the tendency towards the hybrid version is even stronger, especially for in the “Ease of Use” category. It matches with the hypothesis, although not as strongly as expected.

Players said that the rotation in the digital version was very hard (a direct turning with touch points was used, as if one was touching points on physical objects – maybe a rotation speed multiplier would have been good here) and one tester remarked that the hybrid version had an unfair aesthetic advantage, with the simple graphics on the screen being the same, but the Lego model looking more interesting. One player said that the Lego model was obstructing his view and because of that he preferred the touch version, while others liked the look and feel of the model.

Duel Game

Hypothesis

The hybrid version of the Duel Game is the prototype that suffers the most from wrongly recognized tokens, as it contains 10 tokens that have to be properly recognized at the correct positions before the game can even start. This often involves moving around multiple markers to trigger a refresh and having some markers in unstable conditions. Putting the physical role info cardboard stand-ups into the tokens makes the setup phase lengthier, and there is a certain chance that a wrongly detected marker shows a hidden token to the enemy. When that happens the game has to be restarted and the token role info cardboard stand-ups have to be taken out and reassigned again. After the preparation, the game progresses more smoothly, but one still sometimes has to adjust unrecognized markers and wait for markers lagging behind so that the level/health etc. information does not get exposed to the enemy.

In the digital version, players are more distanced as they are not playing directly on the same playing field, but ease of preparation and play might make this version much preferable. It was therefore the hypothesis that in this game, the digital version will be preferred.

Results

The Duel Game had 6 testers. As expected, the touch-only version is preferred when it comes to ease of use and players feel slightly more in control. Despite players not showing strong tendencies about which version to play again, the goal of the hybrid version was reached: Players feel closer to each other because they play on the same field and see each other moving the tokens. One player in particular remarked that he felt that he was playing against the computer in the digital touch-only version, saying that his opponent is “right over there”, but he is still watching the screen instead of talking to him. In general, it seemed like more personal interactions were happening between the players in the hybrid version.

Summary

In general, the differences between the games are rather small, but they are not surprising. The hybrid version in the Spaceship Game provided a bigger improvement over the touch-only version than the Finger-Flicking Game, and the Duel game had more control problems in the hybrid version, but also brings the players closer together.

The differences between the hybrid versions and the touch-only versions are not very strong though, and individual testers preferred games on either side with just the average tending slightly towards the hybrid side.

Possible Future Evaluations

There is another thing to take away from the tests: Which future evaluations could be made. More information on the following list can be found in the thesis.

• Multiple iterations between evaluations to reach “ideal” hybrid/touch-only prototypes.
• Long-term tests instead of short “first impression” tests.
• Play tests in a non-laboratory setting, for example an installation.
• Tests between hybrid and physical-only board game versions.
• Tests with certain groups of people.

Conclusions

In the end, I couldn’t demonstrate a strong player preference for physical elements in tabletop hybrid games, despite trying to give these elements meaningful gameplay character. There is a slight average preference to the hybrid versions, but it seems to come down to individual player preference.

Considering that hybrid games are harder to produce and have high and costly hardware requirements, touch-only versions might be preferable in most contexts – except maybe certain cases like permanent installations or museums where you only have a one-time cost.

It was rather hard to find advantages for the physical side that a) work with a touch table, b) cannot be simulated by touch-only and c) improve gameplay. Digital advantages on the other side were very easy to find.

It might be more promising to look at hybrid games away from the 2D interface of a touch table – games that are played in 3 dimensions, be it a stacking/building game or pervasive games where people use their own body and their environment, but also smartphones and other sensors. In games like these, a purely digital version should be a wholly different experience – unlike the prototypes presented here, where a touch-only version was believed to be inferior, but still easily creatable and comparable.

I imagine a game where a good portion of the game takes place in the physical world, but that uses the touch table as an interface to another part of the game, could also be interesting to play. In such a game, for example, cards could be obtained in a fully physical card game and be placed on the touch table to trigger effects there. The ease of handling cards in the real world could be a good argument for the making the game a physical/digital hybrid (instead of fully digital) if the interface is done correctly.

Another approach could be to concentrate even more on the physical-tactile aspect, for example by making a game that does not use visual output at all, but takes physical input and creates auditory and possibly tactile (vibrations, movement) output. Here, the screen of the table would not be used, only its recognition capabilities.

Libraries/Assets Used

The prototypes/videos use assets by:

• Music: Kevin MacLeod
• Sfx: Moritz Ufer, Iwan ‘qubodup’ Gabovitch, carbilicon
• Font: The Northern Block
• Icons: J. W. “eleazzaar” Bjerk

Libraries used:

• Uniducial
• TouchScript
• DOTween

This project was made possible by the Creative Media​ department of the HTW Berlin and supervised by Prof. Dr.-Ing. Carsten Busch​ and André Selmanagić​.​

Take your pen-lance! Get ready, and… fight!
Poke the other player before they poke you!

But beware, don’t touch them before
you hear “fight”, or it’ll be a foul…

It’s not all fun and sunshine though: The game is a rather repetitive. I hoped to get a fencing kind of game, but it is really hard to balance the distance so it’s neither too easy to hit nor unreachable. Moving while touching the copper wire (which ensures that the right distance is being kept) isn’t easy, so you aren’t very flexible. That leads to very short distance jabs that are nearly impossible to react to and each round was pretty short. Despite that, fun was definitely had while developing and playtesting!

PS: When you do something like this, have water nearby to regularly dip everything into which will make circuit contact for a very short time. Water improves the conductivity so much.

Credits:

• Idea, Execution and Programming: Tobias Wehrum
• Music: Steven O’Brien
• Font: Egidio Filippetti