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.

1. 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.

2. 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.

3. 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.

1. 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.

2. 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.

3. 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.

Hex Rally Racers

Role: Lead Software Developer

Genre: Couch Multiplayer Arcade Racer

Development Cycle: 3 months

Team Size: 52 developers (12 programmers)

As Lead Software Developer, I planned sprints and coordinated 12 other programmers on an interdisciplinary team of 60 developers over 3 months - from idea generation to launch.

Gameplay Trailer

Major Takeaways

Communication on a Large Team

For many on our team, Hex Rally Racers would be their first published game. It would also be the first time they worked on a 60 person team. Keeping the studio aligned with a unified vision was challenging, but we took several steps to address this:

• Giving regular informal briefs - prior to scrum each day, I would create a brief of the major decisions and changes to game features or sprint priorities. I received feedback from the team these were useful for them to reference and stay on topic.

• Building a strong pipeline - our team’s daily tasks were backed up with redundancy checks and supporting documentation. This prevented information getting lost or out of date because each peace of information lived in a place where it was consulted regularly.

• Playing the game publicly and regularly - As soon as we were able to show the game on screen, we played the most current build on a projector in the background where the whole team could see. Issues were often fixed faster than a bug report could be made for them, and the time from implementation to player feedback was reduced nearly to zero.

Risk Mitigation and Contingency Planning

Three months prior to the Steam launch, the only tangible piece of the game’s design was its genre - a couch multiplayer arcade racer. In order to maintain the necessary sprint velocity to hit our launch window, we lacked distinct pre-production and production phases, and took measured risks to stay on target.

• Cross-discipline strike teams - we regularly used small mixed teams of designers, programmers, and artists to answer very focused questions. By eliminating production unknowns with this strategy, we could keep the larger team agile.

• Plans that could be scaled down or up - sometimes, there were great ideas for the game’s design that we rejected because the minimum viable version of the idea required too much overhead, or once complete would be too expensive to scale up.

• Quick Iteration Times - our modified sprints could often be shorter than a week and have very tightly scoped goals. More chances to iterate and do product reviews proved crucial for staying on target.

Channeling Team Creativity

One of the most valuable responsibilities I fulfilled as Software Development Lead was gatekeeping new features and changes. If the sprint plan deviated too much, we would not be able to deliver the existing features we had already promised. At the same time, many of Hex Rally Racer’s best ideas came from our developers having the room to experiment with features. When something of significant value showed up, the biggest challenge of the job was working with other leads to revise the project plan to make a slightly better game than the one we were previously making, within our constraints.

The Hex Rally Racers Development team poses for a picture in the SMU Guildhall atrium