The whole process of an AI narrative game from conception to shelving

QKPFX0 What does this project want to do?

Ember, an AI-driven continuous multiplayer narrative RPG.

Core idea: Players enter an apocalyptic wasteland world, all NPCs are driven by AI, and conversations are not preset scripts but generated in real time. The world ticks every two hours, and NPCs will act, form alliances, and betray themselves. Players can trade, steal, and spy among themselves. There is one chapter every 7 days, and four chapters are in a round, like a series that you can play.

Sounds cool, right? The question is how to make it happen.

backend first: FastAPI + AI engine

The back end is the first part to be formed and the most solid part of the entire project:

• FastAPI runs on port 8000, PostgreSQL stores world status, Redis caches
• Telegram Bot Make the first version of the interactive entry, polling mode
• AI Engine : Main Model + OpenAI Fallback
• APScheduler Triggers the world tick every two hours
• 5 regions, 5 camps, 7+ NPCs, 3 player identities
• is bilingual in Chinese and English

This set of things can run, and so can the quality of the dialogue generated by AI. But the question comes-what should we do about the front end?

Three front-end iterations

This is the most strenuous part of the entire project.

First Edition: Telegram Bot

The simplest solution. When users send messages in Telegram, Bot returns the AI-generated narrative text and option buttons.

The advantage is that the development cost is extremely low, and the disadvantage is that the experience is too word-risky. Without visual feedback and a sense of space, it is difficult for players to become immersed in this "world."

Second Edition: Next.js Website

I want to make a web version with maps, role cards, and dialogue panels. Deploy to Vercel using Next.js + Tailwind CSS.

After making it, I realized that this thing looked like a website, not a game. No matter how much you add animation effects and illustrations, you still have the div and flex layout in your bones. The first feeling when users open it is "This is a management backend", not "I want to take risks."

Give up decisively.

Third Edition: Phaser Pixel Wind RPG

In the end, I chose Phaser, the most mature HTML5 game framework. With Vite + TypeScript, the development experience is smooth (341ms cold start, 357KB gzip product).

This direction is in the right direction: pixel style is naturally suitable for indie games, and Phaser's tilemap, physics engine, and scene system are all complete.

zero-cost art engineering

The biggest headache for independent development is art. Hire a painter? The budget is not enough. Using AI to generate pictures? Different styles.

Final plan: CC0 open source material + Python automated processing .

I found a high-quality CC0 material pack-completely free, unified style of pixel wind characters and terrain. Then I wrote a Python script and used PIL to automate the processing:

• Terrain darkening : Reduce brightness and saturation, superimpose ash tones, and turn the bright adventure wind into the doomsday wasteland wind
• Character Variants : Use the hue rotation matrix to generate 10 visually different variants from 4 basic characters
• Particle Generation : Program transforms into ash and embers particle textures

Key parameters have been adjusted several times. The first version of the characters were so dark that they were almost invisible on a dark background. Finally, the ash tone was reduced from 10% to 5%, and the character's brightness was increased to 0.65-0.9 before reaching a balance.

programmatic map generation

The map is not drawn by hand, it is generated by a program. An 80×45 grid world with 5 areas with different styles.

The first edition has five rectangular color blocks, which are extremely ugly. Later, the organic shape was made with value noise:

• Elliptic distance + noise threshold : Make area edges irregular
• Bresenham Path + Random Swing : The path connecting the area naturally bends
• Deep sorting decorations : Trees, buildings, and rocks are sorted according to y-coordinate, with front and rear levels
• Water system : swamp ponds, rivers, coastline

Scenario Architecture

There are 6 scenes after the game runs:

• BootScene: Generating programmatic resources such as particle textures
• PreloadScene: Load all real material (10 characters spritesheet, terrain tilset, 4 BGM tracks)
• MainMenuScene: Main menu, ash particle background
• GameScene: Core World--tilemap terrain, decorations, NPC (with idle animations and interactive prompts), player movement
• ** UIScent : HUD overlay-area name, number of days, action point, tension*
• DialogScene: NPC dialogue pop-up window, typewriter effect + option branch

QKPFX28 How far has QK achieved?

milestone	content	state
M0.1	Project skeleton + programmatic placeholders	Completed
M0.2	Real material integration (character/terrain/BGM)	Completed
M0.3	Programmatic map + organic area + decoration	Completed
M1.0	Front-end joint debugging + AI dialogue	Put aside
M2.0	Multiplayer + PvP	Put aside

All technical verification passed: Vite hot updates are smooth, the 357KB product volume is controllable, Phaser's tilemap and physics engine are working normally, and the Python material pipeline can be released in batches.

QKPFX29 Why did QK stop?

When I was doing M0.3, I stood on the map and looked at the trees and houses generated by the program, and suddenly realized a problem: This project is not a fish or fowl .

Several fatal contradictions:

1. Art Ceiling : Zero-cost material can support a demo, but it cannot support a game that makes people willing to spend time. To achieve visually "beautiful", the investment required far exceeds expectations. Programmatic darkening can only be "not ugly" and cannot be "attractive".

2. gameplay complexity vs starting threshold : The system is designed very richly-camp, intimacy, PvP, chapter moderation, AI dialogue. But the first time a player opens the game and sees a pixel-like person standing on a dark map. Why should he spend the time understanding these systems?

3. Ambitious positioning : Words risk? You don't need a Phaser. Pixel RPG? That requires better art and level design. AI narrative experiment? Then Telegram Bot is actually enough. Each direction requires full commitment, but the project jumps sideways repeatedly between the three directions.

To put it bluntly: I want to do too much, but I can do too little well .

QKPFX33 What did QK gain

Although the project was shelved, several technical directions were fully verified:

• Python PIL batch material processing is really easy to use. Hue rotation, brightness adjustment, and batch generation variants can be directly reused for any pixel wind project in the future.

The - programmatic map generation idea (noise + elliptical distance + path carving) is applicable in many 2D game scenarios.

• Phaser + Vite + TypeScript This technology stack is really smooth. If you make more focused Mini games in the future, you can move them directly.

The backend design of the - AI narrative engine is reusable. World tick, NPC autonomous behavior, and dynamic dialogue generation, this architecture can still run with a more suitable front-end.

The biggest lesson: The biggest fear of independent projects is not technical difficulty, but divergence in direction . For every more "want to do", the workload will be doubled and the probability of completion will be half. Next time, you will nail the core experience first and cut off everything else.

---

This article documents the complete process from conception to shelving of a real project. Not a tutorial, not a best practice, just an honest review. If you are also making indie games or AI applications, I hope these detours will be of reference value to you.