loading

Saturday, 09 September 2017 15:01

Space Orbs

“Space Orbs” is a Virtual Reality puzzler.

PROJECT INFORMATION

Date: 8th semester (2017)
Duration: 8 weeks
Team Size: 1 person
Technology: Oculus Rift, Unreal Engine 4, Blueprint Visual Scripting, Autodesk Maya, Adobe Photoshop, Ableton Live
Constraints: Develop a fully playable VR prototype with emphasis on motion controls.

Gameplay Video

Oculus

Rift Headset Rev 2.0

Oculus Rift Headset Rev 2.0

Introduction

This project is a resemblance of what I have learned and achieved over the course of the last three and a half years, and I am aiming to synergize the knowledge I have gained from my studies with the experience I have gained from work.

Oculus

Rift Motion Controllers

Oculus Rift Motion Controllers

Motivation

I am interested in virtual reality and mixed reality. I believe that these technologies will shape the future of the media landscape. The technology is somewhat new but leaves us developer a lot of room to explore. I am very interested and curious about its potential and how it can be utilized. I am sure, that we only see the tip of the iceberg and that we are still in the process of comprehending its possibilities.

Oculus

Rift Motion Tracker

Oculus Rift Motion Tracker

Goals

My goal is to create a virtual reality game, which is not only appealing in its design but is also set up in a way, that the content is modular and easily expandable. For that matter, it is essential to carefully plan and set up a clean foundation for the framework. I hope that this will result in high stability and great expandability of the game, as well as a solid foundation for further development. I believe, that if the foundation is set up correctly, content generation can be very efficient. With this belief, I am aiming to create content which allows for roughly thirty minutes of playtime.

Technology

I have been playing around with the HTC Vive and the Oculus Rift. While the HTC Vive is superior in image quality and device tracking across a whole room, the Oculus Rift is superior in comfort and setup. Although I like the touchpad of HTC Vive’s motion controllers, I prefer the ones from Oculus Rift due to its more ergonomic design.

Looking at my game, all advantages of the HTC Vive would not have any significant impact, and I, therefore, preferred to choose the one which is sufficiently tailored towards my needs.

Work Process

Timeline

Ideation

Conventional video games require the player to cognitively map specific action options to corresponding buttons or even button combinations. The use of motion controllers allows for an input option, that is more similar to the actions of everyday life. Simple tasks like reaching out for objects, grabbing and dropping them are very natural to perform. The simplicity and natural adaptation of the controls made virtual reality an enjoyable experience for everyone. It was important to me, to maintain this condition and to not end up with a hot wire game.

Throwing objects is interesting in many ways. In its core, it is a seemingly straightforward action, but it gets hard real quick if asked to throw an object consistently. I can throw a basketball, but can I hit the basket? Too many variables are contributing towards the outcome so that even professional basketball players are unable to predict their shot with 100% accuracy. Most of those variables, including angle and force, are also replicable in virtual reality. But I did not want to create a hit the basket simulator.

One of the great features of virtual reality is the possibility to set up conditions, which are difficult to be set up in the real world and let’s face it: gravity was always an annoyance in sports class.

Preparation

Execution

To make development most efficient, I carefully sketched out the dependencies of game objects. The graph to the right shows which entities are inheriting from where.

Review

Because of the focus on establishing a robust framework, adding more content in the form of extra stages became very easy. Due to the modular system, it is purely about arranging the layout, setting few triggers and adding it to the level array. This circumstance allows for more time being spent in actually designing levels rather than solving implementation problems. I believe that this fact is noticeable while playing my game. I can now already build a lot of more content by just using the currently available modules, but also adding new modules and features should be relatively easy.

Considering the amount of quality content I have been able to generate in this short amount of time, I would mark this project as a success.

>>This is just a slice. For my full documentation: Click HERE!<<
Published in Projects
Tuesday, 03 March 2015 10:16

Cubed

Cubed” is a partly procedurally generated, high score based stealth action game with puzzle elements.

PROJECT INFORMATION

Date: 3rd semester (2014/2015)
Duration: 5 months
Team Size: 7 people
Technology: Unreal Engine 4, Blueprints Visual Scripting
Constraints: Make a fully playable game using the Unreal Engine 4 and its Blueprint System. Use a modular system with a maximum of 10 different objects.

Gameplay Video

Introduction

“Cubed” is representing my second team project within game development. Looking back at the first team project “Armville”, in which I have already gained a lot of experience, my expectations on this project were very high. Because I have assigned myself to a broad variety of tasks on the last project, I was able to widen my knowledge especially horizontally and find out which areas within the game development are in the interest of mine. Having this knowledge, enabled me this time to specialize and to go into more depth especially in regards to scripting and coding.

Concept

“Cubed” is a partly procedurally generated, high score based stealth action game with puzzle elements. Our project was strongly inspired by the Rubik’s Cube and is the result of an idea to combine the problem-solving aspect of puzzle games with the high tension of stealth action games. We wanted a game that offers the player a diverse gaming experience with puzzler, stealth and platformer elements. While the player progresses by coloring in the cube, the difficulty continually raises, making it nearly impossible to color in 100% of the cube. To reward highly skilled players without putting too much pressure on beginners speed is a small factor.

Cubed

Transparent materials
are coming in handy when debugging.

Transparent materials are coming in handy when debugging.

Mechanic

The unique selling point is arguably the integration of a fully functional Rubik’s Cube as the playing field of the game. The player can manipulate this cube within “the principles of Rubik’s Cubes”; meaning the player is being able to influence the environment in which her playable character is moving on. The player could, for example, use this feature to rotate obstacles out of the way. While the playable character can freely move along all surfaces of the cube, the gameplay can change drastically depending on which surface the playable character is currently active. While the top surface is being played as a game in top-down perspective, the side surfaces are being played as a game in side-scroller perspective.

Art Style

Especially in regards to the puzzle aspect of our game, it seemed essential to us, that the player would be able to keep the best overview of the entire cube. For that reason, we decided that the whole cube should fit onto the screen at any given time. This in return forces everything to be far away from the camera, thus appears smaller. Having this in mind, it only made sense to us to use simple shapes and strong outlines for a better overview. A cartoony and slightly over stylized art style is ideal for this purpose.

