While taking the graduate-level Level Design course at Savannah College of Art and Design, I was tasked with creating a gameplay kit that could be used to build at least three unique encounters using Unreal Engine 4 and Blueprints. I chose to keep my project simple by making a small-scoped side-scrolling platformer with modular pieces that could be used to create different types of obstacles for the player to overcome.
Since the focus of the course was on the design and scripting of our game, we were able to use assets from the Unreal Marketplace and as such I designed the themes of the game around the assets I used from Infinity Blade packs, Kenney and other sources. The title of the project, Of Chickens and Dragons, was derived from a chicken asset I found in one of the Infinity Blade packs and a dragon noise I got from Kenney.
The design of the game underwent changes in order to keep the scope small and to allow for more polish. For example, one of the features proposed in my level design document was attacking/spell-casting. I ultimately chose to abandon this and move towards a Super Mario Bros. style enemy system because it allowed for more iteration and faster implementation; I would have needed to find player character assets with attacking and spell-casting animations since creating those would have been both outside the scope of the class and my skill-set.
The original levels were laid out with the following mechanics in mind:
- Sprinting
- Double-Jumping
Attacking/Spellcasting- Removed to reduce scope.
As such, the levels in the game deviate from the original documentation. The first level saw the least amount of change as Trampoline was introduced during development and a platforming section replaced the bridges between islands originally planned.
In order for the gameplay kit to be effective, each piece needed to be flexible enough to fit together to form cohesive yet unique challenges across all three encounters. However, this also needed to be balanced with not writing redundant code and ensuring that properly organized systems using inheritance and Structs.
The most prominent modular piece in the game is the pick-ups. There is a base Pickup actor in which the following actors are inherited from:
- Health
- Energy
- Key
- Gold
- Chicken (Double Jump)
The Pickup base actor contains a StaticMeshComponent and a PickupCollisionBox child actor that allow for the subactors to have the same functionality that is standard to all of them such as hiding the mesh display, particles on pickup, effecting their corresponding PlayerResource value, etc. Each of the PlayerResource types, Health, Energy and Gold are the only ones transferred between levels by the OfChickensAndDragonsGameInstance by having them stored in a struct called PlayerData which is where the player gets their resource values from when they start a level.
Whenever the player collides with a Pickup object, feedback was needed to alert them they had acquired a new resource. Since the feedback consisted of a sound and an emitter, these two elements were organized into an Effect struct. Multiple Effect instances should be added to an Effects array which allowed for multiple emitters and sounds to played.
Another example of where this modularity was used was with the moving platforms. In order to create engaging platforming gameplay, various different moving platforms were implemented with both helpful and harmful elements added to them. In addition to have empty platforms and platforms with a Pickup on them, platforms could also have Spike or Trampoline child actors on them.
The enemies in each level are also a form of modularity that exists in the game. Each enemy moves back-and-forth and shares a similar mechanic to Super Mario Bros. where players need to jump on top of them to kill them. Each individual enemy may have additional collision volumes that launch the player away and deal damaged if overlapped.
A significant area of improvement in this project would be reorganizing the assets and restructuring the project. As the final due date approached, I quickly imported assets without much thought to where they should go and used the search bar to locate them when needed. Should I go back and revisit this project, I would sort all the asset types into corresponding folders.
This project could also use significant refactoring. While most of the code is organized into functions, not all of it is and there are also some redundancies with some of the actors like the enemies and platforms. Additionally, significant amounts of the code is not commented which could lead to confusion as to what is actually taking place in the scripts.