Tobi's World

Hello world, please welcome Project PERCEPTION NEURON! 

Last week I was finally able to test an idea that I had in my head for some time now. This idea was very simple: Bring your whole body into a game world by combining the Oculus Rift virtual reality headset with a real-time motion capture system. Here's how it was done and what problems I encountered.

The setup

For the HMD (Head-Mounted-Display) I used the Oculus Rift VR. To capture the motion of the body I used the Xsens MVN system provided by the friendly motion capture studio Artanim in Geneva. The Xsens MVN is wireless which is a handy thing when walking around while having your vision replaced by the output of the Oculus Rift. However the Oculus isn't so I used 5 meter cable extensions for this first test. Here's a photo of me wearing the whole setup:

I tried researching a wireless hack for the Oculus Rift but as it turns out making an wireless USB to USB bridge is harder then one might think. The wireless HDMI connection on the other hand is easier to accomplish as there are a few professional solutions available. Since latency is a big issue in head-tracking this adds to the difficulty of finding a good wireless setup.

Initial results

Surprisingly the first test feels really natural and your perception adapts immediately to your new surroundings. Body movements like walking around or waving your arms feel natural and from all the people who tried this setup, nobody experienced any form of motion sickness. There is an immediate connection between your virtual body/limbs and your motor skills. Interaction with physic objects in the game world feels fine due to immediate visual feedback but the absence of haptic feedback makes the experience a bit unusual.

The problems

Of course any new and experimental technology has its share of problems. Here's what I've encountered thus far:

Double head-tracking Since the MVN system tracks the head as well and we parented the camera to the head there is some mix-up here. We tried using only the head tracking of the MVN system but this turned out to be unfeasible since the system transmits with 30 fps to Unity this form of head tracking introduced a lot of motion sickness.

Drift There was some odd rotational offset by about -90° for the head tracking. This might be because we used the MVN system inside an office with lots of interference from the computers and cables. Or it might also be because the Oculus Rift wasn't designed to be used for walking around with. Or it could be that Unity mixes up some quaternion values.  

Distance Calculation One scene had bouncing balls you could push around. In this scene it was difficult to judge the distance of yourself to the nearest ball. I'm guessing this is because you're unable to focus in and out of objects while wearing the Oculus Rift since our eyes are looking at a screen. Another contributing factor could be the perfect roundness of the balls as opposed to the other scene with cubes where this issue was less apparent. I have no idea how to fix this for now. The stereoscopic perception however worked great.  

Tactile feedback When interacting with virtual objects there is no tactile feedback. This makes interacting with physic objects a bit unusual, however the visual feedback helps. It also adds to the problem where you try pick up a virtual cube, but your hands pass straight trough it because there is no feedback, making this endeavor very delicate.  

Cables, space and safety Since you're wearing a fully immersive virtual reality display you lose total sense of your real world surroundings. Making your prone to walking into objects, desks and walls. Having the Oculus Rift connected by cable also poses the risk of stumbling over the cable and hinders your movement.  

Price The whole MVN motion capture setup is really pricey and nowhere near a consumer-friendly level. Thus this technology remains pretty exclusive until someone brings a setup on the market for less then $500 USD. It looks like PrioVR is headed into the right direction all tough their tracking looks a bit jerky.

Future development

Despite the current problems I believe this technology has great potential and I'm looking forward to further exploring its possibilities. Here's what I've planned next:

Fix the camera setup, drifting and head tracking issues.

Find a way to optimize interaction with physic objects.

Find a way to make the Oculus Wireless.

Try out real-time motion capture with the Vicon system in Unity.

Test a form of tactile feedback by using a real cardboard box thats replicated inside the game along with tracking its position and rotation if possible.

Finally wrote the post mortem for my Ludum Dare game. You can find it here: http://www.ludumdare.com/compo/2013/01/07/you-are-the-king-post-mortem-timelapse-video/

This is a timelapse of me developing the game "You are the king" for the Ludum Dare 48h game development challenge. In total I worked 30 hours and 34 minutes on the game. You can download the game and play it for yourself here: 

http://www.ludumdare.com/compo/ludum-dare-25/?action=preview&uid=7317

Dear readers,

I'll take part in the Ludum Dare game development challenge this weekend. Where I'll try to develop a working prototype in only 48 hours. You can watch the whole thing happening live and direct on my stream here: http://www.twitch.tv/naughtyloose

And here's my introduction post on the Ludum Dare website: http://www.ludumdare.com/compo/2012/12/14/im-in-1211/

