Tagged: Open Source

And thus, the third week ended. It had its hits and misses, but I learnt new stuff and I’m especially content with the three dailies at the end! And now, without any further ado:

#015: Probably a Metapher for Something

On the other hand, maybe it isn’t. Let’s… let’s just skip this one, okay? I guess it’s safe to say that it didn’t go where I wanted it to go.

s15_03_15_probably_a_metapher_for_something_01

#016: Hypnotic Eye

This one didn’t really go where I wanted it to go either, but luckily, sometimes cool things happen while you’re experimenting. The video recording didn’t have a high enough frame rate to show how it smooth it really looks, but I recommend downloading the processing sketch or an executable – it feels pretty hypnotic full screen and with a high frame rate.

s15_03_16_hypnotic_eye_01      s15_03_16_hypnotic_eye_02

s15_03_16_hypnotic_eye_03      s15_03_16_hypnotic_eye_04

#017: Circuits

This one is inspired by a chapter of Generative Design about stitching together simple SVG shapes in a grid to form more complex patterns. I wanted to try making circuit-like images, so I designed my own shapes in Inkscape. Fun, but man, this took some time doing for the first time – the sketch uses 36 shapes, and everything had to correctly align. I like the results though, some parts look really interesting!

s15_03_17_circuits_01     s15_03_17_circuits_02     s15_03_17_circuits_03

s15_03_17_circuits_04     s15_03_17_circuits_05     s15_03_17_circuits_06

#018: Cloudy Tunnel

Another one in the category “I thought this would look better”. It’s kind of like a more boring version of #013 (Fissures). Oh, and it serves as a reminder for me – I wanted to go somewhere entirely else with that, but I forgot my goal along the way because I didn’t keep switching back to my reference.

s15_03_18_cloudy_tunnel_01     s15_03_18_cloudy_tunnel_02

#019: Insect Generator

Ha, this one is fun! Originally I just experimented with using perlin noise on circle drawing, but then I realized that the results look kind of like insects with the right parameters. While I experimented further, I discovered that a certain parameter makes them look very alien and glitchy. That parameter is part of the sketch now, slowly escalating on each result, leading to a tour from normal earth insects to otherworldly abominations.

s15_03_19_insect_generator_01     s15_03_19_insect_generator_02     s15_03_19_insect_generator_03

s15_03_19_insect_generator_04     s15_03_19_insect_generator_05     s15_03_19_insect_generator_06

s15_03_19_insect_generator_07     s15_03_19_insect_generator_08     s15_03_19_insect_generator_09

#020: Forest of Lights

One of the few sketches where I have a concrete inspiration – this time from the manga Soul Eater. The trees with the light balls on top of it fascinated me, so I tried my hand on generating something similar. It was a bit hard to get something decent looking despite using 2D graphics without cool premade lighting effects and shaders, but in the end a bit of cheating (the tree shading is totally randomized and even though they are reminiscent of low-poly models, they are fully 2D, haha) got me close enough to where I wanted to go!

s15_03_20_forest_of_lights_01     s15_03_20_forest_of_lights_02     s15_03_20_forest_of_lights_03

s15_03_20_forest_of_lights_04     s15_03_20_forest_of_lights_05     s15_03_20_forest_of_lights_06

#021: Gradient Skyline

And the last of the pack! This one uses palettes again to create interesting color combinations, but this time I’ve learnt my lesson and picked them by hand. Also, for the first time: Gradients. And pixel line shifting.

The following palettes are used (and highly recommended): Thought Provoking by Miss_Anthropy, cheer up emo kid by electrikmonk, Ocean Five by DESIGNJUNKEE, fresh cut day by electrikmonk, (◕〝◕) by sugar, Dance To Forget by joy_of_summer, Storming Psychedelia by Bionic Blender, Gamebookers by plamenj, A Dream in Color by madmod001, Hymn For My Soul by faded jeans, Koi Carp and 400 Lovers by Tzadkiel, it’s raining love by tvr, vivacious by plch, antidesign by death—of—design, mai by lovelyrita and Pop Is Everything by jen_savage.

s15_03_21_gradient_skyline_01     s15_03_21_gradient_skyline_02     s15_03_21_gradient_skyline_03

