Guildhall's most downloaded game on Steam!
A game by Think Arcade Studio
Lead Level Designer
Alexander Cocoles, Zhi Yang, Xiao Wei, Quest Washington
Rui (Siri) Xie, John Peng
Unna Pussayapaiboon, David Rosario III
FrostRunner is a first-person platformer “speedrunning” game, where the player is tasked with rapidly completing platforming challenges before the timer runs out. The game is set in a desolate, frozen environment seemingly abandoned by all life. Scattered throughout the icy landscape are mysterious energy crystals emanating a strange power. The player navigates 36 levels of arctic terrain using their platforming skills and a tool that allows them to tether between crystals. The constantly ticking timer encourages players to complete levels as quickly as possible and compete with others to earn their place at the top of the leaderboards.
The game originated as a first-person platforming game called Warp, in which the player moved around via teleportation. It was a puzzle game that challenged the player to use their warping abilities to complete obstacle filled levels. Over time, we found that the most engaging moments of our game were high speed moments where the player was moving. The team agreed that we wanted to focus more on the fast-paced aspects of the game and we slowly removed all elements of the original puzzle focus. As we continued to develop, we embraced the speed of the game and put in leaderboards and achievements to encourage players to go as fast as possible.
In Game Screen Shots
Roles And Responsibilities
Lead artist/art director
As the lead artist of FrostRunner, the very first challenge I ran into was to define an art style and theme for our team. I, along with most of the team members, was onboarded to this project when it had relatively solid core mechanics but very a vague theme/world setting. I managed to push the artists to find the style we wanted by concepting bigger pictures (what would be an environment they would be interested in building) and storyboarding with the LDs in the team on core game mechanics. I made sure to set limitations on their concepting and brainstorming. For example, as artists in the team, we always considered what are our strengths were, what we are not the best at, kept in mind how much time we had (5 months), and how many artists we had (three including me).
By exploring and analyzing the team, we settled on Brutalism, which allowed our artists to play to each other's strength. We avoided stylized/painterly style, as none of us were best at hand-painted texturing, whereas we are all better at modeling and PBR texturing. We also decided not to set our world in an organic environment that could demand much optimization for foliage and other sculpting intensive assets.
I tried to manage my artist team in a more agile way at the beginning by letting them take whatever task that's available. I found out that since there were only three of us, instead of letting them do work that they're not so comfortable with, it is more efficient for them just to take more ownership over tasks that they are better with to play to each other's strength. For example, we had one artist that had more experience in animation but not so much in texturing. I decided to let him be fully in charge of animations than having him help the other artist with texturing. This actually resulted in better animation quality as well as a more consistent texture style. This is a big lesson I learned - even though agile development is a commonly agreed upon system, leads still need to adjust the method to better serve the team. As for us, we ended up having one artist on animation and UI, one on texturing and materials, and me on modeling :).
Below are some of the assets I created for the game (modeling to unwrapping, textures, and materials are created by another artist)
This modular kit was originally made for the main game play space/path. It is built in power of 5 dimensions as a result of an agreement with the LDs on the team because they were more comfortable with working with this unit system than power of 2. However, after playtesting it, we found out the uneven surface of this modkit would slow the players down by making them think they would trip over it even if we made the collison box flat. We repurposed this modkit as decorative kit that fill along side the main path.
Decorative fragments, walls
To follow the art style we established, I created smaller planes and corner pieces to make the environment a little bit more interesting. They are also built under power of 5 for compatibility with the main modkit we have. The corner pieces are also used for softening the hard edges on our main game path modkit. Considering the short development cycle we had, and the amount of levels we planned to create, we chose to use some of these assets to cover seams between modkit, rather than demodulate our levels.
Exit Gate, light assets, under structure
One of the goals for conveyance in our game was to highlight the main path for the players. We decided to have unique meshes for starting gate, exit gate, and light assets that lit up the path. The box shape light was what I first made, but by playtesting, it seems that players were regarding it as a platform to stand on. I made the top right asset in the image which is closer to a plane that's more subtle but still serves the intended purpose.
decorative crystals, ice spikes
Decorative crystals were made with the shape that were very different from the tether crystal.
ice level path assets
For ice levels in the game, I decided to make custom meshes for the main path to make it look smoother and curvier than the regular levels. The pipeline for making these meshes is as follow:
LD map out the path with regular modkit
I export the path from the engine to 3ds Max
I export the parts that needs to become ice into Zbrush for sculpting and unwrap
back to 3ds Max for pivot/position check to make sure the new mesh overlaps the old one
back in engine to replace the old meshes. Collision box unchanged.
Retro: It seems to be a more efficient way to do this with the landscape tool within the engine. Optimization for that method still needs to be tested.
Early Concepts/Mood Board
One of the important processes in our development cycle was the level beautification. This process was to add in all the decorative assets. I was able to borrow some of the LDs in our team to help us with the process. We formed a strike team dedicated to level beautification. I made and prioritized a checklist of all the assets they would need, and I created the pipeline chart on our whiteboard (see image below). This pipeline helped us make sure everything looked good before we moved on to the next step. The chart shows clearly who's working on which level to avoid overlapping or lost work on the source file manage software (p4v) we used. I decided to use the whiteboard as the team preferred physical information over software like Hansoft. This chart was later used for QA too.