The CAREN: Walk Again

ReLoop: Walk Again

The CAREN is an advanced hardware and software system for registration, evaluation and training of functional human behaviour. One of these impressive machines is located at the Military Rehabilitation Center Doorn and is developed by Motek Medical.

ReLoop is an application that stimulates the patient to make steps in specific ways, without them consciously focusing on walking. With every step a part of a virtual, abstract environment is revealed, motivating patients to keep on walking.

The Dutch Department of Defence asked us to design and develop an application for CAREN that is capable of changing a patient’s walking pattern or helping redevelop his or her ability to walk by making a fully immersive experience. Help them temporarily forget they are rehabilitating and give the therapist full, but indirect control over patients exercises.



The CAREN consists of a flexible plateau in where a treadmill is build. This plateau can tilt, yaw and move up and down. Because of this you can simulate for example walking up a mountain or a bumpy road. In front of the plateau is a 180 degrees projection placed which can show a 3D environment. infrared (IR) cameras placed all around the plateau. Lots of very reflective dots are strategically attached to the rehabilitant to reflect the IR light back to the cameras. These dots are so bright on the captured image that they can be separated from the surrounding environment. This can be used to analyse the walking movements.

The Application: ReLoop

ReLoop puts the patient in an abstract and colorful world and each new step illuminates the environment around him. The more the player plays the more music and visual rich the world gets.


ReLoop In-Game ScreenshotReLoop In-Game Screenshot

While walking may be nothing special to anyone that is not physically impaired, it’s an exhaustive effort for someone with – for example – a prosthesis or a cognitive impairment. To develop his or her ability to walk, we took ‘step by step’ literally; with each step the patient takes, a light beam appears in the direction the step was taken.

Lightbeam in Action

Hitting certain checkpoints with this light beam reveals parts of the world, so hitting these functions as a reflection of how the patient is doing. These checkpoints can be placed in specific patterns in real-time by the therapists thus steering the way the patient takes his step.

Julien Ranzijn – Interaction Design & Programming
Remco Meinsma – Coordination
Rob van Duinen – Interaction Design & Concept
Justin Grupper – 3D and Concept Artist
Glenn Verheij – Environment Artist

UMU: A Helping Hand For Busy Parents

UMU is a project by Bright

Children are born adventurers. Everything is new and with great enthusiasm they explore the world around them. As a parent it’s your job they can do this safely. However; it’s not your only job. (by a long shot) This is why ụmụ helps you pay attention at the right time. ụmụ is highly accurate; down to the meter, works indoors, has a battery life of 6 months and is context aware.

News Update #56: Road To Overlord Part 3/3

Original Source: Traction Wars

Traction Wars is a PlayforFree WWII Tactical Teamplay Multiplayer Game.

The game brings a vivid and realistic representation of the Second World War to your screens using the stunning CRYENGINE. The game dynamics & balancing are designed to inspire a teamwork orientated tactical style of gameplay which rewards players who work together closely as a single fighting unit.

Following our discussion on some of the design behind the game in Part 2, in this update we continue our in-depth look at the mechanics which will give Traction Wars its unique and authentic gameplay experience.


Each team is divided into squads of eight players known as a “Section”. Each section is lead by a Section Leader who directs the group in the field to provide coordination and a focus to the other section members.


The Section Leader has at their disposal several unique tools to direct and support the squad in combat. These tools include the ability to mark objectives on the map, call in off-map mortar support, and placing of rally points to act as forward spawn location for the section as they advance.

The screenshot below shows the near final interface design which will be replacing the current placeholder interface used in Internal Alpha testing. The map you can see is the internal “mini” version of Pegasus Bridge which we use for testing. The full 32-player version will be released in OVERLORD.

In-Game Menu Concept For Section, Role and Spawnselection

Player Classes

The same interface is used for the selection of the players role in the section. Once players have selected the Section of their choice they can select from the available roles in the middle column.

