Page tree

Computer Games Laboratory
Winter Term 2017/2018


 

 

Hikari no tō

tower of light

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



Artem Bishev - Jonas Mayer - Muhammad Inshal Uddin - Paul Preißner

Team Pick One
 



1. Game Proposal

1.1 Game Description

Overview

Summarized in one sentence, the game is a cooperative networked dungeon crawler enriched with native virtual reality support.

C:\Users\Jonas\AppData\Local\Microsoft\Windows\INetCache\Content.Word\totalview.png

The main objective is to create a cooperative dungeon crawler with VR and rogue-like elements. During a game, up to four Diablo -like crawlers must work together to survive and work their way through a procedurally generated dungeon, supported by a dungeon master. The dungeon master is a god-like entity that can observe and influence the dungeon from a giant’s VR perspective as well guide and support the other players. The crawlers and the master working alongside each other to achieve a common goal implements the “Together” theme for this project.

This document will discuss the basic structure and mechanics of the game in question. As such, it is divided into the following sections: Crawler and Master Gameplay , Overall Mechanics , Style and Setting .


Crawler Gameplay

The crawlers play on a standard PC using keyboard and mouse. Each crawler has an individual perspective of the map containing a real-time view of their immediate surroundings and a structural view of the dungeon rooms they have explored thus far (i.e. Fog of War). This necessitates the presence of an intermediary party (the master) to act as a coordinator between the crawlers. Their primary tasks are to defeat foes, interact with objects inside the dungeon, reach certain locations, collect loot and the like.

Each crawler has special abilities depending on their class like melee, ranged, support, etc. with its own set of strengths and weaknesses. Thus, a single crawler will not be able to master the dungeon alone. These classes not only provide a different experience for each player but also give them  a specific role in the team. A squad of multiple players will ideally pick different classes to complement each other’s strengths and weaknesses.

No levelling system, or a very rudimentary one, will be implemented to avoid programming complexity. The objective of classes and abilities is to provide the feel of a role-playing game without creating an entire “ Dungeon and Dragons ”-like stat levelling system.

C:\Users\Jonas\AppData\Local\Microsoft\Windows\INetCache\Content.Word\crawler_final.png


Master Gameplay

The master plays the game using a VR headset and hand controllers. The dungeon is mapped to the VR space of the system, so the master can overlook the entire dungeon and focus on areas of interest intuitively. Floating above the dungeon, the master cannot take damage. He can see the crawlers running around but only has a limited understanding of precise enemy activity. From the crawlers’ perspective, the master will appear as two hands and an abstract face representation floating above the dungeon.

The role of the master player can be summarized in two words: “Guide” and “Support”.

As a guide, he leads the crawlers to their destination. This can be in the form of helping isolated crawlers avoid combat, bringing them together to regroup, coordinating their individual movements and so on. To do this, his set of actions will include pointing in certain directions or placing physical markers. As such, the master player functions as the strategist of the group.

In his supporting role, the master has different abilities to benefit the crawlers or harm enemies either directly or indirectly. Indirect measures include altering the dungeon structure to benefit the crawlers, spot enemies, give temporal speed, damage and health boosts to crawlers directly, nerf enemies similarly, set up traps for enemies and supporting structures for crawlers. The master can also directly heal crawlers and damage enemies but is limited in accuracy in the scale differences and the clumsiness of VR direct manipulation.  As an example, the master can toss a physics-based fireball that will cause a large area damage that can also damage the crawlers, or a heal ball that will also heal enemies. The challenge for the master is therefore to assess the usefulness of naturally inaccurate but powerful direct interaction.

Despite being god-like, the master is limited in power. Since abilities are limited in their usage by cooldowns, resources or consumables, he will have to manage his abilities carefully to be able to use them when they are needed most. This includes having to collect resources or collectables or have the crawlers supply them by picking them up or finishing side quests.

C:\Users\Jonas\AppData\Local\Microsoft\Windows\INetCache\Content.Word\master_final.png

Overall Mechanics

Initially, all crawler players are dispersed randomly in the dungeon. They are isolated from each other and have no knowledge of the others’ location. The dungeon master must micromanage navigation and support in this phase. They explore the dungeon either following the master’s directions or of their own will. Although “going rogue” is possible, players are additionally incentivized to form groups and cooperate by scaling enemy difficulty and/or employing debuffs on isolated players.

Once the crawlers are together, all players must work together to accomplish a given goal such as defeating a boss, solving puzzles, finding treasure, eliminating all enemies in the dungeon, etc. They receive rewards upon completion of the goal after which they may continue to the next level of the dungeon and start again.

Setting and Style

