Throughout the day, various keynotes were held. Our lab hosted two keynotes and showcased three projects:

Does She Remember How You Felt?

Does she remember how you felt?

In many new video games, characters talk with you through an AI language model. These characters cannot keep every word that you say, so they write short notes about each conversation. When the notes pile up, the AI rewrites them shorter, and then it does this again and again. AFTERSTATE, Al Shifan’s Master’s project, asks what survives all this rewriting: the facts of what happened, or the feelings behind them.

We tested 12 open AI models on 219 role-play conversations from a fantasy game, and we checked every fact and every feeling after each rewrite. The first results surprised us. Feelings lasted a little longer than facts: 29% of feelings were kept, against 23% of facts. But the feelings lost their detail. In about 7 of 10 cases, the memory kept that a feeling was there, and whether it was good or bad, but it lost what kind of feeling it was or how strong it was. Feelings that a character only showed, such as a slammed door, were lost more often than feelings put into words. Most of the loss happened at the first rewrite. To show what this means for players, we also built a small demo game, The B Gate 3, where a companion rewrites her notes about you after each night at camp. These are early results, and we will check them with human labels next.

PEAK: Testing Levels with Evolved Players

What PEAK is

PEAK is a game-balancing tool for 2D platformers. Small neural networks learn to play a level and then report what happened: how often they win, where they die and why. This way, a level can be tested thousands of times without humans.

PEAK has 5 game engines: Mario, Mega Man, Sonic, Meat Boy and Bomberman.

Players with different styles

The agents imitate 6 types of players:

The experiment

The newest work asks one question: if you make one small change to a level, do the agents notice it?

Each game has 1 test level, and each level has 5 changes:

• A sealed route: a wall blocks the way to the exit
• A harder obstacle: a wider gap, an extra enemy or a shorter bomb fuse
• A weaker jump
• A hidden change: a tile that no player can reach
• A cosmetic change: the level file is different, but the level plays the same

The agents first learn to play the original level. Then they play each changed version, and PEAK compares the two sets of play.

The results

• PEAK caught 11 of 12 changes that make the level harder or impossible to finish.
• PEAK correctly ignored 4 of 4 changes that do not affect play.
• The cosmetic changes played exactly the same in all 4 games.
• The one miss was the weaker jump in Meat Boy.

Novice, experienced and speedrunner players noticed the most changes. Clumsy players noticed none, because they could not finish the original levels.

TokyoEmerald

Can pedestrians in Shinjuku, Tokyo beat Pokemon Emerald?

Given enough time, probably!

TokyoEmerald is a computer vision project I myself worked on during the university’s reading week. The concept is simple: track pedestrians from a 24/7 live stream, mapping their real-time location to a virtual surface containing buttons. There are buttons overlayed on the stream that map to actual inputs in the game. The game feed is positioned in the top-lefthand side of the stream.

As of the time of writing, it has been nearly two weeks since the stream started. We have a level 17 Combusken and we haven’t beat the first rival fight.

More information can be found in the Twitch channel description: twitch.tv/TokyoEmerald. Feel free to walk on by our lab (SCI-2071) to see the stream on display, as well.

We recently went inside Minecraft to explain our new research paper, RIDGE: State-Conditioned Reward Blending for Behavioral Convergence in Deep RL Game Agents. The paper was accepted for an oral presentation at the IEEE Conference on Games (CoG) 2026.

Why Minecraft? Our reinforcement learning agent learns in Crafter, a 2D survival game that works very much like Minecraft. In this environment, the agent chops trees, crafts tools, fights zombies, and tries to stay alive. Presenting the paper from inside a similar block-building world felt like the perfect way to demonstrate the agent’s capabilities.

The Problem

Usually, reinforcement learning agents are trained around a single play style. If you want an explorer, a survivor, a craftsman, and a warrior, you traditionally have to train four separate agents. Simply hard-switching rewards while an agent is learning destabilizes its entire value function.

Our Idea

Our idea with RIDGE is to train one agent that possesses all four reward profiles and smoothly blends them together based on what is happening in the game. Instead of needing separate specialists, the agent adapts its priorities as the situation changes. When its health is low, it prioritizes playing it safe. When it has sufficient resources, it focuses on building.

What Happened

The state-conditioned approach led to significant improvements in versatility and performance:

