GDD

(Written by James Holt)

High Concept

A fast paced one versus one, stylised, vibrant, third person shooter with bouncing, physic based projectiles. In conjunction with this mechanic; the middle line of the ‘dodgeball court’ moves with the flow of the game. Whoever controls the whole court before time is up, wins!

Bartle’s Taxonomy [8]

Killers: Our game within itself is heavily PVP and skilled based; killers can impose themselves upon the opposing player in this one versus one scenario.

Achievers: Our game poses challenges through the competitive gameplay of the one versus one, this will work in tandem with achievements the player can accomplish throughout gameplay.

Explorers: The environment panders to the explorer type. It’s stylised, vibrant look makes it interesting to visually explore. The downside being that the player is locked to the ‘dodgeball court’, greatly diminishing the explorer’s psychological portrait. On the other hand, the finer details of the mechanics can be explored- all the short-cuts, tricks and glitches- which our game is built upon.

Socializers: Our game is unplayable without two players, together, in-person (since online play will not be supported). Forcing relations between two, an aspect of community, for our game to be playable.

Key Features

• Third Person Shooter

• 1v1

• Fast Paced

• Stylised

Visual Style

Taking inspiration from: Fortnite [1], World of Warcraft [2], Niko Gesell [3], Overwatch [4] and Jessica Dinh [5]

We are striving for a; stylised, hand-painted, somewhat exaggerated, saturated visual style. This style will be accentuated with the use of low poly meshes. We won’t be using; normal, height, roughness, metallic, specular maps or subsurface scattering. We will heavily depend on the albedo map alone; with the occasional use of emission and opacity maps. Furthermore, instead of having individual AO maps for every object, we will be depending on Unreal Engine 4’s lightmaps for AO; and our capabilities to paint such detail on the albedo map.

The lighting [10] of our environment will be geared towards a stylised, vibrant look. This will be primarily achieved through the application of post-processing (volumes): colour grading, bloom, anti-aliasing and post-processing materials (cell shading). Lighting will consist of; point lights, directional light, sky light and reflection capture spheres. Lighting will be adjusted accordingly to suit the ‘temperature’ of its source and scene. Overall, our lighting will be saturated and warm, to match the game's mood.

Colour Palette [7]

Our game needs an obvious, emphasised split between both sides of the ‘dodgeball court’. Our idea to tackle this issue was to differentiate the assets and their colour between the opposing sides; ‘jungle’ and ‘pirate’. So the environment itself is an ‘identifier’ to the player. This obvious boundary within the ‘court’ plays an integral part to the game’s playability and flow. The worst thing which could happen, which would greatly detriment the core playability of our game, is that the player can’t tell what area of the ‘court’ is theirs and what part is the opposing player’s. Additionally, the chances of this occurring are raised when the player is focused in fast paced combat.’ If we have time or any future plans with this game, we could always take it further than just the concepts of ‘jungle’ and ‘pirate’ alone.

Our colour palette choices are rather balanced, there is a lack of overwhelming, stand-out colours-- without being muted in colour. This is to the benefit of our chosen third person shooter genre. We can highlight/ identify important components of the game, in strong colours, which stand out to the player; in comparison to the environment itself.

UI Concept

Camera Placement:

The third person camera is placed in similar style/FOV to that of “Star Wars Battlefront 2” [6], putting both the character and weapon in clear view to the player, without the camera too far pressed up, blocking the player's view. This benefits the player; by seeing their character's placement they can manoeuvre effectively within the environment. Equally, the camera isn’t far back enough to prevent the player from seeing the enemy player or any points of interest at distance.

Visual System/ Interface and Screen Flow

Screen Flow -- A graphical description of how each screen is related to every other and a description of the purpose of each screen.

Players start the game facing a large animated title screen, with two simple buttons, "Start Game" or "Quit Game". Both obviously state their purpose. Our UI is to the point and simply loops, for the player's easy navigation.

Whichever side wins will get a suiting prompt. Two UI buttons will be available, one to quickly retry said match-- as our game is fast paced this option is extremely easy to access, and positioned closest to the left. The other button takes the player back to the main menu if they choose to exit; instead of directly exiting the game, in case of a mis-click.

A pause menu quickly brings the game to a halt, by pressing the assumed button "Start". Player's can resume gameplay and exit to main menu, instead of completing the full match to reach said UI. The "Options" menu is kept here also. I believe the Screen Flow could be further optimised if "Options" were readily available on the first title screen. So players could adjust settings to match their hardware, before beginning gameplay.

The options menu allows for common changes, to help adapt the experience of individual users. Shadows, resolution, anti-aliasing and texture quality. We are hoping to also place an annotated controller, with controls here. For more on this menu see the relevant blog post.

Mechanics/ Gameplay

Physics/ Movement: The player can dash, and sprint. Both tie to a stamine bar, requiring the player to resource manage, choosing to use more stamina to dash, or less to sprint. The player can also jump, there are some ideas in place of double jumping, or boosted jumping through powerups. Some powerups may also limit player movement, like a "Freeze".

Objects - Interactions: Players have to pick up shot balls when low on ammo. Forcing players to manaouver on the defensive, to be able to once again play offensively. A quick and simple back and forth to break repetitive gameplay. Some objects can also be broken, in response to forces.

