Fractured Time
Lead Programmer, Lead Designer, and Writer
About Fractured Time
Fractured Time is a third-person puzzle-platformer created remotely over the course of 6-weeks with a team of 8 developers. I took the roles of lead programmer, lead designer, and writer. Here, I learned a lot about game production as a whole. Being my first game of this scale, I learned much about creating a complete experience, and to efficiently utilize time to create a project that
In Fractured Time, you play as a robot in a testing facility who one day gains sentience. Instructed by an unknown actor, you attempt to escape by utilizing newfound abilities to manipulate time and space. Jump between the present and the future to solve the mystery of the facility.
My Contributions:
1. Created the concept, and designed the game’s mechanics. Consisted of the time jumping mechanic, the platform freezing mechanic, and all of the different types of platforms throughout the game.
If I had to go back, I’d add some more platforms, particularly ones that crumble or fall away when the player stands on them. I would also make it so that these can be frozen, so the player can use them to provide footing for a longer period of time. I would also add rotating platforms, something I believe we did not make use of but could have easily broadened the design field.
2. Wrote the story of the game, and much of the critical dialogue, presented in the world through monitors with text on them.
Monitors are laid throughout the levels, presenting the tutorial, but also the narrative.
Monitors with different colors represent different AI that control the facility, each with distinctive “voice”.
The primary voice, represented by the light blue screen was written to be condescending and discouraging of the player.
3. Programmed the player controller, all mechanics, and the handling of camera collision.
The time jumping mechanic was an interesting one to create. My solution was to have all of the pieces in the level, but held in separate containers which were toggled on or off depending on whether the player was in the present or the future. The base geometry of the level was held in one higher level game object, while the geometry and relevant game objects for each held in their own containers. Lighting was also unique to the past or future, which helps the player understand their place in time.
Remixing this mechanic was fun, and often included the player utilizing this while jumping in tandem with the ability to freeze platforms in order to create complex jumping puzzles.
The platform freezing mechanic was simpler. At its core, when the player right clicks, it casts a ray. This ray, if it collides with a platform, freezes it for X amount of time. It has 3 charges that come back over time. This created some interesting interactions with the previous mechanic in that the previous mechanic caused the time freezing script to stop. This means that platforms could be frozen for longer than X period of time, and that X would only count down while the player was in that place of time perceiving the object. The emergence of this dynamic was taken into account, and utilized by our level designer when designing further levels.
The platforms themselves were rather simple to implement, they simply were placed in the level and bounced between two points. I made them easy to work with by having publicly facing variables that influenced the speed. Freezing them was implemented by disabling the script that handled the movement using a co-routine in a separate script. This little optimization kept us from having to call a boolean every frame in update to check if every moving platform was frozen or not.
I also learned a lot from this project about camera collision, it’s tricky to do right, we used an arm and collision on the camera to bring it in front of the point it collides with. There was a lot of tweaking I did to handle edge cases, especially in corners and places where the camera can possibly clip through multiple planes.
As a quality of life feature, I also implemented a quick respawning system. On collision with the floor, the game would register this as your spawn point, so if you died there was little friction to getting back to where you were. This was initially an issue, as collision with walls would cause that to become your new spawn point. This was solved with a simple raycast to make sure that your collision was with the floor and not with a wall. Similarly, everything that could change your spawn point was tagged as a “floor” so that platforms could not become your spawn point. This allowed us to control when and where we gave you checkpoints without having to painstakingly place volumes throughout the map.
4. Imported and Implemented all art assets:
This included all textures, models, animations, sounds, particle effects, and images necessary to make the UI function.
5. Designed and Implemented the HUD:
The HUD underwent a lot of iteration. Initially, it was simply 3 cubes to represent charges, and no conveyance of when your charges would come back, only whether or not they were available. After some iteration we added the filling meters, so you could know exactly when it was safe to make some risky plays. Finally, we ended up adding a clock to have even further conveyance of the player’s place in time.