PLANESWALKER
Take on the role of an astronaut of the multiverse, explore exotic worlds, delay your return to their universe one crystal at a time.
Concept
With little time to create this project, I aimed to minimize the assets needed and maximize the replayability.
​
I had an interest in exploring procedural generation and decided this was a good project to learn how it worked. I decided terrain generation would be a good place to start, so I found this tutorial on how to create meshes at runtime and pursued the idea.
​
As my terrain system developed, I explored numerous ideas to make each terrain more unique and a mechanic that would require the player to see many different terrains and have the chance to explore them.
Terrain Generation
I began by implementing multiple octaves of noise and tuning them to be navigable with the 3D platformer character controller. Then I added a gradient that would color each face of the mesh, depending on the height of the vertex. Every world has a unique color palette. Next, I added a skybox randomizer that would select a skybox from a list of eight different images. This choice brought different lighting and sky to each world.
While tinkering with the mesh generator, I experimented with modifying the coordinates of vertices based on their base position. I programmed terrain features, like plateaus, creators, and mountains, by modifying the base vertex coordinate by a constant or function. However, combining all of these features in one terrain would look messy, so I separated these into biomes.
​
All of the variables that I created were carefully tuned for each biome to make them as navigable as possible and yet still different enough to easily tell different worlds apart.
​
Finally, I learned how to use raycasting. Ray origins are randomly determined above the terrain. When it intersects with the generated mesh, objects are placed randomly throughout the world, including the crystals that players collect, the portal, and then a random assortment of objects.
Game Loop Design
A time-sensitive, arcade-style game loop where players must search the worlds for objects to get to the next world made sense for showing all the features of the terrain generation system.
​
To see how much time the player should have, I ran from one corner of the square of terrain to the other. It took around a minute for every terrain I tried, so I decided a minute is a good amount of time, a choice confirmed later with playtesting.
I initially wanted the player to find and collect all of the time crystals before entering the portal, but I found it was more interesting for the player to decide whether or not they wanted to collect more time crystals.
​
The next thing to balance was how much bonus time each crystal gives. Too much time would allow the game to go on forever and become boring. Too little time would be too stressful and likely end the game soon after a run started. Ten seconds was a good compromise that allowed players to get into a flow of collecting crystals and making it back to the portal.
​
Because there were only five crystals per level and levels could be completed in about a minute, players would recoup at most 50 seconds, not the full minute.
User Interface Design
I found UI was important for a fast-paced game where players need to be focused. Even a brief moment of confusion could cause a player a frustrating second or two that could be the difference between their new high score and a loss.
I went through a few iterations of the UI and assumed that players would want to see the amount of crystals they collected, but the far more important number was the time they had left. For this reason, I decided to remove the crystal count and scale the timer text to cover the whole screen.
In retrospect, the number of crystals didn’t matter as much because the player isn’t making a choice about the number of crystals, if they can get another crystal in the time left.
This sleek, screen-spanning text became a recurring motif in the design of the rest of the in-game UI.