Temple Imperium was the first major project I was a part of. This one was different to everything else because I had to work in a team of people, working with people I had never met before and trying to get as best work as possible. At the time, this was the largest project I had ever worked on, and it was challenging because it was when COVID first hit, and learning how to remotely work in a large team was definitely a large takeaway from the creation of this game. Simiarly to all of the other university modules, we had to follow a very specific brief set out by a “stakeholder” and every week we would have to show our progress in milestone reviews in the form of presentations to the “stakeholders” as well as every other group project, totalling to around 60 people. As the producer, I ended up focusing the most on the presentations, and while each discipline showcased their own work off, when it was a more general showcase, I ended up taking the responsibility for those sections so that the other disciplines could focus on their own work without having to worry about it.
Designing the game
There was quite a lot to design for this game, and I didn’t need to do any of the programming, I was able to focus my entire time on the design aspects of the game, writing all in a wiki-document. For this game, I had to design:
- The full player character
- Primary Weapon
- Secondary Weapon
- Prototype Weapon
- Offensive Ability
- Defensive Ability
- Melee Attack
- 3 unique enemy types + a boss enemy
- How the main objective works (The Generator + Star Stones)
- How the different waves of enemies work.
- Wave timings
- Amount of waves
- Enemies per wave
- Map Design
- Player Feedback
- The different difficulties
The Level Design Process
At this point in my design journey, it was coming to the end of my first year as a designer. At the time, I did not actually have experience designing Levels / Worlds in 3D, as this would be something I focused on later in my 2nd year at University. So ultimately, this was not only a huge learning experience, but it was also an experience where… Looking back it wasn’t the best. I ended up making a few design decisions that didn’t work well. This project was also not a project I ended up spending a lot of my time on for the level design itself, as I was mainly focused on gameplay design.
It started off pretty early with a whitebox attempt. I actually ended up doing this with very little idea of what I wanted to do, I had some written design work down (such as looking at inspiration from Aztec architecture, Toltec architecture and themeatic influences (Specifically from Mictlantecuhtli – God of the Underworld). After this, I ended up just jumping into Unity very early – which reflecting on this, wasn’t the best idea. The first version of this is shown on the sidebar. This version didn’t even use Unity’s “pro builder” add-on, so I can confidently say that it was not a good idea for a map. In addition to this, as this was a wave-based game, I know that looking at this whitebox, the combat would not have been fun or engaging and it didn’t take long to go to the drawing board after that whitebox.
After discussing it in our team, we decided to get a top down version – which I would hand over to the art team to create a basic whitebox of it (as at the time, I had little experience creating a whitebox). To the right is the new top down, but this wasn’t where the map changes finished. From here, we made some changes by adding corridors connecting everything so that the player didn’t feel trapped in a corner when running around enemies. But that was actually the majority of the map work (apart from some prop adjustments to avoid AI bugging out and a meshing pass later down the line).
Designing the game mechanics
I previously wrote about a specific design process I used for Flashback (that page has a much better description of this process) and I ended up using it again for this project to give myself more experience using it. This process was:
There was a lot of gameplay design work in this production, much more than I had ever anticipated before going into it, but I was willing to put in the work, and by the end of around the third week I had designed at least the 1st iteration of each piece of work necessary for a minimum viable product (MVP) that was given to us by the person leading all of the groups.
The “Star Stones”
Temple Imperium was a part of the canonical universe of a Masters project called “Star Stone”, and had to link to this in some way with the idea of “Star Stones”, a gameplay object that powers-up the enemies in the game in 4 different ways but it also affects one of the player’s weapons (which is by discussed later on in this page).
These were a requirement given to me but the specifics of each Star Stone wasn’t. So each Star Stone was given a colour, which represented something.
- Purple | The Power Star Stone
- Orange | The Heat Star Stone
- Pink | The Heal Star Stone
- Blue | The Ice Star Stone
As previously mentioned these affected the enemies.
- Power | Increased the amount of damage the enemies dealt to the player
- Heat | Attacks left the player on fire for a few seconds
- Heal | Attacks healed enemies for a small percentage
- Ice | Attacks slowed the player
The design process for this was relatively quick compared to the design of other mechanics because we (as a team) wanted to implement the Star Stones as quick as possible to get testing. After testing, these effects felt fun to play against while not being too overpowered (after some much needed balancing), so they stayed like this.
These Star Stones also affected the final boss of the game – but this will be discussed later on in this page.
Each of the weapons on this MVP had specific requirements for the direction of their designs, shown below.
- Primary weapon for shooting at mid to long range.
- Secondary weapon for shooting at short to mid range.
- Prototype weapon charged by the Star Stones.
The primary and secondary weapon didn’t have a huge amount of research given over to them – just mostly looking at different guns and using them as the main inspiration (Taking the RPM from a selection of different weapons and averaging them out to get the RPM for this game’s weapons).
The Prototype Weapon wasn’t decided at all on the minimum viable product though, and so it went in our own direction. A laser beam rifle.
As it interacted with the Star Stones, we made sure there were 4 different kinds of laser beams
- Power | Charged attack that dealt massive amounts of damage after a few seconds
- Heat | Attacks left enemies on fire for a short duration
- Heal | Any attacks healed the player a small amount
- Ice | Attacks slowed the enemies
The main part of the enemies that I want to discuss is the boss enemy that the player encounters at the very end of the game. This boss actually went through quite a few different ideas, some of which were too demanding for the short period of time we had to work on him (the boss was actually a stretch goal for us so we only had around 3-4 weeks to work on him).
Firstly, we ended up just making it a giant version of a previously existing enemy – this was mostly for a time save as we initially only had a couple of days to work on the boss (this later got extended to a couple of weeks).
But, if you haven’t guessed, this boss changed to be more interesting with his attacks. This boss would change depending on the Star Stone.
- Power | Giant charge beam that follows the player (shown below)
- Heat | Giant flamethrower that follows the player (shown above)
- Heal | Spawns puddles of acid that damage the player
- Ice | Giant ice projectile that charges up and gets shot towards the player
Ultimately, there’s a lot more that I could talk about but this page is already dragging on. Maybe in the future!
June 2020 – August 2020
Team of: 8
1 Designer & Producer