Teriun Games
I worked as a Game and Level Designer and Developer in Teriun Games, working on the games Dashmellow3D and Extinction. Here are some of the features I'm most proud of, and a deep-dive into my creative process.
Multiplayer Endless Racing Level Design
I was responsible for designing an infinite runner-like level system for our online multiplayer game Dashmellow3D with specially tuned difficulty for multiplayer and in-game progression.
Free-To-Play Economy System
I designed and implemented the game's economy system - from currencies, LiveOps planning, and cosmetic items, to back-end IAP hookups with in-game storefront.
Extinction and Ad Network Solutions
Extinction was a smaller project created to test tools and usability in an in-house gamejam that lasted a week.
Multiplayer Endless Racing Level Design
The Challenge
Dashmellow3D is a point-to-point on-rail runner multiplayer racing game, and I was tasked with designing the levels for it. Because of the nature of the game, there were a slew of considerations that I had to keep in mind when designing them.
First was the difficulty of each level, which is affected by level geometry and obstacles, as well as other players and their power-ups.
Second was the design of the game itself, as it was based on the idea of making a multiplayer racing game based off of the on-rails controls and mechanics of Subway Surfer and similar infinite runners, except, it is a finite race.
Third, the levels needed to be random, but also, have a way for players to learn them and improve at the game.
Here you can see one of the Beginner segments in it's first iteration compared to it's final iteration. Beginner levels are short, have very few obstacles, and are the segments that are designed to give the players some breathing room after more intense segments, or to get them situated for the rest of the race.
Difficulty
When thinking about difficulty in multiplayer racing games, two factors often come to mind: the levels and obstacles within, and the other players.
Dashmellow's design doesn't mesh well with traditional track design and interaction, so to tackle this, I created a level creation system which accounts for level difficulty and player interaction difficulty.
This system utilizes a classic difficulty curve by implementing 4 different tiers of modular track segments that vary on obstacle placement and density and have specific spawning to achieve the desired curve: Beginner(B), Intermediate(I), Advanced(A), and Special(S). With this baseline design, as we playtested and got further into development, iteration and improvement was fast and easily achievable.
The pictures above show the first iteration and final implementation for one of our Advanced modular track segments, which were some of the hardest segments in terms of difficulty. Feedback reported that the turns were too short and too sharp, making it too difficult to avoid the obstacles, leading to the final version of the segment, keeping the difficulty without the frustration by making the segment longer and the turns softer.
Learning and Improvement
The level system had more design decisions behind it past just difficulty.
We wanted to include a ranked mode in our game and for players to be able to learn the game as they would any other racing game with closed circuit maps, but with a degree of randomness.
Since each segment had self-containted difficulty, I was able to take each segment and create the whole track on which each game would be played on.
By lining up the segments by difficulty category and spawning them in the default order, I was able to create a level that changes between sessions, but allows players to learn each segment and start to recognize it. After continuous testing and the creation of more segments per category, we found that the order of B - I - A - I - A -S repeated twice led to a satisfying race length with opportunity for players to catch up, that players didn't feel was frustrating or too boring and just varied enough to feel like it is random, but also constant enough to allow them to learn each segment.
In this gallery, you are able to see the process from initial track sequencing, beginning with the first segment of each category, to what different games could look like with a wider variety of segments for each category with the target length for regular gameplay.
Art Standardization
Another consideration that I kept in mind while designing this system was art implementation.
As with any other Level Design process, for the creation of each level I created a reference document which kept information regarding any metric available in the game, including player scale, movement speed, jump speed, jump duration, horizontal jump distance, jump apex, and many more, to avoid many such delays.
With this, I created documentation which standardized the most valuable segment information needed for asset creation, ready for when art department would start working on any assets required for each track segment, allowing art team to keep creating art assets for current levels and for those planned in the future.
The first images show the end segment for two different game worlds: the forest, and the city, the latter of which was planned for future content. The last 2 images show some of the level segments created, which took into account all of the level metrics.
More Variety and Race Length Adjustments
As the game kept progressing in development, we found that the time to complete the race was not quite what we were hoping, and tuning speed and other factors would imply a lot of additional changes and adjustments to the levels themselves.
Besides this, testing showed players desired more variety across games, adding another layer to the requirements.
To solve this, I came up with something called long levels, which were a mix of regular track segments which got brand new art assets.
Each long track was composed of segments following the rules of the system to keep difficulty at it's intended amount even with these variations in segments.
Pictured are some of the long levels created for the game, with art assets and polish passes done on them.
Issues, Bugs, and Countermeasures
There was one issue in particular that to this day still sticks to me.
We were creating the track by spawning each segment in the specified order of difficulty, each segment had a start and end point, connecting to the end of the previous segment and to the start of the next segment respectively.
If the player input to change lanes in those specific locations where each segment meets, they were able to skip the entire segment and teleport to the next one. There was no fixing the issue in code, and after weeks of trying to fix it we had to look for a new approach.
To solve this, I went against all of my design philosphy, and created the Input Restriction zones.
Each zone acted as an obstacle that players had to take into account when entering a new segment. Entering these zones disabled input for the players, meaning they had to plan ahead to get across without stumbling against an obstacle. It wasn't the cleanest solution, but player feedback came back rather positive, so in the end mission accomplished.
These were the input restriction zones. Each one worked in a combination of the rails and speedboosts (second image), and a randomized choice of rising, rotating, or activation doors.
The railing was a visual indicator for players to know that they cannot change lanes in this zone, the doors each presenting a challenge that they needed to plan ahead, and the speedboosts turning each of these interactions into a timing challenge, rather than an area that just disables input.
Succesfully clearing this zone meant that players were rewarded by getting a speedboost, while failing simply meant a rather inconvenient delay.
Free-To-Play Game Economy System
Designing the Economy system
The economy system started with the main objective of an average of achieving $3 average ltv per user. While we were planning to have cosmetics, the main source of revenue would be seasonal battle passes with constant LiveOps updates.
While cosmetics were a big part of what would be our revenue stream, we considered that a battle pass with a player-friendly approach would yield better results, with mechanics such as granting a small amount of premium currency that players can use to either purchase cosmetics or additional battle passes in later seasons.
With this planned, we had more room to make cosmetics and different purchasable items that were offered in both in-game currency and premium currency, the cosmetic item's quality and rarity being the main factor as to which would be used.
Finally, to add another source of revenue to achieve $3 ltv / user, we created event tickets, a type of premium currency that allows players to join exclusive in-game events.
Implementing the Economy system
Implementing the store itself was a completely different challenge on its own - since we are dealing with creating an in-game storefront, I decided that an MVC model would fit our project.
We needed a database that would allow us to scale upward, with enough flexibility that would allow us to rapidly create and iterate on data, and we decided on Firebase Firestore as it provided a service that met our needs and also had easy unity implementation.
Now that we had our database covered, it was time to create the code to process all of this data, that would allow us to dynamically adjust which store items are available, add more without having to create new builds of the game, and provide all of this data to our front-end of the store.
To tie everything together, I created a UI system that populates the store with eligible database items, current prices, discounts, and bundles, without needing to update the game, which then was the basis of the In-game Store.
Extinction and Ad Network Solutions
Extinction: The Game
Extinction came from an in-house gamejam we held before starting work on Dashmellow3D.
The theme for this jam was "endless", with an additional requirement of implementing different ad networks into the game for different rewards.
Since we were aware that we would be working on Dashmellow right afterwards, I decided to create one of those viral fake-ad games that show up everywhere, with some more polish and care.
My game was an infinte-runner game in which the player controls a group of aliens, and the way to survive is to keep at least one of them alive at all times.
I implemented several types of obstacles, created the cinematics, and implemented the AppLovin API into the project.
More importantly, in this game is where I tested the level randomization tool that would later on be used within Dashmellow.
Ad Network Solutions
Dashmellow was going to be a free-to-play game from the beginning, so we were aiming to implement an in-game ad solution for ad revenue.
I tested AppLovin as one of the options for ad-networks.
To integrate ads into this gameplay, I designed a quick ad-reward loop that allows players to watch an ad to revive once per run, mainly to keep the casual nature of the game as well to get player feedback about ad intensity, interruptiveness, and overall enjoyment or detriment to the game.