In 2011 the Swiss government decided, for the first time ever, to fund a few indie games in Switzerland. Naturally I applied with the prototype of an aspiring and innovative music game called "the flight". All tough my application was rejected the video of the prototype was later on picked up by Kotaku. Much to my surprise.

The game concept behind The Flight was inspired by the graduate game of a good co-student of mine Daniel Lutz. His game was called “Float & Jitter”. It was a top-down shooter where the music generated an array of projectiles all in sync to different elements of the music. I was a huge fan of the concept and saw a lot of potential in it. So one day I asked Daniel if he would mind me developing a game around that concept. He didn't and so I started prototyping.

If you brake down the concept to its bare minimum you could say that it's a game where everything is generated by the music. This concept however has one fundamental design concern: Since everything is based upon a linear track what influence does the player have?

The first prototype used a sequencer where the player arranges certain musical elements which in return generate certain game elements when played. Like for example every beat sample fires a bullet when played by the sequencer. This worked fine but generated another more fundamental issue: Its rather difficult to make good sounding music if you don't know what you're doing. My concern was that players would just arrange random stuff on the sequencer and then will start to get bored if it didn't sound good. A musical composition often has a lot of work invested into it before it actually sounds great. I want the game to be a synaesthetic experience and not just something where you arrange samples in the most effective way in order to beat the game even if it sounds terrible. Realizing that there is no way I would be able to provide the player with the right tools and assets to generate awesome music in a game environment I went for another approach.

The second prototype was based upon the following concept: a complete visual game experience of a music track down to every last tiny beat. The inspiration was the crazy videoclip "Gantz Graf" from Autechre made by Alex Rutterford.

If you watch the videoclip you'll see that every tiny sound element is visualized in some way. And of course everything is perfectly in sync with the music. This is easier to do in a video because it'll always play back at the same speed and exactly the same way. But how can we get that much synchronization in a game engine?

My first approach was using a function in the game engine Unity 3D called GetSpectrumData. What this function does is it analyzes the currently being played audio data and brakes it down into an array of values using an FFT (Fast Fourier Transform). Its essentially what every equalizer does. You'll end up with some sample data which you then can use to check upon. Like for example if a sample in the lower frequency range goes above a certain trigger value you'll know a beat was played. I even made a small editor for this:

This worked relatively fine for simple tracks but what if there is a double beat? Or two beats who are very close together in the frequency range. It got really hard to filter out certain elements for the level of detail that I wanted. The fact that the data provided by the FFT is never exactly the same didn't help as well. So I went on to search for another approach. How do other projects and games do their music synchronization?

During this search I stumbled upon the "Music Animation Machine". Its a tool that takes Midi files and displays the notes in a very interesting and detailed way. Watching a demonstration really lets you see every note in perfect timing as the music gets played.

I also learned that Midi essentially is just a note sheet designed for computers with all the important pitch, volume, duration and timing data. So if I could tap into that data in the game engine I would have perfect control over anything that happens in the music. Combine that with a high quality mp3 file that plays in sync with the midi file and you'll have good sound quality as well. It looked to me that I found the perfect solution for what I wanted to do. An interesting fact that I learned later on is that the famous music game REZ, and a few others, does their music thing exactly this way. Another interesting benefit was that there would be little work needed for the musician to make his track work in the game since a lot of stuff in music production is already done using midi data. The downside however is that this technique prevents the players from using their own music library to play the game. 

So I went back to prototyping in Unity once more. Using a midi-plugin I was able to establish the basic functionality. The next problem was in finding a song that had a corresponding midi-file of the whole track (harder then you might think). Once this worked I was interested in doing a few experiments. I tried to recreate the famous video clip by Michael Gondry for Chemical Brothers track "Star Guitar".

Which worked pretty well. Another experiment was to have the notes fly towards the player and play them at a certain point (kind of like in Rock Band). The third experiment was to split the midi file up into three parts and use that data to display the flow of certain elements (high, middle, low). You can download these experiments here and try them out for yourself:

TheFlight_MidiTest_mac_and_Windows_Package.zip (190 MB)

So this is the current state of development. I'll keep iterating until I get things the way I want. Right now I'm still at the very basics. Like for example the midi tends to go out of sync so thats what I'm going to fix next. If you want to play the original prototype that used the audio spectrum analyzer you can download it here:

The_Flight_v0_1_Mac_and_Windows_Package.zip (198 MB)

If you rather watch a complete playthrough then playing it yourself, I got you covered:

In the 5th semester we were tasked with creating a multiplayer game in an engine of our choice. Realizing that I suck at programming and that writing proper net code is one of the hardest things to do I choose Valves Source Engine for my project. This allowed me to modify a very powerful code base, with great multiplayer functionality, while adding my own art assets.

