Ascension Evolved is a speedrunning roguelike game with an emphasis on replayability.
Length
7 Weeks
Genre
1st Person
Speedrunning
Roguelike
Team
8 People
Contributions
Concept
In Ascension Evolved, you play as an intergalactic hunter that evolves by consuming creatures to mutate yourself. You have landed in a desert world inhabited by a hostile alien race. Use your abilities to traverse the land, hookshotting and dashing through the air and use your kukri knife to destroy your prey.
Consume enough prey and mutate, powering up your abilities to become stronger and faster.
Every run is different, where your choice of mutation changes your playstyle. Speedrun through the level and get the best highscore!
Game Pillars
Mutations
Easy to learn
Hard to Master
Player choice of which mutations to pick makes each run unique
With each run, player's skills improve, enabling them to tackle more challenging maneuvers.
Speedrunning
Speedrun to beat your highscore!
Core Loop
Eliminate your prey
Kill your prey to absorb their essence and gain mutations
Speedrun through the level
Use your abilities to speedrun through the level
Enhance your abilities by selecting mutation and tailor to your own gameplay
Pick Mutations
Moodboard
I started off by researching similar media and concepts of desert worlds. My aim was to evoke a sense of vastness, making the world appear enormous compared to the character. I found visual inspirations showcasing characters in expansive deserts and cavernous areas.
Level Maps
I sketched out some rough drafts of the level initially. It was established early on that the level would include encounter rooms connected by various paths.
At the start, the idea was to have separate rooms with an easier path for dashing and another one that was easier for using the hookshot. This way, players could pick their path depending on the mutations they had acquired during the run.
However, I believed that balancing it would be challenging as well as it being monotonous to always be forced to follow a path if it was chosen. I then came up with the idea to allow players to be able to change their path while navigating the hallways. The hallways would be interconnected in different ways to allow this flexibility.
A boss had been planned out, but ultimately, it was cut, along with the melee path.
Level Design
To design the level, I had to grasp how the player abilities and the movement worked. Since it is a speedrunner game, I aimed for a large, open feel, letting players use their fluid movement in satisfying ways. The setting was a desert canyon on an alien world. To figure out the layout, I researched real life canyons as well as fictional desert worlds or concepts.
To nail the level design early, I had to playtest the game often in order to understand the movement of the player. Here, I'm testing the dash - how far it reaches for longer gaps and upward movement. This helped me create a level where players can freely use their abilities and enjoy the experience.
The player could grapple to hookpoints. I playtested each time the mechanic was iterated upon because the level was designed specifically to let the players hookshot and fly max range in order to overcome the more difficult obstacles.
The player could also hookshot to enemies. In this example I considered having the enemy being the initial hookshot point. However, this posed problems since it introduced both the enemy and the hookshot simultaneously to the player. The enemy's placement also caused the player to collide with the rooftop, resulting in an unsatisfying experience. A valuable lesson on enemy positioning and the optimal ceiling height.
I then quickly decided I needed a gym in order to test the mechanics so I set up a few different "obstacle courses" with different measurements. This would allow the gameplay designer and I to try out the changes of the movement.
To get a feeling of a desert canyon, as well as giving the player freedom in their movement, the whitebox had to be made spaceous. It was important to discuss with the environmental artists to understand what kind of environment the team wanted to create. I got the level to feel organic using Unreal 5's BSP’s and stretching and moving the objects in order to fit the vision. As the game was supposed to be fast paced and with the player having fluid movement, I wanted the level to allow that gameplay to shine. I tried to limit how many obstacles there would be whenever the player wasn't using their abilities and running on the ground.
Early on I decided to use the landscape tool. I had started off with whiteboxing the ground but it did not fit the organic feeling I wanted in the world. So I decided to use the tool to achieve the desert feeling.
At a later iteration, the level would open up a lot more, allowing the players to use their hookshot freely without feeling they would hit something in their path.
Some areas would also change a bit more drastically from the whitebox to ensure I got the desert canyon feeling. They would otherwise feel disconnected from the other parts of the level.
Between encounter rooms I created two different paths for the player to traverse. One would have hookpoints and one would have dash resets. The player would be able to choose which path they wanted to take - which would often depend on their choices of mutations.
Dash Reset path - The player has gotten several upgrades to their dash, notably longer range allowing them to speed through this path.
Hookpoint path - The player has gotten several upgrades to their hookshot, notably shorter cooldown which allows them to speed through this path.
Shortcuts
Our gameplay designer wanted shortcuts in the game. Exciting! I took heavy inspirations from games such as Neon White. What I realized with Neon White is that they have shortcuts in the game that are not too obvious unless you have replayed the same levels for several times. For this project I decided I wanted to let the players discover the shortcut quite easily so that they can attempt to use them even early on, making it easier for the player to use the shortcuts for their second or third run as they get more comfortable with the movement and abilities.
Which gets to the fun part, I had only created on purpose one shortcut. I spent a considerable amount of time making the shortcut be a couple of seconds faster than the normal path.
The normal path would have the player go straight forward, whilst the shortcut would have the player needing to turn left mid-air making it a more difficult maneuver to accomplish.
The Normal Path
The Shortcut
However, there are more shortcuts in the game. All discovered accidentally by playtesting either internally or externally. Early on when I had implemented the intentional shortcut, players would try to find more shortcuts and would go out of bounds or find cracks in the walls they could use. Instead of sealing them up or not allowing the players to reach those paths, I would use those discoveries and make them into actual shortcuts. Of course, I playtested them to make sure they didn’t break the game.
An internal discussion was made if we were to allow players to shortcut through encounter rooms and skip them. The encounter rooms would be where the player defeated their enemies and get a mutation that would alter their abilities. Ultimately I decided to allow the players to be able to skip them. It would let the player save time however the drawback would be that the player would not get a mutation. Meaning, it would be the player's choice if a mutation was worth it. I saw in playtesting that every player would have different strategies, they would clear the room or they would skip them depending on the run and what previous mutations they had. At the end it was still the player's skill to speedrun the game that would net them the best time.
The Normal Path that had the player defeat the enemies and gain a mutation at the end.
The Shortcut that would let the player save time by skipping the combat, but get no mutation.
Playtesting
The above brings me to the next point, playtest, playtest, playtest. To ensure that the level would fit the gameplay mechanics, I would myself put aside time in order to playtest the game either internally or externally. As it often is, it was crucial to the game. The game has an emphasis on player choice and replayability so it was important to get the player's feedback. As gameplay was tweaked based on feedback, I had to change the level too.
The game was designed to be easily understandable for all players, so I wanted players of all skill level trying the game. There were valuable lessons to be learned from players that weren't comfortable with fast paced games with a First Person Camera. It helped me understand how to frame the path and the level so it would be easier for player to localize where they were.
Issues and Solutions
Playtesters would sometimes get lost or disoriented as they traversed the world. The colours would blend together and there were no distinct pathway that would show the way.
Solution was to create each room to be distinct from each other in their form. Encounters would take place in large rooms whilst the running paths would take place in hallways. I also discussed with the environment artist to create foliage that could be of different colours. I would then use these foliage to keep each room distinct from each other.
I would also use the meshes to create landmarks where I placed them in a way that players could easily identify.
What I found was that the playtesters would more easily navigate through the level with the use of the foliage and landmarks.
Another issue with the whiteboxing was that I intended to make the players have to use their abilities in order to progress. This meant blocking paths so the players had to hookshot or dash over obstacles. It was supposed to be a tutorial for the players to learn their abilities and thus had these obstacles quite early in the level. However, what ended up happening was players getting frustrated if they failed the dash as they wouldn’t be familiar with the player movement.
It would be easier for them the second try and then afterwards but I wanted to remove that initial frustration.
What I did was make a path that would go around the obstacles which allowed players to try and dash over it, but if they failed they could still progress without having to wait for their cooldowns.
Encounter Design
A system was created for the encounter rooms in the game. When players triggered an encounter, the system would randomly spawn elements from a preset list, including enemies, hookshot points, and dash resets. I had control over the placement and quantity of these elements, resulting in dynamic gameplay in these encounter rooms each run.
However, there was a bit of a conundrum as it was another RNG element to a speedrunning game that already had RNG in the form of mutations. Therefore, I had to playtest these encounters a lot both internally and externally to understand what would work or wouldn’t work.
What I noticed was that players would get frustrated if the enemies would randomly be in a different position each run they played. People had “muscle memory" of where the enemy would be in one run and would try to quickly get to them in the second run, but wouldn’t find them in the same place. I therefore had the same spawn points for the enemies in each encounter.
However, what I did realize and something I would often ask is, - did players understand that I had different placements on the hookpoints or dash resets? And the answer would mostly be no, they still identified where these elements where and could use them to their advantage.
That meant I had more freedom on where I positioned the dash resets or hookshot points. Some points that I considered pivotal were placed in the same location for every encounter. However, I could randomize the spawn points in different places for the less pivotal but still useful movement elements.
In this example, the encounter has two dash reset points near a hookshot point.
In this example, the dash resets are missing, however there are other elements in the encounter that the player can use.
Scrum Master
As scrum master I would plan the daily stand ups and hold the team meetings. We used Jira to organize the teams work. I set up the Jira with our epics and sprints. As I've done in my previous projects, I would regurlarly check the Jira to deem what tasks were being worked on and what tasks we could remove due to being too difficult or time consuming. To prepare for the longer project, I took the time early to figure out what people wanted to work on and appropriately accommodate those wishes.
For the team culture, I also held a meeting each Thursday to ensure that every individual was happy with where the project was heading towards. We could collectively understand what problems and issues we needed to solve.
What I Learned
I learned that players get frustrated when they are stopped from literally moving forward in a speedrunner game. Instead of stopping the player to teach them an ability, allow them to fail and still move forward, albeit a bit slower. When the player get familiar with the movement and their abilities, it will feel more satisfying to overcome obstacles that they previously had failed on in their runs.
Another takeaway was to not hide enemies or change enemy positions in a speedrunner game. The enemies are to be obstacles that are easily overcome rather than objectives that hinder the players. Keep them around the same location each run so players can use their previous knowledge to be able to beat their highscore.