In addition to the “regular” roles such as rifleman, more advanced and specialist roles are available on a limited basis.

Each of the four maps in OVERLORD will have slightly different role configurations depending on the historical events of the battle.

The most specialist roles (e.g. marksman) are only available to near-full squads and on a very limited basis. Each section will almost always have more than 8 roles available to choose from (e.g. up to 5 riflemen, 3 assault, 1 support, 1 engineer & 1 marksman = 11 roles). The result of this flexibility is that players will often be able to change their role in the game without having to leave their section-mates for a different section.


That’s all for our first look at some of the game design of Traction Wars. We are always on the lookout for fresh talent to join the team. If you think you have a skill which might be useful to us please head over to our recruitment page for details of our open positions, just like the one highlighted below.

Operation Deadstick: Pegasus Bridge

Original Source: Traction Wars

Traction Wars is a PlayforFree WWII Tactical Teamplay Multiplayer Game.

The game brings a vivid and realistic representation of the Second World War to your screens using the stunning CRYENGINE. The game dynamics & balancing are designed to inspire a teamwork orientated tactical style of gameplay which rewards players who work together closely as a single fighting unit.

At 2256hrs on the 5th of June 1944 six Horsa Gliders, towed by Halifax bombers, took off from RAF Tarrant Rushton in Dorset, starting the events of the allied invasion on D-Day. In the Gliders were 181 men from the 6th Airbourne division “D Company”, led by Major John Howard.

Their aim was to capture two bridges. Success would prevent a German counter attack on the eastern flank of the D-Day landings at Sword Beach. Failure would leave the men isolated in enemy territory and make the already risky D-Day landings vulnerable to German Panzers.

At 0016, five of the gliders landed within 50 feet of Bénoville Bridge. When Howard’s glider hit the ground, it jolted the men. Everything went black for Howard and he thought he had gone blind, until one of his men pointed out that his helmet was covering his eyes.

Travelling by glider enabled the British to surprise the German troops defending the bridge. Within 10 minutes of landing, following a fierce gunfight, the British were able to secure not only Bénouville Bridge but also the nearby Orne Bridge. Thus, 90 minutes after taking off, Major Howard was able to send the code words “Ham and Jam” to indicate the successful capture of both bridges. The victory was perhaps the “single most important ten minutes of the war”.

The swift victory gave the men two hours to prepare for the German counter attacks and to defuse the explosives that laced the bridge, placed there by the Germans in case of attack or an allied advance.

2015.07-1_06 (1)




cache (6)


My Coding Style Guide

Consistency is important. It’s importent when designing and even when writing code. So it’s good to have some sort of guide to help you. I made my own based on multiple guides I found on the internet and my own preferences/experiences. Currently this one is for C++ – as I code mostly using OpenFrameworks – but it can be used for other languages like Java or PHP.

// Coding Style Guide
// Based on

// All names should be written in English.
// NOT: bestandsNaam;

// Class names are writen with CamelCasing starting with a capital
// File names shoud match there class names. "ClassName.cpp", NOT: "class_name.cpp"
class ClassName 


// A class with a word like "HTML" is also written with CamelCasing
// NOT: exportHTMLSource();
class ExportHtmlSource


// Private class variables should start with an underscore suffix.
// In general, the use of global variables should be avoided.
class SomeClass 
		int width;

		int height;
		int _length;

// If-else statements
if ( a < b ) 

// Mulit line if-else if ( a > b ) 
else if ( a > c ) 

// For oneline if statements short version is allowed
if ( a > b )
	doThisFunction( c ); 

// For loop. Use i, j, k, etc for iterator variables
// Variables named j, k etc. should be used for nested loops only.
for ( int i=0; i<10; i++ ) 

// Complex conditional expressions must be avoided. Introduce temporary boolean variables instead
bool isFinished			= (elementNo < 0) || (elementNo > maxElement);
bool isRepeatedEntry	= elementNo == lastElement;
if ( isFinished || isRepeatedEntry ) 

