Aly-hjem
A 2-player local co-op 3D action-platformer.
▶ THE BRIEF
Aly-hjem started with an idea: a space game setting that felt like one of those browser games you'd stumble across when you were younger. Easy playable, no friction, just pick up the controller and go. The target audience was tweens, 9–12 years old, which meant there was a lot to think about to make it actually work for them. Controls had to be fairly simple. Two kids sitting down together had to be able to figure it out without anyone explaining it to them, and it had to be fun enough that they'd want to keep going. To ground those decisions in something more than gut feel, we did research. We leaned on Self-Determination Theory and Flow Theory to understand what keeps a young player engaged without tipping into frustration, and drew on Piaget and Erikson to think about what's actually age-appropriate at that developmental stage. That research ended up justifying a lot of the more conservative design calls; fewer buttons, a simple and readable playthrough, and prioritising co-op fun over mechanical depth.
▶ WHAT WE BUILT
The core of the game is planet-relative gravity so players walk around the planet. On top of that we built a three-state jump machine (grounded / rising / falling) to drive jump feel and animation transitions, directional combat using dot-product comparisons between input direction and facing paired with Physics.OverlapSphere for hit detection, and a hold-to-revive co-op mechanic that we were particularly happy about: when one player goes down, their partner has to physically stay close and hold the input to bring them back. It turns what would be a frustrating fail-state into a co-op moment instead. The rest of the game have wave-based enemy encounters, a boss fight, achievement system, main menu, and settings, which all had to connect coherently. One thing we made sure of early was an in-game tutorial card UI that pulled its control labels directly from the live input scripts, so onboarding stayed accurate even as the controls changed during development. We made a simple cartoon-like 3D character design in Blender, where we made a base character and from that we made different models so that players can choose different characters that best suit them.
▶ A TECHNICAL CHALLENGE
A technical challenge we had was that player and enemy movement started on Unity's CharacterController, but once planet-relative gravity needed to interact properly with physics, CharacterController really working with it. Therefore, we migrated everything over to Rigidbody, driving velocity manually in FixedUpdate and switching jumping from a fixed positional offset to an impulse-based approach. The trickiest part of that migration was ground detection. The naive version was just checking whether a downward raycast hit the ground layer, but that reintroduced a subtle bug: a player who had just jumped was still close enough to the surface for the ray to return true, so the game would immediately re-flag them as grounded mid jump. And that broke the jump feel entirely and also allowed unintended double jumping. The fix was a !movingUp check alongside the raycast, so we usinged a Vector3.Dot to project the player's current velocity onto the surface normal, and only treating the character as grounded if the ray hits and they aren't still moving away from the surface.
