Using GPT-6.1 Sol Medium to Reconstruct Fast Food Tycoon 2: An AIApplications Workflow Guide

When an AI application team asks what a model can add to a legacy-software investigation, the Fast Food Tycoon 2 reverse-engineering case provides a concrete pattern. GPT-6.1 Sol Medium was combined with Ghidra to unpack a 2001 business simulator first encountered among discounted mall games in 2004; the project turned 4,046 functions into about 9.5MB of C-like text, indexed that text in SQLite, and then inspected live Windows process memory through ReadProcessMemory. The notes that follow describe rendering, lighting, pedestrian rules, schedules, pizza scoring, and the originality check that marks copied recipes as not original.

The loop itself is easy to describe and unusually hard to fake. The player constructs a pizza empire inside a living isometric city by renting restaurants and warehouses, hiring staff, designing pizzas, and managing supply chains. Customers judge food, service, and reputation, while rival firms compete through advertising, political influence, and organized crime. That world fidelity is why the title seemed ahead of its time.

Step tutorial: embedding an AI agent in the reverse-engineering workflow

1. Use Ghidra to convert fastfood2.exe into 4,046 functions of C-like text, preserving function addresses, field offsets, constants, and calls in about 9.5MB of output.
2. Load the raw code into SQLite and add an index script so related functions can be located without reading enormous text. Example queries: decomp_index.py grep "0xe8\) =" finds field writes, decomp_index.py callers 0x4ed360 finds callers, and decomp_index.py string "fnt" finds font references.
3. Use ReadProcessMemory, the Windows API that lets the agent examine the running game and compare memory values to what appears on screen. This made it possible to find the memory address of cash, camera position, or selected building, then query the decompiled code for functions that changed those values.
4. Patch the Windows message handler so commands can run on the game's own UI thread. The agent could click buttons, move the camera, and advance the simulation without changing the executable on disk. An early breakthrough was a crawler that clicked through the interface and discovered the remaining unknown controls.
5. Guide the search with curiosity. After that step, the author and agent went digging through the renderer, lighting system, animation rules, schedules, and scoring logic.

The overworld, inspected from an application angle

A city is a painted backdrop plus a few hundred sprites. The captured example shows Berlin at 12:30. Beneath the fully rendered scene, the map file ber.tga contains streets, plots, and the Brandenburg Gate's shadow, but no buildings, people, or cars.

To draw the overworld, FFT2's renderer writes the scene into a memory buffer. It first determines which screen areas require repainting, such as where a person moved or when the camera position changed. It restores the background in those areas and redraws the scene on top. Each pixel stores a 16-bit colour value and a separate lighting byte.

The renderer performs several passes to decide which objects cover others, visiting map cells diagonally, or isometrically. To keep hidden people visible through walls, it marks their shape with a temporary pixel value before drawing objects over them. Later passes draw a yellow outline around hidden body parts and a white outline around hidden thought icons, then finally fill the visible parts. The renderer then combines each pixel's color with its lighting value and writes the final 16-bit display buffer, using a repeating dither pattern for intermediate shades.

An efficiency graphic highlighted pixels changed during the last 0.6sec, such as cars, walkers, swaying tree tops, and blinking signs. Most of the picture remains unchanged because the dirty-region system restricts repainting.

Lighting rules that turn values into visible product behavior

Daylight follows a table of 25 hourly brightness values: 70 at night, rising sharply around dawn to 251 during the day, then falling at dusk.

Lamps react to that light level. Their glow thresholds vary slightly by object IDs, so they turn on in small groups. Their light pools remain at least 160, so pavement patches stay bright through the night.

The id & 7 expression gives eight possible threshold offsets (0-7). Under FFT2's default brightness, standard lamps switch on around 18:25–18:30 and off around 05:35–05:40. Other object families use lower thresholds, so their glows appear later as the city darkens. The result supports a very satisfying day-night-cycle feel.

