Overview

Design Goals

  • I concepted and created a dynamic turn-based combat system with ships that dealt/received damage depending on their position and orientation because I thought that this would make for a good tactical game mechanic 
  • I created a paper prototype to test initial ship stats, game interactions, ship movement/rotation, and how damage is dealt. This allowed me to balance the gameplay, plan how game systems will be set up in UE4, and envision what type of UI/UX is needed.
  • I created data systems for ship stats in UE4 and input the data from initial paper prototypes. These data systems made creating new ship designs and iterating on existing ships quick and easy 
  • I created a rapid prototype using Unreal Engine 4 using minimal art to begin testing the game's features and balance early 
Engine: Unreal Engine 4.10.0
Genre: Turn-based Strategy
Team Size:  Just me
Page navigation
Paper Prototype
Ship Orientation and Combat
UE4 Rapid Prototype
Blueprints and Game Widget  

Space Command Design

​Space Command is a single player 3D top-down turn-based strategy prototype set in space built using Unreal Engine 4.10.0. Players interact with the game’s pieces on top of a hexagonal grid and play against another opponent hot-seat style. Each player can move, rotate, and attack with their ships as long as they have enough action points. The player that destroys their opponent's fleet wins. 

In addition to the Unreal Engine project, I created an equipment system where players can upgrade their ships by equipping crew members that add abilities and change the stats of ships. I developed this concept using a paper prototype to start testing and balancing all of the combinations of abilities and stat changes. 

Paper Prototype 

  • The goal of the paper prototype was to test the game's mechanics and ship interactions before making the project in engine.
  • I also tested advanced features of the game such as different crew abilities and stat changes. 
  • I continued to balance the game's advanced features while implementing the basic interactions in engine.  

Ship Orientation and Combat

  • I wanted to create a more dynamic turn based experience to encourage players to move around on the battlefield. I did this by making ship orientation matter:
    1. Some ship's damage varies depending on which direction they fire in relation to its orientation.  For example, the attack craft deals 10% more damage when he shoots directly in front of him.
    2. Some ship's defense varies depending on which direction they take damage from. For example, all ships have a weakness from attacks to their engines (behind the ship). 
  • This system allows players the option to try and flank their opponents in order to exploit their weaknesses. It also encourages them to move their ships into optimal arrangements to maximize the damage they can deal  in one turn.

Rapid Prototype Design (UE4 Prototype)

  • The goal of the rapid prototype was to set up the game's basic mechanics quickly in order to begin testing the actual game in engine.
  • Another goal was to set up the blueprints (scripts) so that other systems could be added to the game without having to redesign existing work.
  • The game features a top-down perspective hot-seat style game where two players play against each other. A player loses when all their ships are destroyed.  
  • Used UE4 blueprints to create all the mechanics.
  • Used UE4 widgets to create a simple HUD for players to see ship information and to choose interactions like movement and attack.

Blueprints and Game Widget

Three major blueprints drive the game: The game mode, the hex tiles that make up the game's grid, and the parent ship. The widget communicates between the other blueprints in order to display data about the player's ship. 
Game mode
  • Sets all the game variables, creates the game's HUD, and creates arrays of the player ships, enemy ships, and hex tiles when the game loads. 
  • Contains data of the ship and hex tile blueprints so that they can easily access data from each other. 
  • Contains the logic for ending a turn to allow player 2 to move and attack when its their turn. 
  • Contains the function to move a ship to a new location. 
Parent Ship
  • Contains the variables and functions all the child classes share such as the ships stats, movement, and attack systems.
  • Detects when it is clicked and displays the HUD so that the player can interact with the ship and view its stats. 
  • Detects the enemies that are within attack range and highlights the hex underneath them to red during attack mode.
  • Sends a request to the Hex Grid blueprint to highlight all the tiles it can move to during move mode. 
Hex Grid
  • Is able to 'activate' and 'deactivate' based on requests sent from other blueprints. 'Active' hex tiles allow click events. 
  • When clicked, it sends a request to activate a player's ship if a player's ship is above it. 
  • Also when clicked, it sends a request to damage an enemy ship if there is an enemy ship above it. 
  • Detects other hexes within the grid, which provides data for the movement and attack systems. 
Ship Info Widget
  • Displays a ship's name, shields, hull, and AP data to the player. Updates the HUD information when stats change in game. 
  • Allows the player an interface to toggle between attack and move modes. 
  • Allows the player to rotate if they have enough AP.

Postmortem

What Went Well
  • It was very easy to iterate on the game's design after play testing the paper prototype.
  • The paper prototype made creating the game in UE4 straightforward. 
  • Using object-oriented programming in blueprint was easy to implement and visually easier to understand. 
  • Game design did not require a lot of art assets to build. 
What Went Wrong
  • Testing the paper prototype took a long time since all the data was calculated and tracked by hand. This made play testers bored and reduced the number of play test sessions. 
  • It was difficult play testing and iterating on the paper prototype while building the game at the same time in UE4. 
  • I had no repeat play testers. Due to the nature of the game's design, some players chose poor strategies for victory. Having repeat play testers would have help me figure out where players where having a difficult time learning optimal strategies. 
  • The movement system was more complicated than I initially scoped. I iterated on three separate systems of ship movement. Each had their strengths and weakness in terms of interface and movement detection algorithms. 
​What I Learned
  • Although a paper prototype is great for testing a game's mechanics before they are implemented, a rapidly prototyped game is even better. Play test sessions went faster when the UE4 prototype was complete, which allowed more play test sessions. Blueprints made the rapid prototyping much easier. 
  • Learned how to fully flesh out a game's mechanics and immediately start gathering play test data before needing to use a game engine. 
  • Not only is play test data important, but repeat play testers would have been a great benefit to this project as well. This way I could test new scenarios against more skilled players
  • learned to take player feedback in order to iterate on a complex game system. 
  • Learned how to use object oriented programming using blueprints.