标签：#phaser

There is a big difference between a game prototype that technically works and one that feels like a game. Movement, spawning, upgrades, and collision can be built with colored rectangles. That is often the right way to start. But the moment you want an animated player, a family of enemies, weapon variety, collectibles, and a consistent visual identity, the art pipeline can become the project. For a recent experiment, I wanted to see how far I could get by combining three tools: Phaser 3 for the game runtime Codex for implementation and iteration SpriteShip for game-ready visual assets through its MCP/API workflow The result was Last Light , a top-down survival game that runs in desktop and mobile browsers. It has an animated player, multiple enemy families, a large humanoid with separate walk and attack animations, sixteen weapons, sixteen collectibles, upgrades, an objective, and a boss encounter. Play Last Light: https://spriteship.github.io/sample_games/last-light/ Browse the source repository: https://github.com/spriteship/sample_games More importantly, it became playable through a surprisingly natural loop: describe an asset, generate it in SpriteShip, inspect or revise it, and let Codex wire the exported data into Phaser. Starting with gameplay, not presentation The first version was intentionally plain. It established the systems that mattered: Top-down movement Automatic targeting and firing Enemy spawning and difficulty progression Experience drops and upgrades Desktop and touch input A camera following the player across a large map That gave us something useful to evaluate. Once the loop was playable, every art decision could be judged in motion rather than in isolation. This order mattered. SpriteShip did not have to invent the game design; it could supply assets for systems that already existed. Creating a coherent project in SpriteShip Instead of making unrelated images one at a time, we created a top-down overhead project in SpriteShip. That project co

I initially wanted to **make a side-scrolling game like MapleStory**. YouTube was flooded with "I made a game with AI (Claude)," so I thought it would be easy. But when I tried it myself – it turned out that **people with existing game development knowledge were just using AI to improve quality and speed**, not that you could just "make it for me" without any knowledge. In the end, what I completed wasn't a playable game, but an **"auto-battle" spectator game** (like raising a mushroom) that you just watch. This post is about that **honest journey** – where I got stuck, why I pivoted, and what I learned. (And you can try out the completed version via the **🎮 Play Now** link below.) I'm a developer in Korea building an AI chatbot alone. I only write about things I've **actually tried and experienced**.## 1. The First Wall — AI-Generated Characters Can't 'Walk' **Moving characters** are essential for games like MapleStory. So, I first tried **AI image generation (gpt-image) to create chibi characters** and then generated walk cycles (4 frames of walking animation) for them. This is where I got stuck. **With each frame, the character subtly became a different character** – the color of the clothes, the proportions, the face all changed slightly between frames 1, 2, 3, and 4. When stitched together in a game, the character wouldn't walk; it would just **tremble erratically.** The Ceiling of Character Animation — AI Generation vs. Pre-made Sprites ❌ AI-Generated Characters (Re-imagined each frame) 🧍1 🧎2 🕴️3 🧍4 → Clothing/proportions wobble each frame = 'Trembling' instead of walking ✅ Pre-made CC0 Sprites (Hand-drawn sheet) 🏃1 🏃2 🏃3 🏃4 → Consistent frames = Smooth walk cycle This is **exactly the same ceiling** I hit in Making AI Videos (Dev Log #3) – AI image generation **cannot create consistent character animation (multi-frame movement).** The same wall in videos, the same wall in games. 2. Pivot ① — Abandoning AI Characters for Pre-made Sprites So, my first surrender