Cubed

The row selectors
are snapping to the cursor.

The row selectors are snapping to the cursor.

Solving the Rubik's Cube

This section gives a little insight on how I have realized the virtual Rubik's Cube.

Generating the Cube

To have a basic structure from where I could start working on the functionalities of the Rubik’s Cube, I decided to spawn the base of the Rubik’s Cube itself via code by using three “For Loops”, one for each dimension. The advantage of spawning the Rubik’s Cube via code, compared to the method of stacking the cubes together by hand, lies in the ability to customize it easily via parameters. Variations like the number of fragments of or the scale of each segment can be easily modified by changing some variables.

Cubed

Selected rows can be rotated
in either direction.

Selected rows can be rotated in either direction.

Making it rotate

Having the basic structure of the Rubik’s Cube, the next task was to find a solution on how to group up a row of cubes together and to rotate them. For that, I created two colliders with a custom material. The material allows the colliders to change their appearance dynamically. To make those colliders movable, I decided to create a cursor. The cursor is being spawned on top of the Rubik’s Cube. Each collider for rotating the cube is following the cursor along its one axis. To avoid misbehavior, I needed the colliders not to follow the cursor seamlessly, but to snap onto the grid of the Rubik’s Cube. Having the grid snapping done, I was then able to group all cubes, which are overlapping the collider, by attaching them to a common “Target Point” in the center of the Rubik’s Cube. The attached cubes can then be rotated around the “Target Point” and can finish their rotation by snapping onto a 90° angle.

Cubed

Easy modification of the cube
through changes in variables.

Easy modification of the cube through changes of variables.

Making Customization Easy

Because we had not defined our game mechanics yet and are still about to experiment and try to figure out what kind of game to design based on the Rubik’s Cube, I thought it would be handy to be able to customize and adjust the Rubik’s Cube in many different ways. To guarantee an easy and quick customization process, I have created a “Game Mode Blueprint”, which gathers all modifiable variables for better overview and easy access. I have then implemented further modification options for the Rubik’s Cube which are selectable and adjustable through this “Game Mode Blueprint”.

Cubed

Our playable character
does not like to live in a gray world.

Our playable character does not like to live in a gray world.

Making of Cubed

This section gives a little insight on how I have designed a game around the virtual Rubik's Cube.

Cubed

His mission is to color in the whole cube
without being caught by the agents.

His mission: Color in the cube without being caught by agents.

Designing a Game

...is about giving the user the chance to make her own decisions and therefore alter the progress and influence the outcome within a set of rules and constraints in a predictable but ungranted way. There has to be a way for the user to communicate with the application to be able to change its state. While there are several ways to design a communication interface, we decided to create a game, in which the user is communicating with the application by controlling a representative of herself.

Making Decisions

...are about evaluating dependent factors and predicting the result in regards to a preferred outcome. While there are different ways to promote desired outcomes, we decided to design our game around an apparent goal.

Cubed

The progress bar is time unrelated.
There is no need to hurry
to reach the 100%.

The score related to time, whereas the progress bar isn't.

Dual Scoring System

The goal is to color in as many faces as possible and with that to set a high score. We wanted the game to be competitive while remaining rewarding for casual players and therefore decided to implement two significantly different progression feedbacks. While some players will put more attention to the color progress bar, which shows the current overall percentage of painted faces, others may give more attention to the scoring system which is designed to be more competitive. The significant difference is, that the scoring system is related to playtime, while the color progress bar is not.

Cubed

Camera while on top.

Camera while on top.

Making all Sides of the Cube Accessible

Because the playing field of our game is cube-shaped and we did not want to limit the player's movement to the top surface, we had to think of a solution for the transition from one surface to another. The first step to make all sides of the cube useable was to implement a camera system, which provides the best overview over all sides of the cube. To do that, I placed a rotation point in the center of the cube and attached a spring arm which holds a camera. The camera is set up to face towards the center point. Depending on the player's position in world space, the spring arm is set to interpolate to a specified angle.

Cubed

Camera while on sides.

Camera while on sides.

As soon as the player leaves the top surface, the spring arm will automatically orientate itself orthogonally to the corresponding side surface. In addition to that, the length of the spring arm will be extended, resulting in a higher distance from the camera to the cube. While the range changes, the cameras field of view is being adjusted accordingly, which allows for smooth transition between perspective and orthogonal camera projection mode.

Cubed

Double jump is handy.

Double jump is handy.

To give the player some control over the camera, I added the ability to rotate the camera around the cube by changing the yaw value of the rotation point and the ability to tilt the camera up and down by changing the pitch value of the rotation point. I wanted to give the unique shape of our playing field more relevance and make the game feel different after the transition from top surface to side surfaces. The idea was to give the game the feeling of an isometric top-down game when on the top surface while changing it to be a platformer when on the side surfaces.

To emphasize the difference of the movement on the top surface from the movement of the side surfaces, I lowered the height of the jump when on top and raised it when being on the sides. Furthermore, the movement is being locked to be planar while being on the sides.

Thinking around Corners

Cubed

Jumping around corners.

Jumping around corners.

While it is nearly always possible to make a transition from the top surface down to the side surfaces, the transition back up is not granted. To compensate for this issue, I implemented the transition from one side surface to another and the ability to change gravity. Instead of changing the direction of the gravity, I achieved the illusion of a gravity change by flipping everything instantly by 90°.

To make the playable character being able to jump around corners the game needs to understand when the player wants to make a transition. The position of the playable character is being tracked continuously and saved into a variable. As soon a corner area is being entered, the application reads out the last position of the character and assumes, that a transition to the adjacent side is desired. At this moment the game slows down and readjust camera and controls.

Designing Tiles

Cubed

Designing the tiles.

Designing the tiles.

The tiles which are shuffled up and placed around the cube had to be designed to provide exciting shapes and hiding spots on the top surface, as well as providing platforms and obstacles for the side. To make sure, that the tiles will be equally distributed around the cube, I was setting up an array containing each tile once. This array is being shuffled up, and the tiles are being laid out accordingly for each side of the cube.

Painting the Assets

Cubed

Painting Assets.

Painting Assets.