• Dual Specialization: RIDGE was the only agent to successfully reach both the crafting and combat skills. It reached the wood pickaxe about 32% of the time and the wood sword about 26% of the time, whereas each individual specialist only mastered its own designated branch.
• Survival Mechanics: It learned to sleep and wake up safely 0.66 of the time. The fixed agents reached 0.15 or less.
• The Importance of State: When we removed the state-based blending and simply mixed all four rewards equally, performance dropped by 30–50%.

One agent with many play styles costs less to train, and it plays much more like a human adapting to a dynamic environment. Beyond games, this idea could potentially extend to adaptive autonomous systems.

A big thanks to my co-authors Kevin Christopher Chua, Ali Neshati, Loutfouz Zaman, and Cristiano Politowski, and to the Code & Sorcery Lab at Ontario Tech University.

Links & Resources:

• Full Video: Watch on YouTube
• Code + Paper: GitHub Repository

With this review, I wanted to see how far AI has taken the capabilities of NPCs in video games.

For many years, I went from being someone who not only enjoyed playing games as a kid, wondering how they magically made the NPCs fight the player or help them in some way, to learning how to program them bit-by-bit in university.

Now, with the rapid emergence of AI and LLM-based applications and characters, I constructed this review to explore what researchers have done to potentially enhance the realism of NPCs. The review has been designed to show what can take a simple conversation or encounter and make them feel similar to a true interaction.

Can LLMs improve the experience of players? Or do they diminish their enjoyment? Can NPCs be efficiently created with current technology, or do they imply that manually crafted behaviour trees/dialogue are the most optimal?

Read the paper here!

The visit is hosted by Prof. João Eduardo Montandon, coordinator of the project Improving Software Development Productivity with Large Language Models (CNPq nº 444507/2024-8), and has three goals: strengthen the research collaboration between our groups, deliver a seminar for graduate students and faculty, and hold focused meetings with faculty members to advance the project’s research lines.

The seminar

I gave a talk titled Games, Software Engineering & AI — What we build, break and measure in our lab, covering the work we do at Code & Sorcery: how we build games, how we break them, and what we measure along the way.

Meetings

Beyond the seminar, the visit is built around individual meetings with faculty. So far I have met:

• André Hora
• João Eduardo Montandon
• Marco Tulio Valente
• Eduardo Figueiredo
• Lucas N. Ferreira

Many thanks to João and the DCC for the invitation and the warm reception.

What the lecture covered

The first part set up what empirical research means in this context: building knowledge from observation, measurement, and evidence rather than intuition or advocacy, and what that looks like when applied to games.

The hard part is that games have subjective goals. Ordinary software is judged on correctness, reliability, and performance. Games are judged on fun, fairness, immersion, frustration, pacing, and balance — none of which can be measured directly, so empirical game research leans on proxies. That splits the field in two: research on game development (bugs, patching practices, testing strategies, engine usage, maintenance) and research on the game experience (difficulty, balance, pacing, immersion, engagement).

Four case studies

The rest of the lecture walked through projects from the lab, all of them on retro games:

Creativity Beyond Functionality: An Observational Study of Easter Eggs in Video Games — with Claudio Di Sipio, Benoit Baudry, Michalis Famelis, and Houari Sahraoui, published at the 10th International Workshop on Games and Software Engineering (GAS 2026). Where do easter eggs come from, what counts as the first one, and what does a dataset of them across decades of releases actually show?

Iterating a Game Series’ Identity: Mixed-Methods Analysis of the Creative Process Developing Dragon Quest I–VI — with Aleksander Franiczek, presented at the International Conference on Games and Narrative (ICGaN 2025). A studio iterating on a series wants each entry to be better while reusing assets to keep the work tractable. But what does “better” mean, and how do hardware constraints such as cartridge size shape those creative decisions?

Rewriting Nostalgia in Official and Unofficial Iterations of Final Fantasy IV — with Aleksander Franiczek, accepted at the Canadian Game Studies Association Conference (CGSA 2026). Final Fantasy IV has been ported, remastered, and remade repeatedly, and fans produce ROM hacks that remix features across versions. That makes it a strong case for treating nostalgia as an active process rather than a fixed memory.

Decompiling (retro) Pokémon games — reverse engineering an executable back into human-readable code, and asking whether a feature you see in the game is really the code you think it is.

Thanks to Andrew for the invitation.

A GeoGuessr-style campus exploration game for Ontario Tech University

https://www.otuguessr.com/

