Town Centre: An AoE2 Tournament Desk with Local AI

Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle Submission 💸

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.

Town Centre is an organiser desk for small Age of Empires II: Definitive Edition 1v1 tournaments.

Picture an eight-player community cup. The first round has four series. One pair has agreed a time, another is waiting for a reply, one player has shared no availability, and two opponents cannot find an overlapping window.

That is the situation in Town Centre's fictional sample tournament. The organiser can see which matches need attention and take the next action from one dashboard.

The intended customer is a streamer or community organiser who runs tournaments repeatedly. My pricing hypothesis is $5–$10 per tournament for less scheduling administration. That price has not been validated, and I have not measured time saved or collected payments. An open-source app could still have a paid hosted service or event-support offering around it; the prototype does not implement either.

The next useful test is to put it in front of an organiser: can they arrange the first round more easily, and is the improvement worth paying for?

Demo video: Watch the Town Centre demo on Google Drive

The recorded walkthrough uses the fictional Castle vs Monk match to demonstrate the organiser workflow:

Testing: I recorded the sample workflow described above. Automated checks cover core rules, DOM-adapter interactions, and AI request/response contracts. This is a functional demonstration with fictional players; I have not measured general extraction accuracy, run a real customer tournament, or validated willingness to pay.

Source repository: Hornet-Wing/tourney-organiser

From the repository's project directory:

npm start Enter fullscreen mode Exit fullscreen mode Then open http://127.0.0.1:4173. The AI reader separately downloads its browser runtime and model when requested.

I developed the prototype with Codex, starting from the game and event format I wanted to support: AoE2 and competitive 1v1 tournaments. I kept the first version to eight players so the whole competition could be represented and tested.

The AI integration uses WebLLM with the open-weight Qwen2.5 0.5B Instruct model, through its MLC WebGPU build.

An organiser chooses a player, supplies their declared time zone and the message's reference date, and pastes that player's availability message. The model is asked for JSON containing complete availability windows and clarification questions.

Messages are pasted manually in this prototype. There is no automatic Discord import or channel monitoring. After arranging a match, the organiser can copy an announcement and post it to Discord themselves.

The implementation supplies an explicit JSON Schema string with the JSON-output request, validates the returned fields, converts valid local times to UTC, and presents the interpretation for review. Saving the reviewed output adds availability; it does not confirm or schedule a match automatically.

The first model load requires a substantial download and a compatible WebGPU device. Manual entry remains available throughout.

The rest of the workflow uses ordinary application rules:

Player message → local model extracts proposed windows → validation and organiser review → saved availability → code checks possible match slots → organiser proposes a time → organiser records player confirmations → manual result advances the winner Enter fullscreen mode Exit fullscreen mode For example, the application checks whether a complete reserved series slot fits within both players' availability. A proposed time change clears both confirmations. Later rounds must follow the reserved slots of their prerequisite matches.

The organiser supplies the estimated series duration, including drafts and breaks. That duration is a scheduling allowance, not an AI prediction of how long an AoE2 series will last.

The app rejects impossible local times during daylight-saving changes. For a local time that occurs twice when the clocks go back, it asks the organiser to enter the time in UTC instead.

The current suite has 26 passing tests: 14 core-rule tests, eight DOM-adapter interaction tests, and four AI request/response contract tests.

They cover daylight-saving cases, availability intersections, invalid scores, winner progression, imported backup validation, UI navigation, confirmations, event creation, and escaping player text.

The recorded walkthrough supplements these automated checks with a sample browser workflow. It does not establish compatibility across browsers or accuracy across different scheduling messages.

The World's Edge AoE2 tournament handbook informed the scheduling workflow. Individual events provide their own rules, maps, settings, and draft links.

Local inference is a useful fit for this particular customer.

Availability messages may contain players' personal schedules. The integration is designed to process those messages on the organiser's device, avoiding the need to send them to a hosted inference API. The browser still fetches runtime and model files, and the page requests external fonts; this is not a claim that the app makes no network requests.

There is also no per-message inference API charge in this architecture. That could make a small per-event service easier to operate, although device resources, download size, hosting, support, and maintenance still have costs.

Open weights and an open runtime make it possible to experiment with a larger model or change the extraction prompt without rebuilding the tournament rules. The small default model keeps the initial scope manageable, but its extraction quality still needs to be evaluated on real scheduling messages.

The tradeoff is hardware compatibility. Organisers without a suitable GPU can use manual availability, while the model-backed workflow needs a compatible device.

The project builds on lessons other developers have shared:

The next milestone is an organiser trial using scheduling messages shared with permission. A future Discord integration could reduce copying and pasting, but it is not part of the current prototype. I would measure incorrect interpretations and the organiser's remaining manual work before expanding the scope.

Town Centre currently stores data in one browser, has no player login or multi-organiser synchronisation, and requires results to be entered manually. No first-user feedback, sales, or partner-category eligibility is claimed in this draft.

The code and this draft were prepared with assistance from Codex. The author should review and verify the content before publishing.