To be able to color in any face of the cube and any face of any asset, the playable character does not only need the ability to distinguish between the assets themselves but also the ability to differentiate between one face from another of the same asset. To gain information about which face the player is meeting I had to use meshes with predefined face IDs. Those could then be assigned to different physical materials.

Designing Behavior

Cubed

the behavior tree

the behavior tree

Because our game is partly about sneaking and hiding, we wanted to include an enemy with a field of view and ranged sense of hearing noisy activity. Since our game is to a certain extend procedurally generated the challenge was to design an enemy, which would work with any arrangement of the tiles.

The enemy is using an environment query system which lets him break out of his waypoints and check on potential hiding spots. He is preferably checking positions, which are blocked from his view and are near to known suspicious locations. The playable character is dropping paint while running, which can be tracked by the enemy. The enemy will aim at the playable character on sight and charge his taser for an electric shot.

Recap

Cubed

It was important
to experiment with the cube.

Experimenting with the cube was important.

I was extremely motivated and started to prototype with the Unreal Engine 4 from the very beginning. Although most of the early scripts are not in use anymore, they still served as a useful exercise and helped me a lot to get into the new engine. The transition from Unity 4 to the Unreal Engine 4 went surprisingly smooth, and I was able to gain more scripting knowledge than I initially thought I would.

I already felt quite satisfied working with Unity 4. Seeing me being even more confident while working with the Unreal Engine 4 underlines the success of this project and my goal in transferring and expanding my knowledge. After spending over 300 hours scripting, I am relieved to know, that I am still very interested in programming. I realized though that I have to be careful not to be overambitious in future projects. After having two very intense projects, in which my primary task was to take in as much information and gain as much knowledge as possible, I see the urge to learn how to improve my work-life balance for future projects.

Although I was not able to set a specific goal and milestone from the very start, I feel like I have surpassed my expectations by far. I am satisfied with the result as well as the progress, and the experience I have been gaining through this project. Since I was able to find a solution for every scripting problem I was encountering, I believe, that I have improved my scripting skills tremendously. Looking back at my expectations, personal goals and milestones, I would mark this project as a great success. I made a great leap forward in understanding programming and game engines.

>>This is just a slice. For more details: Part 1 , Part 2 , Part 3 , Part 4 <<

Published in Projects
Tuesday, 09 September 2014 10:15

Armville - Archie's Book Chase

“Armville - Archie’s Book Chase” is a nonlinear, high score based time trial runner with high replay value.

PROJECT INFORMATION

Date: 2nd semester (2014)
Duration: 5 months
Team Size: 5 people
Technology: Unity5, C#, Photoshop, Ableton Live 9
Constraints: Develop a fully playable vertical slice of a 2D platformer using the Unity-Engine. It has to be about four screen sizes large and include sound as well as animation.

Let's Play

Introduction To Our Project

Dustforce

by Hitbox Team

“Dustforce” by Hitbox Team

Two games were catching our attention while brainstorming for this project: “Dustforce” by “Hitbox Team” and “Super Meat Boy” by “Team Meat”. Both games are focusing on precise control and movement of the playable character. While “Dustforce” felt a little bit too slow paced and “Super Meat Boy” a little bit too fast-paced, they still had a lot in common. We agreed, regarding pace, that our game should feel like something in between of the two mentioned games

Concept

Super Meat Boy

by Team Meat

“Super Meat Boy” by Team Meat

We wanted a game, which provides a scalable challenge to players of any skill level. The difficulty on the first trial could be to familiarize the controls and to combine the mechanics of the game to reach the end of the game at some point. The second attempt could be driven by the eagerness to improve the controls and the desire to find the best route and to beat the current high score. To enhance the replayability of the game, we decided to design a nonlinear level with multiple alternative paths. One goal was to avoid the existence of a superior route, which would have an advantage over all other routes. The primary focus, however, was addressed towards the unorthodox movement of the main character.

Armville

Pulling the right stick down,
will result in the arm to go down.

Pulling the right stick down will result in the arm to go down.

Mechanics

Our character is lacking the ability to jump through a single button press. Instead, he has a free rotatable arm, which can be used to punch onto solid ground for repulsive force and rebound into opposite direction. The position of his right arm is directly translated through the position of the controller’s right stick. The player has the freedom to move the right arm independently from the character's body, which enables a high variety of movement combinations. Not only is the character able to use his arm to gain repulsive force for rebounds, but also to use his hands for grabbing corners and swinging around the environment.

Art Style

To provide a nonlinear level design, we decided to install checkpoints all around the level, which the player has to reach in unrestricted order. We chose a library as a setting since it provides a reasonable explanation to reach certain checkpoints. The checkpoints are represented through books, which the character has to collect. To emphasize the burlesque nature of our futuristic setting, we decided on a “cartoony” art style with sharp outlines. Deciding on a color scheme was representing a difficult task since a library usually contains a high variation of books with different colored book covers. It was important to us to describe a vast library with its high variety of books, without dragging too much of the player's attention to the background.

Level Design

Intention

Armville

First, we blocked out
several levels.

First, we started to block out several analog levels.

To maintain high replay value, it was necessary to design a nonlinear demonstration level which would offer various paths with each of them offering even more options on how to traverse through them. One of our other tasks was to assure, that the level design would not provide an apparent superior path, which most of the players would end up going for automatically, rather than having the urge to replay the level to figure out their optimized path. Due to the limited scope of our project we were trying to use every space as efficient as possible.

Working Process

Armville

Every change in the design
was communicated and documented.

Every change in the design was communicated and documented.

I have been hosting several playtesting sessions, in which external subjects were playing our level for the first time while I was studying their behavior. I ended up in doing countless tweaks and optimization processes to the level design, as well as adding and removing whole areas to achieve an overall balanced level design. Every tweak and optimization process always had to be tested again by new external subjects, which in return was resulting in even more improvements to provide the best experience for beginners and advanced players.

Result

