Our task was to create a game within eight weeks. Our initial concept was an arena shooter, which over time turned into a hybrid of a platform shooter. With limited time, we wanted to have only a few sets of abilities that could be used in creative ways.

I want to show the weekly progress in order to explain the growth and iterative process of this project. The game went through a lot of changes during it’s runtime, where we relied a lot on playtesting in order to find the most fun.

Continuing I will be showing my weekly progress as the lead programmer.

Week 1

• Plan features from concept art

• Categorize feature priority

• Experiment with Blueprints

• Raytracing

For the first week I did a lot of planning. With my Scrum master I put up a reasonable time frame for the features that we wanted to be in the game, as well as categorizing which mechanics were going to be a higher priority. My source of reference for planning features was the concept art our lead artist had created, pictured above.

This is also where I decided to do the whole project with Unreal’s nodesystem Blueprints. My reasoning was that blueprints could be a visual aid as well as a communicative tool. I wanted to be able to explain the coding structure of the game to my team members, in order for them to understand the scope and limitations of the created mechanics.

The feature that I prioritized first on my list was the shooting mechanic. I started out with some very simple raytracing for bullets that would have an originating position from a specific bone.

What also was included in overall planning was setting up GitHub with SourceTree and making sure every team member was connected to the repository.

Week 2

• Building mechanic

• Split screen 2-player

• Basic UI

The building mechanic was a sort of reverse engineering of the building mechanic in Fortnite. The cube gets the position and camera rotation from the player and snaps it in a grid.

I decided, give the time frame, the game would have a split-screen set up rather than implement networking code with a lobby that players could join.

Additionally I implemented some very basic UI for player HP, a timer and placeholder character models.

Week 3

• Asset implementation

• Invisible wall with only player collision

• Internal playtesting:
  — New winning condition
  — Knockback on bullets as a feature

Here the first proper level design is implemented together with a winning condition. However at this point the game had taken a different approach, with the winning condition being reaching the top of the map and colliding with the beacon. This meant that shooting each other was not meant as a way to gather points, but we wanted to add a knockback effect to the bullets that would hinder the other player and make them fall.

This decision was made collectively through internal playtesting. We simply did not find our idea fun and decided to take on a new approach.

The players were divided in two separate sides with a wall inbetween them. This wall would only collide with the player tag, thus making it possible to shoot through it.

Week 4

• Asset implementation

• Bullet spread

• Bullet knockback effect

• New crosshair with feedback on target hit

• Cube destruction

• Powerup

• Split playtesting:
  — Two groups with different builds
  — Gather data to evaluate which version is more fun

The shooting mechanic went through some changes. It would shoot three bullets at each key press, with each bullet having somewhat of a different trajectory. Now it also had a knockback effect, meaning it was a way to hinder the other player from advancing upwards. The knockback effect took the forward vector of the shooting player and drastically increased it since it is normalized.

What you might also notice is that the cubes would get destroyed from bullet impact. The built cube gets destroyed and a destructible mesh is spawned and takes it’s position. Beneath to the side of the player is a bar that is filled up when hitting the player, this was the beginning of a powerup that would destroy all of the enemies cubes.

A lot of our decision making was a direct result from split playtesting. We had 28 testers where one half would get one build, and one half would get another. Group 1.A played a version where you built one cube per click, whereas group 1.B played a version that built two cubes in the shape of a staircase. Our thought process was that we wanted to reduce every “stop” that the player needed to do which would take down the tempo of the game.

Week 5

• Iterations from playtesting:
  — Double cube
  — Better feedback for the powerup
  — Aim assist
  — Glowing outline on characters, visible through objects

• Warmup phase

• Animation implementation

The result from the playtesting was that the double cube solution made the gameplay faster and more intuitive. Most players did not realize that there was a powerup in the game, and we decided to display it as a power meter around the crosshair.

Many players had found it difficult to aim at the other player, so an aim assist feature was implemented. To make it easier for the players to locate each other, I implemented a glowing border around the character models that would be visible through objects.

Due to the successful extraction of information in regards to fun gameplay with our playtesting session, we decided to keep playtest as often as possible. We would make improvements, changes and iterations from the results of these playtests as they proved to be very valuable.

Week 6

• Iterations from playtesting:
  — Removal of separate areas, now sharing space
  — Bullets reworked, is now an exploding missile with a blast radius

• Sound implementation

• Tutorial implementation

• Removal of warmup phase, instead countdown before game start

Many of the decisions during development came from results of playtesting, where we could with data identify what players found fun. One of the big changes was to remove the two separate areas and make the players share the same space. This was a way for us to get more player interaction.

Instead of having a warmup phase, a tutorial was created. I created a transition from the tutorial to the main level when both players had completed it. Therefore the warmup phase became redundant, but I made some changes to it so it became a countdown sequence before the game started.

The far most important development was the explosion missile. Due to players finding it difficult to find each other and the aiming gave a really strong advantage to the most experienced players. Therefore I created the explosive missile, that would create an explosion radius that would knockback players and destroy cubes on collision.

Week 7

• Minimap added

• Knockback shield added

In order to further provide assistance in overall navigation in the gameplay, I created a minimap based on player locations. At first it was a zoomed out projection of an ortographic camera, and then I removed objects that did not need to be rendered. This meant that it displayed two axes, since it was represented in a 2D space. Two rectangle shaped objects would use the same position as the players and render it on the map.

In order to encourage more player interaction, another ability was introduced. The knockback shield had a similar effect to the explosive missile, but needed the player closeby and did not destroy cubes.

Week 8

• Removal of powerup

• Game split in three levels:
  — Main menu
  — Tutorial level
  — Main level

• Iteration on minimap

From results of playtesting, we realized that the powerup to destroy all of the enemies cubes was far too powerful if one were ahead. Additionally it would create some lagging issues when thousands of chunks from the destructible meshes would fall down. The game was performance heavy in general and we were in a pretty good spot schedule wise, but I decided to split the tutorial and main level into two different maps. My reasoning was that it didn’t need to be rendered when playing within the main tower.

The minimap was iterated upon, taking only the vertical axes of the players. Displaying two axes became more disorienting than helpful.