DEV Community

Cover image for One Coin, Two Tests: Check the Test Behind Your AI-Built Game Mechanic
Krishna Soni
Krishna Soni

Posted on Originally published at global.krizek.tech

One Coin, Two Tests: Check the Test Behind Your AI-Built Game Mechanic

A person holding a game controller; illustrative photograph
Photo by Sam Pak on Unsplash. Illustration, not a screenshot of the prototype.

A player touches one coin. The score rises by 10. The coin disappears.

That tiny mechanic is a useful place to start with AI-assisted game creation, because its promise fits into three observable facts. The interesting question comes next: would your test notice if the pickup logic stopped working?

Write the promise before generating the events

Here is a proposed acceptance scenario for a small, disposable test scene—not a claim about a shipped game:

Arrange: one Player, one Coin, Score = 0.
Act: move the Player into the Coin using gameplay input.
Observe: Score = 10 and the Coin no longer exists.
Continue: remain in that area for another second.
Observe: Score is still 10.
Enter fullscreen mode Exit fullscreen mode

The last observation matters. It distinguishes a single reward from an event that keeps adding points while a condition remains true.

Make the scene boring on purpose: flat ground, no other collectibles, no enemies and no passive scoring. Then a score change has a much narrower set of explanations. Use actual object and variable names in the prompt. Say what must stay unchanged, including movement and the reward value.

GDevelop's AI documentation describes an agent that can inspect project objects, behaviors, variables and events, and modify game logic. It also explicitly recommends specific requests and checking the work. That makes a small coin contract a more useful starting point than “build a complete platformer.”

Let the game produce the result

There is a crucial boundary between arranging a test and manufacturing its success.

Setting Score to zero establishes a starting state. Setting Score to 10 immediately before asserting that it equals 10 does not test collection. Deleting the coin from the test script would have the same problem: the test, rather than the pickup mechanic, produced the evidence.

GDevelop's gameplay-test documentation makes this distinction directly: arrange the situation, then assert; do not fake the thing being checked.

Availability caveat: the retrieved page labels gameplay tests experimental and says the feature will be available in the next release. Check your installed version before relying on the interface or APIs. The scenario here can also be run manually. No GDevelop project was executed for this article.

Check the check with a broken copy

On a separate disposable copy, disable only the coin-award event. Run the same test without changing its expected result.

It should now fail the exact-score assertion. If it still passes, investigate the setup: perhaps another event awards points, the scene carries old state, or the test changes the score itself.

Restore the event and run again. The point is not to collect a green badge; it is to show that the check responds to the behavior you care about.

Version under test Expected observation What it tells you
Intended pickup logic Score becomes exactly 10; coin disappears This scenario meets the stated contract
Award event disabled in a copy Exact-score assertion fails The check can detect this particular defect
Intended logic restored Original scenario passes again The baseline behavior is restored

This is a small mutation-style check, not proof of complete test coverage. A passing result says nothing yet about two coins collected together, scene restarts, saved progress or controller input. Add those as separate scenarios when they become relevant.

Keep design judgment in the loop

A correct pickup can still feel flat. The sound, animation, timing and placement need human playtesting. Conversely, a satisfying sparkle is not proof that the score changed correctly.

AI assistance is useful when it shortens the path from an idea to an inspectable mechanic. A compact acceptance contract helps you keep that speed without handing over the definition of “works.”

Which small game mechanic would you test first by deliberately breaking a copy?

Full KRI ZEK article on AI-powered game creation.

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)