Technical Design Document

## Project Pitch

***Unworthy Roses*** is a Top-Down Perspective, Co-op 3D Hack and Slash PC game, where players take control of Irene and Valeria, two girls that must free the Modern Human World from the Ancient Monsters from the Underworld.

### Overview

* **Platform:** PC
* **Controls**: Xbox Controller
* **Players:** 2 player co-op.
* **Genre:** Hack and Slash
* **Engine**: Unreal Engine 4.2

## Evaluation

### Engine of Choice

**Unreal Engine 4** is the better solution for *Unworthy Roses’* development. The team has worked on the engine more and working with both C++ and Blueprints will make for a quality product that not only Programmers work on directly in-engine.

### Target Platform

PC, due to the lack of console’s development kits along with input opportunities for both Mouse + Keyboard and Controller.

## Development Requirements

This section describes all needed tools, software and hardware that will be required for the game’s development:

 **Storate** | 15 GB

## Online Services

### **Networking**

The Networking in the game will follow  Unreal Engine’s  **client-server** model. One computer in the network acts as a **server** and hosts a session of a multiplayer game, while all of the other players' computers connect to the server as **clients**. The server then shares game state information with each connected client and provides a means for them to communicate with each other.

Majority Of the Networking will be done using **Rep\_Notifies** while the Events will be handled mostly by the server and communicated to the client later using **RPC functions**.

Our Main focus should be the gameplay is smoothly performed on both the client and server sides so building replicable components  is encouraged.

### **Servers**

* Listen Server.
* Steam Online Servers.

### **Cloud Services**

* Google App Engine / Microsoft Azure
* Cloud Services will include tracing of analytics like DPS, Player movement , Completion times with representation shown in a graphical view.
* Live Patching can be introduced in later stages of development.

## Development Plan

The project’s development has been broken down into seven different milestones: **Pre-Production** in which the team will work on documentation and prototyping, **M1** with core gameplay fully implemented, **M2** with polished gameplay after feedback, **M3** with all levels implemented without polish, **Alpha** for feature complete, **Beta** for content complete and **Final** ready for ***Pitch & Play*** presentation.

All deliverables will follow a *Scrum* philosophy in order to break down major tasks along Production into smaller and manageable deliverables with adequate time estimations.

### Project Objectives

Our goal is to develop a 10 to 15 minutes 3D Top-Down Co-op Hack and Slash gameplay experience over the span of 4 months of Production that will showcase both individual and team abilities at *Edgy Entertainment's* disposal. Players will take control of Irene and Valeria into the depths of the Underworld.

### Finished Product Goals

#### **Full Online Launch**

After all is set and done, we would love to release the game in a full, polished version on the Steam Store for everyone to play. Our game is built upon Co-op in its entirety so we would love to have people have a chance to give it a try with their friends online!

#### **More Levels**

The gameplay’s duration is just a few minutes due to all constraints of the project, however, the team would love to create even more challenging levels for the player to continue experiencing the game’s mechanics and its art.

#### **Sequel**

Our game will provide a hook at the end of it. Whether the stretch goal for the boss fight is implemented or not, we will leave the players wanting more of our character’s stories.

## Project Structure

### Project structure and naming File formats naming convention

The following tables describe the project structure and naming format for the game’s folder’s in-engine.

### General Naming Rules

The following rules will always be followed whenever a new asset is created with no exceptions unless strictly specified with proper documentation and reason behind it:

* All names in English.
* All asset dependencies should be in the same folder. (except for shared assets)
* Asset type determines prefix.
	+ *Blueprint is **BP\_**assetname\_01*
* Certain types (eg. textures) use a suffix to specify sub-types.
	+ *T\_Grass\_01**\_N** for normal maps*
* Use underscores to split type from identifier and numeric values.
	+ *SM**\_**DoorHandle**\_**01*
* Use numeric values with 2 digits.
	+ *SM\_Pipe\_**01***

The following table describes the project’s structure and naming format for the game’s asset’s in-engine.

## Levels

*Unworthy Roses* will provide the player with two Main Levels which provide branching for replayability and player’s choice:

