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

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:

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.

Databases

 * Google Data Store

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.
 * Live Patching can be introduced in later stages of development.
 * 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.

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 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.

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:

Coding Conventions
All c++ files must have '''// Copyright 2020 Edgy Entertainment . 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:
 * 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
&#9; Acceptable and Unacceptable Blueprint examples:

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& 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 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;

}

Namespaces : Do we really need those?
Just use forward declaration!

General Style

 * Pointers
 * FShaderType* Ptr : Correct
 * FShaderType *Ptr : Wrong
 * FShaderType * Ptr : Wrong

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

Table of Metrics

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

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

Table of Metrics

A.I. Horde System
Overview

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

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

Table of Metrics

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

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

Table 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

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

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

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

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

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
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.

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.

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.

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