s15_03_21_gradient_skyline_04     s15_03_21_gradient_skyline_05     s15_03_21_gradient_skyline_06

s15_03_21_gradient_skyline_07     s15_03_21_gradient_skyline_08     s15_03_21_gradient_skyline_09

Download

Windows (32 bit)

Windows (64 bit)

Source Code (GitHub, MIT license)

Instructions:

  • Probably a Metapher for Something: Watch. Contemplate. Close. Move on and try something else.
  • Hypnotic Eye: Left-click to restart.
  • Circuits: Left-click to refresh.
  • Cloudy Tunnel: Left-click to refresh.
  • Insect Generator:
    • Left-click to refresh (and increase alien glitch)
    • Right-click to refresh (and reset alien glitch)
    • Mouse-wheel or +/-: Cycle through coloring options
  • Forest of Lights: Left-click to refresh.
  • Gradient Skyline:
    • Left-click to refresh.
    • Right-click to refresh, but keep palette.

If you’re not on Windows, fret not; for some reason I can’t compile for Mac and Linux, but you can just download Processing and open the sketch files in the archive. It’s really straightforward. If you need any help doing that, just send me a mail or comment here.

And now, once more into the fray! I’ll do a fourth week of dailies, and then I’ll change the format a bit. I’ve got some experience with smaller sketches now, but I wonder what I could do with more time – so instead of daily sketches, it’ll be one or two bigger sketches a week. But for now, you can look forward to the next and last round-up of dailies next Sunday. See you then!

And the second week is over! I had some interesting and diverse results this week. I’m especially fond of the Silk/LightWeaver and some of the results of Stormy Weather look very dynamic.

#008 – Silky Smoke

A variant of #006 (CircleTrails), inspired by this video where Casey Reas talks about the circle collision thing that #006 also uses, but with drawing lines between them. Silky Smoke works in a similar way, but isn’t about drawing a persistent picture and more about the movement created. It looks okay, but I have to admit that I was hoping for more.

s15_03_08_silky_smoke_1     s15_03_08_silky_smoke_2

s15_03_08_silky_smoke_3     s15_03_08_silky_smoke_4

 

#009 – SilkWeaver

 Ladies and gentlemen, may I introduce the star of this week: SilkWeaver! It’s not self-praise if I’m praising the results of a program I coincidentally, right? Either way: Aesthetically, I these are the best pictures I’ve created so far. And the complex patterns are created quite simply actually: It’s another variant of #006, but this time, there are lots of little circles wandering and some bigger circles called “weavers”. When a weaver intersects with a circle, it draws a line from the center between the two to the center of the little circle. That’s all the magic!

s15_03_09_silkweaver_01     s15_03_09_silkweaver_02     s15_03_09_silkweaver_03

s15_03_09_silkweaver_04     s15_03_09_silkweaver_05     s15_03_09_silkweaver_06

s15_03_09_silkweaver_07     s15_03_09_silkweaver_08     s15_03_09_silkweaver_09

s15_03_09_silkweaver_10     s15_03_09_silkweaver_11     s15_03_09_silkweaver_12

 

#009b – LightWeaver

My friend increpare noted that the images made by SilkWeaver are too dark, and yeah – he’s right. So I looked up how to use the additive mode in Processing. Turns out, that’s just a single line – and now my SilkWeaver is a LightWeaver. When you start the sketch, that’s the standard mode – with “m” you can switch to the SilkWeaver mode. You know, if you like Silk more than Light.

s15_03_09b_lightweaver_01     s15_03_09b_lightweaver_02     s15_03_09b_lightweaver_03

s15_03_09b_lightweaver_04     s15_03_09b_lightweaver_05     s15_03_09b_lightweaver_06

s15_03_09b_lightweaver_07     s15_03_09b_lightweaver_08     s15_03_09b_lightweaver_09

s15_03_09b_lightweaver_10     s15_03_09b_lightweaver_11     s15_03_09b_lightweaver_12

 

#010 – Homage to Mondrian

I guess the inspiration here is quite clear. The version with the zig-zag lines looks more interesting than I thought it would.

