
A Deep Dive into Solarios, A Tiny Uprising game. Started as a University Final Year project, this page will explore my contibution to the project.
​
Officially my role in this project is the Team Lead, but I also handled a few things such as Producer, Rigging, Unreal Scripting and Tech art. So this page is dicated to the more techy roles.
Introduction
My name is Timothy Wee and I am a Game Designer and Game Indie Developer in my free time. During my time in University of Hertfordshire, my team and I decided to make this game project for our Final Project: Solarios, A Tiny Uprising in Unreal Engine.
For most of us, it’s our first time really getting into a true game production pipeline. Personally, while I’ll be responsible for game designing and project management, this would be the first project that I will be fully diving into the Blueprint scripting as well. That said, production on this project will keep moving forward regardless!
​
Below we breakdown some of the components of the game scripting as well as the final product for full preview.
Gameplay Walkthrough
Here's a run through of the entire Demo, if you like to get a copy of the demo, you can download it from our Google Drive.
Click Link
https://drive.google.com/drive/folders/1hSZctg-BnaxpbQGlnPg119InQZ0Gm-So?usp=sharing
Game Plan
Solarios, A Tiny Uprising is a Turn Based Strategy game with focus on narrative story exploration elements, following a group of exiled tiny races who lost their home to a different bigger race known as the Exploiters. The story follows a young exiled individual who attempts to free her deity and her people from the Exploiters.
The game is divided into two core game modes, nicknamed Exploration and Combat. Players will get to explore the world and lore of the world with Real-Time movement through Exploration mode but as they meet threats, they shall face these enemies in a unique (hopefully!) turn based combat.
Ultimately the fun and difficult part of this is to translate my game design into Unreal directly via blueprint scripting so hopefully I fully am able to capture it here by breaking down some of the main elements in the game. Here's a Pre-alpha footage of the entire flow of level.
​
Full Tech Breakdown
A long overall of the project I did. This involves unreal scripting, rigging, animation and producer roles.
​
Watch this if you want to "quickly" scan through my entire contribution on the project.
​
​
Vertical Slice
Here is the initial vertical slice video that we created to convince our lecturers of the project.
We had planned for a Start & End cinematic, a explorative 3rd person adventure section that can be interrupted by combat. The combat uses wherever the environment the player encounters the trigger and uses it as the environment for the Combat system which swaps to a turn based game.
​
​
Debug Menu
Unlike the other mode, the Combat Mode has way more technical challenges and to help debug this, the first direction was to make a Debug Menu. The contents of this menu were created at different timings of the production but all in all, they really helped identify any problems and made some of the debugging process less miserable.
-
Console Command: Some in-game buttons to help check performance throughout the process.
-
Camera: Allow us to constantly test and adjust the Camera setting while in game.
-
Grid: The gameplay is all based on the logic of the Grid so it made sense to have these debug options to help identify any anomalies and fix it on the spot if needed.​​
-
Pathfinding: When pathfinding calculates, this menu helps display every math and result of each formula used for the A Star pathfinding.
​
Camera Setup Pt01 (Combat)
The Top Down camera was chosen to help with the tactical synergy of a turn based game. Ensuring players are able to see their options, threats and loot was very important to the gameplay plus when the threat gets bigger in size, we want to make sure this enemy type does not block the player’s view as well.
Camera Setup Pt02 (Combat)
A breakdown of the important parts of the Camera Setup in the Combat Mode. It is important to note that I ensure the game itself or the future menus can access this values as well to edit the camera setting at any point of the game.
Level Setup & Loading
At the start of the production, we were not sure if we were going to use Square or Hexagon grids, so I thought it would be a good idea to make both from the ground up first before eventually coming to the final decision.
Plus this is the time where I learn how to set up “Level Loading” which will probably be very useful since we have two different game-modes.
Grid
The first complex task I had was the grid, this will be the cornerstone and foundation of all future logic as many will rely on the Grid System to function or calculate on it. This includes the AI pathfinding system, spawning of assets, calculation of abilities and movement & more.
So the grid section is broken down into what I found was the most important, this does not highlight every little blueprint but does cover a wide range.
Grid Alignment
The grid consists of multiple shapes being duplicated, then each becomes aligned into a grid position starting from the first position of the bottom corner (Vec(3) value) then counted up into both X & Y axis based on their individual Index Value (for position).
Grid Base on Environment
Setting up a custom collision label, we can allow specific parts of the environment to allow the grid to detect it. Including a way to tell the height of the environment so that our tiles can scale up or down too.
Tile Type Pt01
Each tile is subjected to different kinds of types, opening the door for gameplay elements. As such, we will feature the following types of tiles. (Whether we use them all, we can always toggle them in the future).
Tile Type
Normal: Each tile has a “cost” to enter, normal tiles simply cost 1 movement to enter. This cost can be modified by other features in the future.
Obstacle: Each tile that completely blocks movement and line of sight. This just prevents any possible movement on all types of unit.
2x Difficult Terrain: Each tile cost twice (2 times) the amount then normal tiles. This affects pathfinding calculation when it tries to optimise the cheapest path to reach anywhere.
3x Difficult Terrain: Each tile cost thrice (3 times) the amount then normal tiles. This affects pathfinding calculation when it tries to optimise the cheapest path to reach anywhere.
Flying only: Each tile that completely blocks movement for any unit except for unit type that has the tag “Flying”.
Selection of Grid
Selecting anything on the Grid is the important step. We ensure that the grid registers the mouse cursor and mouse clicks. Afterwards, we can establish which grid tile was selected.
Pathfinding
After some research, A* (A Star) algorithm is the best and quickest way to settle the pathfinding system for a more tactical gameplay.
This one was probably the most complex coding and personally I have never done this before, thankfully there are a lot of Unreal with A* tutorials to really help develop this.
I’ve decided to try to break down important steps of how this pathfinding system works.
Step #01: Figure out current position tile and Destination Tile.
Step #02: Discover neighbouring tiles of current tile.
Step #03: Pick the one closest to the end point.
Step #04: Repeat Step #01 to #03 until the Current tile equals the Destination Tile.
Step #05: Retrace all the tiles chosen in Step #03. Forming the path.
Neighbour Tile Detection
For the first step for the A* Pathfinding, we have to identify all the tile neighbours for the Grid. That way, we'll be able to jump from one neighbour to the next until we reach the target.
Spawn Units (On Grid)
A huge feature was setting an action that allows me to spawn in units onto the grid itself. This section covers the basics and later will cover a more detailed version of this.
Setting this part was important as the next few steps involved unit selection and how to manipulate them so it was only the right next thing to do.
Movement of Units (On Grid)
The first usage of our Pathfinding System is the Movement of our units. With that said, we also wanted to setup the units stats.
So ensuring that moving around is important, we also want to restrict their movement base on specific stats of the units.
For the future, we can use this stats to influence other aspect of each unit too.
Implemeting Abilities Part 01
We begin with creating a framework for abilities. This is our next big feature in the game where each abilities should feel unique. But first we ensure we have some form of basic concept to begin. Ultimately this abilities later will have more advance features as well as cost to using it.