Created by: Adrian Fudge & Vincent Wong

Introduction

Ontario Tech University has a large and diverse campus with many hidden or lesser-known spots that students may never discover during their time at the school. As students ourselves, we noticed that many people tend to stick to the same few buildings and paths, missing out on some genuinely great areas across campus.

We built OTUGuessr to help change that.

OTUGuessr is a GeoGuessr-style web game designed specifically for the Ontario Tech University campus. The goal of the project was to create something fun and interactive that would encourage students to explore their surroundings, improve campus culture, and give both new and long-time students a new way to engage with the university.

This was a personal project between two students, built outside of any course requirements, with the goal of gaining real-world development experience and showcasing our technical skills. After deploying the application, we saw hundreds of users within the first 24 hours, which was incredibly motivating and validated the idea.

What is OTUGuessr?

OTUGuessr is a browser-based guessing game inspired by GeoGuessr, but fully themed around the Ontario Tech University campus.

Players are shown an image taken somewhere on campus along with an interactive map. They place a pin where they believe the image was taken. Once submitted, their guess is scored based on how close it is to the real location.

After several rounds, players are given a final score and can submit their name to appear on a global leaderboard.

The target audience is students — from first-years seeing campus for the first time to postgraduates who may still discover places they’ve never noticed before.

How the Game Works

1. A random campus image is displayed.
2. The player drops a pin on the map.
3. The guess is submitted.
4. The distance between the guess and the actual location is calculated.
5. A score is awarded based on accuracy and speed.
6. After several rounds, the final score is shown and can be submitted to the leaderboard.

Tech Stack

• Frontend: React TS
• Mapping: Leaflet
• Backend / Cloud: Firebase
• Hosting: Vercel

High-Level System Design

Image + Coordinates → User Guess → Distance Calculation → Score Computed → Stored in Firebase → Leaderboard

Key Challenges & Solutions

Accurate Distance Calculation

We implemented the Haversine formula to calculate the shortest distance between two points on Earth using latitude and longitude.

Image Performance

Images were resized and compressed before upload to significantly improve load times and responsiveness.

What We Learned

• Full-stack web development
• React + TypeScript workflows
• Firebase cloud integration
• Deployment and performance optimization

Future Improvements

• Monthly resetting leaderboards
• Larger curated image pool
• Moderation system for submissions
• Difficulty modes

The Team CSS (Code & Sorcery Students) Kevin christopher Chua, Mohame Al Musqi Mohamed Shifan, Alex Lowe, Adrian Fudge created this great tool that can identity body parts and facilitate the interaction between medic and pacients, even using multiple languages.

More details bellow.

Bridging the Gap in Telehealth: Introducing Gestura

I’m excited to share Gestura, a project built for the 2026 Global Hackathon that aims to revolutionize patient-clinician communication in telehealth.

The Problem: Describing pain is hard. Language barriers, physical limitations, and the lack of tactile feedback in video calls often lead to misdiagnoses and frustration. “My arm feels like fire” shouldn’t become a translation error.

Our Solution: Gestura is a real-time, AI-powered body mapping tool that translates gestures into structured clinical data. No wearables, no special hardware just a webcam.

We believe technology should make healthcare more human, not less. Gestura is our step towards a future where every patient is understood, regardless of language or location.

Check out the demo below!

Check the details here: https://devpost.com/software/gestura-23czgh?ref_content=my-projects-tab&ref_feature=my_projects

FaSE4Games brings together researchers, practitioners, and educators working on the challenges of software engineering for entertainment games, serious games, and gamified applications. The workshop offers an open and collaborative environment to share new ideas and discuss emerging topics in game development.

🔍 We welcome: • Long papers (8 pages, incl. references) • Extended abstracts (5 pages, incl. references)

All submissions will be reviewed by three reviewers. Accepted contributions will be presented at the workshop.

📅 Important Dates • Submission deadline: February 12, 2025 • Notification: March 19, 2025 • Camera-ready: April 2, 2025

🌐 More information: http://fase4games.quest

Whether you submit a paper or simply join us for the event, FaSE4Games offers a welcoming space to learn, share, and connect with the community driving software engineering for games.

See you in Montreal! 🇨🇦

To solve this in PEAK, we implemented Spatial Hashing, a broad-phase optimization technique that partitions the game world into a grid of “buckets.” This post details our implementation and the architectural decision to use a Dual Hash system.