Before #010 I’ve just randomly generated colors, but I thought that this calls for a few handselected colors. Luckily, the ever-wonderful ColourLovers has API access! I tried to make it call the API on runtime, but sometimes the call actually timed out because the site was taking so long to load – so now I’m just using a downloaded version of the result XML.

While I’m content with the result in general, when it came to taking screenshots I wished that I had handpicked the palettes. Some are really interesting, but others simply don’t have enough contrast. Well, lesson learnt I guess.

(I’m sorry that I don’t have any idea whose palettes I’m using here – they are randomly selected from the top 100. If I’m using your palette, please tell me and I’ll credit your here!)

s15_03_10_homage_to_mondrian_01     s15_03_10_homage_to_mondrian_02     s15_03_10_homage_to_mondrian_03

s15_03_10_homage_to_mondrian_04     s15_03_10_homage_to_mondrian_05     s15_03_10_homage_to_mondrian_06

s15_03_10_homage_to_mondrian_zig-zag_01     s15_03_10_homage_to_mondrian_zig-zag_02     s15_03_10_homage_to_mondrian_zig-zag_03

s15_03_10_homage_to_mondrian_zig-zag_04     s15_03_10_homage_to_mondrian_zig-zag_05     s15_03_10_homage_to_mondrian_zig-zag_06

 

#011 – Stormy Weather

This one had a long way behind it. Lots of circles attached to other circles, in turn attached to other circles, every rotating. At first it was constantly drawing and resulting in a thing that kind of looked like an ugly ball of wool. Changing it to motion blur led to the results below – much more dynamic-looking!

s15_03_11_stormy_weather_01     s15_03_11_stormy_weather_02     s15_03_11_stormy_weather_03

s15_03_11_stormy_weather_04     s15_03_11_stormy_weather_05     s15_03_11_stormy_weather_06

 

#012 – Calibrating, Please Wait

“Calibrating, Please Wait” got its name because it reminded me of how zooming/targeting display are sometimes displayed on TV – as if it was trying to get the right settings, but they are never quite right.

s15_03_12_calibrating_please_wait_01     s15_03_12_calibrating_please_wait_02     s15_03_12_calibrating_please_wait_03

s15_03_12_calibrating_please_wait_04     s15_03_12_calibrating_please_wait_05     s15_03_12_calibrating_please_wait_06

 

#013 – Fissures

Again, lots of little lines, rotating and moving, with additive blending. I guess I’ll have to experiment further with that technique as it always seems to have interesting results. In this case, it kind of looks like a very old scratched glass panel (or shard of ice) with fissures and light shining from the other side.

s15_03_13_fissures_01     s15_03_13_fissures_02

s15_03_13_fissures_03     s15_03_13_fissures_04

#014 – Noisy Forms

Last one! Polygons with 3 to 8 points and a random rotation determined with perlin noise according to the polygon radius. Not the most glorious way to finish the week, but I guess there are good and bad days, eh?

s15_03_14_noisy_forms_01     s15_03_14_noisy_forms_02

s15_03_14_noisy_forms_03     s15_03_14_noisy_forms_04

Download

Windows (32 bit)

Windows (64 bit)

Source Code (GitHub, MIT license)

Instructions:

  • Silky Smoke: Left-click to refresh. Right-click to switch between white/color modes. +/- keys or mouse wheel to change hue.
  • SilkWeaver: Left-click to refresh. Right-click to pause/resume. “m” to change blending mode (Lightweaver [default] or SilkWeaver)
  • Homage to Mondrian: Left-click to refresh. +/- to change speed. 1 to 9: Set scale. i: Switch between drawing or instant. s: Switch between straight or zig-zag.
  • Stormy Weather: Left-click to refresh. Right-click to pause/resume.
  • Calibrating, please wait: Left-click to refresh. +/- to change speed.
  • Fissures: Left-click to refresh. Right-click to refresh and draw instantly.
  • Noisy Forms: Left-click to refresh.

If you’re not on Windows, fret not; for some reason I can’t compile for Mac and Linux, but you can just download Processing and open the sketch files in the archive. It’s really straightforward. If you need any help doing that, just send me a mail or comment here.

