Minimum Viable Product Development – Antarctic Ranger Development Log #2

Welcome to the second development log for Antarctic Ranger! This looks at the Blueprint scripting behind the game’s Minimum Viable Product, meaning this leans a bit more towards Programming than it does Design but it’s a necessary measure that was taken to allow for further gameplay design and to inform the level design which is much later in this project.

After the initial planning stage was completed and the requirements were drawn up, it was time to get into Unreal Engine 4 and create the Minimum Viable Product shown in the video below.

Minimum Viable Product Gameplay

The goal was to implement the core gameplay mechanics (shown below), from scratch, using minimal flair, only using the graphics needed to prove that the gameplay works, to get the the core gameplay fully programmed and playable in preparation for further development and iteration.

Again, the MVP Requirements as shown in the Game Design Documentation

In Unreal Engine 4, this broke down into five main objects, the game mode, player, weapon, enemy and play area volume. Some of these provided a challenge while others were much simpler to implement.

Game Mode

The Game Mode was responsible for handling gameplay elements that are not under the player’s direct control, most notably the wave-based gameplay and enemy spawning. Below are some snippets of the core gameplay that was handled by the Game Mode.

Setting up a new wave
Snippet of Enemy Spawning Logic
Increasing Wave Difficulty
Selecting a Random Spawn Point (Target Points placed in the Level) for an enemy to spawn on

As shown in the video at the start of this article, the Game Mode was successfully able to spawn enemies onto a randomly selected spawn point as well as hadling increasing wave difficulty as the player successful defeats a wave of enemies.

Player Character

Being the player character, this object took a lot of setting up as it needed to take into account a lot of components such player input for multiple actions such as firing weapons (more about that during the weapon’s discussion), movement, aiming, looking around and so on.

Script for Player Movement and Looking around

While it was quite a challenge to set up from scratch, it was still successful and performed as expected in the minimum viable product.


As shown in the video above, the weapon was a basic one, no aim-down-sights mechanics, reloading, overheating and so on which just needed to be usable on the player’s input as this stage.

This was achieved by using the Player Object to handle inputs from the player and the Gun Parent object, intended to be used as a parent class for different types of weapons which appear later in the game’s development, which contained all of the firing logic using values such as the player’s location and rotation to determine where the weapon is being fired and what direction the shots are travelling in.

Blueprint Script in the Player Object that feeds the Player’s Location and Rotation into the weapon the player is currently using

The weapon made use of a ray-tracing line instead of spawning projectiles to allow a much simpler approach to damaging the enemy objects in addition to allowing me, as the Designer, to make changes to the weapon’s firing range using an appropriate variable, named Max Bullet Distance.

Max Bullet Distance being used to set the Direction and Distance that the Bullet travels from the Player

As shown in the image above, the Max Bullet Distance is used as a part of the calculation in the Player Object that determines the direction in which the bullet will travel and how far it will go.

Line Trace Setup taking in values generated by the Player Object

Furthermore, the use of the ray tracing system allowed a much simpler system that allowed me to take advantage of the ability to make each child object of the Gun Parent use different sounds and particle systems to give each gun a unique feel, keeping with the intended science fiction genre of the game, as and when it was needed later in the project and removing the need to spawn a separate projectile object which would have likely added complication for hit and damage events as well as going against the intended feel of the science fiction genre.


For the minimum viable product, the enemies just needed to do three things, move towards the player, stop moving and attack the player if they get close to the player and go through a death sequence when they are out of health.

Blueprint Script Showing AI Movement and Attack logic
AI Death Sequence which is included as a part of the Damage Event

All of this worked successfully in the minimum viable product since it managed to track the player’s position at all times and responded to each situation as designed and scripted.

Play Area Volume

This was a measure taken to make sure that the player would stay inside the level’s intended boundaries and ensured that if they were to find a way outside the level and use that to their advantage, it wouldn’t last long, making the negatives of such actions outweigh the benefits for the player.

This appears in the video above as the wireframe box that encapsulates the entire test envrionment. This was probably the simplest of the mechanics to implement using Blueprint Scripting for the following reasons.
– The only extra variable in the player character object needed was a Boolean which was true by default and became false if the player was outside the volume
– Not many functions were needed, simply timer events and a function to kill the player when they have spent too long outside the play area volume

Blueprint Code for the Play Area Volume

Overall, the Minimum Viable Product was very succussful at providing a starting structure for what’s to come later. Next time, I will be discussing what was designed and developed after the MVP, the different types of weapons and pickups.