To not end up with yet another dungeon crawler with a medieval/fantasy setting, the decision was made to set the game in a modern Asian city. Instead of a bunch of adventurers having to crawl down through different levels of a dungeon, a squad of diversely skilled street warriors has to fight its way up through the different levels of a fortified high-rise tower in order to rescue their friend from a rivalling Yakuza clan. While he’s being kept for his supernatural powers and is unable to escape by himself, he uses his powers to guide and support his friends on their way up.

The graphical style will be a minimalistic 3D style (à la Superhot). This decision was made due to limited artistic resources and a focus on technical aspects and gameplay. To keep it visually interesting, the visuals will be dominated by strong contrasts between shady, foggy darkness and colourful, bright “Neon” lighting and particle effects, inspired by nightly streets in Asian cities like Tokyo that are dominated by illuminated street signs.

C:\Users\Jonas\AppData\Local\Microsoft\Windows\INetCache\Content.Word\style_tower.png

C:\Users\Jonas\AppData\Local\Microsoft\Windows\INetCache\Content.Word\inspiration_colors2.png

C:\Users\Jonas\AppData\Local\Microsoft\Windows\INetCache\Content.Word\pictures-of-tokyo-4-1.jpg C:\Users\Jonas\AppData\Local\Microsoft\Windows\INetCache\Content.Word\inspiration_colors1.png

C:\Users\Jonas\AppData\Local\Microsoft\Windows\INetCache\Content.Word\style_dungeon.png


1.2 Technical Achievement

The game is to be implemented using Unity3D, using Unity networking for player synchronization and virtual reality controls for the master.

From the gameplay and setup description, the following are the main technical challenges to tackle to implement the game:

  1. Set up stable and efficient networking between all players
  2. Set up and tweak virtual reality with hand tracking
  3. Procedural dungeon generation

1 and 2 look to be the primary tasks as they are the backbone of the game. Networking is to be constructed off of Unity’s built in networking functionality, where the main challenge lies in correctly handling server/client communication, tweaking latency and link load, continuous synchronization and possibly error correction.

VR setup and tracking are planned to rely on the Oculus Rift CV1 headset and included “touch” controllers. While camera setup is simple with recent Unity versions and only requires some tweaking to camera parameters, hand tracking might turn out to be a larger challenge for correct translation, accuracy of control and error (both digital and physical) correction/avoidance.

Procedural dungeon generation is still an unknown. The most likely candidate is to use the well documented Cellular Automata algorithm and premade level modules. Nevertheless, considerable effort is expected.

1.3 "Big Idea" Bullseye

 

 

1.4 Development Schedule

Functional Minimum

  • Basic crawler
    • third person player controller
    • box
    • no c lasses
    • can deal and take damage
  • Basic VR master
    • box for head
    • two sphere hands
    • hand-tracking
    • buff and debuff by button press (no physics and ray casting)
  • Basic enemy
    • red boxes
    • can deal and take damage
    • primitive movement (no pathfinding)
  • Basic map
    • Hand-made
    • square shaped plane
    • box obstacles (“walls”)
    • spawn points
    • enemies
    • end-goal to restart/win
  • Networking
    • world objects synchronisation
    • crawler and master synchronisation

Low Target

  • Classes for players
    • Four classes with two abilities each
  • Physics-based abilities for the master
    • heal orb
    • fire ball
  • Four types of enemies
    • different attacks
  • One primitive Boss
  • Better models
    • humanoid models for crawlers
    • hand model for master
    • whatever models for enemies
  • Communication mechanics between players
    • Creating a mechanism for crawlers to signal master
    • More communication options for master
  • Prefabs for 10 rooms and assets for later use in dungeon generation
  • 4 handmade examples of levels with enemies and bosses
  • Moving to next level after reaching end-goal
  • Win screen after completing all example levels
  • Primitive UI for crawler and master

Desired Target

  • Total of 6 classes for crawlers
    • Main + Side attack
    • 3 special attacks
  • 6 different Enemies
    • advanced pathfinding
    • advanced idle behaviour
    • random spawns
  • 2 fleshed out Bosses with different behaviours
  • Hide enemies from master
  • Higher variety of skills for master
    • abilities to alter the dungeon layout (like creating and destroying the walls)
    • make enemies visible for short durations, spot enemies and traps
  • Basic eye candy (lights, particles)
  • Basic SoundFX
  • Main menu
    • Server lobby system
  • Mini-map for crawlers with fog of war
  • Semi-stat based system for crawlers (strengths and weaknesses)
  • Procedural generation of dungeon
    • more props and tiles
  • Better models (enemy models, variety)
  • Basic story elements
  • Add crabs as enemies
  • Collectibles (Boxes)
  • Win screen