While the final demonstration level is perfectly suitable for medium to advanced players, it sometimes appears to be a little bit too difficult for players, who are not familiar with video games. We were aware of that issue, but we decided not to lower the difficulty. Instead, we want the necessity for improvement and aid the player through specific set up areas. We are sure that a more extensive tutorial would have helped some players to be able to jump right into the game with less struggle, but due to the limited scope of this project, we decided not to include it yet. Still, the demonstration level represents the level design we were aiming for in a big picture. There is no superior path, and I am confident, that we achieved a level design, which is delivering a highly diverse experience regarding movement and problem solving altogether.

Learning Effect

Studying and going through countless optimization cycles, have shown me, how little changes within the game design can have a massive impact on the game and change the way it is being played. It also underlined the importance of playtesting in general. Fixing one design issue can cause another unpredictable design issues to appear, which often can only be discovered by more intensive playtesting. Also, it is important to let as many different people as possible to test the game. The differences in the way the games are being played are very insightful and can lead to great ideas.

Sound Design

Intention

Ableton Live

Multiple cues have to be able
to fire simultaneously.

Multiple cues have to be able to fire simultaneously.

As a musician and sound enthusiast I pay a lot of attention to the sound design of games. It was not easy to think of a soundtrack, which would reflect the atmosphere of a quiet library, but also emphasizes the action orientated fast-paced gameplay of our sidescroller. The feedback sounds did not only had to be designed out of a functional intention but also had to fit the overall style of the game. The possibilities of video games as an interactive medium were always fascinating me. Unlike movies, everything can be influenced and altered by the player. Instead of just being purely a consumer, the player can become a producer to a certain degree. I like the idea of giving feedback to the player in every aspect of a game. Not only visuals and special sound effects, but almost everything should be a reaction to the player’s action. I believe this is the primary strength of video games and what distinguishes it most from other media or non-interactive art. That is why I wanted the soundtrack to be highly reactive to the game state.

Working Process

To get the required information I had to add a script with a “void OnCollisionEnter2D()” method to the playable character. All the collision information can be handed over to the sound script. The sound script knows when the playable character is colliding and with what velocity it was colliding and therefore can distinguish between different cases of the collision’s direction and strength. The collision’s direction is essential to be able to differentiate between cases like for example: hitting the head, landing on the feet or running into a wall. The collision’s strength is easily linked to the volume of the triggered sound so that a higher impact is louder than a smaller impact. The opposite applies for the whip sound of the playable character’s arm and the airstream sound of the playable character’s body while falling: the velocity, while being in a state of not colliding, matters. The velocity of the playable character and his arm can be read out of the “Rigidbody2D.velocity” variable. If the velocity is high enough, a sound will be triggered, and the volume, as well as the pitch, is adjusted accordingly.

I composed a soundtrack accordingly to the art style. I ended up with six bass lines, one drum line, and one percussion line. The soundtrack starts off with a solo bass line to reflect the atmosphere of a quiet library and ultimately ends up with a composition including drums and percussion. The soundtrack reflects the progress of the game with the increased intensity of the bass line. To apply even more pressure, drums and percussion are added at a later stage. Because the playable character is usually faster in the air, I wanted to emphasize this state by letting the percussion only play while in the air. The percussion is added after collecting books, but also fades out after a while again if the player stops collecting books.

At last, I was designing additional sounds for the Archie ghost and the high score screen. I was modulating sounds by using the Operator in Ableton Live and added some sound effects afterward. The ghost sound was then attached to the ghost itself as a 3D sound. I then adjusted the 3D sound settings of the ghost in Unity, to get the best-balanced sound effect whenever the ghost floats over the screen. Mostly, I had to reduce on the high pitches to make the assets sound dull. This is because, our setting is mainly dominated by big wooden objects and heavy books, which would swallow some of the high pitch frequency. I also had to record sounds and dub our character with my voice.

Result

I am pleased with the result, and I am confident, that I succeeded in catching the right atmosphere and matching the style of our game. I know that there is a lot of potential for further improvements, which I couldn’t tackle on due to the lack of time. But there were more urgent tasks to finish at the end of the project.

Learning Effect

I was always very curious about the design and implementation of sound in games. After this project, I have learned a lot about the possibilities of sound design in games. This experience was very inspiring, and the options are overwhelming. Designing sounds paired with the implementation is opening an entirely new dimension for creativity and problem-solving. This has only increased my interest in sound design. This task was a lot of fun, and I cannot wait to continue experimenting in this area.

Recap

Armville

GamesCom visitor is playing Armville.

GamesCom visitor is playing Armville.

I am satisfied with the result of our game and the progress and experience I have gained through this project. I made a great leap forward in programming and understanding game engines. Because I have assigned myself to a broad variety of tasks, I was able to widen my knowledge horizontally. I have a much more defined idea of the working pipeline in game development. This helped me to figure out, which parts of game development I do enjoy most. Knowing one's interests represents an excellent advantage for further projects. It will enable me in future projects to build up my knowledge vertically and go into more depth.

Looking back at my expectations, personal goals and milestones, I would mark this project as a great success. Although I was not able to set a specific goal and milestone from the very beginning, I feel like having surpassed my expectations by far.

I have a much more transparent image of what to expect for the next project now. This allows me to have a better understanding of how to prepare for future projects and enables me to reach out to higher goals. I would like to focus even more on programming and sound design for the next project and hope that I will be able to tackle more significant programming problems and modulate my sounds in a more defined way.

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

 

 

Gameplay Video

 

 

Making Of

 

 

Published in Projects
Thursday, 03 March 2016 22:06

Dominion

“Dominion” is a strategic top-down local multiplayer battle arena.

PROJECT INFORMATION

Date: 5th semester (2015/2016)
Duration: 5 months
Team Size: 3 people
Technology: Unreal Engine 4, Blueprint Visual Scripting
Constraints: Develop a fully playable prototype with the focus on AI.

Gameplay Video

Introduction

Dominion

“Lemmings“ by DMA Design
(Rockstar North) in 1991

“Lemmings“ by DMA Design (Rockstar North) in 1991

Our task was to create a game within a three month period, with each team member spending 600 working hours on this project and an estimated 1800 working hours in total. This project marks to be the last and greatest group project of our game design studies. Having this in mind; we were able to stretch our scope a little bit further than in previous projects. The topic for this group project is: “Agents”.

Concept

Dominion

“SimCity“
by game designer Will Wright in 1989

