Lockpicking mechanic

I've been playing around with an idea for my own lockpicking mini-game (obviously influenced by Bethesda's). The clou behind this one is, that it is heavily dependent on player skill. Although the lock difficulty influences the lockpick tolerance, a player with enough skill/training can open any lock at an instant. At the moment input is only possible via controller (two analog sticks). Play in Unity Webplayer (Game controller is required!)

Pirates of the Deep Space

Pirates of the Deep Space was a game installation performed at the Ars Electronica Festival 2011. The project is the successor of the HEIST project.

Two players could compete in their pirate ships to destroy the other one's - thus gaining control of the archipelago.
Players controlled their ships movement by positioning themselves on a bar, affecting their ship's course. Each player had a small miniature of their ship in front of them, divided into 3 pieces. These pieces represented the ship's healthpoints.
If a player could see the other player's ship on his screen, he could start throwing cannonballs (sand filled rubber balls) at the enemy's miniature ship. To reload a player had to abandon his ship for a short time and regather his cannonballs. A player had won when the other's miniature ship was destroyed.

the team

the level (the skull even has LEDs)

interface with miniature ships

Apart from capturing the webcams integrated in each ship and playing soundfiles, each part of the game was executed by team members. In pairs of two team members per ship, one was announcing the other which way the player steers the ship, while the other constantly moved the ship forward - adjusting it's course.
The archipelago was created out of painted and decorated Styrofoam chunks - spending my younger days with Warhammer miniatures and terrain finally paid off.
The island were placed on a colored wooden plate, allowing us to change the leveldesign from play through to play through.

Check out the videos below!
The one on the left shows how players were controlling the game, the one on the right what actually happened 'ingame'.

The team consisted of students and lecturers of the University of Applied Sciences Upper Austria, Campus Hagenberg.
The name 'Pirates of the Deep Space' comes from the place in the Ars Electronica Center where the game took place - the 'Deep Space', a huge room with 4 HD projectors directed on projection areas on the floor and up front.

HEIST

the guard units

HEIST was a course group project for the 'special topics' course at the university. The goal was to create a playable game prototype, without using any art assets or programming. The user(s) would sit in front of a computer and give 'normal' orders. These had to make an impact on the game asap. Each of the team members took over some actions and calculations the game would normally do by itself and converted them to ingame actions.

In HEIST two players were competing against each other. One is a thief trying to steal something from a specific room in the gameworld he did not know initially. The other is the security chief who is commanding two guards and trying to catch the thief.

The players would only see what their characters see (first person view) - which was implemented using webcams walking through the level. As the security chief would see the views of his two guards and two static security cams, the thief would only see his view plus he could hack in one guards transmission.
A map with updated positions of this players units made navigation easier.

The thief could hide in rooms whereas guards could check rooms. These actions of course consumed some time. And time as well as timing were an important part for this game to function.
The players controlled their units via voice commands. The numbered doors were used as waypoints (e.g. 'Guard 1 goto door 4!'). To prevent hearing the other players command, each one had a pair of headphones playing an increasingly dramatic music.

If a guard would see the thief, the game was over. Though the webcams were directed slightly downward to prevent a to broad cone of vision.

the 'computer' at work

our level with numbered rooms

the security chiefs view

The advantage of prototyping your game ideas this way is obvious.
In most cases it is very quick and effective. Thou it's not perfectly accurate (camera is stuttering, latency...), it hasn't to be - you just want to test if it's close to the experience you want to create. And of course you can change vital parts of the gameplay on the fly. So if a part of the level would be to easy for player A you could just rearrange it quickly between two rounds.