Genre: Adventure, Strategy
Engine: UE4
Role: Technical and System Designer
Project Duration: 32 weeks (September 2021 -June 2022)
Release: 21 june 2022​
​
Dune Strider is an adventure strategy game where the player takes control of a trader traveling on a sand barge through the desert. The player will need to survive deadly fights against groups of bandits, gather and sell resources, and upgrade their ship until their are strong enough to face the final boss.
I worked as a system and technical designer on:
-
the upgrade system;
-
the trading system;
-
the level obstacles;
-
the traveling merchant.
Upgrade System
As we were approaching the last two months of development, the team had a problem: Defeating enemies and engaging with the trading system gave the player several resources, but there was almost nothing to spend them on.. To compound the issue, our project brief required the player to be able to upgrade the ship, and no such system had been implemented yet. To solve both of those issues, and with the approval of the leads, I set out to build the upgrade system.
​
Concept
I needed the upgrade system system to:
-
be simple to implement;
-
reward the player for exploring and trading;
-
offer some amount of tactical choice;
I created two types of upgrades:
-
ship upgrades, which improve basic stats of the ship like the speed or the health.
-
ability upgrades, which improve the stats of the combat abilities, like cooldown or damage.
Different settlements offer different upgrades, and the player needs to pay with both money and resources to obtain them.
To take effect, each upgrade has to be equipped, with only 2-3 slots for each upgrade type. Getting new upgrades increases the range of tools the player has at their disposal, and before entering a battle the player needs to choose which upgrades to actively use.
​
I made several simple mock-ups for how the UI could look like
Gameplay Ability System
Upgrades were implemented using the GAS (Gameplay ability System) plug-in. I did it because the player's abilities had already been implemented using the plugin. I had to use the same tool to make the upgrades compatible.
​
The GAS already had an upgrade mechanic, but I decided not to use it. It only allowed for linear, progressive, upgrades, which wouldn't work with the necessity of equipping and unequipping them. Instead, I made each upgrade its own ability. Under the hood, it would be turned on and off by the player when equipping/unequipping.
The implementation allowed us to create many upgrades quickly
Menus
The feature required two menus: the blacksmith menu (from which players could buy upgrades) and the upgrade menu (from which they could equip them). They were, for different reasons, the hardest part to implement.
We did not have a UI designer nor a UI Artist, and all previous menus had been implemented by different designers using different methods. This meant I had to implement them almost from the ground up.
Making them gamepad compatible was another headache. The team had decided to use the UI nav plugin to get the menus to work with a gamepad, which took quite a bit to learn how to use.
The final look for the upgrade system
Wandering Trader
One of the challenges when developing the concept for dune strider was coalescing the trading aspect of the game with the traveling/exploring/combat.
The wandering trader was one of the solution we employed. It travels through the map towards different settlements, carrying resources, which are displayed above its head.
The player can choose to let the trader go on their way, or risk fighting them to get their loot.
​
Except for the combat ai, which was inherited from the bandit enemies, I implemented it by myself.
The most challenging part was getting the trader to navigate the large open level towards one of the settlement, regardless of their initial position. The default "MoveTo" function Unreal provides doesn't work unless you are using the character, and the nav mesh starts to "malfunction" when you are trying to go too far away.
​
To make this work I had to implement several different solutions. The two main ones where:
-
Getting the path points directly from a separate function and then feeding them to the nodes the programmers were using to move the ships around.
-
Checking, after reaching the end of the path, the actual distance from the settlement. If the distance is still too long a new path is calculated.
A lot of other small edge cases had to be considered as well. What if, for example, the ship overshoot and went beyond one of the path points without clearing it? How could I make sure it didn't travel too close to the walls? How could I reduce the impact of the nav mesh on performances? I had to resolve this smaller issues to make the wandering trader work.
​
​
The wandering trader traveling from one side of the map to a settlement on the other.
the behaviour tree used to guide the wandering trader around
Feature Post-Mortem
​
While I worked hard on it for 6 weeks, the feature eventually had to be cut. The 2 reasons for it were:​
-
It still wasn't up to the technical standard programmers wanted. They were afraid that my solutions would require too much upkeep.
-
Other features, like the upgrades system, had a higher priority and had nobody working on them.
Looking forward to my next projects, what I learned from this was:
-
I need to understand what features everyone else is working on, and what the priority of the to-do tasks is. With a clearer picture of the project's momentum, I would have chosen to work on upgrades sooner.
-
Open worlds games can stretch almost any system to their breaking point. In this case, I had not considered that the nav mesh wouldn't work on long enough distances. When developing open worlds, I need to be more considerate of their specific technical requirements before jumping into a new feature.
The exploding crystals
During pre-production, as the game solidified as a small open world, I realized that we would have issues filling it with content and, more specifically, with challenges. Creating a large variety of enemy types is resource and time intensive, so it wasn't going to be an option. That is why I decided to focus my research on level mechanics: simple, interactive objects that could be re-used in different configurations to create a large variety of encounters.
​
Research
I had two questions leading the research:​
-
How do different games creates entertaining level mechanics?
-
How can level mechanics be built to be as reusable as possible?
With these leading questions, I looked into as wide a variety of games as I could within my time limits. Because I was searching for general heuristics, I didn't limit myself to the game's main genre, instead casting the net as wide as possible: from Sunless Sea, one of our inspirations, to Celeste or even Binding of Isaac.
The takeaways from the research
The Concept
I settled on the concept of the exploding crystals. Scattered throughout the level, the player and the enemies can shoot them to cause an explosion. After exploding, the crystals become sources of of either heat or cold. if two opposing sources are close enough, they generate an air current, which can push players and enemies alike.
If two currents cross, they create a Tornado, which will roam through the map destroying everything in its path.
There were several motivations for the mechanic to work this way:
-
The crystals could be placed in different configurations and could be both a boon and an obstacle to the player, like my research suggested to do.
-
Wind currents could be used outside of combat as well.
-
I was hoping to re-use the concept of "hot and cold = wind" for other mechanics as well, like player abilities.
-
I wanted the mechanics to create a form of escalation during the fight: from explosive barrels, to wind currents to Tornadoes going around.
Explanations and sketches to get feedback from other designers.
Implementation
Basic Structure
I implemented all three mechanics in blueprint. Most of the functionality, for example how to determine the temperature of an object or how to create a wind current, was put in a component. This would allow me to reuse it for other mechanics.
​
Visual Effects
The visual effects, meant to be temporary, were a mix of external assets and things I made myself. I worked on the materials for the hot and cold crystals, on the particles for the hot and cold air rising up, and on the particles for the wind currents.
The exploding crystals can make the level a lot more dynamic even without enemies
Feature Post Mortem
Looking back on this feature, I think there were several things I could have done to both make my life easier and improve my success chances:
-
Starting Smaller: The idea of wind currents and tornadoes was really interesting, but it took time to implement it. I should have, as my research suggested, started smaller - get simpler mechanics in the engine, test the fun and let the level designer play with it.
-
Asking for help on the visuals: this project was the first time I really dug into the material system in unreal, and I was eager to learn and prove myself. Because of this, I didn't think of asking for more help when getting stuck, leading to a lot of delays. Even though it was a student project, asking for help should have been a given.