Summary

 

"The Shifting Castle of Antiok" is a procedurally generated 2.5D platformer created by me and William Karlsson over the course of a month.

 

The purpose of this project was to collaboratively script and design a nice game while exploring procedural generation and learning more about Unity and C#.

 

The player's main goal in this game is to navigate through the mysterious castle of Antiok in order to find three keys. Those three keys can be used to unlock the castle gate and escape. The player must be careful not to fall prey to the deadly traps and enemies of the castle, since the layout of the castle will shift every time the player dies, making memorization of one's escape route impossible.

Specifications

  • Created together with William Karlsson.
  • Finished in four weeks - at 50% (4 hours/day).
  • The game procedurally generates a new map every time the player dies.
  • Created with assets from the Unity Asset Store.

Tools used

  • Unity 5.6.0
  • C#
  • Photoshop
  • Autodesk Maya
  • Audacity

Getting started

 

William and I were excited about the idea of creating a game together in Unity several months before we even started this project. Inspired by an earlier assignment from our education - creating an endless runner in Unreal Engine 4 - we eventually decided to involve procedural generation in our project.

 

A modular environment, a player character and an enemy were the three key assets we needed for our game. Sooner rather than later, we ended up finding exactly what we needed through the Unity Asset Store.

 

The next step was to delegate the varying work tasks between the two of us. I was mainly responsible for the programming part of the game, while William handled the majority of the design.

The assets that we bought for the project. Handpainted PBR was the visual style we sought for our game.

 

  • Animation through Mecanim
  • Handling HP, damage and death for the player and enemies
  • Healthbar system
  • Sound system
  • Varying menu functionality
  • Spawning particles
  • Handling keys and game ending

My contributions

 

Programming:

 

  • Main part of the procedural system
  • Player controls
  • Enemy AI
  • Damaging laser
  • Lava surfaces
  • Projectile shooters
  • Movement/rotation scripts

for traps in the level

  • Platforms that can be jumped through

 

 

Design:

 

  • Game design
  • Level design (3 out of 10 levels)
  • Main menu scene
  • Lighting
  • Postprocess Effects
  • Smaller part of the audio design

 

 

Art:

 

  • "How-to-play" screen
  • Intro screen
  • Death screen
  • Outro screen
  • Minor texture- and model tweaks

 

The procedural system

 

At the start of this project, we originally had grand plans about programming a dynamic procedural system instead of a static one (generating new rooms as the player moves through the map, instead of generating the whole map in one go). We wanted to introduce a difficulty curve within the generation, and even randomly generate enemies and player weapons. Unfortunately, as we all know, time is limited.

 

Given the time we had, and all other features we had to create in order to make this feel like a game, we eventually decided to scope down to the most basic procedural generation we could come up with. In retrospect, we see this as a wise decision as we otherwise most likely would have ended up with a game extremely lacking in gameplay.

 

In the pictures below, I shortly explain how the system works and showcase how it looks behind the scenes.

A slightly more detailed rundown over how the generation works.

Added a 0.25 second delay between every spawned room to visualize the generation.

Modular scripting

 

In order to truly make use of the procedural system, we needed to give it an as big pool of rooms to randomize from as possible. To make varying rooms as quick as possible, we scripted level mechanics in a way where they would "just work" perfectly with eachother without any advanced setup.

 

Create new gameobject -> Add movement component -> Add laser component. There, a moving laser!

 

Examples in the pictures:

 

1 - Topmost left: Alternating movement + Projectile Shooter

2 - Topmost right: Rotation + Laser x 2

3 - Bottom: Rotation + Alternating movement + Lava surface +

Projectile Shooter x 4

Game design problems

 

The three keys which the player needs to find in order to escape the castle was a change me and William decided to make after two weeks of working on this projects.

 

Originally, no keys existed in the level - the player just had to survive on her/his way to the end room and then defeat a boss residing inside it. This design may sound exciting, but posed several problems:

 

1. If the boss room randomly ended up really close to the start zone, the game ended up being too easy.

2. The player had no incentive to explore the castle. It was all about reaching the end as fast as possible.

3. We simply had no time to script a second AI for the boss.

 

The three randomly spawned keys solved those three problems

perfectly without creating too much work for us.

The player's main mission was not always to find three keys. Originally, the end room was supposed to contain a boss.

Before and after postprocess camera effects.

Improving the aesthetics

 

The visual part of the game suffered significantly when we started to realize how much work we had to put into scripting functionality and creating enough content for the procedural system.

 

Even though we did not have time to prop the various rooms of the castle too much, we did not want to abandon the aesthetics of the game entirely. The Dark Souls inspired theme of "darkness + fire" got to be our signature style after several light and postprocess tweaks.

 

We also decided to use a heavy Depth of Field effect on the back- and foreground as many modern 2.5D platformers seem to use this to make the player focus on the main "gameplay layer" of the game.

Final thoughts

 

This game was an extremely fun and challenging project to work on. Procedural generation was a really interesting feature to include in the game, even though it felt as it was not a feature one should try to implement in a game created in such a small amount of time.

 

There are lots of things that could be improved with the game, given more time. Mainly, I would've liked to adress the linear feel of the game, since it right now gets relatively boring after a few deaths. Some sort of collectable coins (player keeps them even after dying) throughout the rooms in combination with an upgrade shop in the starting room would have introduced an interesting loop and helped make the player's feeling of progression. This, paired with an upgrade to the procedural system which would have made it follow a difficulty curve, would in my opinion bring the game closer to its true potential.

 

All in all, I'm really proud of the game and feel that I learned a lot, especially when it comes to scripting and game design.

Screenshots