Niranjan Girhe

This is a physically simulated character in Unity that reacts to surprise events: a box falling toward it while it sits on a bench, or a ball thrown at it while it stands. Its body is 15 rigid parts joined by motors, and it never plays an animation clip. Every movement comes from the physics simulation.

When the simulation senses an event, it describes it in one sentence, such as “A heavy object (about 12 kg) is falling toward the head, about 0.4 s until impact.” A typed decision model reads the sentence and chooses one of seven reactions, such as bracing, dodging sideways or curling up, along with how stiff the muscles should be. The character tenses briefly while it waits, like a flinch. If no answer arrives within 200 ms, hand-written rules decide instead. I compared Laya and GLiClass, both used without fine-tuning, with the rules and with a fixed reaction, on the same 30 events in each scene.

Results.

• A decision from Laya took 47 ms (median) and 1.7 GB of video memory; GLiClass took 15 ms and 0.6 GB. The rules took under 0.1 ms. Only 1 of 116 model decisions missed the 200 ms limit.
• On the CPU, Laya took about 1.8 s per decision, too slow for the 200 ms limit; GLiClass took about 44 ms.
• Without fine-tuning, the models didn’t use the details of the event. On the bench, Laya curled up and GLiClass dodged every time. Standing, each spread its answers over three to five reactions, but not in line with the object’s weight, the time left or where it would hit.

One computer: NVIDIA GeForce RTX 4070 SUPER. Two scenes × 30 seeded events per decision method. Times run from the event until Unity has the answer.

Laya’s model card says its base checkpoint is meant to be fine-tuned, and the simulation can label training examples itself by trying each reaction and keeping the one that worked best. A lighter option is a small policy trained with reinforcement learning that reads the event’s numbers directly. It could output the values that drive the body, so reactions would be generated rather than picked from a list (Q1, Q6).

Mira is a shopkeeper who remembers her interactions with the player. If someone helps her and later steals from her, both events affect her response and the price she charges.

I use hand-written rules to score her responses and prices, with templates for dialogue. Depending on the player’s history, Mira can offer a discount, charge more or refuse to sell altogether. She can also offer a free apple after repeated help, share a quest or warn the town guards.

I have built a separate prototype that runs this with local AI. A typed decision model, GLiClass, gets her history and the current game state and scores each action the game supports. A small language model, Qwen3-0.6B through Ollama, only turns the chosen action into what she says, so it can’t change her decision or her price. If either model is missing, slow or returns something unusable, the game falls back to the rules and templates above. I timed each step over a 50-turn game on my own computer (an RTX 4070 SUPER), and compared Qwen3-0.6B with SmolLM2-1.7B.

Results.

• A decision from GLiClass took 61 ms (median) on the CPU, or about 120 ms after a purchase, when the price is scored too.
• A whole turn with dialogue took 276 ms with Qwen3-0.6B and 262 ms with SmolLM2-1.7B. Both ran fully on the GPU, using 3.1 GB and 2.6 GB of video memory.
• Speed is fine, but the choices are not yet. GLiClass picked “welcome” on all 50 turns, even after thefts and a hit, though it did raise her price after the player started stealing. Qwen3-0.6B copied its prompt in 44 of 50 lines; SmolLM2-1.7B wrote new lines in her voice and copied only once.

One computer: Intel Core i7-13700K, 32 GB RAM, NVIDIA GeForce RTX 4070 SUPER, Windows 11. One 50-turn game, seed 1.

An enemy boss can become predictable once a player has learnt its attack patterns. I’m interested in one that notices the player’s habits and changes its tactics in response. If a player keeps attacking from behind, the boss might turn to guard its back or sweep its tail, leaving its front less protected.

In this model, the boss has a limited budget for counter-moves. Each has a warning the player can learn to read and a weakness they can exploit. The chart follows twelve attempts, showing how the assumed challenge changes with the player’s habits and the boss’s adaptation.

I have also built this as a playable fight. The player picks a move each round, and every counter shows its warning before it strikes. Between attempts, a typed decision model (GLiClass) reads a summary of how the player has been fighting and scores the four counters, and the boss splits its budget by those scores. A small language model gives the boss a taunt about what it noticed. Built-in rules based on the model above take over when GLiClass isn’t running.

To compare it with a static boss, I wrote five bot players, each with one strong habit (or none), and had each fight both bosses for twelve attempts. Every attempt, the bots get better at reading the warnings and at beating the base moveset. Challenge is the share of health a bot lost in an attempt, or 100% if it lost.

Results.

• Against the static boss, challenge fell from 52% to about 30% as the bots learned it; 13% of later attempts were inside the 35–60% target range.
• Against the adaptive boss, challenge settled at about 40%, and 60% of later attempts were inside the target range.
• The bots still won 59 of 60 fights against the adaptive boss, against 60 of 60 against the static one, so it made fights harder without making them unwinnable.
• The adaptive boss was hardest right after the first attempt (60% on average), when it countered a habit the bots couldn’t yet read.

Five bots × twelve attempts, one seed, with the built-in rules making the boss’s decisions, not GLiClass. “Later attempts” are attempts 7–12.

The bots learn the way I told them to, so these results test the design under my assumptions; they don’t measure difficulty or enjoyment. I would need player studies to find out how much the boss can change while giving players a fair chance to learn its counters, and whether those changes keep the fight engaging (Q4).

This idea came to me while playing Ghost of Tsushima. I wondered how encounters might change if enemy populations adapted to the tactics a player kept using. Could traits that help enemies survive those encounters become more common over time?

In this simulation, predators and prey pass traits such as speed and eyesight to their offspring, with small mutations in each generation. The traits affect survival and reproduction. Speed, eyesight and agility also cost energy, so there are tradeoffs in which traits a creature can sustain.

I’d like to test this idea over successive playthroughs or seasons in a game. There is no player in the simulation; the possible adaptations in Table 1 are ideas for a game.

Results.

• Predators developed a wider binocular zone in 7 of 10 runs (65° → 80° on average).
• Prey vision range decreased in 9 of 10 runs.
• Predators got faster in 10 of 10 runs; prey in 9 of 10.

Prey eye placement showed no consistent trend.

In a game, these population changes would need to work with the behaviour of individual enemies. I’d like to test whether a game director can coordinate the two, and what that does to encounters over repeated play (Q3).

The idea for this prototype came from playing Cities: Skylines II. I wondered whether commuters could learn from earlier journeys and use that experience to anticipate congestion before it appears on a live traffic map. This simulation explores that question in a small city.

There are two copies of the city, each with 420 commuters. In one, drivers use current traffic conditions alone. In the other, they combine memories of previous journeys with live updates. Adding roadworks in the interactive version disrupts the same street in both cities.

Drivers with memory store travel times by road and time of day. They use that history to choose when to leave and which route to take, then consult live updates if a road is much slower than expected.

Results.

• Average delay per commute in week 3: 6 min with memory, 18 min with the live map only.
• Average delay during unexpected roadworks in week 4: 39 min with memory, 45 min with the live map only.
• Drivers who had to reroute mid-trip: 2% with memory, 52% with the live map only.

Averages across six runs, over days 15–21 unless noted. Delay is measured against the fastest trip on empty roads. Some drivers with memory left earlier or planned longer routes; unexpected roadworks narrowed the advantage.

These results come from routing rules and stored travel times. I would use them as a baseline for testing a small model that summarises travel patterns or revises a plan after an unexpected disruption. Any improvement in its decisions would need to justify the model’s runtime cost (Q1).