And that’s it for the second week. Considering how small the results look, it’s surprising how taxing it can be to actually do a sketch a day (and to make videos, pick screenshots and do all the other things needed to publish the results). But I’ll keep at it at least for four weeks in total – some days where I felt particularely uninspired, like on the days I made Stormy Weather or Fissures, still had great results. The “I have to sit down and make something” now is a great if somewhat uncomfortable cure to “I feel uninspired”, apparently. Either way: See you next week!

Hey! If you’ve been reading this blog for a while, by now you’ve probably noticed that (true to my tagline) I mostly post games that I make – but sometimes, it’s also other stuff. The “other stuff” might get a bit more from now on! I’ve been getting into generative art, and I’ve decided to make one generative art sketch per day until I get bored with it. Every Sunday I’ll post the results of the week with screenshots, videos, executables for Windows and the processing source files. And if you’d rather see me making games, don’t worry – making interesting and potentially beautiful things with code can only help making my games look better, can’t it? And now without further ado, I present to you week 1!

#001 – ShardSphere

First one in my daily series! Mostly inspired by Generative Art Chapter 5. I really like the beginning when it comes to life out of nowhere.

s15_03_01_shardsphere_1     s15_03_01_shardsphere_2

s15_03_01_shardsphere_3     s15_03_01_shardsphere_4

 

#002 – ShardCircle

A rehash of #001. I was wondering how it would look in 2D. Turns out: Pretty good. Even more as in #001 I like the how it appears with a swoosh like a swarm of little shards.

s15_03_02_shardcircle_1    

s15_03_02_shardcircle_3     s15_03_02_shardcircle_4

 

#003 – TriangleChain

Things don’t always look like I envisioned them, and #003 is a very good example of this. So along the way I thought if it doesn’t want to look like I want it to, I’ll just add silly perlin noise motion to it and call it a day. (Perlin noise is SOOOO good.) You might notice that it has much clearer colors than #001 and #002 – here I discovered the joys of the HSB color mode.

s15_03_03_trianglechain_1     s15_03_03_trianglechain_2

 

#004 – CubeSphere

