Star Dropper is a prototype project I worked on to showcase my level design and system design capabilities. The player, armed with a grapple hook, flies through three levels at soaring speeds, and can keep track of their times with a functional leaderboard system.
Whilst working on this project, the original intention as laid out in my statement of intent, and the final project that I am submitting, could be considered to be distant from one another in several ways.
Despite this, I achieved what I overall intended to do: create a game that above everything else was fun. The feedback I received on this solo project was complimentary towards the movement system and level design, and how the level design allowed for the movement variety created. I used (credited) pre existing free to use code, and took this code to create my own system.
The ability to "get stuck into" an engine and code to create a functional and fun experience was what I was focusing on accomplishing with this project, and from feedback I received I feel that this was a success.
As part of this project, I created a blog to detail my development of the game. This is an excerpt from said blog detailing the fundamental process that I undertook designing a level.
When designing a level for a game such as this, there are many traditional conventions regarding level design that are broken due to the mechanics featured within the game. The game features, by design, very little solid ground, as momentum is gathered via falling and transitioning this into forwards momentum, any ground would break this fall and halt any momentum; harshly going against the design principles of speed and momentum this game has. As such, the challenge is to create unique environmental set pieces that allow both a wide-open space and the ability for player skill expression. Considering the “narrative” of the game, the player using this tether to fly through a futuristic sci-fi space setting, there are numerous types of objects that can be featured within a level, such as pipes and debris, that create the bulk of the portions of the level.
There is also the mindset of designing a level that tests the player. Skillgating is a key feature of the first level, the player opens to falling through the level, and has to react and time their tether accordingly to pass through the first ring. A skill gate for this game could test skills of the player such as timing a swing, directional WASD movement, sliding past obstacles and reflex-based gaming. I aim to include as much of these as possible, as I feel that it would be healthy for the players’ enjoyment of the game, as they get better and complete these skill gate-based sections faster, their times will improve.
This level begins with a huge asteroid field, requiring the player to navigate through the obstacles while maintaining verticality. Whilst not a skill gate per se, this area requires the player to both maintain momentum without crashing into an obstacle, as do the previous levels, but now requires them to navigate through a somewhat open-ended environment using the quickest possible physical route. Despite appearances, this portion is quite open; the obstacles in question are positioned quite far away from each other. The player is required to use both rapid, short tethers as well as their directional aerial WASD movement in order to pass through the obstacle field. The player is directly punished for failing this; crashing into an obstacle loses all momentum the player has, resulting in the player either having to try to pick their momentum back up, or restart the level entirely. This portion of the level is very horizontal, meaning that falling at a higher speed is less likely here. The more horizontal a portion of a level, the slower the player moves.
This ending bar to the asteroid belt section means that, given enough speed, from any position from the asteroid belt, the player can easily make it into the ring.
The purpose of rings are to act as checks that the player has to pass through in order to finish the level; they ensure that they can’t just fly towards the end whilst disregarding the level. As such, they are essential for the player to pass through, and can be used within the level design to ensure that the player has a route to follow.
For the second section of the level, I am planning to change the players’ focus once more. Whereas in the first section, the player had to navigate from an open-ended space as fast as possible, the second section will be far more linear, bringing the players’ focus back in, and testing their skills with sole use of the tether, rather than navigation. For the environment, the player will be passing through a series of pillars, tightly bound corners focusing their movement on pinpoint precision. With this section, I will be designing it iteratively: I will create a mass of floating pillars, all with random positions and orientations. I will then move these pillars and relocate them to create a “path” through them, test the level to see how well the path is marked out, and iterate the level design accordingly. In essence, I will create a random mass of obstacles, and use iterative design and testing to adjust the positions of these obstacles to create a level that while “feels” random, is in fact fully designed and planned out. This is a form of level design that I believe could work well in certain situations such as this one; with unconventional movement it could create a sense that the player is truly moving through a randomly generated space, and plays further into the thematics of them passing through futuristic ruins; objects are strewn across and floating in space randomly.
To explain what I mean further, note the difference between the orientation of the pillars in figures 6 and 7. The pillars in figure 6 are randomised, simply given a random rotation and position and thrown in the scene. After playing through the first section of the level and entering this section, I noticed that the path that I always wanted to take passed me under the first top pillar and through an open space. As such, I placed a ring within this hole and proceeded to play the level out. After iterating on this design, I noticed issues with swinging from the last ring into this one, such as pillars being hard to avoid, which I moved further away from this “route”.
I also noticed that there was no “incentive” for the player to pass through this way; granted there was a ring that the player has to pass through to complete the level, but the rest of the environment looks just as manageable. As such, I relocated and rotated pre-existing pillars to act as environmental signposters: they partially block space the player is not meant to pass through, and they are oriented to point directly towards the first ring in this section, drawing the players attention towards it. After further testing, I also repositioned and resized the ring, as I felt that, even for the level designed to be the most challenging out of all of them, it was far too hard to reliably pass through this ring. I also added a secondary pillar behind the first, that the player can use as a substitute to the first pillar if they are in a dissatisfactory position to use the first whilst swinging towards the ring.
This is the second portion of the second section of the level. These screenshots are taken from the same location (directly in front of the second ring in the level), and showcase the changes I have made to this portion of the level via iterative design. The most obvious, and first change that I made was moving the central pillar in figure 8 out of the way. After this, I found that swinging from the last ring to the ring seen in figure 9 felt very smooth, the curvature of the swing felt satisfying coming off of the last swing in the level. I then moved the two horizontal pillars directly above the ring upwards by a noticeable amount, meaning that the player is less likely to collide with them whilst moving vertically as part of their swing. From this, they pass out of the group of pillars, swing around one final pillar, and pass through a final ring, ending this section.
Creating a level with this method is something that personally, I doubt would work in the vast majority of games. However, given this games nature of movement, it is a system that could work to various lengths. At the very least, I wanted to experiment with the methodology I use when designing levels, and I feel that, whilst it may not be the best portion of the level, it allowed me to create a level that could be designed quickly. There are advantages of using this methodology when creating a level, however. It is fast to do, as previously mentioned, but the constant and repetitive iterative construction of the environment could result in a section of the level that feels incredibly natural to pass through, as it was designed specifically to feel the best to swing through, each object that could pose an issue has been relocated, and if I deemed that a new object could allow for a better experience for the player, it was easy to iterate and move it into the best place.