// Defining functions using camelCase with small starting character
// Use a "_" after the attribute variables to show there are attributes
// Like class namings stuff like "HTML" is written as "Html". NOT: thisHTMLIsMyFunctionName
void setPlayerPosition( int x_, int y_, int z_ ) 
	playerPosition.set( x_, y_, z_ );

bool thisHtmlIsGood()
	return true;

// If a function is called in de code make sure there a spaces between the "(", ")" and ","
thisIsMyFunctionName( mouseX, mouseY, mouseZ );

// Names representing namespaces should be all lowercase.
model::analyzer, io::iomanager, common::math::geometry

// Names representing types must be in mixed case starting with upper case.
Line, SavingsAccount

// Variable names must be in mixed case starting with lower case
line, savingsAccount

// Variables with a large scope should have long names, variables with a small scope can have short names 
x, y, z
posX, posY, posZ

// Constants are written with all capitals and words are seperated with underscores
// In general, the use of such constants should be minimized.
#define THIS_IS_A_CONSTANT 11500

// The name of the object is implicit, and should be avoided in a method name.
// NOT: line.getLineLength();

// Plural form should be used on names representing a collection of objects.
vector  points;
int            values[];

// The prefix n should be used for variables representing a number of objects.
nPoints, nLines

// The suffix No should be used for variables representing an entity number.
tableNo, employeeNo

// Variables representing GUI components should be suffixed by the component type name.
mainWindow, propertiesDialog, widthScale, loginText, leftScrollbar, 
mainForm, fileMenu, minLabel, exitButton, yesToggle;

// The prefix is should be used for boolean variables and methods.
// Negated boolean variable names must be avoided. Example "isError", NOT: "isNoError".
isSet, isVisible, isFinished, isFound, isOpen

// There are a few alternatives to the is prefix that fit better in some situations. 
// These are the has, can and should prefixes:
bool hasLicense();
bool canEvaluate();
bool shouldSort();

// Floating point constants should always be written with decimal point and at least one decimal.
// NOT: double total = 0;
float total = 1.0;

// Complement names must be used for complement operations
// Examples: get/set, add/remove, create/destroy, start/stop, insert/delete,
// increment/decrement, old/new, begin/end, first/last, up/down, min/max,
// next/previous, old/new, open/close, show/hide, suspend/resume, etc.

// Abbreviations in names should be avoided.
// NOT: compAvg();
// Examples: never write "cmd" instead of "command" or "cp" instead of "copy"

// Group variables by type
int 	x;
int 	y;
int 	z;

char 	a;
char 	b

bool 	isBool;

// The terms get/set must be used where an attribute is accessed directly.
employee.setName( name );

// The term find can be used in methods where something is looked up.

// The term initialize can be used where an object or a concept is established.
// The american initialize should be preferred over the English initialise. Abbreviation init should be avoided.

// Structs are named the same way as classes
struct Stop 
	string name;

// Vector lists, for example a struct or class, should be writen like:
vector stops;

// Use appropiate variable types
// signed char 			: -127 to 127 (note, not -128 to 127; this accommodates 1s-complement platforms)
// unsigned char 		: 0 to 255
// char 				: -127 to 127 or 0 to 255 (depends on default char signedness)
// signed short 		: -32767 to 32767
// unsigned short 		: 0 to 65535
// signed int 			: -32767 to 32767
// unsigned int  		: 0 to 65535
// signed long 			: -2147483647 to 2147483647
// unsigned long 		: 0 to 4294967295
// signed long long		: -9223372036854775807 to 9223372036854775807
// unsigned long long	: 0 to 18446744073709551615

// Exception statements
catch( ExceptionName e )
	cout << "[exception] " << e << endl;
Traction Wars Motion Capture Day - Maniche In Action

Dev Blog #17: Traction Wars in Motion

Traction Wars is a PlayforFree WWII Tactical Teamplay Multiplayer Game.