High Target

  • Cooler technical stuff, such as volumetric lighting for fog and neon lights
  • Loot and artifacts that can make each run distinct and interesting
  • Better level generation, puzzles
  • Collective AI for enemies, different behaviors
  • Music
  • Sounds of enemies and atmosphere
  • More fleshed out story
  • Levelling system for players
  • Separate levels by themes (10 levels dark and gloomy, 10 tropical, etc)
    • Create enemies according to the theme of the level
  • Final boss fight, end scene
  • Completely randomized spawns of enemies and Bosses

Extras

  • Deep Story
  • Matchmaking
  • Side-quests
  • Steam Integration
  • Steam Greenlight

 

Detailed schedule here:

https://app.agantty.com/sharing/6350e3c98f45772e54ad99f881c67321

1.5 Assessment

The game’s main point is to provide the players with a unique cooperative experience within a familiar concept. They will feel right at home in the setup of a dungeon crawler, but the master player, the vastly different viewpoints and the distinct task distribution give a new spin to the genre. Crawlers and master must play together, build on each other’s strengths and come up with a shared strategy in order to win the game. Each player should feel that they have an equal purpose in the team.

The crawlers will be get a rush from the closeup action and seeing their comrades fight alongside them, while the master player will be immersed by the sense of scale and direct hand tracking in VR, leaving each side with a unique experience.

Additionally, the setting and style of the game, the winding headquarters tower of a modern Asian underground organization in the hazy nights of a metropolis flooded by the contrast of bright neon signs, offer a game environment seen less often in dungeon crawler games.

 


2. Paper Prototype

2.1 Protoype Description

Basic Setup

There are three players in our prototype: two crawlers and a dungeon master. Additionally, a “game master” handles the tasks that will be automated in the digital game like enemies and environment alteration.

The crawlers and the dungeon master each have their own play-board composed of a 4x4 module grid. The modules are drawn on one side of the cardboard cutout. Each module contains a 5x5 tile grid representing one room of the dungeon.

C:\Users\Jonas\AppData\Local\Microsoft\Windows\INetCache\Content.Word\WhatsApp Image 2017-11-12 at 22.51.39.jpeg Each of the tiles within a module can be either a wall (filled) or a floor. Adjacent floor tiles can also have walls between them to prevent movement from one to the other. Floor tiles at the edges of a module can contain a door connecting it to the next module.

A T-shaped divider separates the dungeon master and crawlers. This is to hide the maps of the crawlers from each other so they each have their own perspective of the dungeon. All boards are in the same configuration and orientation with respect the master’s point-of-view.

C:\Users\Jonas\AppData\Local\Microsoft\Windows\INetCache\Content.Word\WhatsApp Image 2017-11-12 at 22.53.01.jpeg The dungeon master has four ability cards, featuring a symbolic representation on the front and a number from 1-4 on the back. Further props required to play the game are two dice (D6 & D4), a black marker and post-its in four different colors.

Entities on the map

Four distinct entities can take up a floor tile on the map. They are represented by differently colored post-its.

C:\Users\Jonas\AppData\Local\Microsoft\Windows\INetCache\Content.Word\WhatsApp Image 2017-11-12 at 22.52.28.jpeg Crawlers are represented by blue and the numbers 1 or 2 depending on the player controlling them. Each crawler can move up to three tiles per turn, pick up collectibles and attack one enemy in an adjacent tile.

Basic enemies are represented by red. They deal 1 point of damage per attack, have 5 HP and can move up to 2 tiles per turn.

The boss enemy is represented by yellow. It deals 2 points of damage, has 20 HP and can move up to 3 tiles per turn.

Lastly, loot, represented by green, can be picked up by crawlers by walking over the tile. It will recharge a random missing ability of the master.

Game Setup

Before the game starts and the players can see, the game master prepares the playboards. They place players, enemies, loot and the boss on the boards. As mentioned in the basic setup, all boards are oriented to be the same when looked at from the dungeon master’s perspective.

To simulate fog of war, crawlers can only see the module they currently occupy. All other modules are flipped over to hide their contents. The dungeon master can view all modules on his map but he can only see the location of the boss enemy, crawlers and loot.

Game loop

The turn order is:

  1. Dungeon Master
  2. Crawlers
  3. Game Master

Before each of the other players’ turns, the game master has to make their visible modules globally consistent. If a player moves to another module, it needs to be updated so that it represents the current state of enemies and loot e.g. the other player may have picked up the loot or killed the enemy there.

The dungeon master can perform one of two actions per turn: gesture to a crawler or use an ability. This restriction is placed upon him to represent the multi-tasking constraints the master will face in the final game where he will have to guide four players at once. The dungeon master also has markers that he can place on his map to remember enemy positions as well as keep track of crawlers. This is considered a free action for him.

If the master chooses to gesture to a crawler player, the master may ignore the divider to point to a position on the crawler player’s map. This simulates the perspective of the crawlers where each of them can see the dungeon master from within the dungeon but cannot see what exactly he is pointing to unless it is close to them.