Back then I used to play a lot of Garrys Mod and found one game mode to be very interesting. That mode was called Suicide Barrels and was made by Heyo. Its concept was very simple: a player is either disguised as an oil barrel that can move around and explode or the he plays as a soldier with a gun. The goal was to either survive, or to sneak up on your buddies and explode while laughing manically. Here is a video of the original mod:

I saw a lot of potential in that core concept and so I decided to recreate the core mechanics as a standalone Source Mod without using any art assets from Valve. I had two months time for that.

Since I studied at an art school we were not allowed to use any form of explicit violence in our games. So oil barrels eventually turned into shrubberies, inspired by the famous Monty Python sketch "How not to be seen": http://www.youtube.com/watch?v=zekiZYSVdeQ Guns turned into handbooks (Gardening for Beginners, by Barbara Bush) as a reference to knowledge is power and the fact that throwing books at plants is a rather silly looking endevour. Due to time constraints I simply re-used my very first 3D-Character model which I created in an earlier semester. Thats why the soldier model turned an slightly overweighted and chain-smoking WW2 pilot / gardener. I'm still a bit embarrassed by the ugliness and the many weight map errors on that model. But I guess it servers its purpose of creating a wacky game.

It was an intentional design choice to make the game a bit silly and cartoony. Specifically because the very nature of suicide attacks isn't something to make fun of. I further disconnected the game from any real world resemblances by removing such things as blood, death screams and flying body parts. While at the same time adding things like instant respawn, wacky sounds, lots of high contrast colors, goofy looking characters and low-poly 3D models. Early playtests showed that players really enjoyed the art direction combined with the sneaking/surviving.

It's a bit hard for me to remember a lot about the development process as this was back in November 2008 but heres what I still remember: I spent most of my time working in the huge code base of the source engine. Trying to figure out how to create new weapons and game rules among many other things. I also did a few recordings for the sounds and some sound editing of existing sound effects. Here are some interesting facts:

The squeaky boot sound of the survivors is originally from the movie "Spirited Away". Its the sound the radish-spirit makes when he walks around. I found the sound very funny and quite fitting for the game.

The "yalalala" scream of the bushes, when they use their speed boost, is actually my own voice. Most people mistakingly thought I stole the sound file from the game Postal.

Since I was going to disguise players as shrubs, the action had to take place in an environment where there is a natural abundance of shrubs. So they would be able to blend in. I did some research on gardening layouts and eventually decided to use one small part of the Gardens of Versailles.

Development was actually pretty straight forward and it all came well together for the first public play test in our class room.

People had a blast. Shortly after presentation in class I released Suicide Survival 1.0 on the Internet. First on a blog I made for the game and then on ModDB.com. I didn't do any publicity or press stuff in the beginning. Yet the mod got increasingly popular. Probably due to its uniqueness and because it was hilarious to play. Another thing that certainly helped to increase popularity was that once you told your friend that there is this new game where you are disguised as an exploding bush. You immediately got their attention (and their WTF's). Version 1.0 got more then 3'000 downloads.

About a month later I released version 1.1 with a few balance fixes and a few new maps made by fans. Until today version 1.1 has been download more then 45'000 times. Which makes me feel all warm and fuzzy inside. The game also got some pretty nice reviews:

"Suicide Survival is the best argument for user modifications since improving coke with whiskey: more fun, less likely to gain official support than a Care Bear firing range, and not for anyone who cares about professional skills. It’s madder than a Katamari rolling up Alice’s Wonderland and filled with more lunatic genius than Arkham Asylum. - The entire concept is more a testament to insane fun than LSD in an amusement park." - Lowpings.net

Suicide Survival Is genius, let's get that out of the way first. As someone who's hoping to go into a career in games development I can't help but stand in awe of the concept." - Gamesradar Community Member Review (7 out of 10)

"They are watching you. At home, at work, at school… you walk by them everyday, completely unaware of your impending doom. They lie in wait, ever vigilant, ever patient, awaiting the perfect time to strike you down. Take care, dear children, for your foes are as numerous as they are terrible. They are terror personified… they are death incarnate… they are… shrubberies." - Planet Half-Life Review

Unfortunately most of those reviews aren't online anymore.

Now while this all sounds fine and dandy, Suicide Survival wasn't without its flaws. The game is quiet entertaining for about an hour. After that the it gets pretty repetitive and boring pretty quickly because there isn't much else to do. There are no real objectives or goals in any of the maps which dumbs the game down to simply team deathmatch. Also there is only one weapon available for each team which further hinders any kind of dynamic gameplay. This is the main reason player attention has declined a lot after the initial rush. None the less I'm pretty amazed that people still download and play this until today. Essentially its a lot of fun on LAN-parties or with a couple of friends once in a while.

