The game
Sk8 Escape is an endless runner about skating through a city and landing tricks. You steer and trigger tricks with touch input, the score climbs while you stay on the board, and a run ends when you come off it. There is a leaderboard to climb after that.
We made it in four weeks at Forsbergs, and the whole class was on it. That was a bit over twenty people split into four teams: gameplay, meta game, backend and integrations. I was on the gameplay team and the player was mine, and the idea for the game was mine as well, so I had a hand in a lot of the design decisions.
One thing to be upfront about: the art is AI-generated, and I am not proud of it. We had no artists in the class, image generation had only just turned up, and we wanted to see what it could do. I would not do it again.
The player
The player is split into three parts, in an MVC-inspired shape. PlayerModel holds the data and the tuning values, PlayerView drives the animation, and PlayerController takes the input and moves the player. That mattered more the further in we got. As tricks and behaviours piled up, the file you had to open was the one that owned that part rather than the one that owned everything.
The tricks themselves are a state machine. Each trick is a state, and the transitions say what has to be true to enter it. An ollie has its own behaviour but sits in the same movement system as everything else, so adding a trick meant writing a state and its transitions instead of another branch in one long movement script.
Four weeks
Four weeks leaves almost no room for iteration or polish. We ran it Scrum-style: tasks handed out at the start of the week, a short check-in every day, and a meeting and a fresh build at the end of it.
Four teams changes what you are building for, too. Gameplay had to meet work being done elsewhere in the project, so the question was never only whether the movement worked. It was whether it could still be extended once the rest of the game arrived.
What I took away
This was one of the first larger things I made in Unity with other people rather than on my own, and most of what I got out of it came from that. Input handling, player architecture and state machines were all new to me, and doing them to a four-week deadline with three other teams waiting on the result is a different job from doing them alone.
The part that stuck is keeping gameplay systems modular when several people are working on the same game. Because the tricks were separate states with their own transitions, adding one late did not put the ones already working at risk. As a single movement script it would have been the same code every time, and every new trick would have been a chance to break the rest.