“SimCity“ by game designer Will Wright in 1989

The focus of this project was to design a game with an emphasis on artificial intelligence. An agent represents an entity, which can operate by itself without constant player input. It can be a representation of an actual visible character, like for example in games like “Lemmings”. It can also be visual less apparent while managing the whole economic system of a game, like for example in games as “Sim City”. Agents are game entities which are operating as independent individuals or as a group, like for example as in the flocking behavior of ants.

Dominion

ants using flocking behavior
to bridge a gap in real life

ants using flocking behavior to bridge a gap in real life

One of the main advantages of agent-based systems is that the player can maneuver a high amount of units without the need of steering each unit individually all the time, like for example in Real Time Strategy games such as “StarCraft”. We decided on a system in which the player has to handle a small number of units. The units would have individual characteristics, behavior and a somewhat sophisticated artificial intelligence system. Each unit would have a unique personality.

Initial Idea

Dominion

Concept sketch by Jeremia.

Concept sketch by Jeremia.

Our game was aimed to be a multiplayer local battle arena, in which each player is in charge of a little squad. Each squad member would have its unique statistics and therefore unique strengths and weaknesses. This again would ultimately influence their decision making, thus their behavior. The player would not be able to steer the characters directly. Instead, the player would be able to set the statistics, the class and assign tasks to each squad member, which will determine their behavior.

There would be two classes: workers and fighters. A worker could be given tasks like scavenging for resources or building expansions. Fighters, on the other hand, could be given assignments like looking out for enemies and to attack them or to defend a specific area. The player would be able to change the assigned tasks of a squad member whenever needed, but the squad member would be forced to return to the base or expansion whenever a change of class is required. Meaning, that changing tasks within a class would be free of expenses, but changing the class of a unit would be uneconomical due to the required time to return to the base.

There would be several ways to win the game. A player could win by being the first to collect 3 out of 5 targets, a player could outplay the other players by being the first to reach the target amount of resources, or a player could be the last surviving race by destroying all enemy bases while maintaining the own base intact. Setting our game up as a local multiplayer was essential to us because we wanted to add a diplomacy system to the game mechanics. We hope this diplomacy system would leverage the player's social interaction on the metagame layer.

Dominion

Color schemes by Jeremia.

Color schemes by Jeremia.

Art Style

We decided to develop a game which could be played against other players locally on one shared screen. The advantages of a shared screen are the excellent overview of the whole map, the full usage of the entire screen for every player and the convenient and comfortable set up for gaming sessions and presentations. We were eager to develop a fun and also good looking game with beautiful assets and animations. One of the main challenges was to find an art style, which would not only look good at full HD resolution but would also provide all four players an excellent overview over the action on one single shared screen.

Dominion

Character Design by Jeremia.

Character Design by Jeremia.

Background Story

The background story of the game is about four scientist, who went insane because of their dedication to science. These mad scientist, are now creating their little army of minions to conquer the world.

Dr. ‘Dolly’ Dolbert, who created unsatisfied clones of himself.

Dr. Vicki Frankensteiner, who tried to keep people alive for too long.

Dr. Robert Asimov, who did not see any harm in researching robotics.

Lady Bugoni, who studied bugs and experimented with cross-species.

My Task Area

Dominion

first prototype with the level generator

first prototype with the level generator

After our team has agreed on the topic “Agents”, we decided that it would be most efficient, if everybody is developing multiple gameplay concepts by her/himself. We would then have a pool of thoughts and ideas, which we could share, combine or redefine.

After having defined a gameplay concept, my task as the only programmer was to start prototyping. I realized that I would need a consistent level, which I began to develop and to block out in the engine with brushes, in order to be able to test the AI. I was then programming the units and a cursor as an interface to select and interact with the units. To be able to spawn those units, I was creating an object which would represent the base. I created several items for the AI to interact with. Having all this set up, the next big task was to implement the units' behavior. Things like the implementation of GUI and animation had to be done as well.

Prototyping

Dominion

comprehensible
vs.
not comprehensible

comprehensible vs. not comprehensible

A game concept which heavily relies on artificial intelligence was new to us, and it seemed very important to have a running prototype as soon as possible. We needed to figure out, if and what makes a game fun, in which the player’s main activity is watching, not interacting. Besides, I was very unfamiliar with AI systems and needed to understand its capabilities as fast as possible.

I started with a level generator, which would stack random rooms and corridors together. The idea was to confront and test the AI on many different level layouts. I realized that it was too complicated to observe and understand behavior in ever-changing environments. That is why I abandoned the level generator and started blocking out a new persistent level.

Dominion

an early sketch of the Level Design

an early sketch of the Level Design

Making Changes to the Concept

If the behavior is following a simple ruleset, the player will not get disappointed as long as the behavior is consistent. The player is able to comprehend the condition, which led to specific actions in certain situations. If the patterns are too complicated, the player might not be able to follow how decisions are made. The behavior should always be readable and considered as reasonable in any situation.

Dominion

the redefined version of the first level

the redefined version of the first level

Our game did not deliver on that. Behavior was wildly interconnected with the statistics of a unit and it became challenging to comprehend how decisions were made. Since the unit’s behavior was unpredictable, the actual behavior often did not match up with the expected behavior, and the player was getting unsatisfied. To minimize situations, in which the player can get unsatisfied, we implemented the feature, which allowed players to assign tasks to units directly so that the player could overwrite the units decision makings.

Level Design

Dominion

blocked out a new level layout

blocked out the new level layout

I started to sketch out a level on paper and used this sketch to block out the level in the game engine. It gave me the opportunity to test the behavior in a consistent environment and helped Jeremia in developing the visual appearance of the environment. Blocked out areas got decorated with his Assets. The plan was to combine a consistent layout of the map with a little bit of randomness for the target placements etc., to raise the replayability.

Because we were aiming for a shared screen game, every bit of space had to be used wisely. Even the placement of thick solid walls would result in unused space. Using thin planes to divide space would not look right. A solution was to handle differences in heights to separate areas from each other.

Scaling Down

Dominion

new level layout after adding assets

new level layout after adding assets

