1.1 Long Lost Lightning
Team size: 11 (3 Programmers, 3 Artists, and 5 Designers)
Duration: 25 days (5 weeks)
Long Lost Lightning is a wholesome puzzle game inspired by Breath of the Wild. Manipulate where the lightning strikes by tinkering with things spread out throughout the level.
1.2 Goals
Since we had a team composition with a surplus of skilled designers, brimming with creativity and ready to embark on a new project, we wanted to ensure that we kept them busy; therefore, our first goal was given:
Designer Centric
​
For most of us, this was the first project in unreal; it had a broad theme and generous time for each milestone compared to our previous endeavors. We felt like this was something we had to capitalize on. Therefore, our second pillar revolved around continuous learning and wholeheartedly embracing the developmental journey.
To keep it simple, our third pillar was: Learning
1.3 The Plan
To enhance the autonomy of our designers, we strived to build a system that could operate without constant programmer intervention. To ensure that simplicity was a top priority, we opted for a Subclass Sandbox-inspired pattern, which contained everything necessary to create all the required features of the game.
For the project to be a success, we had to put more work in the hands of our designers and, therefore, we thought that a solution that involved leveraging a combination of blueprint events, guided by criteria defined in the code resting on the back of Unreal's built-in interface definition would be optimal since most of our designers already were experienced with blueprints. The system outlined in the provided UML provided a sandbox so that the designers could quickly iterate on their work and design new features without programmer assistance.
​
.png)
1.4 Execution
My focus is on providing a broad overview of the coding journey. Instead of showcasing flashy one-liners, I aim to give a comprehensive perspective on the challenges encountered. The goal is to highlight the complexity of the bigger picture without delving into overly technical details. I spent a large chunk of the project assisting or pair programming with my fellow programmers.
1.4.1 Generic Actor
The Generic Actor class is the base class for all objects within our game with any functionality and serves as our SubClass Sandbox (see Sandbox Graph). The game had three different categories of objects: Lightning conductors, Event Initiators, and Event Listeners. Lightning conductors are used for our main game mechanic; these can be hit by lightning; tinkering with the level to change what is being targeted by the lightning is how you progress within the game. Since gameplay-related objects inherit from the same base class, the functionality is set in the Construction Script (See Blueprint).​
Sandbox Graph
GenericActor
1.4.2 Lightning Conductor
Lightning Conductor is a base class and utilizes Unreal's interface implementation. While being an interface, it is not abstract; The lightning conductor allows it to be targeted by lightning once it's enabled through the construction script.
Lightning strikes in the scene based on the current conductivity, which is calculated based on the following formula:
When Lightning Conductors get near each other, they share a percentage of their base value; the height value is grid-based; every 100 units, it increments with a set amount.
ILightningConductor
1.4.3 Lightning Zone
The lighting within the game is heavily inspired by The Legend of Zelda: Breath of the Wild's lightning, which warns the player both with sound and visuals to give the player a chance to react. The zone tracks all the conductors in the area; this is done by adding and removing them from an array. All the conductors are then sorted by their current conductivity thanks to a simple overload of the less-than-operator. The lightning zone was built with two timelines defined in code that queue each other, one for downtime and the other for the span that warns the player when the OnFinished is called; we seek the best target and call the thunderstrike, as shown by the Lightning Link Graph.
Lightning Link Graph
The provided blueprint is a wall that breaks when hit by lightning since it subscribes to the LightningStrike event; additionally, it is an Event Intiator and messages all the listeners when it is struck.
LightningZone
1.5 Post Mortem
The project as a whole was the most successful of any game project I've been a part of due to excellent communication, a small scope, and a clear vision for both the code and the game as a whole; this led to everyone being able to work on their own and produce things that were cohesive to the vision.
Our Subclass Sandbox class had its issues; it acted as the base for the entire game, and the designers could easily "activate" functionality from the construction script, which in turn enabled all the appropriate events.
The biggest problem with this was that the generic actor class was way too big and followed the Monolithic Persistence Antipattern, which in turn breaks the open-closed principle and the single responsibility principle, making it more annoying to debug and extend.
​
Our approach for creating a blueprint-heavy framework for our designers turned out to be a great way to work; after the system was in place and a short introduction, we only had to answer some questions along the way. Resulting in almost no bottlenecks for our designers, and they implemented new features almost nonstop. As a result, the programmers could focus on fixing bugs, improving the infrastructure, and polishing features.