Each pizzeria stage has its own light mask, stored in files such as h_pizz_a1.m.spr. Each visible pixel in the mask holds a brightness value. The renderer compares that value with light already present at the same position and keeps whichever is higher, so windows and signs remain bright while the rest of the building darkens. A separate file, h_pizz_a1.l.spr, supplies window colours used at night. The renderer draws those colours, then applies the light mask; colour and light remain separate until the final screen step. These light-curve values can be altered by the brightness setting, producing formulas like light = base + (251 - base) * brightness.

The cast: animation rules inside .ani files

Anything that moves is stored in an .ani file, a sprite sheet plus named animation sequences. Much of the internal text encountered was written in German, the developers' language.

One frame-by-frame breakdown the author studied was an office worker eating in a restaurant. Since FFT2 is a pixel-based isometric game from 2001, every animation is pre-drawn.

The walker update logic compares the next node's position with the current one, then selects the direction animation from the two signs: (-,+) is 1, (0,+) is 2, (+,+) is 3, and so on.

A named animation sequence also stores how far the sprite moves each frame. For example, the waitress's gehen4 moves (+1.25, 0) each frame, while gehen3 moves (+0.884, +0.442). The tick adds that vector on every frame advancement, keeping feet and ground in sync.

Maps include predefined pavement nodes for walkers and street nodes for vehicles.

The speed hierarchy is also explicit. The errand boy is the fastest walker at 27px per second, ahead of the tourist at 16.2px/sec and the celebrity at 13.8px/sec.

Inside a branch: same pipeline, different constraints

The restaurant view uses the same rendering pipeline as the overworld: it draws flat images into a buffer and stores colour and light separately. Indoor light remains fixed at 248 whatever the hour, even though exterior daylight can reach 251.

This view uses larger, separate artwork for characters and a special draw order for seated people. When a chair back faces the camera, the renderer draws the main chair image, then the character, then the back of the chair, or the chair's front from the camera point of view.

A special sprite is used for pizza on the table. The animators can be forgiven for giving everyone the same eating pattern.

Hidden details list: habits, pizza scoring, and originality

The research uncovered many quirks, and a few favourites are worth listing.

• Citizens keep daily habits. When created, they receive schedules, and those schedules do not reset each day. An office worker assigned to a particular cinema for the afternoon keeps returning there. This likely contributes to the city's real feel.
• These schedules contain stereotypes: Goths stay home until 09:00; students have a 40% pub allocation for midnight–03:00; big shots have a 70% opera allocation for 18:00–21:00.
• The game calls itself Pizza3, and one city config file is named Init-File für Pizza3-Stadt.
• The pizza ability question is resolved. The game divides the pizza into 24 regions to score topping evenness, looks for matching pieces on opposite sides, and checks ingredient combinations; different customer groups receive different ratings.
• There is even a plagiarism check based on ingredient weights. Rearranging a competitor's pizza, a strategy the author definitely tried before, does not fool it. A copied recipe is marked not original and misses out on +30 taste points for yuppies, goths and tourists, plus +5 for big shots.
• All of that detail exists with very little in-game guidance. Since it was lost during a house move, the author recalls that FFT2 shipped with a ~100 page manual. That was back when games could be inherently challenging.

Reproduction note: font aliases and traceable labels

The images and videos used in this rewrite drew on some of FFT2's decompiled fonts. Some generated content still shows PC2, because the author also calls the game Pizza Connection 2, its European name. The PC2 label is therefore present in the material.

Common pitfalls and action suggestions

From an application perspective, the workflow offers reusable cautions rather than a generic model story.

• Do not start with the 9.5MB text directly. The project needed SQLite indexing to locate field writes, callers, and font references.
• Do not rely only on visible code. ReadProcessMemory connected memory values to on-screen events.
• Do not assume controls can be found by inspection alone. The crawler uncovered unknown interface elements by clicking.
• Do not expect rich in-product documentation. The game contained hidden schedules, scoring regions, and originality checks with little guidance.

1. Choose one observable subsystem first, such as lighting or movement.
2. Convert executable behavior into searchable code once; in this case Ghidra produced about 9.5MB from 4,046 functions.
3. Compare code evidence to live values with Windows process memory.
4. Operate the application through its existing UI thread when possible.
5. Document numeric thresholds, because small tables can create a convincing day-night feel.