How we write and check our guides.

Who is writing?

These guides are published by Dashpop. We build the agent-native Dashpop Game Engine, so we have a point of view and a product interest. We also cover workflows that do not use our product.

AI assists with drafting and development. We do not present that work as a personal account from an invented author. Articles use the Dashpop byline unless a named contributor actually wrote them.

What the labels mean

• A guide explains a workflow or topic. Its scope note says what has and has not been tested.
• A workshop is an exercise for your own project. Example prompts are suggestions, not recorded generation histories.
• A decision guide helps compare approaches. A comparison method is not a benchmark result.

A measured result needs the actual versions, tasks, conditions, attempts, and evidence. We do not turn a provider’s general coding claim into a claim about game quality.

Lessons that teach

The game-design course uses original examples, interactive experiments, and exercises you can apply to your own project. We credit the literature where it informs an idea. The course is not a chapter-by-chapter retelling of a book, and its fictional playtest cases are labeled as teaching examples.

Interactive experiments isolate a relationship so you can inspect it. Their scores and simulations do not measure fun or predict real player behavior. A useful lesson explains both what an example shows and what it leaves out.

Sources and dates

Model and tool facts link to official documentation where possible. Sources support the specific facts they describe; they do not mean the vendor endorses this guide. Technical instructions depend on your tool version.

Publication and update dates should describe real editorial changes. We do not refresh dates just to make an old page look new. This collection was prepared on September 15, 2026.

How we study games

A deep dive asks a specific design question. We name the game and the part of its design we examine, link official material and creator accounts, and distinguish our interpretation from documented facts. We do not imply that a source-based article is a recorded playtest.

Interactive models use original art, layouts, and illustrative numbers. They explain a relationship; they are not replicas or measurements of the commercial game. A design observation does not establish what caused sales or retention. Game creators retain credit for their work.

What counts as proof?

A project opening is evidence that it opens. A successful export is evidence about that export. Neither proves that a game is enjoyable or that a model can repeat the result across different ideas.

When a story includes generated work, we explain what the model and the creator each contributed. Worked examples are labeled as exercises; measured comparisons include their method.

Name the tool and the task

Editor guides explain the steps you can take in Dashpop Editor. Guides for other tools name the application, prerequisites, and output so you can follow the right workflow.

A guide about Astra and Roblox does not mean Dashpop exports Roblox experiences. A character-production guide does not mean a coding model directly outputs a rigged mesh.

Corrections

If something differs in your version, keep the article URL, the tool version, and the specific step or claim. Those details make a correction useful. We will update affected guidance when we establish a change, and keep material limitations visible.