Build a Video Game with AI in 2 Weeks — No Code

We create the base card prefab and review how it will work inside the project. This lesson prepares the main reusable piece for the rest of the game.

We build the base board where cards will be spawned and organized. We also prepare the scene so we can start adding gameplay logic.

We create a script that spawns multiple cards in a 3x3 grid inside the board. We also ask for beginner-friendly code comments to understand each part step by step.

We review the initial system and how the prefab, board, and spawner connect. The goal is to read AI-generated code with enough understanding to modify it confidently.

We introduce what MCPs are and why they help connect external tools with AI assistants. This gives Claude or Codex better access to Unity and the project.

We test the Unity MCP connection inside Claude and solve the first setup issues. Then we use the MCP to create objects, scripts, and scene configuration directly.

We check the MCP connection from Codex and see how it fits into the workflow. This lesson shows how to move between AI tools while keeping project access.

We add GitHub Desktop to the workflow to save changes and manage project versions. We also make a simple spawner change to validate the edit and version-control cycle.

We import the 3D card model and prepare it for use in the prefab. This gives the game its visual base before the logic grows.

We adjust the camera so the board and cards are framed correctly in the scene. The goal is to have a clear view for testing gameplay.

We configure the card dimensions so the system can calculate positions and spacing accurately. This keeps the level builder and board working with consistent measurements.

We build the first level builder system for painting cells, saving levels, and loading configurations. We also define how the board should adapt to the content created by the player.

We fix color application so cards use the correct material based on the level builder data. This connects the editor information with the game's visual output.

We improve the level builder to create vertical card groups with controlled spacing. We add deleting, drag painting, grid movement, and visible coordinates.

We adjust card positions, drawing order, text clarity, controls, and UI organization. We also start moving parts of the interface into real scene objects through the MCP.

We add support for horizontal chunks in addition to vertical ones. The lesson handles directions, rotations, and visual arrows so each card group communicates where it moves.

We implement creating, saving, reordering, and loading multiple levels. We also improve board scaling so it adapts to the actual content of each level.

We remove unused scripts, reorganize folders, and separate responsibilities between managers and UI objects. This makes the project easier to maintain as it grows.

We create a system that keeps the board visible based on each level's size. We also tune margin and padding values to avoid incorrect framing.

We add arrows to chunks so their movement direction is visible. We also fix rotations and placement so the arrow appears on the correct central card.

We implement chunk movement on click, including collisions, bounce feedback, and movement toward the board edge. The lesson also optimizes colliders for scenes with many cards.

We review the organization of scripts related to cards, chunks, and UI. The goal is to keep each class in the right folder with a clear responsibility.

We create the order system so cards leaving the board fly into color-specific slots. We also add animations, capacity limits, and replacement of completed orders.

We analyze how multiple simultaneous orders should work and what rules they need to follow. This lesson clarifies the expected behavior before more code is added.

We validate that levels generate card counts compatible with order capacity. We also make each order accept only its own color and display clearer information.

We fix issues with deleting chunks, selecting directions, and keeping chunks as valid chains. We also handle edge cases where too many cards or wrong arrows were generated.

We adjust the camera framing so it considers both the board and the orders. We also separate responsibilities so the board, orders, and camera are positioned cleanly.

We create the level completed screen and a UI for the current level. We also add a reserve object to handle leftover cards without breaking the order flow.

We polish the existing interfaces so they look clearer and work better inside the game. This lesson focuses on visual and usability improvements before adding more systems.

We refactor managers, level builder scripts, UI scripts, and the scene hierarchy. The goal is to keep the project ready for larger systems.

We introduce the reserve logic and how it should connect with the board, orders, and vertical framing. We also start adapting the scene for a portrait mobile experience.

We adjust framing so the board and orders stay properly visible. This reinforces the importance of calculating real bounds before moving the camera.

We adapt the interfaces to the game's vertical format. The focus is reorganizing screen elements so they work better on mobile.

We visually review how the reserve should behave in the gameplay loop. This helps define the expected result before implementing the belt.

We ask Claude to build a belt-like reserve with editable points, portals, and scene visuals. The lesson shows how to describe a complex Unity system for AI implementation.

We iterate on the belt to fix points, diagonals, portals, and visual rebuilding. We also make the system clearer and more editable outside play mode.

We fix cases when changing levels, clearing old presets, and keeping the belt aligned with its shape. This improves the reliability of the reserve system.

We correct points that were ending up away from the belt path. The lesson focuses on making the data and visuals match exactly.