PEAK – Platform Engine by Al and Kevin

PEAK is a small SMB1-style RL/game engine with: A custom Mario-like environment (MarioCore) using Pygame. A modular reward layer (mario.py) that shapes behavior into different “personas”.

Clean Gym-style API: reset(), step(action), get_action_space(), get_observation_space().

The core loop is:

1. Env loads a level from ASCII.
2. Player + enemies/coins/powerups are spawned.
3. Each step(action):
   • Apply input → physics → collisions.
   • Update game objects, anti-stall logic, camera.
   • Compute reward and info.
   • Return (obs, reward, terminated, info).

The Architecture: Why Two Hashes?

When designing the collision system, we evaluated three primary architectures: a single unified hash, separate hashes for static/dynamic objects, and a hybrid approach.

We selected Option 2: Dual Spatial Hashes. In this architecture, we maintain two distinct instances of the spatial hash:

1. static_hash (TileHash): Contains walls, floors, and platforms. Built once at level load and treated as read-only.
2. dynamic_hash (ObjectHash): Contains enemies, coins, and the player. Cleared and repopulated every single frame.

Why this approach?

• Performance: By keeping the static geometry in a read-only hash, we maximize cache efficiency and avoid the overhead of re-inserting thousands of wall tiles every frame.
• Separation of Concerns: This mimics industry standards used in engines like Unity and games like Celeste (which separates “Solids” from “Actors”). It prevents accidental modification of level geometry.

Implementation Details

Our SpatialHash class is a lightweight grid partitioner. It uses a dictionary to map integer cell coordinates to lists of objects.

1. The Grid Structure

We define a cell_size slightly larger than the average object. This ensures most objects sit in only 1–4 cells, keeping queries fast.

1
2
3
4
5
class SpatialHash:
    def __init__(self, cell_size=64):
        self.cell_size = cell_size
        # Maps (cx, cy) -> List[obj]
        self.contents = {}

2. Cell Addressing

We convert world-space float coordinates into integer grid indices using floor division.

1
2
3
def _get_cell_coords(self, position: Tuple[float, float]) -> Tuple[int, int]:
    x, y = position
    return int(math.floor(x / self.cell_size)), int(math.floor(y / self.cell_size))

3. Insertion

When an object is inserted, we calculate its Axis-Aligned Bounding Box (AABB) and add the object to every cell that the AABB overlaps.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
def insert(self, obj):
    target = obj.gObj if hasattr(obj, 'gObj') else obj
    if not target.active:
        return

    # specific AABB calculation
    start_cx, start_cy = self._get_cell_coords((target.x, target.y))
    end_cx, end_cy = self._get_cell_coords((target.x + target.width, target.y + target.height))

    for cx in range(start_cx, end_cx + 1):
        for cy in range(start_cy, end_cy + 1):
            cell = (cx, cy)
            if cell not in self.contents:
                self.contents[cell] = []
            self.contents[cell].append(obj)

4. Querying

To find nearby objects, we query a specific rectangle. To handle objects that span multiple cells (and therefore appear in multiple buckets), we use a set of seen_ids to ensure we don’t return duplicates.

Integration in MarioCore

PEAK integrates these instances directly into the core game loop.

The Static Pass (Level Load)

During _build_level_from_txt, we populate the static_hash. This includes ground, platforms, spikes, and goal tiles. Because this data never moves, we never clear this hash. This makes resolving player-environment collisions extremely fast (O(k_tiles)).

The Dynamic Pass (Update Loop)

Every frame, _rebuild_dynamic_hash() runs:

1. Clears the dynamic_hash.
2. Iterates through all active entities (Enemies, Coins, Powerups).
3. Inserts them into the grid based on their new positions.

This allows us to handle Entity-vs-Entity collisions (like a Shell hitting an Enemy) efficiently without checking the entire map.

Beyond Physics: Rendering

We also leverage the spatial hash for rendering optimization. Instead of sending every object to the GPU, _draw_entities_from_hash queries the dynamic_hash using the Camera’s view rectangle.

This serves as an effective frustum culling mechanism: if an enemy is not in a bucket overlapping the camera view, it is never processed for drawing.

Conclusion

By adopting the Dual Spatial Hash architecture, PEAK achieves a balance of simplicity and performance. We avoid the O_n² sorting trap, maintain clean code separation between world geometry and active actors, and gain a rendering culling system for free.