Abilities: Each player can dash and sprint. But, player's can grab a powerup pickup to gain randomised abilities -- these pickups are in limited supply. First come, first serve. Powerups range from: splitball, freeze and coconut rain. We also have plans of a timed catch, similar to actual dodgeball. This mechanic would instantly restore ammo and negate a hit. Furthermore, it could also count as point to the catchers side.

Character: Two characters are present, either controlled invidually by either player. One "Pirate", one "Tribal". Both characters are similar size and silhouette. There is no health, if you are hit, the barrier moves, there is no possibility to die. Characters are accentuated through a cell shaded, red outline -- the most visibile colour, at distance, to the human eye.

Economy: Ammo and Stamina. Players must effectively balance these, through fast-paced actions to turn the tide of the game to their favour.

Environment/ Area/ World (Cover etc.): The environment is very open, but the play area is encapuslated by invisible walls. The play area will be defined through vertex painting the landscape along the borders, filling in said area. Varios assets could litter the surrounding play area to further break it away from the surrounding environment. Cover is available to the player, but the player cannot effectively hide behind it. Since the player cannot crouch, plus no barriers are higher than the players waist. Hiding behind barriers limit your movement, but you do protect half of the player. A decision which can be decided by the player, depending on the flow of the game and their playstyle.

Combat: Players have no health, the barrier moves in response to players being hit at all. Removing the aspect of death and respawn makes the gamr much faster paced. Once the dividing line (the barrier) reaches the opposing players side, controlling all their ground, the player controlling said ground wins.

Training/ Tutorial: No tutorial is available, or guided walkthrough. Our game's controls are especially simple and common. Instead we hope to have a annotated controller within the option menu.

Game Options: We aim to have a range of options available to the player. For example: audio, colorblind options, FOV, controller remapping and game fidelity -- which can be further broken down into: resolution, anti-aliasing, shadow quality and texture quality.

Accessibility: Colourblind options and remapping, for various ease of access controllers.

Replaying/ Saving: Basic statistics are saved so they can be applied to achievements.

Easter Eggs: N/A

Animation: Needs to be obvious to the player what animation allocates to what action.

Audio: Needs to be obvious to the player what sound allocates to what action. Some suiting upbeat music loop will be playing at all times also.

Progression: Currently we have no way to progress through our game, nor have we planned for it. If we did, we could have customisable items, various maps or combat enhancements, which become accessible throughout the player’s time in game. Alternative methods of progression could be: overall number of ‘knockouts’ acquired; achievements accomplished and secret unlocks (easter eggs).

Achievements: We plan to have a simple achievement system, where the player can be rewarded with achievement pop-ups whence they have accomplished simple tasks. Such as: ‘knockout’ streak without being ‘knocked out’ yourself, trick-shots, amount of ‘knockouts’, etc.

Control Scheme

The game is built and aimed to be played with two controllers, for an equal hardware advantage by both parties. UI, mechanics and rebinds are all built around the use of controllers only.

The control scheme will be kept simple and intuitive, in relation to popular, similar third person shooters. This will be to the benefit of the player and the accessibility of those who struggle with complex control schemes. To further accessibility, various controller brands can be used, since those with accessibility issues may struggle to use certain controllers, or prefer others. We plan to introduce functionality for PlayStation and Xbox controllers. For other brands, a rebind feature will be in place.

Market Analysis (Written by Abbie Hipwell)

After some research, we’ve established a primary target audience of young children, age seven and up, to young adults, therefore we predict that ‘Dodgeball’ will be rated a 7 on the PEGI rating system [8] due to the nature of it being accessible to the majority of ages, but still having implications of mild, non-realistic violence. We are able to achieve this rating by adhering to a non-realistic, stylised game which uses mild violence in a child-like manner; the competitive theme of this game brings the rating up to a 7 since the majority of players younger than this wouldn’t understand this type of gameplay and may become frustrated.

Our game is targeted towards a gender neutral target audience, due to the theme of the game being a ‘party game’, which a wide range of audiences should be able to enjoy.

By looking into the existing market, particularly at games marketed towards our target audience, we are able to take inspiration from their art styles, gameplay, and themes within the game.

We want to appeal to young audiences through a bright, hand-drawn art style, similar to that of World of Warcraft. These kinds of art styles are commonly catered towards young audiences because of their vibrant and energetic use of colours and shapes - as shown in the picture below, simple shapes are usually exaggerated and bright colours and patterns are used in the texturing.

Competitive and fast-paced games such as Nidhogg appeal to audiences, particularly younger ones, because of how easily accessible they are to play. Nidhogg is extremely easy to pick up and play without almost any tutorial or requirement to be good at games, its overall premise is simple as well as its mechanics. Our goal during production is to aim for a similar style of gameplay which captures these features.

The GDD is much more underdeveloped than I would've hoped. In some places it expects much more than what's possible, or what isn't implemented in game. However, these were ideas we hoped to have, but never had time to implement.

I primarily worked on the GDD with help from Abbie. Our lack of pre-production meant it was swept under the carpet. Furthermore, we were so often in contact with one another, we were able to be on the same page most of the time. The game was constantly undergoing metamorphosis, constantly updating the GDD independently for each back and forth change seemed unnecessary. As I don't think many in our group frequently really referred to this document, as the GDD was stored through communication to one another. I would prefer to reserve my time for work applicable to the project.

References