Light of Alariya
Role: Software Developer
Genre: Open-World Exploration
Development Cycle: 7 months
Team Size: 30 developers (5 programmers)
Engine: Unreal Engine 5.0
As a software developer, I was the primary author of code relating to vehicle movement, map, quest, collectibles, and related open world systems in Unreal Engine 5. In addition, I created our UI framework on the UE5 CommonUI plugin and was responsible for our automated build pipeline. From preproduction to launch, I supported designers and artists by developing tools, adapting to player and stakeholder feedback, and debugging code all across the game.
Gameplay Trailer
Major Takeaways
Prototyping Gameplay Through Composition
Seven months is a short time to bring original open world game concept from idea to market. This was especially true for our team, given this was our first venture into Unreal Engine 5, and we had additional overhead in Unreal Engine 5.0 from bugs and technical limitations (that would be fixed in later versions of the engine). Needless to say, we pursued a development plan that was change-tolerant and risk-adverse. During this process, I learned how to better decompose gameplay requirements into distinct problems, which made it easier to pivot when those gameplay requirements changed. One example of this was in the design of vehicle movement.
The first iteration of the protagonist’s ship had two systems that operated independently - move in the horizontal plane in response to player input, and orient the ship to acknowledge the contour of the sands. As additional requirements solidified, I often wrote new systems which could be toggled on and off or configured. Here are examples of feedback that occured -
“We want the ship to bend around curves, roll over dunes, and lean with player input.” - I wrote a system which observed the terrain incline and player input to add a configurable offset to the ship’s mesh.
“We would like to use sand dunes to create natural boundaries to the playable space.” - I added a system which observed the incline and added a corrective steering force away from steep terrain.
“We would like the ship to get airborne and do tricks.” - I added a system to blend between a grounded and an airborne state and another system to play potential trick animations.
Some of this feedback stuck. Some requests, like the ability to do tricks and fly, were later scoped back or cut entirely. At minimum, I could disable any of these systems simply without impacting the others, but more often the components were repurposed to offer slightly different experiences. If I had not implemented movement as a set of loosely coupled systems with distinct responsibilities, much of the requested extensions and revisions would have required a major rewrite we did not have time for. Many bugs that we found were simple to resolve because I could easily isolate each of the components to identify the core issue.
A representative screen capture showing quest, compass and vehicle controls from early game exploration.
Managing Different Kinds of State in an Open World Environment
In Light of Alariya, like in many open-world titles, the game state was made of information updated on different frequencies, at different levels of precision, for a variety of purposes. We often asked questions like, “What should happen if the player completes an objective which opens a gate on a section of map that is unloaded?”, or, “Under what conditions would a player not be able to save their game due to unreliable behavior when they load back in?”. In order to address these and related questions, I implemented a few strategies throughout multiple systems.
Simplified Game State - Often it wasn’t important to cache high resolution state when it was directly tied to lower resolution state. For example, when completing a puzzle, we could have saved off details of all the interactable parts of the puzzle to be loaded back later. The puzzles, however, could only exist in a finite set of configurations, and it was lower development overhead to allow a puzzle to reconfigure itself into one of a set of safe states rather than deal with the bugs that arose from allowing an amount of variation. We verified through user testing that the player didn’t notice these variations or care about preserving them, and moved on.
Created a Small Interface for Unique Cases - Puzzles and world locations sometimes had unique mechanics, or there were areas of the game that needed some hand tweaking to improve user experience, but we didn’t have the operating room to design more custom systems. For these cases, I extended the blackboard I made for the quest system to handle unique kinds of state. In limited cases, designers could add to and query values from the blackboard in their own blueprint scripts. For example, a designer could make a destructible wall in a puzzle that is tied to a bIsSpecificWallDestroyed key on the blackboard. While this tool proved flexible for designers and enabled fine tune control in different areas of the game, I also worked with team leads on process control and testing to avoid bugs from irresponsible usage.
Allow a Limited Number of “Always Alive” Actors - The actors representing metadata for world locations and a subset of quest markers were allowed to always be loaded and frequently receive updates. In order to meet our performance budgets, we leaned into Unreal Engine 5’s World Partition system to have live actors and terrain only near the player, but the design of multiple systems was simplified when we could rely on the state of a handful actors to always be available.
The world map showing many locations discovered and some completed. Open world data touches the map, quest, and navigation systems, among others.
How to Write Documentation that Actually Gets Read
On this project, with the breadth of systems I was responsible for, I had to be very conscious about how I spent my time each day. Many of these systems — quests, open world locations, collectibles, and vehicle systems — enabled the designers to generate new content. In order to manage the volume of questions relating to the use of these systems, I wrote documentation to cover the most common questions. I found the following strategies helpful during that process.
Make wikis and tutorials strategically - If I found myself answering a question repeatedly, I wrote a tutorial or wiki article to cover the topic. The development wiki was not a complete breakdown of the entire game, but a prioritized list of the most desired knowledge. The articles which received the most views received more time and attention over time. Our wiki provider showed metrics about views and usage which informed these decisions. Ultimately, I avoided writing documentation which didn’t practically add value to production.
Ask designers what kind of information is most helpful to them - No designer wanted or needed to read a technical breakdown of any systems. By working with designers and observing how they learned third-party tools, I wrote better, more brief, and more focused documentation over time. I also biased future system development towards shortening onboarding time, which made a difference of hours and days during critical sections of development.
Create an evangelist designer for major systems - I didn’t have time to train every designer deeply on each system, but I could spend time to train someone who knew enough about a system to answer questions and develop additional documentation. My responsibilities to onboard new designers or diagnose problems decreased over time, and I was free to flesh out other areas of the game that needed attention.
The Light of Alariya development team poses for a team picture after being greenlit to the Steam marketplace.