The level design part was a huge task to be tackled. To fit the whole map into one single screen, we had to scale everything down. We were not able to predict whether we would be able to fit everything into one single screen in a reasonable manner and whether this concept would work at all. Furthermore, it was quite difficult to predict, what kind of level design would work. It was necessary to try out a lot of features and to keep the good ones and to throw out the bad ones. The shared screen concept in combination with the 1K HD resolution was representing a though constraint, and I am glad, that we figured out a solution. We also experimented with different angles of projection. One idea was to develop this game as a table surface game. We dismissed this idea because it did not provide enough benefits compared to the rather complicated setup.

Artificial Intelligence

Dominion

my interpretation of the AI architecture

my interpretation of the AI architecture

It is crucial to differentiate between: what is performing the action, what is controlling the performer and through which controlling device is the performer being controlled. The performer could be the representative game entity, the avatar for example. The controller could be a human being controlling this avatar through an input device, but also a non-human system, like for example an AI could be the controller.

This architecture comes handy, whenever the controller wants to change its performer. Racing games, where the player can choose from different car models, is a good example. Even more so, this allows AI to control the same type of performer in the same manner as humans would. Empty slots can be filled up with bots, as an example.

Behavior

After having set up the meshes for the units, I now needed to feed them with behavior. For that, I needed to set up an AI Controller and a Behavior Tree with all its Services, Decorators, and Tasks. According to my previous example, the representative body including the mesh would be the “performer”, while the behavior tree would be the “controller”, and the AI controller would be the “controlling device“.

Dominion

Setting up an Environment Query.

Setting up an Environment Query.

The sensing component enables an AI to sense his environment through vision or hearing. Unlike with human players, the AI does not look at the screen but instead senses the surroundings out of the bodies perspective. Nonetheless, the sensing component is part of the AI controller. The AI Controller does not only possess the body and runs the behavior tree on it, but also contains the sensing component. With this sensing component, the AI can sense specific objects in its surroundings. In this case, the sensing component can detect all the intractable game objects. Every sensed object is being categorized and analyzed to figure out, whether it is relevant and should influence the behavior.

In this example a worker is sensing a fighter:
--> is this fighter one of ours?
--> is this fighter already occupied with something?
--> am I already threatened by another fighter and if so, is this other fighter closer to me than the sensed one?

If any of these checks are being answered with yes, then the sensed fighter will be ignored. If all of them are being answered with no, then the detected fighter is an enemy fighter, which has no other occupation right now and is closer than any other threatening opponent. This relevant fighter information will then be sent to the behavior tree and saved into a variable. Those variables, which are being set by the sensing component in combination with variables which are set by the player, when assigning tasks, are forming different combinations, which can result in different outcomes for the behavior.

Dominion

Environment Query System with scores

Environment Query System with scores

In this example we have a fighter with different conditions set up for entering a specific behavior:
fighter sensed relevant enemy worker --> go to enemy worker
fighter sensed relevant enemy fighter --> go to enemy fighter
fighter is low on health --> hide

Having these conditions and behaviors ready, we can now set up the priorities for each branch. In this example, the last condition would have the highest priority, whereas the second last condition has the second highest priority. Having these priorities setup will let the behavior tree decide which behavior is more important. In our example: If the fighter senses an enemy worker and an enemy fighter at the same time, he will approach the enemy fighter, due to its higher priority. In any case, if he is low on health, he would flee, since it has top priority.

Animation

Dominion

a worker units State Machine

a worker units State Machine

Another Task of mine was to implement the animation assets into our game. That involved setting up the Animation Blueprints and Animation Blendtrees. An animation is essential to give the player visual feedback about the state of the game. It is necessary to communicate and visualize the current activity of the units.

To guarantee a smooth transition from idling to running, I was setting up one-dimensional blend spaces with loopable animation assets of idling, walking and running. Depending on the velocity of the unit it would perform a scaleless blend from idle to walk and from walk to run. Because sudden changes in the velocity were causing little hiccups while blending, I was feeding the blend spaces with an interpolated value of the velocity.

Dominion

Montage Blueprint of a fighter

Montage Blueprint of a fighter

A State Machine regulates the timing of the transition from one animation state to another. It observes whether predefined conditions for a change are matched and performs the transition from one state to another if necessary. To get the fighter units to play the walk and the attack animation at the same time, I had to setup Montage Blueprints. These Montages can be fired and stopped via Blueprint and stitched onto an active pose, beginning from a dedicated bone. This way, the fighters final pose can receive the locomotion pose of the state machine while performing the attack animation for the upper body.

Recap

Dominion

testing our game as a surface app

testing our game as a surface app

Compared to previous projects, this turned out to be the most complicated one so far. I have tremendously underestimated the workload of complex AI systems. It took me a lot of time to get used to the AI components of Unreal Engine 4, and I needed numerous iteration steps. Nonetheless, I have the feeling, that I have learned a lot about game AI and that I have a much better understanding of it now. I think that this knowledge will come very handy for future projects.

The concept of the game has changed a lot during development. Features had to be replaced or removed. One of the significant changes was the introduction of the assignable tasks. I think that only through these several iteration processes it was possible to get into that final stage. I have to learn to set the scope right next time, to get my work/life balance right. The crunch time was getting very tense, and I want to avoid that for future projects.

In overall, I am satisfied with the outcome of this project. The game is fun and helped me a lot to understand the basics of game AI.

>>This is just a slice. For my full documentation: Click HERE!<<
Published in Projects
Saturday, 08 August 2015 21:59

inVert

“inVert - evade and destroy” is a high score based, VR Segway-like action racing game, in which the player is moving along the inner surface of a sphere and tries to reach certain checkpoints while avoiding any contact with enemies.

PROJECT INFORMATION

Date: 4th semester (2015)
Duration: 3 weeks
Team Size: 4 people
Technology: Unity5, C#, Oculus Rift DK2, Wii Balance Board, Photoshop, Ableton Live 9
Constraints: Develop a fully playable prototype with the focus on alternative interface devices as a proof of concept.

Gameplay Video

Introduction

inVert

We think of the Wii Balance Board
as a great expansion to enhance
the illusion of Virtual Reality.

We think of the Wii Balance Board as a great expansion to enhance the illusion of Virtual Reality.

