Choose your genre (pick one). 

Design and submit a playable prototype package in one of three genres.  The prototype must be single-player and built for portrait orientation and must not make any external network requests while running.

1. Survival & Resource Management
   A prototype where a player gathers, crafts, and survives escalating threats. The player collects resources, converts them into tools or defenses, and stays alive as pressure ramps.
2. Simulation & Management
   A prototype where a player repeatedly invests, harvests, and upgrades loops with visible growth. The player makes choices, sees the system respond, and optimizes over time.
3. Tower Defense & Strategy
   A prototype where a player builds and manages defensive systems with unit variety, escalation, and an economy. The player places or manages defenses against waves that get harder.
   
   

What to Submit (three artefacts)

• Playable Prototype Build - A genuinely playable prototype of one core game experience using any AI tool. Builds must be generated by prompting in your chosen AI tool (Minor hand coding to fix bugs or to tune are fine - the build log should show the AI did the heavy lifting). Here is the Design Guidance.
  • Submit your prototype as a self-contained Three.js / HTML5 build. It must meet all of the following:
    • Package. A single .zip file, no larger than 35MB, with index.html at the top level of the .zip and not inside a folder.
    • Your game code. Your submitted index.html must contain all of your own game code, in readable, unminified form. You may develop across as many source files as you like, but you must assemble them into a single index.html before you submit.
    • Third-party libraries. Libraries such as Three.js must be included in the .zip inside a folder named vendor, and referenced with relative paths. Do not embed them in index.html.
    • Everything else your game needs. All assets, fonts, images, audio and data must be included in the .zip and referenced with relative paths.
    • No network access. The build must not make any external network request while it is running.
      
      Builds that load resources from external URLs, including content delivery networks (CDNs), will fail validation.
  • Your prototype must let a player actually play a core loop, not click through screens. It should at minimum have:
    • A primary action the player takes. What does the player do repeatedly? Why is it satisfying?
    • A goal, and a win / lose / reset state so it feels like a real session.
    • Real-time feedback so the player knows they are doing well or badly.
    • Progression or escalation so a session builds instead of repeating one static state.

• Design-Intent Document (500 words max, text-only, .docx) - A document that explains to the judges: who the players are, what the game is, what the prototype contains, and your future-state vision. It gives judges context; it is not the basis of ranking. It must not include your name or other identifying information. Here is the template for Design Intent. 
• Build Log (.md) - A running record you keep as you build: the decisions you lock and what happens each session. It shows your prototype was built with AI. Required, but not scored. Here is the guidance for Creating and Maintaining a Build Log.

All text in the submission, including the design-intent document, must be in English.