I hope this was informative and not confusing. I'm still not too sure about what exactly I should write on this blog so for now I'll just keep writing what comes to my mind. If you want to stay updated on the development of Suicide Survival you should follow the main site: www.suicide-survival.com or my Twitter feed. Of course you can always download and play it yourself. See the requirements here.

I'm going to wrap this post with two gameplay videos:

Doppelscope was my thesis game in my undergrad program at the University of the Arts, Zurich. It's an abstract puzzle game where you have to bring each world into balance by making the right connections. Even tough the game received the very low grade D, it won the Unity Awards 2009 in the category Best Visual Design.

The game has gone trough a lot of iterations. More so on the visual side then gameplay wise. I'll try to write down some of these and the current issues I'm having with the game.

In the beginning I wanted to create a very dynamic world contained in a small space. A place where the player can change certain parameters and watch the changes happening in the world. I also wanted to create a very unique and stylized visualization. Something I had a pretty clear picture of in my mind.

What I was totally unsure about tough was how to do the player interaction and what kind of story the game should have. I knew I wanted to keep the interaction as simple and obvious as possible. But I wasn't too sure about everything.

One of the earlier prototypes had a third-person styled gameplay where you control a protagonist that can switch between two views (visions) of the world. One in which he can influence things and one where the actual objects are displayed. Here are some screenshots:

Now you may think: Wait a minute! this sounds and looks awesome! Why did you change it?

And the answer is very simple: I realized I lacked the time to do it properly because I would've had to model and animate the character on top of all the other work. I worked alone and did everything myself. Since I'm not a very good programmer I didn't wanted to waste my time trying to make something very complicated. We only had like two full months of time for our thesis game. Also I felt that this wasn't the right way to portray the game world and that the movement interactions we're too complicated for some people. Or in other words: why make something very complicated when you can make it a lot easier to play. At least thats what I thought back then.

So I searched for a solution and got inspired by the art of Josh Keyes:

Some of his drawings are like a scientific cut-outs of certain elements of our daily life. Arranged and displayed in an artifical way. So thats where the cubical world comes from. I wanted to an actual 3D mask that would've allowed me to fade stuff in and out of the cube bordes. But I didn't find a good way to do it in Unity. Note: time versus complexity.

Another thing that changed was how the player switches between the two worlds. The world is completely mirrored vertically. Just like a perfect reflection on calm water. The player switches views by simply rotating the camera to the other side. There are some additional effects when passing over the horizon to emphasize the transition.

The view on the mirrored side:

Which brings me to one of the core problems with Doppelscope: The primary gameplay mechanic of changing the connections between things.

In the first prototype players could change connections by holding a button which pulled the nearest connection towards their character and then walking to a new connection point. Upon releasing the button the connections would simply search for the nearest possible connection point and use it as their new target.

In the final version connections always flow to their target point unless a possible connection is within range. Players change the connection by dragging the target object towards a new connection point on a 2D plane in 3D space. Which is a very bad idea because stuff like this is only obvious to you if you've worked in 3D before. What usually happened was that players didn't get why they could move the target object only in a certain way or that it will stick to the closest connection point. This also gets increasingly difficult if the camera is at an odd angle, and sometimes its very hard to tell the position of the target object in relation to the connector you want to drag it to.

Now while most of these things sounds very simple and logically if someone explains them to you they evidently are very cryptic. I mean I wanted the game to be that way initially. I wanted players to experiment and find out how the game works by themselves without some big tutorial text explaining everything. But what I realized was that only a few players actually enjoyed figuring it out and that my interaction methods really were way to cryptic. For example: it makes sense that trees need water to grow right? But it doesn't make sense that I have to drag a floating ball towards the tree so it'll get water. I realized that making these things as obvious as possible is pretty damn hard especially when you're trying to create something unique. None the less I still believe the core concept of Doppelscope could be a fun experience and I am currently working on a prototype for iOS devices. So stay tuned for that. :)

To conclude this pretty lengthy post here is a complete play trough video of the game:

As well as the original documentation for my school back from 2009: DOPPELSCOPE_Documentation_2009.pdf 

In one semester during my Bachelor degree in game design we had to pick our favorite game and analyze its internal mechanics. I worked together with my co-student Dario Hardmeier and we choose the game Magic Carpet. It was a pretty popular and innovative first-person shooter released in 1994 by Bullfrog.

