This module gives its students an opportunity to study various topics related to video games.

As the name of the module implies, we had to study a specific case, which has been the 'SmartFloor' for our group. This invention consists of a pressure sensitive floor with 36 panels and two projectors for displaying something on both the floor and a screen in front of it. With that, it's possible to determine the position of a person on the floor and the amount of pressure caused.
In particular, the module was about developing a new game concept for the SmartFloor and demonstrate how it would work by creating a game prototype. But before doing that, we were also asked to research about game engines, activity games and the Internet of Things. As an exchange student, I've got a smaller task to do because this module normally lasts two semesters: I developed a small prototype that can be played on the computer without using the SmartFloor. Two players can interact with the game via two different keyboard assignments. I also researched about the activity games topic, where I focused on the Nintendo Wii as an example.

Researching about the topic

Here you can read my research about activity games on the Nintendo Wii!

Finding an interesting idea

As you may already noticed while reading through my research about activity games, I'm quite the Nintendo fan. And of course, I was inspired by a very recent game of the Japanese company: 'The Legend of Zelda: Tri Force Heroes'. This is a multiplayer game that allows the user to connect with other players and solve many puzzles in several dungeons together with them.
Because I try to connect things of which I'm enthusiastic about with my work wherever possible, I thought it would be fun to develop a game in which the player explores dungeons together with other players on the SmartFloor! But for this to work, all players would somehow have to share the space on the SmartFloor by only moving within predefined areas. Otherwise, the SmartFloor game wouldn't be able to distinguish who is who. But if each player has his own area, the system would need to convert the player's position within that area to the playable character's position in the virtual room because he still should be able to explore the complete room and not only a small area of it. We considered many ways to implement a camera scrolling mechanism until we found a quite good solution, which I visualised as follows:

Visualising the concept

The idea was to convert the position of the players as follows:

  character1sPositionInRoomAtX = player1sPositionOnSmartFloorX x 2;
  character1sPositionInRoomAtY = player1sPositionOnSmartFloorY;
  character2sPositionInRoomAtX = (player2sPositionOnSmartFloorX - smartFloorWidth / 2) x 2;
  character2sPositionInRoomAtY = player2sPositionOnSmartFloorY;

But in action, this is sometimes hard to imagine, why I created this short animation:

After seeing this, it's probably easier to imagine. Basically, all movements on the X axis are reproduced in the virtual room twice as fast as movements on the Y axis, since each player only has half the SmartFloor on the X axis for his own movements...

Coding a very basic 'puzzle framework'

I never used Unity before, but it seems to be a great tool for focusing on the game's design.
After I implemented a simple camera system that follows the player in a top-down perspective and some key assignments for controlling the characters, I thought about the actual puzzle to solve in the first test room. For this, I used my original idea of the two switches: To solve the 'puzzle', both players need to hold a switch down at the same time. This would request two players on the SmartFloor in every case! Only then, the door will open and both players can exit the room.

Instead of coding this right away, I wanted to enable further development of my game idea by creating a very basic 'puzzle framework'. From an abstract point of view, every puzzle has one or more observers: They wait until the puzzle is finished in order to change their state. Some examples of this reaction on solving a puzzle could be: A door that opens, a treasure chest that appears or a key that gets available. This is already very close to the real behaviour of the Zelda games! Another interesting thing about this abstract observer pattern: A puzzle can even add itself to the observer list of another puzzle in the same room and could therefore request the player to solve the other puzzle first!
It's also worth noting that all puzzle parts (switches, torches, enemies and others) are sending messages to the puzzle class. In the example with the switch puzzle, two switches would send the messages 'I am now activated' or 'I am now deactivated'. The puzzle class would register them in a private variable to be able to determine whether the puzzle was solved. As soon as it knows that two or more switches are activated, it could consider itself as solved. Two methods would suffice to model this behaviour...

With this in mind, the next improvement I've made was implementing inheritance. I wanted to encapsulate the observer behaviour in the base class to be able to focus on the actual puzzle. In my test room, you have to activate switches. Therefore, I made a switch puzzle class that inherits from the puzzle class. The SwitchPuzzle tells its base part through the protected, but accessible PuzzleSolved() function that it has now been solved. Then, the base part can notify all observers, of whose it has been keeping track of during the game.
After applying this, the same puzzle behaviour as described earlier is now implemented in its own class. It's now very easy to combine all these elements and create more complex puzzles. Of course, all the 'puzzle parts' also need to be created with every new room. But because I'm using inheritance here, I could use a switch that likes to send its messages to our well-known puzzle class to build a FancyNewPuzzle class that offers the same interface as the puzzle class. And a very good thing about sending messages is that they're sent to the whole object. This means it doesn't matter if the receiving function for that message is part of the base part or the fancy new part of our new puzzle class...

A prototype for the 'Dungeon Explorer' game

My work only includes the first level because I was asked to demonstrate the concept.
But who knows, maybe I'll have some time in the future to make some more levels..?
Additionally, I've implemented a health system into the player which is displayed on every player's screen. Don't walk into the lava fields, it'll reduce your health by one heart every two seconds! Please keep in mind that this game concept is supposed to be played on the SmartFloor: There, it should be a way harder to remain on the stone path, especially for a first level. In general, first levels are normally demonstrating the principles and let the player focus on controlling the character. If one of the two players is game over (no hearts left), the other player should rescue him by running into the blue sphere in the middle of the room! By doing that, he sacrifices 1.5 hearts for giving his fellow full health! Well, that's a friend.
Here you can download my game prototype consisting of the first level!