From Prompt to Playable: Building a Phaser Survival Game with Codex and SpriteShip

Building a Phaser Survival Game with Codex and SpriteShip

Creating a playable game goes beyond simply constructing the underlying mechanics. While basic movement, spawning, upgrades, and collision can be achieved with simple shapes, adding animated characters, multiple enemy types, weapons, collectibles, and a cohesive visual style requires a more comprehensive approach.

In a recent experiment, the author sought to explore how far they could push the creative process by combining three tools: Phaser 3 for the game runtime, Codex for implementation and iteration, and SpriteShip for generating game-ready visual assets through its MCP/API workflow.

The outcome was a top-down survival game called "Last Light," which functions seamlessly across desktop and mobile browsers. Featuring an animated player, various enemy families, a large humanoid with distinct animations, sixteen weapons, sixteen collectibles, upgrades, objectives, and a boss encounter, the game showcases the potential of this toolset.

The development process began with a plain version of the game, establishing essential systems such as top-down movement, automatic targeting and firing, enemy spawning, experience drops, upgrades, desktop and touch input, and a camera following the player across a large map. This foundation allowed the team to evaluate the game's core gameplay mechanics before diving into the art process.

SpriteShip proved instrumental in generating assets for the game's systems. By creating a top-down overhead project in SpriteShip, the team ensured a consistent visual identity across characters, enemies, weapons, and collectibles. From there, they followed a structured selection process, generating options, refining assets, and adding animation states.

This approach proved efficient, with SpriteShip returning structured animation data, including atlas frames, FPS, looping behavior, source sizes, previews, and collision-body definitions.

The integration of SpriteShip animations into Phaser proved straightforward, thanks to Phaser's built-in atlas support. The loader only required the sheet and its JSON metadata, enabling the creation of animations for the player and various enemies. The collision data provided by SpriteShip also proved valuable, as it offered normalized rectangular collision bodies for individual animation states.

This data was converted into rotated world-space rectangles within Phaser, allowing for accurate collision detection tailored to each enemy and enemy animation state.

One of the key advantages of this workflow was the ability to make art decisions based on live gameplay evaluation. By adjusting assets in the SpriteShip dashboard and re-fetching them for incorporation into the game, the team could quickly iterate and refine the visual elements without the need for manual rebuilding or guessing. This streamlined process fostered a smooth division of labor, allowing the human artist to focus on visually editing assets while Codex managed the integration and synchronization of files.

Throughout the project, the team encountered several valuable lessons. One notable insight was that two 256×256 frames may not always represent the same visual size. By measuring the visible pixel bounds of the player's walk and idle animations, the author discovered discrepancies in the character's footprint between states. Adjusting the idle frame to match the walk frame's dimensions resulted in a more consistent visual appearance without sacrificing source detail.

Overall, this experiment demonstrated the potential of combining Phaser, Codex, and SpriteShip to create a playable game efficiently. By leveraging the strengths of each tool and establishing a natural loop of asset generation, inspection, and integration, the team was able to produce a functional and cohesive game. The experience underscored the importance of evaluating art decisions in motion and the benefits of using structured data to streamline the development process.