The game brings a vivid and realistic representation of the Second World War to your screens using the stunning CRYENGINE. The game dynamics & balancing are designed to inspire a teamwork orientated tactical style of gameplay which rewards players who work together closely as a single fighting unit.

Hello there my fellow Traction Warriors and welcome to another Traction Wars development blog. In previous updates we have shown some of our “Work in Progress” first person weapon animations, but today I want to talk about the third person, full-body animations such as running, crawling and jumping.

Animations are not my main task and I’m normally working on different things but once in a while I encounter interesting technologies due to my current stay in Sweden. This time I came across a room which caught my full attention. The room contained a fully operational high speed motion capture system, also known as Mo-cap. The first thing that came to my mind was: “**** ****, we need this for Traction Wars”. Using my superior seduction techniques on the person in charge I managed to get a reservation to use this fascinating piece of equipment for a full day. I immediately called up fellow developer [TWDEV] Maniche, who drove the three hundred kilometres from Norway to help me out.

[TWDEV] Maniche lurks in the undergrowth of the Mo-cap studio.

We humans are so used to body movements like walking that it is very easy for us to spot flaws in artificial animation. This makes creating full body animations an incredibly difficult and time consuming task, often taking days or weeks just for a normal walking loop. It is challenging to find the right balance and weight to make a full-body animation feel as realistic as possible. Because of this, Motion Capture is used heavily in current games and movies.

The commercial grade Mo-cap system uses eight infrared (IR) cameras placed around the subject; in this case [TWDEV] Maniche due to his military experience. Lots of very reflective dots are strategically attached to the subject to reflect the IR light back to the cameras. These dots are so bright on the captured image that they can be separated from the surrounding environment. Due to the use of multiple cameras precision of movement can be calculated to an accuracy within 0.2 millimetres, 120 times a second.

They are strategically attached to the subject enabling realistic motion to be captured.These small white dots reflect infra-red light back to the cameras around the room.

During our capture day we tried to get as close to the real movements as we could. Using weights, a full sized rifle prop and help from [TWDEV] VonMudra during a live Skype call, helping us with the correct way weapons were carried and used. From grenades to heavy machine guns, running, climbing and setting up – we went through as many movements we could think of. It was good to see [TWDEV] Maniche running around getting tired while I pressed the right buttons and verified the captured data so anything could be re-done if something went wrong.

We look forward to showing the processed Mo-cap animations on our in-game characters in the future. Until then, stay tuned for more development updates. And thanks for reading!

Interested in joining the team?
The team is currently looking to recruit 3D Artists, Particle Artists and C++ Programmers in addition to a couple of other areas. If you have experience in game/mod development and are interested in being part of our friendly and professional team then please head over to our recruitment page for full details about the team and available positions.

For the very latest media and updates follow us on Facebook, Twitter, YouTube and Steam, as well as our community forum or media gallery.

Balance Board

Gamified / Interactive Balance Board

Rehabilitation isn’t fun and no one will do it when it’s not needed. But there are times that you’re just forced to. In one of these ocasions it can happen you have to rehabilitate using a balance board. During my time at Interactive Institute we tried to come up with a way to make rehabilitation using the balance board more fun, engaging and find a way of showing the progress you make during the exercises.

To find the answer of these questions we ordered a couple of balance boards and started to exercises ourself. We confirmed that it was not really fun to do. To see of this was really the case we talked with people who used a balance board to train. I was surprised how many people were using them and the variety of age groups.

With this new knowledge we started brainstorming and one of the first things that came to our minds was; what if we made a game controller out of this board? Using sensors inside we could connect it for example to a computer or console and make games for it. The gameplay of the games would be based on real exercises. It could be a great way of showing progress as you could try to improve your highscore.


We build one prototype with lots of duct tape and one high fidelity prototype with all electronics nicely worked away. The final version looked like a normal balance board. Expect when you turned it on, it illuminated the ground around it with strategically placed LEDs. These LEDs we used to communicate the gestures of the games.

