Skip to content

Lizard Wizard

A whimsical 3D puzzle-platformer: build speed across the dunes, carry it through jumps, and deliver water to thirsty critters before you run out. I set up the production structure the five of us work in, and I'm building the predators' sensing AI.

My sandbox scene: the spider's vision cone and hearing radius as gizmos, and the console confirming a vision detection.
My role
Production setup lead and predator AI programmer on a five-person team
Team
Ibrahim Shaheed, Vivian, Xavier McIntosh, Diego Santiago-Rodriguez and me
Built with
Unity 6 (URP), new Input System, GitHub feature-branch workflow
Status
In development as our senior capstone (fall 2026)

The game

You play a lizard wizard whose hat is also a water reservoir. Water drains over time, spills when you fall or get hit, and is the only thing keeping desert critters alive. Movement is the core: sliding down dunes and carrying momentum, with references like HASTE, Alto's Odyssey, Titanfall 2 and Sonic Frontiers. Predators and weather add pressure to your route.

Terrain generation, player physics and the water UI belong to teammates. The sections below cover only my part.

Production foundation

  • Five-person project structure

    I laid out the shared Unity hierarchy for art, audio, data, scripts, scenes and docs, and gave each teammate a personal sandbox scene. Features get built and tested there before anything touches a production scene, which keeps merge conflicts down.

  • Team rules and reference

    I wrote a folder cheat sheet and working rules: coordinate before editing production scenes, branch per feature, keep files where they belong. I also set up the Trello board and a shared PureRef reference board.

  • Repository recovery

    When a terrain asset was corrupted by line-ending conversion, I restored the working version and updated the Git attributes so Unity binary assets are never treated as text again.

Predator sensing AI

The first predator is a desert spider. I kept its state machine to three states (Idle, Pounce, Retreat) and put the effort into how it notices you, plus a little randomness so it doesn't feel scripted.

  • Vision

    Checks distance and view angle first. Only if both pass does it spend a raycast on line of sight. It runs a few times per second, not every frame.

  • Hearing

    A radius around the spider receives noise events from the player. If the noise lands inside the radius, the spider has heard the player.

  • One shared reaction

    Both senses call the same ChooseReaction method. The spider rolls once: 75% pounce, 25% retreat. It never re-rolls every frame, so it can’t flicker between states.

  • Readable in the editor

    Gizmos draw the vision cone and hearing sphere, and every state change is logged, so designers can tune ranges without reading the code.
The spider state machine from my technical design doc, written before the code.

Production blog

The team posts weekly progress on a public production blog. My first post covers the movement research and the project structure above.