1. Unworthy Undertakings
2. Unworthy Laqueus

Each level will test the players with all mechanics provided. However, if both levels are delivered on time by their respective milestones, then we will be able to provide a small Tutorial and a Boss Fight to round up the experience.

### Main Level 1: Unworthy Undertakings

This level takes place right after the tutorial. Armed with their new abilities and knowledge, Irene and Valeria are ready to go down further into the underworld. The two’s teamwork capabilities will be tested as the world becomes more and more challenging. As the environment around them changes, Irene and Valeria must adapt to what the world wants. With more combat, puzzle and movement-based tests, the two need to work together to get to the end and escape.

### Main Level 2: Unworthy Laqueus

The whole level is designed in a way which will challenge the combat and the co-operative skills of both players. The level requires both players to fight and traverse cooperatively for them to succeed. The Level is Divided into 2 of the following path players can choose to follow that is path **A** and path **B**

### Levels Parameters and metrics

Both levels adhere to the mechanics that support the game’s features that are fully described in the **Key Features and Core Mechanics** section.

## Asset List

### 3D Assets

Most of the assets listed here are shared throughout the game with some changes only for materials and/or texture, however, they will be done modularly for easier in-game implementation.

### Audio Asset List

The Audio asset list can be found here (This is still a Work In Progress and shall be finalized after we’re given a full dedicated Sound Designer(s) collaborator: https://drive.google.com/file/d/1R6l2wscwOMvUGa7kJ-TNFWbH3ThVuMni/view?usp=sharing

### UI 2D Art

Our game will only require 2D Art Assets for the User Interface:

 HUD: Character Avatar
 HUD: Demon Bloom Bar
 HUD: Health Bar
 HUD: Player offscreen avatar
 Main Menu Screen
 Pause Menu Screen
 Player Selection Screen
 Title Screen
 UI Interactable Button

## **Coding Conventions**

All c++ files must have **// Copyright 2020 Edgy Entertainment <Name> . All Rights Reserved.**

### **Coding Naming Conventions**

* The first letter of each word in a name (such as type name or variable name) is capitalized, and there is usually no underscore between words. For example, Health but not lastMouseCoordinates or delta\_coordinates.
* Type names are prefixed with an additional upper-case letter to distinguish them from variable names. For example, FVector3 is a type name, and Vector3 is an instance of a FVector3.
	+ **Template** classes are prefixed by **T**.
	+ Classes that inherit from **UObject** are prefixed by **U**.
	+ Classes that inherit from **AActor** are prefixed by **A**.
	+ Classes that inherit from **SWidget** are prefixed by **S**.
	+ Classes that are abstract interfaces are prefixed by **I**.
	+ Enums are prefixed by **E.**
	+ Boolean variables must be prefixed by **b** (for example, bPendingDestruction, or bHasFadedIn).
	+ Most other classes are prefixed by **F**, though some subsystems use other letters.eg:
	+ No prefix must be added to primitive types :
		- * **float AttackDamage;**
			* **int32 AttackIndex;**
			* **bool bCanAttack;**
			* **FName AttackName;**
			* **FString PlayerName;**
			* **UClass\* AttackClass;**
			* **USoundCue\* AttackSound;**
			* **UTexture\* WeaponTexture;**
* Functions that return a value should describe the return value. The name should make clear what value the function will return. This is particularly important for boolean functions. Consider the following two example methods:

[what does true mean] **bool CheckAttack(FAttackData Attack)**;

[name makes it clear true means player is attacking] **bool IsAttacking(FAttackData Attack)**;

### **General Coding Rules**

 Acceptable and Unacceptable Blueprint examples:

Acceptable BP 1Acceptable BP 2Unacceptable BP

#### **Guidelines**

* Write self-documenting code:

```
// **Bad**: t = s + l - b;

```

```
// **Good**: TotalLeaves = SmallLeaves + LargeLeaves - SmallAndLargeLeaves;

```

```
**Write useful comments:**

```

```
// Bad:

```

```
**// increment attack**

```

```
++AttackIndex;

```

```
// Good:

```

```
**// cycle through the attack sequence**

```

```
++AttackIndex;

```

#### **Const Correctness**

Const is documentation as much as it is a compiler directive, so all code should strive to be const-correct.

This includes:

* Passing function arguments by const pointer or reference if those arguments are not intended to be modified by the function,
* Flagging methods as const if they do not modify the object,
* and using const iteration over containers if the loop isn't intended to modify the container.

```
void SomeMutatingOperation(FThing& OutResult, **const** TArray<Int32>& InArray)

```

```
**{    // InArray will not be modified here, but OutResult probably will be }**

```

```
void FThing::SomeNonMutatingOperation() **const**

```

```
**{    // This code will not modify the FThing it is invoked on}**

```

```

**TArray<FString> StringArray;**

```

```
for (**const** FString& : StringArray)

```

```
**{    // The body of this loop will not modify StringArray }**

```

#### **The 'auto' Keyword (Please Try to Avoid)**

**When is it acceptable to use auto?**

* For iterator variables, but only where the iterator's type is verbose and would impair readability.
* In template code, where the type of an expression cannot easily be discerned. This is an advanced case

#### **Lambdas and Anonymous Functions (Lets Keep it simple)**

Try to avoid using Lambdas but can be used if all the programmers are in accordance with it.

#### **Strongly - Typed Enums**

```
**UENUM()**

```

```
enum class **EThing** : uint8

```

```
{

```

```
   Thing1,

```

```
   Thing2

```

```
}

```

### **Code Formatting**

Always include braces in single-statement blocks. For example.:

```
if (bThing)

```

```
{

```

```
   return;

```

```
}

```

```
**If - Else**

```

```
if (bHaveUnrealLicense)

```

```
{

```

```
   InsertYourGameHere();

```

```
}

```

```
else

```

```
{

```

```
   CallMarkRein();

```

```
}

```

#### **Switch Statements**

```
switch (condition)

```

```
{

```

```
   case 1:

```

```
       ...

```

```
       // falls through

```

```
   case 2:

```

```
       ...

```

```
       break;

```

```
   case 3:

```

```
       ...

```

```
       return;

```

```
   case 4:

```

```
   case 5:

```

```
       ...

```

```
       break;

```

```
   default:

```

```
       break;

```

```
}

```

### **General Style**

* Pointers
	+ FShaderType\* Ptr : **Correct**
	+ FShaderType \*Ptr : **Wrong**
	+ FShaderType \* Ptr : **Wrong**

## Project Technical Details and explanations

### **Features**

#### **Elegant Stick-Fighting + Powerful Punches**

**Overview**

Both of our characters will engage in melee combat using two different fighting styles: Irene's not a heavy hitter yet a master in her Stick-Fighting style. Her combat is heavily inspired by Martial Arts like the one used by *Shaolin* monks called *Yin Shou Gun.* Valeria is pure muscle. She hits enemies with her *Doberman Gauntlets* with no mercy. Her combat will rely on landing heavy punches, no matter the target. Both characters will trigger combos if successful attacks are landed in a row.

**Visualization**

Screenshot of one successful attack. Disclaimer: animation is not ours and was used only for testing combos on prototype.Screenshot of third successful attack. Disclaimer: animation is not ours and was used only for testing combos on prototype.
**Table of Metrics**

 Powerful Punches (per hit)
 Combos
* 2 hits = 1.5 x original damage upon impact.
* 3 hits = 2 x original damage upon impact.
* 4 hits = 3 x original damage upon impact.

#### **Cooperative Puzzles**

**Overview**

Throughout the game, players will encounter puzzles that will stop them from traversing through the levels. In order to complete these, they must work together to solve them, as they will not be solvable with only one character.

**For example**: If a statue needs to moved towards a specific spot for the puzzle to be solved, the players would work in this way: Irene's player must use the stick to change the path for the statue to reach the eventual target, whilst Valeria's user, must use her powerful punches to actually move the statue.

**Visualization**

Player on the left uses the rotating platform to rotate the sliding track.Player on the right starts pushing a block across the track after it has been rotated.
**Table of Metrics**

#### **Overwhelmed Combat**

**Overview**

Our goal is to have the players feel overwhelmed with the number of enemies at one time. This in turn forces players to play together rather than by themselves, thus reinforces the co-operative play.

**For example:** the enemies will begin to horde around the two players from multiple sides. This overwhelming number or enemies will have players fight “back to back” to clear the waves of enemies.

**Visualization**

Enemies surrounding a static player.Enemies following after a moving player.

**Table of Metrics**

 Moving algorithm

#### **A.I. Horde System**

O**verview**

The AI Horde system tries to corner the player into making decisions about how to combat as the player with heavy attacks can be tasked with defeating the commander while the player with area of effect attacks focuses on the grunts. Also the players are more likely to work together as the horde can get overwhelming for just one of them to feel powerful when working together than when fighting them alone.

**Visualization**

**Table of Metrics**

Increases the damage dealt by grunt by 2 x the base damage.

#### **Demon Bloom Mode**

**Overview**

When the Bloom bar is filled the Demon bloom mode activates and the player can choose when to use it to its advantage. There are certain features of this ability:

* Do more damage: When activated players do more damage with the same attack for a certain period of time.
* Take less damage: While getting a buff on attack players rather take less damage when this is activated.
* Health Regen: The health of the player gradually regenerates while using this ability.

**Visualization**

Regular Health Bar (green) and Demon Bloom meter (pink) yet to be filled and ready for use.Regular Health Bar (green) and Full Demon Bloom meter (pink) ready for use.

**Table of Metrics**

 *Demon Bloom* Duration
 *Demon Bloom* Fill

#### **Edgy User Interface**

**Overview**

Players will have a user interface that complements the style of the game. The user interface is designed in such a way that it feels like it is a part of the game rather than included. The user interface will also be easy to understand, and unobtrusive. For example:

* The menu screen will feature an environment where the two main characters will be posing. Depending on what is selected on the menu, the camera and pose will change. This adds personality to the game’s menu screen.
* Health/Demon Bloom Bar is designed in a stylistic way that implores our world and character design.
* Button notifications will be up to standard to the technical requirements checklist however will still feature personality from the game.

**Visualization**

**Table of Metrics**

Up to **one** camera animation may occur upon hovering a single button.

### **General Reference Table of Metrics**

 Grunt’s health
 Commander’s health
 “uu” units

### **Mechanics**

The following are the mechanics that our players will execute throughout the game’s experience.

#### **Staff Hit**

**Overview**

Irene uses her staff to attack multiple enemies dealing medium damage and clearing the horde.

**Visualization**

T**able of Metrics**

#### **Gauntlet Hit**

**Overview**

Valeria uses her *Doberman Gauntlets* to punch one target at a time dealing high amounts of damage.

**Visualization**

**Table of Metrics**

#### **Simple Movement**

**Overview**

As in most modern games, the players are able to control either Irene or Valeria using simple inputs: up, down, left and right. They are able to walk in any direction the players decide as long as they are grounded. There is no sprinting in the game.

**Visualization**

**Table of Metrics**

 Right/Left
Left when input is **negative**.

#### Dodge

**Overview**

Thanks to the power given to Valeria and Irene by the Demon Lord, players are able to evade incoming attacks to prevent them from getting damaged by the enemies. Same as in basic movement, the dodge can be performed in any direction.

**Visualization**

**Table of Metrics**

 Cooldown punishment for using all three.

#### **Jumping**

**Overview**

Valeria and Irene can jump in order to traverse through the underworld as well as in combat to fight in an interesting way.

**Visualization**

**Table of Metrics**

 Cooldown between jumps.
 Jump height

#### **Climbing**

**Overview**

Valeria and Irene can climb on cracked walls in order to get to a higher location as they advance through the level.

**Visualization**

**Table of Metrics**

 Maximum climbing time.

#### **Interaction**

**Overview**

Valeria and Irene can interact with puzzles. Each with their own interaction. Valeria will be using her gauntlets to interact with each piece while Irene will be using her staff to interact with other elements.

**Visualization**

*Irene character interacting with a rotating pillar for a puzzle.*

**Table of Metrics**

#### **Target Lock-on**

**Overview**

Due to the several number of enemies surrounding the players when in combat, they will be able to use a lock-on mechanic for them to be able to choose their desired enemy to engage. When locked-on, players will be assisted to land their attack on the desired target.

**Visualization**

**Table of Metrics**

 Lock-on indicator

### Stretch Goals

As stated before, our Stretch Goals mainly reside in creating a Tutorial at the beginning of the game as well as a Boss Fight at the very end. While creating a Tutorial is more Game Design challenging, the Boss Fight would require an extra effort for a creation of a unique *A.I.* for it to defer from the already built-in horde system for common enemies.

## **In-House Tools**

Screenshot of Telemary Dashboard
**Link To Tools Page (WIP)** : https://telemetaryproject.wm.r.appspot.com/

The following are tools that will be developed for our game:

**Automated Cloud Building** : Automate The Building of game at 23:00 everyday via by performing a pull request from git and uploading the successful build in google drive, if failed report error to admin.

**Live Data Manipulation:** Use custom made flask server and VUE client to interact with the debug data of the game live as the game will get a pull request of the updated data in specified intervals.

**Game Launcher** : Custom game Launcher for downloading, deploying patches and allowing access to our website for our users..

**Cloud Analytics Tool :** Get graphical representation of core data from our play test and to improve upon liek DPS, Player movement, Completion Efficiency, AI Movement and Damage Chart.

## Technical Diagrams (UML)

### Class Diagrams

Player Class DiagramAnimation Interface Diagram
### A.I. Horde System Behaviour Tree

The following behaviour tree diagrams describe in a rough manner the way our A.I. will behave throughout the game’s enemy encounters.

Grunt Base Behaviour: Checks whether the grunt belongs to a mob or not and chooses the behavior accordingly. Grunts will move in a swarm + shepherding hybrid algorithm.Grunt Swarm Behaviour: Swarm Behaviour Checks which unit number the unit is in the mob and moves accordingly to create a swarm like pattern to encapsulate the players. Also checks if it is in effect radius of the commander if no then moves to protect the commander.Grunt Disoriented Behaviour: The Grunts lose buffs and move near the player when attacking and not directly towards to give a sense of irregularity to their movement.Commander Behaviour: The Commander Checks whether it is in the effective area of another commander or not if yes it moves back to its own area and tries to attack from there.

## UI/UX

### Wireframes/Mockups

Title Screen MockupMain Menu MockupPlayer Selection Screen MockupHeads Up Display MockupPause Menu MockupGame Over Mockup

## Test Plan

Our game requires a lot of playtesting due to the game’s genre. Therefore, tests shall be done consistently throughout the development of the game.

### Types of tests

**Player Combat and Control test**

 Players must feel the movement and combat according to our games pillars. This is the most important test of all, as it will differ if our game is actually enjoyable.

**Character DPS**

The game will challenge the player’s skill heavily through combat. Therefore, Character DPS testing shall be done to improve the game’s combat and balancing.

**AI Behaviors**

 The game’s A.I. is a feature on its own and shall be treated as such. The A.I. must be stress-tested to show it’s true capabilities in early stages of the game to prove our goals.

**Networking Replication Test**

 For the online feature of the game to be fully implemented and working in game, network replication must be tested each time a new feature and/or mechanic is implemented in game in order to prevent lack or a tackle on the game’s experience.

**Progress Tracking**

 For the small experience to be actually playable from beginning to end in the given 10-15 minute window at *Pitch & Play*, we must have our players’ progress tracked and tested to optimize the experience at the highest quality possible.

## Test Cadence

 Character DPS
 AI Behaviors
 Networking Replication Test
 Progress Tracking

## Technical Risks

The following are the major Tech Risks that we identified during Prototyping and Pre-Production along with their contingency plans:

 *If Networking is not fully implemented with as less lag as possible by the end **M2** then we will lose our online feature.* | **HIGH** | MED