Putting the final touch

Prototype oneBottom side

The final prototype contained a Teency microcontroller, a Bluetooth communication chip, a motion sensor so we could see the boards global position and orientation, a battery and a lot of LEDs. All these part were nicely worked away inside the balance board.

Lets Game

After the completion I started working on two different game concepts. Both were based on actual exercises used by patients.

The first game was called Planet where you as player are a small planet in space and you have to protect yourself from incoming asteroids. You could destroy these incoming projectiles by balancing as steady as you can which charged up a forcefield. You could release this force field by tapping a egde of the board on the ground. This released the forcefield and destroyed all objects around you. But you had to get back up as quickly as you could to recharge your field again for the next incoming wave. The goal was to stay alive as long as you could with every wave getting harder and harder containing different types of asteroids you only could destroy by tapping the ground on the “right” side.

The second game was also all about survival. You controlled a small planet by balancing forward, backwards, left or right like the arrow keys on a keyboard. Your goal was get as big as you could by “eating” smaller planets but avoiding the bigger ones.

Both these games used an abstract style to make the game accessible for different target groups as the style was not connected to the real world. This is something I discovered during my previous project for the dutch army where we also encountered a variety of age groups and it worked rather well.

Board at dark

Though gameplay wise both games were very hard as I didn’t had the time to playtest them properly and it would definitely take weeks or months to make them perfect. But it was not about making a game but creating a “proof of concept” to achieve our goal; Making rehabilitation more fun and engaging.

Did we achieve this goal? I think we did though it needs much more playtesting to make the games really good. I can make a basic game but I found out that it I’m not really a gamedesigner and I don’t want to be.

Julien Ranzijn – Concept, Game Design & Programming
Gunner Oledal – Hardware & Programming
Made during my time at Interactive Institute in Göteborg, Sweden

Playing with your buttons

The search for the meaning of Interaction Design; What is IxD?

I and Rob van Duinen are on a quest to find the true meaning of Interaction Design. We think you can’t simplefy IxD to one sentence or can we?

I think part of interaction design is designing interesting and usable interfaces. Making them accessible, easy to understand and good looking. If these things are carefully put together the result can be quite satisfying. But, there is something extra that can enhance the users experience they get from using an interface.

A while ago – when my iPhone was still alive – I found myself opening and closing the notification center over and over again. Swiping with one finger, two or all fingers to see what would happen. I did the same thing with the chat bubble from Facebook, throwing the pictures of friends all over the screen. These things didn’t make the interface more efficient or useful but added something extra. I was experimenting, I was…


We like to fiddle with our hands. Toying around with pencils, small pieces of paper, folding, breaking, especially when we’re bored. So why not give users a way to toy around? It doesn’t need to have any game mechanic. Looking at how real world physics can be applied to buttons in your interface can do the trick or even very small animations.

The tiniest of details can make a good design. So…

Can I play with your buttons?

Traction Wars HUD Update

Traction Wars Dev Blog #15: Heads Up!

Hello, I will be sharing some design details of the Traction Wars HUD. I’ve been working on Traction Wars since 2010 but you haven’t seen a lot from me although I like to call myself the interaction designer of the team. For those of you who don’t know what that is, it’s about designing experiences, how the game communicates with you and ensuring you are completely immersed in the game.

Games work in a certain way so you can’t always compare them to real life. They should be treated as two different things and you can’t just copy what’s out there in real life. For example, your field of view in the real world is roughly 180 degrees and you can’t see sharply at the edges though you can recognize movements. This peripheral vision is very handy if there is any danger, like an approaching bear or tiger. In games you lack peripheral vision and your field of view is only +/- 60 degrees. This means you have a hard time getting all the information you need because you have less spatial awareness with the result that the player needs some form of help. This is mostly done in game by graphical elements placed on your screen, which is known as the HUD or Head-Up Display.

