Lost Toy

Key Contributions

• Turn-based gameplay system
  • Interactions foundation
  • Player movement
  • Enemies
• Mobile optimization
• Startup animation sequence

Jump to Conclusion

Overview

Lost Toy is a mobile turn-based puzzle game where you must catch up with Santa’s sleigh before take off. You must navigate through grid-based levels, avoiding factory equipment and rogue toys while solving puzzles to progress. Every time the player makes a move, everything else does as well.

Turn-based gameplay system

I really enjoy building systems, so I made sure I would be the one to build this one. Making the ticking system wasn’t too difficult, especially after we set up a simple event system using C# multicast delegates:

public enum Turn
{
    Player,
    StageOneEnvironment,
    StageTwoEnvironment
}
 
public class GlobalEventSystem
{
    public delegate void OnPlayerStartMove();
    public static OnPlayerStartMove ourOnPlayerStartMove;
 
	// ...
}
 
// Simply add/remove a listener on enable/disable:
private void OnEnable()
{
	GlobalEventSystem.ourOnTurnStart += OnTurnStart;
}
 

One thing we battled a bit was collision checking. We had to make sure that our player didn’t fly out of the track or phase through walls. I built a simple system with two raycasts to check for obstacles in the direction of movement:

- rotate player to face movement direction
- cast ray forward to check for walls
- if no wall, cast ray down to check for ground
- if ground exists, begin moving the player!

However, we ran into some issues where the ground raycast would sometimes slip in between tiles and think there was no ground, which would make the player return to its original position.

Interactions foundation

I created a script which let our level designers trigger Unity events when the player steps inside a trigger volume. It’s a very simple concept, but it made iterating on levels and mechanics way easier.

Non-player interactions

This was actually a bit difficult. For some reason, non-player objects wouldn’t trigger the action triggers. It was very important that we fixed this, because we had planned for the movable blocks to be able to trigger pressure plates. It took some refactoring, but we got it working in the end!

Mobile optimization

One of the requirements for this project was to have a stable, playable frame rate. We were given some really slow tablets to test on, but we didn’t worry because how bad could it be, right?

Turns out, there’s a lot of little things that can tank performance. While having a playable frame rate is obvious, we didn’t realize how much we actually had to do. One of the more frustrating things we kept running into was that post processing effects kept randomly enabling themselves. Before we turned in our game, we quadruple checked that we had the right settings. We also lowered the rendering resolution to about 70%, which made a massive difference on those tablets.

In the end, all our optimizations added up and our frame rate went from about ~12 FPS to a stable 50 FPS!

Main menu startup animation

While I am primarily a programmer, I also really enjoy motion design! Originally, the startup sequence was meant to be a simple fade, but there were issues and delays while implementing it. Since I didn’t have anything else to do, I got the opportunity to spend a day creating the most maxed out sequence possible (within limits).

They say a picture is worth a thousand words, so here are 200 of them at once:

Originally, the walls in the main menu room were meant to fall down like a box, but it didn’t perform well on lower end devices.

Bonus: The night before Christmas

It was the final day before everybody went home for Christmas break. Things were going really well, I had just implemented a move buffer so early inputs were more forgiving. The game felt responsive, polished, and there were just a few small adjustments left to make.

Until everybody went home and the two of us that were left discovered that all our action triggers had been reset to default values.

Turns out, after some prefab restructuring earlier that day, Unity had lost all trigger connections in each level. We really didn’t want to to deal with this later, so we stayed up all night connecting everything back together, ensuring everything was in place before turning it in.

Conclusion

This game ended up turning out way better than I expected! Getting to build a turn-based system was really fun, since it was both a system and a core gameplay mechanic. I’m very happy with all our contributions, and I really like what we created as a team.