This project was part of our 4th-semester experimental game jam. Our task was to design a game within a three week period. Having this in mind; our schedule was very tight and the scope of this project strongly limited.

The topic for this group project was: “Interface Device”.

Concept

inVert

Using the senses to balance the body,
is just as intuitive
like turning the head to look around.

Using the senses to balance the body, is just as intuitive like turning the head to look around.

The focus of this project was to design a game specifically addressed towards a chosen interface device and not vice versa. The interface device we chose is the Oculus Rift. But having the head tracker of the Oculus Rift as the only input device felt somehow limited to us, for which reason, we decided to include another input device. We then chose Nintendo’s Wii Balance Board, because it is making use of the most natural human body movements while remaining very simple to handle. It was important to us, to forgo the typical, but mostly unintuitive, on hands controller input, which could destroy immersion.

Thinking about the Oculus Rift; one of its main advantages is the player’s ability to look into any direction and to have a 360° view. To fully utilize this feature, we decided, that the player should be surrounded by the playing field, in which the point of interest could be in any direction. By that, we do not mean only all around the player, but also above and underneath. This thought led us to the conclusion that the playing field should be a sphere, on which the player is moving along its inner surface. The player would, for example, see the other side of the sphere by looking upwards.

Game Mechanics

inVert

inVerted Sphere

inVerted Sphere

Our game, “inVert - evade and destroy”, is a high score based, single player, Segway racing, action game, in which the player is moving along the inner surface of a sphere, trying to reach certain checkpoints while avoiding any contact with enemies. Enemies are moving straight along their lanes, and the amount of appearing enemies is increased by time. At specific intervals, the enemies are starting to chase the player, forming a big mob. While the player is moving and continuously trying to avoid the enemies, there are also gates appearing on the surface. The player can drive through those gates to destroy them. When being destroyed, the gate will burst into pieces and destroy all nearby enemies as well.

inVert

inside the sphere

inside the sphere

The player can use this as an advantage to destroy as many enemies as possible. The score is raised with every destroyed enemy, and the multiplicator is increased with every reached gate. If the player gets in contact with an enemy, the game is over. To orientate in space, the player can use the Oculus Rift to look around. Also, the player can move along the surface by leaning forward, backward, left or right on the Wii Balance Board.

Art Style

Having the low resolution of the Oculus Rift’s development kit and general motion sickness in mind; we were aiming for a rather simple and clean look. We wanted the least distraction from gameplay relevant elements as possible and had chosen to use very simple geometries with easily distinguishable silhouettes.

My Task Area

Before anything else, we needed a concept for the gameplay and a working scoring system. In addition to that, I was given the task to design and implement the acoustic feedback. It was essential to coordinate and share our responsibilities carefully as we had three programmers on our team. One of my other tasks was to create all necessary game objects, like gates and enemies, as prefabs for prototyping purposes. I was also in charge of the spawning system of those. Other minor tasks I had to tackle over the course of the project involved the creation of a pole-less sphere, visual feedback by changing the color scheme as well as arranging the title and high score menus.

Developing Gameplay Concepts

inVert

non-digital prototyping

non-digital prototyping

Our mission for this project was not only to work out a game concept, which would support the Oculus Rift and the Wii Balance Board but furthermore, is noticeably designed around those devices. We wanted to make them an honest part of the experience. To be able to start prototyping as soon as possible it was necessary to develop several gameplay concepts. We agreed on the sphere as the playing field and continued to develop the gameplay concept with having the Oculus Rift and the Wii Balance Board in mind. All the little details, like for example the scoring system and the movement system had to be taken into account.

I have learned, that it can be constructive, to take non-digital prototyping material and go through the rule set of the game to identify potential problems early.

Creating Prefabs

inVert

Enemies are chasing the player...

Enemies are chasing the player...

My task was to create a stack of scripts and game objects, which we could use for prototyping. It was important that everything was designed with modularity in mind. Being able to reuse and combine modules was supposed to lead to more efficient prototyping.

The enemies are sphere meshes attached with a script giving them a constant force in the direction of their local forward vector to make them moving forward. They also carry a script which makes the up vector to look at the center of the sphere and a force which is pushing them away from the center and onto the surface of the sphere resulting in somewhat like “reversed gravity”. If they collide with a game object, which is tagged as “player”, the game ends.

inVert

...while the player tries
to reach the gates...

...while the player tries to reach the gates.

The gates are two poles with a collider in between. They will be destroyed on overlap with the player. When being destroyed the tag of all game objects within a specific radius are being checked. If the game object is tagged as an “enemy”, they will be destroyed.

Creating a variety of prefabs helped me to get back into text-based scripting. Each of the different game objects came with a unique programming problem. Because each game object by itself was representing a rather simple problem, I was able to solve them all one by one. Also, it was helpful to put extra attention on the modularity and consistency of the objects. There have been several other game objects like collectibles or projectiles shooting turrets, which didn’t make it into the final game. I am satisfied with the result, and I am proud to see, that I felt comfortable and was immediately able to access and transfer all the knowledge from visual scripting to text-based scripting.

Sound Design

inVert

Creating sound.

Creating sound.

While movies do not give any control away to the consumer, games do. This makes music in games sometimes tricky to handle. The tension in games is often situational, which makes prearranged composition less efficient and less powerful if they do not adapt to the game state. Therefore, I wanted the soundtrack to be reacting highly dynamically to the state of the game, to enhance the gaming experience. I had to find a way to let it react to the current game state through other variables. Because the pacing of our game is continuously raising and falling, I wanted the music to be bound to the pacing and the tension of the current game state. Another goal was to modulate all sounds from scratch, without using any sound libraries. The idea was to learn how to pinpoint a specific sound while having total control over the creation of itself and without being influenced by any external factors.

inVert

Exporting sound.

Exporting sound.

The longer it takes the player to destroy an enemy, the more elements are being cut out, which continually raises the tension and increases the effectiveness of the incoming drop in. The longer none of the enemies are destroyed, the more enemies are gathering in the arena. In the same principle, as a DJ is raising the tension on the crowd by cutting out elements and fading out the lower pitch sounds, my script for the soundtrack is also cutting out elements to build the tension and prepare for the drop in. Furthermore, the soundtrack is also changing accordingly to the state of the enemies. If the enemies are switching to the mode in which they chase the player, the hi-hat, bass, and lead is replaced by a faster-paced arrangement.

