• Animating in Unity

• Choreographing narrative elements with interactive play

• One week to complete - shooting for less than 24 - 36 hours. 

Finding the Fun

About Time started as a story idea - I wanted to explore how I can communicate a lifetime between a father and son through interactive play.  The idea of breaking major milestones into seasons representing the time of their lives was the foundation. Given the limited time I had to make the game and desire to keep the graphics super simple, I came up with the idea of using cubes to represent the father and son and approach the interactive experiences using abstract and stark environments.  

The fun I believe was trying to figure out mechanics that helped tell the story of the major milestones in their lives represented as seasons. 

The mechanic

After some experimentation, I settled on some very simple puzzle style and casual game play game mechanics to represent each season time and activities. I only implemented one style of puzzle/gameplay for each season mostly as a function of time. Ideally, each season would have multiple elements of each to give more time and substance to each season. 

To help communicate the passage of time, I changed the size and material colors of the cubes to represent each one getting older. Animations changed too, as the son gets older, his bounce is smaller as an example.

Game Loop

Putting all of the season game play together proved to be the most challenging. Each season included triggering NPC behavior and player controls that needed to be choreographed with the beginning and end of the seasons gameplay. I started using a timeline and treating each transition as a cut scene, but that introduced some strange behaviors  so I did it all in code. 

Don't drown in sunk costs

I spent a lot of time trying to make a system work that I needed to scrap and start over. The more time I spent trying to make it work, the more I was determined to make it work. I almost scrapped the whole project at one point since I spent too much time on one thing, but I would have missed my bigger goal of completing the game by the end of the week.  So I made the hard decision to scrap the system and start over. 

It's too easy to keep trying to fix something that can't be fixed, just need to know when to change course and try something different. 

Pencils down

Given the abstract nature of the project, I wanted to keep adding to it to help communicate key ideas - I knew the ultra simplicity of the prototype would leave a lot of questions and confusion as to what the heck was going on. But my goal of completing the demo in less than a week forced me to make decisions that where the most crucial and central to making the full loop work. I think this constraint is good in the early stages of design and development to keep you laser focused on the core experience first.  The core elements need to form a solid foundation you can build on.