| Name | APEX |
| Engine | Unity 5 |
| Platform | PC |
| Time | 7 weeks |
A runner game where you traverse a pre-set obstacle course by drag and dropping the platforms and walls you will want to use and then run the course in first person.
I was the sole scripter and programmer for the entire project and thus crafted all systems, gameplay features, player controls, camera controls, UI, etc. As the lead in all things tech I got to create tools like a level editor and a “piece-editor” (for the drag and drop phase).
Gameplay Scripting
Drag-and-drop functionality
A heavy part of the game is the abilty to create your own path by dragging and dropping preset pieces on to the grid representing the stage.
This was done by adding my own implementation of “begin drag handler”, “drag handler”, “end drag handler” and “drop handler”.
It demanded two scripts. “DragHandler” on the items being dragged and “DragSlot” on the object that represented slots where an item could be dropped (every space in the grid).
Draghandler:
Dragslot:
Every time the player place a piece on the grid a corresponding piece of the actual level (in 3D-space) was created (or moved, depending on if it already had been created).
Once the player hit the “RUN” button all newly created pieces where teleported 200m below the stage and where then animated in to their positions during a very brief period of time (with individual weighted random speeds). This animation didn’t repeat unless the player changed the grid layout (to not bore players who re-ran a level for a better score).
Controls and UX
Communicating Wall jumps
I choose to relay the message through obvious yet natural hints on screen, rather the on-the-nose prompts. There is sound that is triggered when the player “attached” to a wall. The camera tilted towards the wall and movement was restricted away from the wall for a short period of time (the walls where “sticky”).
This was accomplished by using a combinations simple tricks in the code. I also created a simple function to compare vectors with an adjustable margin of error so real time vectors could be compared without demanding the exactness of machine epsilon.
The movement script had some new information for the next frame on what rules to apply to the player:
And this is how I compared the vectors.
Level Editor
Making tools
Since I was the sole scripter on the project and all our levels where based on a grid space I tried to make the process for the level designers as easy as possible.
I created a system where all levels where designed in the same 2D-space as the players used to drag and drop their platforms for their path. Every square in the grid corresponded a coordinate in 3D-space and all 2D-objects spawned a 3D-piece to the actual level. All obstacles and walls worked in the same way. If the level designers placed an icon of a platform with a spinning axe (one of the traps in the game) on grid-space A1, an actual 3D piece of that platform was spawned in the “A1” of the 3D-space.
The 2D view of a level where all walls and traps are shown in their respective grid space.
The 3D-space with only the static start and exit of the level and a list-view of all gridspaces and what has been placed.
And finally the end product where all the 2D-icons have spawned their corresponding pieces (in runtime).
This simple solutions made level creation very fast and the level designers could build and test levels and tweek them in less than a minute – without needing any support.
The pieces used for the 2D-grid where also made in building blocks where new types of grid objects could be created without the artist or the level designers needing to write a single line of code. Just by filling out settings (2D-image, corresponding 3D-piece, offset from origo – for raised platforms – and in the case of creating a block that the players where supposed to drag: the amount of pieces to spawn) in an object called “Factories”.