What were my contributions
- To help document our ideas and decisions through the GDD, dashboards and slides
- To design the game's core mechanics, focused on player movement
- To design the game's obstacle types, positioning and combination
- To design the gameplay loop
- To develop level design and implement it in the engine minding the differences between 3D x 2D maps in game and in the editor
Polishing phase:
- To program and implement visual UI, menu and level transitions
- To program and implement sound effects and soundtrack
- To review and correct level coloring and 2D+3D asset placement
- To implement basic distance culling
Game Design
Initial concept
My first proposition regarding this project was to come up with a core mechanic that could exploit having 2D and 3D artists in the team. So our first talks floated around a game loop that could become a dynamic use of this mechanic, initially in the control of the player. One of our main reference on player perspective mechanic was FEZ (2013), by Polytron Corporation.
We ended up choosing a runner game, for the dynamic appeal and to use a very known simple base to try to make our unique points easily noticed.
Early game core mechanic schemes
Obstacles/Difficulty
After struggling a bit with how to plan the gameplay experience before we had any kind of prototype or MVP available, the Game Design team started off with a difficulty scale chart. With that, we could measure the player learning curve, viewing when each level would have new obstacles and mechanics.
We did this with all of our level intentions as a concept for the prototyping phase. These charts were originally all made in collaboration through figma.
First level difficulty/tension chart
2D x 3D workflow decision defined the obstacles
While those charts were made, talks with the rest of the team happened, defining how we would use 2D x 3D in the game and, after careful discussions and considerations, we agreed to follow a mix up with the assets but have a clear division between 2D and 3D levels, making them completely separate instances so it would make things simpler for both the artists and programmers to work with our tight schedule in an independent way, at their preferred individual time and work frames.
Now that how the game was going to be built was defined, the game design crew started developing the actual obstacles. The first concerns were about having obstacles that could translate through levels, as they now had different dimensions and view angles. As this would limit our output, we recognized that as long as the player main movements and mechanics could be maintained, we could teach how to use them to overcome any obstacle, 2D or 3D, as long as they are all avoidable with the basics.
Early game core mechanic schemes
.png)
Early level sketch, with obstacle types based on player actions
Types of obstacle
Following our previous conclusions, we kept it simple. Using familiar obstacles so that no matter how weird they look the player could learn how to overcome them instinctively. So we basically had obstacles based on the player's actions:
1.Jumping; 2.Sliding/crouching; 3.Jumping+Sliding; 4.Avoid/change lane.
The next steps were inserting combinations of those obstacles in the already finished difficulty charts, then having clear instructions for a block-out inside the engine. But, as we did that, we had many ideas on how the game feel could be improved but most of them were clear stretches from our original schedule and scope, changing a lot of the gameplay so we chose 1. The hover.
Early level sketch
The hover is simply an extension of the jump. It doesn't make you jump higher or potentially flying, but makes you fall slower, therefore not requiring new obstacles. Not an entirely new concept, so the player could understand it with a clear representation. And more importantly, it brought the possibility of something that could spice up the whole game, not necessarily changing it's tracks: Resource management. As the hover could be used to bypass obstacles easily, a limitation was required, but instead of a cooldown, we opted to add something the player would have to control and decide. More freedom felt like the right choice as this becomes a layer of strategy toping what usually becomes a memory game with most runners that aren't procedurally generated.
Camera setup scketches
Theme Insertion
The theme was developed simultaneously with the levels, incorporating the design and mechanics actively.
We defined different setups for each 2D instance, according to the scenario.
Tropical punk maps had a more limited, close view of the track, giving a confined feeling, requiring more of the player reaction time and adaptation. Of course, we tried to calibrate the obstacles so that it didn't get frustrating.
Solar Punk maps had a wider view, allowing to anticipate the track and plan how to move. Not enough to lose the running dynamic but the necessary amount to identify new strange platforms and track branches.
Engine Implementation
I was in charge of building our concept tracks in the engine. Using the obstacle sketches was enough for an early block-out, but as I've tested the game myself and asked for opinions, many small changes were made, as now new, more tangible, factors were part of the scene, such as player speed and jump gravity/extent. To achieve satisfying results, the difficulty charts helped keep the ideas aligned with the original concept.
After getting decent results, I started replacing the blocks with our 2D and 3D assets, which included importing and checking for compatibility.
With the scenario starting to build up, I used the assets Gratz programmed for obstacle collision boxes and modelled them according to each asset we were using as obstacle.
Final first 3D level setup
Wireframes for assets and colliders in different engine views
Obstacle actors collider setup
2D maps
For these, we used the Paper 2D plugin, which uses a tile set based grid, so learning to use that and creating colliders for specific blocks was part of the project. The general process was not that much different from the 3D maps, just with different tools and interfaces.
Final second Solar Punk level setup with assets
Final second Solar Punk level tileset in scene
Final second Solar Punk level tileset customization with paper 2D
Programming
I initially focused on helping with being the main contact between the design team and the programmers, as I had used blueprints before, so most of the programming I actually did myself in this phase were secondary tasks, such as:
- Level transition through "portal" actors;
- Adapt sprite sheets into usable 2D animations and adding them to the player blueprint;
- Creating and configuring Sound Cue actors and how to reference them and play tracks;
- General player camera's adjustments;
- Importing and setting the 2D assets blueprints to fit our work method.
Portal transition function blueprint example
Polishing
Latter on, in the final stages of the projects, I became officially part of the programming team, fixing bugs and implementing features, mostly adding up to the systems that already existed, such as:
* Resources resetting through levels;
* 2D animation's timing, transitions and input responsive;
* SFX implemented, linked to actions and some as spatial sounds through the maps;
* Map lighting/coloring;
* Functional UI with visual assets implemented;
* Comic strip "cutscene" implemented and skippable.