Now it gets more complicated. Traction Wars is focussing heavily on realism. In the real world you don’t have a HUD telling you stuff so we’re looking for the right balance between the real and virtual world. HUD will have a big impact on immersion (i.s. how involved you are) and gameplay.

Traction Wars HUD Progression

Traction Wars HUD Progression

Since I joined Traction Wars three years ago there have been many forms of our HUD. It’s impossible to get it right the first time. To find the right balance we have been testing and researching a lot of ideas, from showing a lot of information to almost nothing. We are trying to show as little information as possible but as much as is needed. The more we can implement in the game itself with animations and visual feedback, the closer we can get to the real world.

Current HUD Design

Current HUD Design

So let me explain what you see here. It’s our current version of the HUD, which during play is not visible. When you press a certain key the HUD appears and when released it disappears again. HUD only shows a mini-map and compass, which are there to give you a better spatial awareness. They show your position relative to friendly players and important features of the map. Team-mates will only be shown when directly in view without any obstacles between you and them. These icons will slowly fade away when losing contact although things like objectives and orders will always be visible. To orientate properly you’ll have to pull out a physical map, so you can’t use your weapon at that moment -just as in real life. Depending on your class you’ll have a more or less detailed map.

Telling team-mates where to look at can be difficult. If someone says “Look left”, you’ll probably not look to the correct “left”. That’s why we incorporated a compass, making it easier for your team-mates to look in the right direction and not get themselves killed.

As you may notice the mini-map and compass are placed on the bottom left. This corner of the screen is mostly blocked by the player’s arm, so it is a perfect area for something like the mini-map. The rest of your view isn’t blocked so it is optimal for checking your surroundings.

On the right we have the magazine counter. This shows the total amount of magazines, grenades or belts the player has left. The amount of bullets left will not be shown as players can keep count for themselves – again as in real life.

There have been almost three years of HUD iterations and it is still work in progress so it may see changes before release. I would love to hear some feedback from you. Feel free to criticize but please try to explain your criticism. This makes it more useful.

There is much more to talk about. Stuff like squad-command order system, the soldier immersion system, suppression, health, hit orientation, moral systems, fancy menu’s with shiny buttons and more. So keep an eye open for more dev blogs and thanks for reading.

Interested in joining the team?
The team is currently looking for level designers and particle artists who have experience in CRYENGINE. If you have the experience and are interested in being part of our friendly and professional team then please head over to our recruitment page for further details.

For the very latest media and updates follow us on FacebookTwitterYouTube and Steam, as well as our community forum or media gallery.

Rendez-Vous: Meet through Motions

Rendez-Vous: Meet Through Motions

Download Rendez-Vous Design Document.

(Currently only available in Dutch)

Rendez-vous is a concept application for the Dropstuff “Kinect Art Challenge 2013”. Rendez-vous was one of the winning concepts that got exhibited at 55th Biennale in Venice & ‘Games and Biz’ symposium in Antwerp.

New technologies allow people to be closer together then ever before. The relative distance is getting smaller and smaller. The Kinect Art Challenge proves this once again by setting up two huge screens. One in Venice and one in Amsterdam. Which people from both cities can get a spontaneous and interactive experiences to meet each other.

We want to show the encounters between people in the purest form. These encounters lead to unexpected and spectacular outcomes. Users shall see themselves as sand men. When they encounter there sand will burst and leave an imprint on the screen. Creating at the end one big piece of art through there motions.


Julien Ranzijn – Coordination, Interaction Design, Concept & Programming
Fabian Heeres – Programming
Joost van ‘t Hoff – Music & Sound
Denise Gahler – Choreography
Jason Schot – Website & Interaction Design
Ruben Bernhardt – Mobile Website
Suzanne Bon – Concept
With special thanks to Dropstuff.

Back to home
Julien Ranzijn Interaction Designer
Julien Ranzijn Interaction Designer