post 1 of 6

Alicia 12-Player Modding Devlog

Development period covered: April 12, 2026 to July 27, 2026
Developer: CherryMakesGames
Main goal: Make Alicia support real 12-player local races, keep the setup practical to test alone, update everything to the current Story of Alicia code and resources, and track down the client crash at the end of a race.

Why I Started This

I am 18, and this project turned into a much bigger reverse-engineering job than I expected. The original target sounded simple: raise an eight-player race to twelve players. In reality, the player limit existed in several different places at once. The server protocol had limits, the room code had limits, the race-start code had limits, the client executable had hard-coded limits, and the finish UI appeared to have its own eight-entry allocation.

I also needed a way to test this by myself. Waiting for eleven other people after every small change would make debugging almost impossible, so I built a 12-client local test setup. It lets me reproduce a complete room whenever I want, test twelve separate accounts or client states at once, and see whether a change works for the host, ordinary players, finishers, DNFs, and late disconnects. It also makes repeated tests consistent instead of depending on different people joining each time.

The most important rule throughout the project has been reversibility. The base game executable stays clean, experimental patches are applied only to per-instance copies, resource-pack switching is controlled by a toggle, server compatibility work is behind config options, and I made full backups before the upstream update.

April 12: Building the Local Test Environment

My first major step was creating a proper local client installation and committing the test setup in the Story of Alicia repository. I added:

• Twelve client folders, from instances/client01 through instances/client12.
• One account entry per instance.
• Individual launchers for each client and a launcher for all twelve.
• A PowerShell launcher that creates and repairs each instance layout automatically.
• Separate writable log and _tmp directories for every client.
• Junctions and hard links for large shared game files so I did not need twelve complete copies of the whole installation.
• A 4x3 window grid so I can see all twelve clients on one monitor.
• An automatic Alt+Enter step to move clients out of fullscreen before tiling them.
• A dry-run mode for checking account paths, arguments, and instance layout without starting the game.
• A check that each configured local account has a matching server user record.

The launcher starts development mode with -GameID 2 and supplies each account’s username and password. I documented the required 127.0.0.1 aliciadev hosts entry because the development client connects to that hostname.

The reason each instance has its own Alicia.exe is that every copy needs binary patches, but I do not want to patch the clean base executable. On launch, the script reads the base executable, verifies the expected original bytes, applies the required modifications in memory, hashes the result, and writes only the instance copy. If the executable does not match the version the patch was designed for, the script stops instead of blindly corrupting it.

April 12 to April 15: Raising the Race Limit

The first server changes raised the protocol and room assumptions from ten or eight players to twelve.I changed AcCmdCREnterRoomOK and AcCmdCRStartRaceNotify so their racer lists accept up to twelve entries. I added validation that throws if the server tries to serialize more than twelve. I also changed room creation so Magic Team rooms resolve to twelve players instead of being clamped to eight.

I added a special loopback exception to connection throttling. All twelve clients connect from 127.0.0.1,