In the game you fly around on a magic carpet and kill monsters that drop mana. The mana gets transported into your castle by a balloon. You win each level be gathering enough mana. The amount of mana you have also influences what spells you can use and how often you can use them as each spell cast costs mana. On later levels there also are rival magicians on magic carpets that fight you for the mana in the world. All in all it was a pretty awesome game with a lot of dynamic gameplay.

In our documentation we looked at every aspect of the game. From menu navigation over how levels are built to the game mechanics behind the mana gathering. I'll give a few excerpts of the most interesting ones from the document.

The graphic above tries to visualizes the way levels are laid out in Magic Carpet. Maps are 2D textures and since there are no borders or invisible walls in the game the edge of each level gets replicated creating an endless-loop. So if you keep flying into one direction you'll end up in the same place you've started from. The obvious representation would be a sphere but since the level maps are 2-Dimensional square textures there would be a lot of distortions. A torus works a lot better to visualize this technique in 3D.

I find this a very practical way to simulate an open and vast world while at the same time preventing issues like getting lost or being blocked by invisible walls.

Each level can be divided into the following layers (Ebene is German for layer):

Water layer, the lowest one.

Terrain and obstacles like walls.

Buildings like NPC houses as well as trees and other static objects.

Monsters and NPCs.

Trigger zones and new spells.

Player, enemy magicians including their castles and balloons as well as all non-creature-bound mana.

The most interesting mechanic behind Magic Carpet however is the mana principle. The mana functions as the very basic source for scoring as well as for all the spells. This mechanic can be broken down into the following three rules:

The total amount of mana in each level never changes.

Mana can be bound in a container or be free at any time.

Mana can change its membership (color) at any time.

This generates the following gameplay example: The player increases his mana-pool (score) by releasing (killing) bound mana from monsters and changing its membership so it'll get picked up by the players balloon and transported into his castle. Increasing ones mana-pool allows the player to cast more powerful spells and also to cast them faster as he has more mana available. Which in return allows him to kill bigger and stronger monsters containing even more mana.

Because the total amount of mana never increase or decrease it often feels like a game of American football as you fight over each piece of mana against up to eight rivaling magicians who are also trying to get their mana safely into their home base. As you can see this generates a lot of dynamic gameplay from a very simple rule set.

The flow-chart above visualizes each state a piece of mana can be in. Some explanation on the cryptic icons: Top-left is the castle container followed by the balloon on the right of it. Below that is the mana with its membership set to your color. Followed by neutral color and then enemy color, etc. On the right side are the states of NPC buildings as you can change their membership as well (and even get mana from it!).

I've decided to start this blog by going through my old work and hitting my readers with a huge wall of text that is my old thesis paper back from 2003. Its a 72 page long PDF called: "Effective Teamwork in online Games". The thesis of the paper is:

“Effective teamwork in online games can be achieved with the right game mechanics and design choices. It's not the players fault that no teamwork takes places”.

The first part gives an overview of the multiplayer games that were available in 2003. The second part tries to analyze the teamwork of those games with gathered player data. To the paper belongs a pretty extensive survey regarding teamwork that almost 5'000 people filled out. Being the young and naive aspiring game designer that I was back then most of these questions can't be used for proper data collection. But they still give some insight into their multiplayer preferences and experiences. The third and last part of the paper tries to provide some ideas and gameplay mechanics that help to provide the player with an environment for effective teamwork. Interestingly some of those ideas were implemented into Battlefield 2. If that was merely a coincidence or because of my paper, I don't know.

Looking back on the paper I feel a bit embarrassed by my own naivety and style of writing. But I guess we all started somewhere. That being said I still believe the thesis holds true to some extent but I also believe that some players just don't want to work in teams even though they're playing a team game. So we can't blame the game mechanics entirely for bad teamwork.

Hi, my name is Tobias Baumann and I'm a game/visual designer from Switzerland.

I've studied Game Design at the University of the Arts in Zurich and this blog will mainly be about my work as an independant game developer. After my graduation in 2009 I did a lot of freelance work as web designer, VFX artist and hosting websites with some game prototyping on the side. Recently I've come to realize that I essentially was wasting my time with boring work instead of focusing what I really want to do: developing highly polished and innovative games. So I've decided to abandon my past workload and focus all of my time on game development.

Because I'm usually a pretty shy person and find my work dull and boring I've kept it to myself. But then again I realized that this may not be the case at all and that some of you actually might find my work pretty interesting. So this I'll post a few of my games and working prototypes on here along with some commentary about game design choices and issues.