“Odd One Out - humans not allowed” is a multiplayer party game.

PROJECT INFORMATION

Date: 4th semester (2015)
Duration: 3 weeks
Team Size: 3 people
Technology: Unreal Engine 4, Blueprint Visual Scripting, Microsoft Kinect V2
Constraints: Develop a fully playable prototype on the topic: Full Body Game.

Gameplay Video

Introduction

Unlike previous projects, which have taken place throughout the whole semester, this project is an experimental game jam with the duration of three weeks. Not only the time has been cut down by a significant amount, but also the size of the group has been halved from around six to three members per group. The scope of this project is strongly limited compared to previous projects and our schedule had to be planned more carefully than ever.

The topic for our group project is: “Full Body Game”.

Concept

Looking at existing Kinect games, we were not able to find one single game, which would meet our expectations regarding: “making good use of body tracking”. Our mission was, to work out a game concept, which would make use of the body tracking technology in a necessary way. We did not want to create another Kinect game, in which the core mechanic is just about mimicking specific gestures to trigger specific events, which could also be triggered by any other input system like for example a gamepad.

Our game, “Odd One Out No Humans Allowed”, is a four-player party game, in which the players have to disguise themselves as nonplayable characters (NPC). The motion of each player is being tracked by the program and projected onto one of the ten characters on screen. The remaining six characters are computer controlled NPCs. The goal is to identify the avatars of the other players and kick them out of the game.

Game Mechanics

As soon as the players are lining up in front of the Kinect sensor, the game starts automatically. Each player gets a random character which is mimicking the body motion. The players are now trying to identify themselves and the other players. Once an opponent player is identified, they can be excluded from the game. But beware: the one who tries to exclude an NPC will lose the ability to exclude any other player. Being unable to mark other characters, this player's chances to win the game are close to zero. If everyone was getting fooled into selecting NPCs, the game will end as a draw. The player who manages to be the last survivor by kicking out all other players will win the game.

Art Style

It was important to us, to find a setting, in which we could easily design very distinct characters. We chose a theme with animal-like creatures. The initial plan was to create ten different character meshes. Each of them would have traits of a specific animal, which would make them easy to be recognized. Due to the time restriction, we had to cut it down to one mesh with ten different diffuse maps. The overall art style stayed clean and straightforward.

My Task Area

Being the only programmer, I had free choice over which game engine to choose. Since the last project was created with the Unreal Engine 4, I felt most comfortable with it. The timetable served as a rough sketch up of the three weeks. It was difficult to estimate how long a task would take because I have never worked with the Kinect before.

Understanding Mircosoft’s Kinect V2.0

First, out of all steps, it was essential to understand how the Kinect works and what its capabilities are. I started off by installing the Kinect SDK 2.0 and had a look at its performance in detecting human bodies and calculating the bones. The SDK is not only providing the position and orientation of the human bones but is also capable of producing a depth map of the camera feed at a rate of 30 frames per second. But it was apparent, that the software development kit had problems in calculating bones, which were out of sight (e.g.: leg hidden behind the other leg), which would result in weird body twitching. Best results were achieved from a frontal perspective, which would expose all limbs most clearly to the camera. Body tracking from the side or back view did not work very well. We also tried a top-down view (hanging the Kinect to the sealing), which did not work at all.

Recording Movement

The idea was to record real human movements while they are playing and feed these data to NPCs in later games to achieve very natural body movements for the computer. This task was a particularly difficult one for me and took me by far the longest to achieve. To manage all the information for a record and playback management system I needed to structure the data very carefully.

There is an array containing each character. Each character is getting a record. This record is a struct containing a frame index and the actual film. The film is an array with the recording time for each saved frame. One single saved frame is a struct holding the information of the position and the posture of the skeleton. And finally, one posture is a struct containing all the orientation data of all joints, which together are defining the posture of the character.

While saving a record of a character the program is filling the array called film with frames and the according to the recording time of the frame. The frame index of the record is ignored, for now, it will be used for later playback. The recording time is required to make the playback later independent from the frame rate. One saved frame saves the position and posture of the character in this actual frame of the game. And finally, one saved posture contains the orientation of all joints, which are forming the overall posture of the character.

When playing the record on an NPC, all the data has to be fed to the animation blueprint of the NPC. In this case, it follows the same principle; just instead of saving, it reads out the film. The frame index starts at 0. Each in-game frame the program is looking into the array called film and starts at the given frame index. It then compares the recording time of the frame at the frame index with the actual game time. If the recording time of the frame is lower than the actual game time, the program will skip the saved frame and set the frame index one integer higher until it reaches the point, where the recording time is higher than the actual game time. At this point, the program starts to dig into the saved frame for information about the position and posture, which is then fed to the animation blueprint of the character.

Sound Design/Implementation

I used Ableton Live to create the soundtrack. I wanted to give the soundtrack some childish character, which is a little bit off the beat sometimes. I wanted the sound to be somewhere between of a wooden xylophone and a ukulele. For feedback sounds for the cursors, I took notes within the harmony of the soundtrack. I choose a cymbal crash for kicking out another player and a loud off tune noise for trying to kick out a wrong character.

Considering, that I have only spent about 5 hours into designing the feedback sounds and the soundtrack, I am quite satisfied with the result. The music fits the art style and is not irritating after several loops.

Recap

Looking back at this project, I would mark it as a great success. I made a great leap forward in programming while maintaining a reasonable work-life balance. Especially the recording function forced me to keep my code tidy and structured. I have also gained a lot of new knowledge in programming by using structures and enums. The sound design part went well, although I was worried about the brief time in the end. The efficiency in sound design made me even more confident for future projects.

There are two things, which did not fit into the scope of a three-week project: the proper implementation of voice recognition and the implementation of a Kinect interface without any third party software. I am planning to look into that sooner or later.

Overall, I am pleased with the result of the project and am very satisfied with my performance. I am looking forward to the next project!

>>This is just a slice. For my full documentation: Click HERE!<<