35%

independent project

Frog Catching Game

A cozy exploration game about catching frogs and spending time with your dad.

  • Unity
  • C#
  • Gadgets
  • Frog AI
  • Character & Camera Systems

Building the systems behind a playful premise

Frog Catching Game is a third-person exploration game built around finding distinctive frogs, learning how they behave, and catching them with a net. Each catch feeds into a wider collection loop, where frogs can be presented, catalogued, and are connected to rewards and objectives.

The prototype became a place to develop three connected systems in depth: gadgets, frog AI, and a Kinematic Character Controller plus camera stack.

Turning menus into handheld gadgets

The Croakidex and scavenger list are not conventional screen overlays. The player raises them inside the scene, moves between pages, paints reveal masks, and operates their controls while the world remains visible around them. This keeps collection progress inside the game's playful, handmade language.

I built the underlying gadget framework separately from either prop. It owns opening, closing, selection, focus, and interaction mode, while interchangeable drivers translate pointer or controller input into a shared context. Reusable 3D controls cover dials, free-spinning knobs, sliders, track sliders, toggle switches, pressable keys, directional pads, and draggable handles. New gadgets can therefore combine tested physical controls instead of rebuilding input behavior for every interface.

Input contexts coordinate gadget controls with movement, catching, and general interactions. When a gadget takes focus, the player controller can suppress or redirect overlapping actions and restore them when the gadget closes. The same gadget stays operable with mouse, keyboard, or gamepad without embedding device-specific rules in the prop itself.

Turning menus into objects you operateThe Gadget system allows for highly modular and contextual setups of different hand held interactables such as the Croakidex, the later test bed shows other primitives like dials, sliders, switches, keys, directional controls, and draggable handles. All with semantic events to rapidly prototype any new gadget.

Composing frog AI from small decisions

Each frog brain combines hop-based movement strategies, sensors, and obstacle policies. A frog can roam, chase, flee, follow a target, hop in place, move along a spline, or transition between authored behaviors. Ground, cliff, obstacle, player, and caught-state sensors supply the facts; strategies decide what to do with them; the hop motor turns the result into movement.

That separation makes behavior reusable and inspectable. A frog type can change how it reacts to an obstacle without replacing its locomotion, and sensor gizmos make the reasoning visible while tuning a scene. Obstacle policies can steer around a blocker, jump it, or switch to another strategy without expanding one central state machine.

The update scheduler handles the population-level problem. Motors and sensors use independent near, mid, and far cadences; visible frogs receive priority; hysteresis prevents rapid tier switching; and grouped frogs can stay synchronized. Nearby action remains responsive while distant frogs cost less, without changing the behavior code that gives each frog its personality.

Modular FMS Creature AIThe Frog AI is simple but highly effective for this game. Allowing designers to chain together multiple states with a verity of triggers, sequencing complex behaviour with simple blocks. The dynamic obstacle avoidence allows navigation of the level as needed along with the base sequence. Performance is handled with custom culling for the physics engine.

Making KCC movement and camera behavior agree

The character stack wraps Kinematic Character Controller behind a smaller motor contract, then builds semantic movement state on top of it. Grounding, steep slopes, jumping, falling, landing, sprinting, scripted hop arcs, and temporary stat modifiers are exposed as deliberate gameplay concepts rather than raw collision results. Catching and gadgets can request a slowdown, locomotion stop, or authored traversal without taking ownership of the motor.

The Cinemachine-based orbit controller treats pitch, distance, field of view, dynamic focus, occlusion, and collision as related but separate concerns. An obstacle sensor array samples the space around the desired camera pose, and the decollider then resolves a safe position and recovers smoothly when geometry clears. Keeping line-of-sight correction separate from physical collision avoids solving one camera problem by creating another.

A majority of these techniques were added only after a deep dive into game cameras; here are a few references and resources that I highly recommend.

Occlusion & collision
Separating visibility from physical contactLine-of-sight recovery and camera collision are solved independently, preserving a readable view around trees while avoiding clipping and abrupt restoration.

Folding input space to preserve a held direction

Camera-relative controls are easy to read until the camera turns far enough that the key being held points toward a different side of the world. Reinterpreting it every frame can then make the character abruptly reverse, even though the player has not changed direction.

The controller remembers the heading established when that movement began. As the camera reference changes, the held S, A, or D direction can inherit the role normally played by W—like folding that part of the input space over the forward direction. Sideways steering can still bend the path, while small gamepad fluctuations are ignored so they do not create a new heading by accident.

The remembered heading is released when the stick returns to neutral, allowing the next movement to begin naturally from the camera's new orientation. The result is not a permanent world-space lock; it is continuity for one sustained action.

Together, these three systems support the same goal: the player should be able to understand a lively frog, operate a tactile object, and move through the environment without fighting the controls or losing visual context.

Aligning input, camera and character's heading seamlessly.Camera-relative controls normally reinterpret movement as the view turns. Here, the controller remembers the heading already in motion, allowing held S, A, or D input to temporarily inherit W's forward role as the camera recenters. Sideways steering can still bend the path, but the character does not unexpectedly reverse. Returning the input to neutral or when the input, camera and heading allign, the remembered heading is released, so the movement stays oriented to the camera's current.

References & further reading