I am delighted with my results in designing sounds and I think, that I have made an enormous leap forward. The soundtrack has a very progressive character, which is precisely what I was aiming for. The highlight for me is, the dynamic aspect of the music and how well it adapts to the tension of the game. I carefully crafted the sounds so that each sound would have its own frequencies within the sensible acoustic spectrum. This helps the sounds to stick out and remain distinguishable even when several sounds are overlapping.

Visual Feedback

After having implemented the acoustic feedback successfully, I still saw opportunities to enhance the experience by adding more visual feedback.

In some cases, the player would hear the shift in the soundtrack, but would not notice the change in the enemies behavior. This situation could provoke confusion, because the sound changes remarkably, but nothing seems to happen. That is why I have been implementing a script, which changes the color pattern of the game, whenever the music changes drastically. Furthermore, it gives the player important feedback about the progression of the game.

inVert

The color scheme is changed via script.

The color scheme is changed via script.

To achieve this, I wrote a script, which accesses all used materials directly. By changing the attributes of a material, which is in use, all game objects that are linked to it, can be altered in their appearance at runtime. This way, for example, the script can change the appearance of all enemies at the same time, by just changing the referred material of the enemies. I added several color patterns so that the script can blend between them.

This visual feedback was implemented last minute and can still be further optimized in many ways. I am not entirely satisfied with the color patterns, which I have been adding and I think the color fading system could be much better. Right now the colors are only changing when the enemy’s behavior is changing. I think a constant slow color fade would have fit perfectly into the mix. Nonetheless, I think it is an important feature, and for the time I had, well enough implemented.

Spawn Point Manager

Having the stack of prefabs done, it was essential to find a way how to utilize the prepared items comfortably for prototyping purpose without having them to be dragged into and out of the scene every time. For that matter, I have written a script, which spawns the desired game objects in the desired pattern under desired restrictions.

The spawn point manager has a public variable for game objects, in which the user can define the prefab to be spawned. In addition to that, the script knows the length of a beat in seconds and can generate the objects in definable intervals accordingly to the music. The user can also define whether the game object should spawn on a random location within the sphere or a random location on the surface of the sphere. This is accomplished by a random normalized vector, going from the center of the sphere. To spawn within the whole volume of the sphere, the vector has to be multiplied by a random float between 0 and the radius of the sphere. To spawn on the surface of the sphere, the vector has to be multiplied by the radius of the sphere.

There can be multiple Spawn Point Managers in the scene, each handling their own prefab, spawn amount, starting time, interval length and end time.

Although it was an easy task to accomplish, it was still confronting me with some new problems. I am glad for every work, in which I have done something new. It expands my knowledge and can help me to solve other problems faster in the future.

inVert

Us trying to solve problems collectively.

Us trying to solve problems collectively.

Recap

I am delighted with the outcome of this project and would mark it as a great success. I have thoroughly fulfilled the goal to transfer my knowledge from the visual scripting language to apply it to the text-based scripting language. Working as a team of three highly skilled programmers was an exciting experience. Because each one of us had a different skill set and approach, it was always exciting to exchange ideas and opinions. Also, working together forced us to work tidy and structured.

Being in the position of having full freedom in designing the sounds was great, and I am particularly proud of this the results of the sound design. I am still very interested in the programming of AI and would love to improve in this area at next possible chance. This time there was no complex AI needed. In overall, I am delighted with the result of this project, and I am pleased with my performance.

inVert

the final setup

the final setup

>>For my full documentation: Click HERE!<<
Published in Projects
Saturday, 06 June 2015 10:18

Odd One Out

“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

Odd One Out

Character Sketches by Betti.

Character Sketches by Betti.

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

Odd One Out

Character Sketches by Betti.

Character Sketches by Betti.

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.

Odd One Out

Character Color Schemes by Betti.

Character Color Schemes by Betti.

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.

Odd One Out

Finalized Characters by Betti.

Finalized Characters by Betti.

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

Odd One Out

Testing the capabilities of the Kinect
in combination with the SDK.

Testing the capabilities of the Kinect in combination with the SDK.

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

Odd One Out

Dancing avatars:
4 of them are mimicking the players.

Dancing avatars: 4 of them are mimicking the players.

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.

Odd One Out

structure of the data
for the recording and playback function

structure of the data for the recording and playback function

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

Odd One Out

our workspace (Betti and Anna)

our workspace (Betti and Anna)

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!<<
Published in Projects
Monday, 24 August 2015 15:00

Medusa's Bloodthirst

“Medusa's Bloodthirst” is a turn-based, puzzle-like, top-down, rouge-like dungeon crawler.

PROJECT INFORMATION

Date: August 21st-24th (Ludum Dare 33)
Duration: 1 day
Team Size: 3 people
Technology: Unity 5, C#
Constraints: You are the Monster. (Theme)

Gameplay Video

Medusa

Medusa

Medusa can turn enemies into stone.

Medusa can turn enemies into stone.

Info

This Mobile Game was created during the Ludum Dare 33. We were a team of three, and I was mainly responsible for the Procedural Level Generator.

Medusa

Medusa

Medusa can eat princesses.

Medusa can eat princesses.

The player is playing Medusa and can turn everyone into a stone statue by direct eye contact. It is a turn-based, puzzle-like, high score based game, in which the player is trying to proceed through unlimited stages to gain points. Each destroyed stone statue, each eaten princess, and each completed stage will reward the player with several points. This game is designed and runs perfectly well on mobile devices.

>>To play the game: Click HERE!<< (Chrome browser is not supported.)

>>For more information: Click HERE!<<

Published in Projects

Hobbies

When I am not dancing Lindy hop or climbing up a wall, I enjoy to create stuff and to educate myself. I believe that most knowledge can be shared and applied across a high variety of tasks. Therefore, it is useful to keep an open mindset for all kinds of different professions.

I have also designed soundtracks for my games and have been playing the guitar in a band.

Please, feel free to browse through some of my hobby projects.

 

Drop Me a Line