We fix card rotation and scale inside the reserve so cards look natural while moving around it. We also hide arrows and reuse the board spacing values.

We split long belt scripts and reorganize hierarchy, managers, and tweens. This turns a fast-growing system into a more maintainable architecture.

We improve the animations for leaving the board, flying to orders or reserve, and collision feedback. The goal is to make cards move in sequence with clearer transitions.

We add controls to create, delete, and manage levels from the level builder. We also fix issues caused by many cards flying at the same time.

We adjust the card entry point into the reserve to avoid clipping. We also add preview and configurable offsets to fine-tune the movement.

We implement level looping so the game continues after the last available level. We also strengthen reserve and order logic for cards in flight.

We fix empty slot behavior and the order in which cards leave the reserve. We also differentiate gizmos and improve how tween points are read visually.

We start creating levels with AI using JSON files and persistent markdown rules. This lesson shows how to document learnings so AI can build levels more consistently.

We improve the rules so AI-generated levels are playable and use varied directions. We also correct existing shapes so they look better and can be solved.

We explore how to turn images into playable levels using a limited palette and reasonable resolution. We also adjust the UI for working with visual references.

We refine image-to-pixel and chunk translation so it respects the original reference more closely. The lesson fixes wrong interpretations and scale problems.

We fix cells without chunks, poorly saved rules, and communication issues with the guide files. We also improve the instructions so the AI remembers to update project documentation.

We generate new levels from images and fix color, multiple, and playability issues. The lesson shows how to iterate with AI until levels are recognizable and solvable.

We fix visual and usability problems in the level builder interface. The goal is to make level creation and editing more comfortable before moving to larger levels.

We change positioning logic to support levels larger than the original grid. We reposition the board, orders, and belt while keeping proper margins.

We polish belt presets, anchors, and camera frames so they work with large boards. This fixes cases where the path or framing ended up misplaced.

We use the new capabilities to create large levels from images. We also correct fills, silhouettes, multiples, and directions while preserving the reference and keeping gameplay valid.

We close the iteration on large AI-created levels. The lesson consolidates the workflow for generating, reviewing, and adjusting bigger content.

We build the visual interface for the main menu and review how it fits with the rest of the game. This prepares the entry screen before connecting logic.

We connect the Play button to load the gameplay scene and display the current level. We also start handling progress between the menu and the game.

We modify the system so a chunk can split if only part of it can go to orders or reserve. This prevents card loss and supports more complex level situations.

We adjust the gameplay UI so it does not cover important elements like the belt. The lesson focuses on balancing screen information with playable space.

We create or adjust the visual level completed screen. This prepares the end-of-level interface before adding logic and rewards.

We connect level completion logic with buttons, level progression, and dedicated controls. We also create a manager to centralize this part of the flow.

We build the game over screen and connect its main buttons. First we prepare the interface before deciding exactly when it should appear.

We add animation and juice to the game over screen using fades, scales, and configurable delays. The lesson shows how to ask AI for a more expressive UI sequence.

We apply similar animations to the level complete screen. We adjust entrances, delays, and button movement so the UI feels more polished.

We analyze when the player can run out of moves or space. This lesson defines the rules before implementing them in code.

We prepare the Need Space screen as a warning before game over. The idea is to give the player an option when the reserve is near its limit.

We implement periodic evaluation of the board, reserve, and orders. The logic decides when to show Need Space or Game Over without interrupting active actions.

We connect Need Space buttons, per-session limits, and transitions into game over. We also fix incorrect progression cases when returning to the menu.

We add a UI anchored to the entry portal to show reserve capacity. The system supports offsets and previewing the position outside play mode.

We add animations to the belt capacity counter when cards enter or leave. We also add feedback for capacity increases and keep simultaneous changes from breaking the UI.

We create a coin system with level rewards, a wallet, and coins flying into it. We also connect coin spending to actions like getting more space.

We adjust the level complete screen so coins fly to the correct wallet and show the level reward. We also polish the Claim button behavior.

We prepare the power-ups interface inside gameplay. This lesson sets up the buttons and visible values before connecting each power-up's logic.

We implement the extra order power-up using the existing coin system. We also respect simultaneous order limits and disable purchases when they should not be available.

We connect the increase reserve power-up with the same logic as the Get Space button. The lesson centralizes per-session limits so both paths follow the same rule.

We create the hint power-up to highlight a playable chunk with a green flash and animated hand. The system tries to choose the best possible move and cancel the effect when the player interacts.