The master has four different abilities representing both direct and indirect skills: Buffs, debuffs, throwing a fireball or a healing orb. The master may not have more than one of the same ability. He will start out with none of these abilities and will only get one when a crawler picks up loot. Upon such an event, a d4 dice is rolled and an ability corresponding to the result of the dice roll is awarded to the master. This design decision was made to create some dependency on the crawlers for the dungeon master as well as to simplify loot placement through randomness.

A buff gives one targeted player double attack damage for that round. Meanwhile, a debuff will prevent one targeted enemy from attacking that round. A fireball will damage all entities within a module including crawlers. The damage will be based on a d6 dice roll. The healing orb will heal all entities in a module to full hit points. The last two abilities are module-based in order to emulate VR-induced inaccuracy.

The crawlers start by moving up to three tiles. Crawlers can only move through empty floor tiles or ones containing loot. Crawlers cannot move diagonally. When moving to another module, the crawlers have to move over the tile containing the door. The neighboring module is then flipped to reveal its contents. On leaving the door tile, the previous module is flipped face down. When moving, crawlers move their post-its to the corresponding tile.

When collecting loot, the crawler throws dice until one of the aforementioned abilities of the corresponding number can be awarded to the master. After this, the loot sticker is removed. If the master has all four abilities, the loot stays in place.

After moving, a crawler can attack an enemy in an adjacent tile. In this case, the player throws a D6 dice and deals that amount of damage to one specific enemy. The damage dealt is indicated on the enemies’ post-it by marker lines. If an enemy takes damage greater than or equal to its health, it dies and is therefore removed from the board.

After dungeon master and crawlers have finished their turn, the game master will play the enemies in the players’ tiles. Enemies will move towards the closest player. Enemies cannot move to other modules. After moving all visible enemies, each crawler will receive damage from adjacent enemies based on the damage of each enemy. Each enemy will only attack one crawler. As the enemies are played by the game master, she may use them as she sees fit. This emulates enemy AI in the final game.

End Conditions

The game is lost when both crawlers are dead and won when the boss is killed, irrespective of remaining enemies.

 

2.2 Results of Prototype Testing

The current design of the game ensured co-operation between the crawlers and the master. Crawler players depended on the master for advice. However, crawlers still moved and explored the map of their own free will. The crawlers co-operated with the dungeon master to locate enemies and helped each other avoid them. The master players initially focused on getting a loot item so they could be of assistance in case of emergencies.

Once the crawlers were united, things became easier for them as they could support each other directly in combat. As such, they easily went through the dungeon and defeated the boss.

C:\Users\Jonas\AppData\Local\Microsoft\Windows\INetCache\Content.Word\WhatsApp Image 2017-11-12 at 22.52.35.jpeg Fun Elements

The initial phase of the game, where the dungeon master was guiding individual players and helping them sneak around the map, seemed to be fun for all players involved. There existed a strong co-operation between the crawlers and the dungeon master in this phase leading to interesting interactions and ability uses. Most immediately recognized the need to serve each other’s needs to win.

Dull Elements

Once the crawler players met up, the role of the dungeon master became less meaningful. Crawlers became more confident and rushed head long into combat. The challenge of surviving in the dungeon was significantly decreased and the master was mostly only needed to locate the boss and provide minor assistance in combat. In the meantime, he would skip rounds simply because there was nothing to do. Even though we pinned the problem down to the turn-based system, adjusting enemy threat, the master’s abilities and map complexity may reintroduce elements that made the initial phase more enjoyable. Further testing will be done in the digital prototyping phase as the real-time mechanic will allow for a closer representation of the final game as opposed to the turn-based paper prototype.

Design Revisions

What we quickly noticed during design of the prototype is that we were not specific enough in our original pitch idea regarding exactly which entities the dungeon master should be able to see and how – that it should be boss enemy, crawlers and loot, but only enemies that can be seen by crawlers, how we could make sure they weren’t abusing their abilities in combination with gesturing – that this would be taken care of by the natural constraint by micromanaging up to four crawlers and the inaccuracy of VR tracking, or how we should skew the balance between exploration and combat – that it is better favor exploration to promote communication with master.

We also noticed that it might be problematic for the master to see the boss from the beginning and being able to kill him directly with fireballs or directly regroup the crawlers there. Therefor it was decided to make the boss immune to damage when no crawlers are in the room. In addition, it might be useful to not show the boss to the master before the crawlers haven’t regrouped.

Unfortunately, the nature of a paper prototype felt quite restricting when attempting to translate our core gameplay to a physical representation, be it by having to change from real-time interaction to a turn-based system, switching to a very strict “fog of war”-esque map system or needing a cumbersome game master player to act in place of a digital synchronizing server.

Nevertheless, the gameplay of the game is now more fleshed out due to our deeper discussion of individual game mechanics and player relationships.