Originally inspired by this crazy thing. To keep the color scheme interesting but also fluent and consistent, I have 4 different functions: “noise(sin(angle t))”, “noise(cos(angle t))”, “noise(cos(angle t) + sin(angle t))” and “noise(sin(angle s)) * noise(cos(angle t). I generate 4 random weights at the beginning to set how each of those functions contributes to the color at the angle t and s. Voila: Different patterns and colors, but consistent and flowing into each other.

s15_03_04_cubesphere_1     s15_03_04_cubesphere_2

 

#005 – Fireflies

This is the one that strayed furthest from its inspiration, and all the better for it. Because gosh, does it look good, and it looks even better in motion. And it’s fun to play with too!

Originally, I was inspired by a scene in the Rule-of-Cool-anime Campione: Lots of flying swords acquiring a target at the same time and then flying towards it. Turns out that looks really boring in 2D without great graphics and sound effects, but the trails looked nice. And it looked even more interesting with colors and just as little glowing dots.

And so, one by one, I arrived at some sort of space fireflies harvesting white orbs for light, always flying, piercing, glowing and looking out for the next one.

s15_03_05_fireflies_1     s15_03_05_fireflies_2     s15_03_05_fireflies_3

s15_03_05_fireflies_4     s15_03_05_fireflies_5     s15_03_05_fireflies_6

s15_03_05_fireflies_7     s15_03_05_fireflies_8     s15_03_05_fireflies_9

 

#006 – CircleTrails

This one started out as me rewriting an example from Generative Art Chapter 6 without reading the code and only reading the description. It looked delightfully different, and with the addition of different modes (black, greyscale and color) even more so.

The chapter’s title is “Emergence” – having complex forms and behaviour emerge from much simpler behavior. And so, in CircleTrails, there are lots of invisible circles just flying around and bouncing off the borders. Those aren’t the circles that you can see in the images – those are drawn whenever two invisible circles intersect with the center point as the circle center and the distance as the circle radius.

s15_03_06_circletrails_m1_black     s15_03_06_circletrails_m2_greyscale

s15_03_06_circletrails_m3_color_1     s15_03_06_circletrails_m3_color_2

 

#007 – Blobs

Last one of the first pack: A collection of blobs, fighting for dominance. It’s not working out very well for them, but more so for us as we get to enjoy the results. Over time, the images feel a lot deeper and richer textured and get an oily look.

s15_03_07_blobs_1     s15_03_07_blobs_2

s15_03_07_blobs_3     s15_03_07_blobs_4

 

Download

Windows (32 bit)

Windows (64 bit)

Source Code (GitHub, MIT license)

Instructions:

  • ShardSphere: Left-click to refresh.
  • ShardCircle: Left-click to refresh.
  • TriangleChain: Left-click to refresh. Space to show UI.
  • CubeSphere: Left-click to refresh.
  • Fireflies: Left-click to spawn a sphere and to deactivate auto-spawn-mode. Right-click to refresh.
  • CircleTrails: Left-click to refresh. Right-click to change mode. +/- keys to speed up/slow down.
  • Blobs: Left-click to refresh.

If you’re not on Windows, fret not; for some reason I can’t compile for Mac and Linux, but you can just download Processing and open the sketch files in the archive. It’s really straightforward. If you need any help doing that, just send me a mail or comment here.

And that’s been it for the first week. See you next Sunday for the second one!

Preface

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 digital equivalent might be harder or even impossible.
  • 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, but also 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

finger-flicking_game1     finger-flicking_game2

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

spaceship_game1     spaceship_game2

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

duel_game1     duel_game2

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

finger-flicking_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

spaceship_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

duel_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:

Libraries used:

15 Minutes in the Shoes of a Game Programmer

For a workshop at the YOU, a youth culture fair, I was asked to make a concept for a short game programming workshop.

The requirements were:

  • The workshop should give an impression of the work of a game programmer.
  • It should take about 15 minutes and allow groups of varying size.
  • I should assume that the participants have no experience in programming at all.
  • Instructions should be kept to a minimum; the focus should be on hands-on experience.
  • The workshop should produce a quantifiable result.
  • It should be an enjoyable experience.

No easy task. Luckily, inspiration struck, and a few days later I finished the game StarCoder.

StarCoder

Move the player to the star by using
Left/Right and Space to jump.

An easy game if it weren’t for the spikes –
or if you could jump far enough, for that matter.
Luckily you can edit the source code.

There are 15 distinct solutions to win the game.
How many will you find?

Download for Windows

Source Code (License: CC BY SA)
Creative Commons License

The Workshop

The workshop went extremely well. Everybody found at least 4 solutions, with some finding up to 10. The game also seems to be surprisingly fun, even (or especially?) for non-programmers! Results were often accompanied by laughter and some of the participants even asked for the program so they could try it again at home. And I remember a teacher who sat down to try it himself after I finished the workshop with his group of pupils.

If you use it yourself (which I’m totally fine with – I’d love if you drop me a message that you are using it!), this was my approach:

  • Tell your attendees that the goal of the game is to get to the star. Ask them to click in the left part and try it themselves: Arrows keys to run, Space to jump.
  • After half a minute admit that it seems rather impossible – but luckily there’s the source code on the right side which they may edit. Ask them to notify you once they have a solution.
  • Once they have the first solution, congratulate them for their achievement. Then ask them to click on “Reset” in the lower right corner and tell them that there are 14 more solutions.
  • After a few minutes (or a few solutions, depending on their speed), tell them that there’s also the “Creation” tab in the upper corner.

The ideal number of attendees seems to be 1 to 3 per computer. You might want them to write down their solutions if you want to assign a score to each group later.

So… how about you? Did you find every single one of the 15 solutions? Try it yourself first – and then check it with this handy walk-through. (No cheating though!)

And if you’re interested how hard solutions are and which are found the most and least easily, you can check out these statistics (contains spoilers!).

Credits

  • Concept, Programming and “Art”: Tobias Wehrum
  • Sounds: Moritz Ufer

Thanks to my playtesters: Moritz, Tobias, Kelvin, Sebastian, Simon, Christiaan, Lukas, Florian, Marina, Jana, Jens, Paul, Ronja and Nadine. You guys have been a huge help!

Made in cooperation with:

It sucks to be cursed. It sucks even more when you’re standing paralyzed in your own wizard tower while your arch-enemy sends hordes of hungry ghosts to gobble up your mana. Luckily your telekinetic powers are still working fine, and now you are defending yourself by redirecting energy beams from your hands with mirrors and whatever else is at hand.

Wizard Defense

You’re paralyzed. Enemies are closing in.

Redirect the energy beams with mirrors to hit the ghosts and
change their colors at the right time to exploit each ghost’s weakness!

A cooperative augmented reality game for two friends and a webcam.

Play it in the web player!
(Download and print the markers!)

Download it for Windows/Mac/Linux!

The source code is available further down in this post.

You can quit the game by pressing Escape while the menu console is showing.

Solo Play?

If you play alone, you might have some problems – it’s made for two players. If you still want to play alone, here are some cheats you can press after the first ghosts spawned so you can at least experience the gameplay: F10 triples the power of your energy beam, and F11 makes you invincible.

Open Source

This was one of my three big projects this semester, this one for the Augmented Reality course. It’s built in Unity 4, with NyARToolkit to recognize the markers. The japanese documentation makes NyARToolkit a little bit hard to read, but good examples and method names go a long way and we had a lot of fun using it.

You can download the source code and Unity 4 project here. The source code is released under the terms of the GPL v3. The assets (meshes, textures etc) are not released under any particular license. Unless mentioned otherwise on their respective source websites stated in the credits, you are not allowed to use them. If you’d like to use them anyway, feel free to contact me. (Disclaimer: The project was for a university course. Due to time constraints and that not being a requirement, the code is not well documented nor does the documentation fit the C# standards.)

Credits

Screenshots

Finally, have a few screenshots:

Take Hammerfight. Add Pong. Mix and stir. Sprinkle with a little realism and Tron.

Recipe serves 2.

Hammertennis

You are playing Tennis. Well, you’re trying to play Tennis.
You’ve lost your tennis rackets, so you take hammers instead.
Also you’ve forgotten most of the rules.

Hammertennis: A fast-paced ball game for 2 players.
Supports Keyboard – or Gamepads! (You only need one stick. Choose any.)

Download the Windows executable

You get 2 points for scoring a goal, and 1 point if the opponent hits his own goal.

Normally only the hammers can hit the ball – but if the ball is red, the blue player can hit it once, and vice versa.

This is the first game I ever started with Python, featuring Pygame and pybox2d. Lovely language! It is also the first game that I ever made that uses any serious form of physics.

Both are thanks to Florian Berger, who is teaching the university course that got me started on making a Python game featuring any form of physics in the first place. Thanks a lot, it was great fun and (obviously, see above) had great results!

You can also download the source code (New BSD License) if you like! It needs Python 2.7, pygame 1.9.1 and pybox2d 2.1.

Credits:

Finally, Dragonflute is finished! In this game, made for the Experimental Gameplay Project “ZERO BUTTONS” theme, you control this cute little fellow:
(<– Click the dragon to download the Windows release)

As the theme of this month’s EGP and the name suggest, you don’t do this my mashing franatically on your keyboard, but but by making sounds, recorded by your microphone. I hope you have one. :)

The dragon will either follow the PITCH of the sounds you make (which I prefer), be it by singing, whistling or by playing an instrument, or the VOLUME (which is fun too, though the game should then rather be called Screaming At Dragons).

I’m ambivalent how this one came out. Gameplay-wise it is not top-notch, and the pitch is often off (especially when not using an instrument), on the other side I think that it shows the key-concept rather well.

I guess I’m (heavily) over 7 days, I didn’t always work day-to-day and didn’t count the time – but since the topic “pitch recognition” wasn’t too easy and required some fiddling with calibration and configuration, not to speak about the keyless interface, the overtime is understandable I guess.

The pitch recognition itself is working fairly well – good enough for a prototype, though I would’ve hoped that it worked better with humming. Oh, well.

For this game I used C++ with my beloved SFML and FMOD as sound framework.

For those interested, here is the source code in form of an Eclipse CDT Project: Source Code (New BSD License).