DEV Community

Cover image for Two Chests, One Key: Inspect the State Behind Your AI Game Prototype
Krishna Soni
Krishna Soni

Posted on Originally published at global.krizek.tech

Two Chests, One Key: Inspect the State Behind Your AI Game Prototype

Illustrative retro gaming hardware, not an AI tool demonstration

Photo by Lorenzo Herrera on Unsplash. Illustrative hardware, not a generated game.

Put two chests in a room. Give the player one key. Ask your game-making tool to open only the chest the player interacts with.

That tiny scene is a useful way to evaluate a generated prototype: can you inspect the state that explains what happened?

A playable result is exciting. An understandable playable result gives you something you can keep building.

Write the rule before looking at the animation

For this proposed test, the rule is deliberately narrow:

  • Both chests start closed.
  • The player starts with one key.
  • Opening chest A consumes that key and opens A only.
  • Trying chest B afterward leaves B closed.

These are design choices for the example, not universal rules for treasure chests. Some games intentionally use shared keys or unlock every chest together. The test only makes sense once your intended behavior is written down.

A suggested observation record looks like this:

{
  "step": "after interacting with chest A",
  "playerKeys": 0,
  "chests": [
    { "instance": "A", "isOpen": true },
    { "instance": "B", "isOpen": false }
  ]
}
Enter fullscreen mode Exit fullscreen mode

This is an illustrative record, not an engine export format or a claim that a particular AI tool produces it automatically.

Follow one instance, not just one object name

Two visible chests may be instances of the same object definition. A shared definition is useful: both can use the same artwork and interaction logic. Their changing state may still need to be separate.

If opening A also opens B, several explanations are possible. The rule might use scene-wide state where per-instance state was intended. The event might select both instances. Or the animation might be wrong while the stored state is correct.

A screenshot alone cannot distinguish those cases.

GDevelop's debugger documentation gives a concrete example of the visibility worth looking for. It describes inspecting global variables, scene variables and individual object-instance variables, as well as pausing a preview. Its instance list groups instances by object name and lets you inspect an individual instance.

That is a documented capability of GDevelop, not evidence that every prompt-to-game product offers equivalent access.

Take three snapshots

Use a disposable copy of the prototype and record the same small set of values at each step.

Moment Player keys Chest A Chest B
Fresh start 1 Closed Closed
After opening A 0 Open Closed
After attempting B 0 Open Closed

These are expected values for the proposed rule, not measured results. Run the actual interaction and compare the result; do not manually set the expected values and call that a passing test.

In GDevelop, the documentation says to use Refresh to fetch game data. Make that refresh part of your observation routine so you do not mistake an old inspector value for the current state.

Changing a variable in the debugger can be useful for exploring an edge case. Keep that separate from testing whether the ordinary player action produces the right transition.

Evaluate the correction path, too

If B opens unexpectedly, the next useful question is not simply whether another prompt fixes it.

Can you name the affected instance, inspect the relevant value and explain which rule changed? Can you repeat the interaction from a clean start after the correction?

That is a practical tool-selection criterion alongside time to first prototype. It is especially valuable when a small experiment becomes a project with more objects and more overlapping rules.

The broader source discusses AI game generators and an editorial ranking. Its testing totals and rankings are publisher-reported, not benchmarks independently reproduced here. This exercise does not establish a fastest or best tool; it proposes a small, comparable check for your own workflow.

Which state would you want exposed first in a generated prototype: inventory, quest flags, or individual object state?

Full KRI ZEK article.

Download Altered Brilliance: https://play.google.com/store/apps/details?id=tech.krizek.alteredbrilliance

Global website: https://global.krizek.tech

Pre-register for Arzenal Human Health: https://play.google.com/store/apps/details?id=tech.krizek.arzenal

Join The Power Of Gaming: https://discord.gg/sbYSPcCqJn

Top comments (0)