The Service Gap Behind AI-Made Games: Device Testing and First-Player Feedback

Games ship faster, but testing remains

One maker who could not write code directly made and published three games with AI assistance. Someone who might once have stopped at implementation can now reach a public page by describing an idea and selecting from the output.

There is an even shorter record. Japanese non-engineering maker yurukusa made three browser games in about two days and entered them in the AI Browser Game Jam. They said they wrote none of the code themselves. AI generated 3,317 lines of code, and the first game took 9 minutes and 11 seconds from concept to a runnable state.

Claude Pro’s published price at the time was US$20 per month. The game jam entry and browser release were free, so the cost of getting a small game into a runnable form came closer to one monthly subscription than to one expensive outsourcing engagement.

The AI Browser Game Jam required entrants to review other submissions. Its first round received 29 games and 96 reviews. By the third round, it had grown to 119 participants, 83 games, and 596 reviews. The published fourth-round schedule ran from July 31 to August 14, and that window has now closed.

There is also a route that remains open without a deadline. Steam Playtest, Valve’s testing feature for games on Steam, lets developers distribute free access to a test without affecting the main game’s user reviews or wishlists. It handles participant recruitment and access permissions, but it does not decide what to ask or organise the feedback for you.

Solo makers get stuck after pressing publish

The person followed in this article is a solo maker who published three browser games in about two days without writing code directly. yurukusa communicated the concept, checked that the generated code ran, made itch.io pages, and published them. That part can be done alone.

The problem starts when a link opens on a phone. The start button may appear in portrait mode, but the bottom of the game board may be cut off in landscape mode. In another browser, sound may not play from the start. A mismatch between the game’s screen size and the embedded play window on the public page can also create scrolling.

When this happens, the maker may photograph the problem screen on a phone, move the photo to a laptop, and explain the issue to AI again. After uploading a fix, they may need to restart the game from the beginning on the same device and repeat saving and restarting. Even with just three games, two types of phones, and two types of laptops, the same checks can repeat many times.

Browsers themselves create differences. Godot Engine’s guidance for exporting games to the web lists differences in graphics processing across browsers and operating systems, restrictions on automatic audio playback, limits on storage methods, and games pausing when the player switches to another tab. A game running well once on the maker’s laptop does not mean it will behave the same way on someone else’s device.

The work does not shrink after recruiting people. A 2024 study of small game teams interviewed 13 developers, and none had formally learned methods for researching user feedback. One participant said that about 80% of collected material might be unrelated to the current problem. Even 50 comments may contain only a small portion that is useful for an actual fix.

The needed service is not a tool that makes the game for you. It is a tool that takes a link, checks the start screen, game board, result screen, and public page across multiple screen sizes, and records the affected device and reproduction steps together. Instead of transcribing scattered photos and comments, a maker can see how many people encountered the same error and decide the order of fixes.

Some work still requires people. Whether controls feel fun, whether someone wants to play again after their first failure, and whether they understand the rules without explanation cannot be judged through screen comparisons alone. AI can propose a fix, but makers and real players must decide which problem to fix first and whether the game’s feel improved.

The early examples added testing as a separate layer

Spell Cascade made 143 manual adjustments after automated checks

Japanese maker yurukusa said they could not write a single line of code themselves and published Spell Cascade, a browser game whose code was written by AI. The maker directed the game rules and the feel of its techniques, played it directly, and gave feedback such as that the attack range felt too short.

During this process, 26 automated checks ran and 143 manual adjustments were applied. The ability to make a game quickly did not automatically produce release quality. This example shows that hands-on play and selection work remained more frequent than generation itself.

Focaccai turned participants into reviewers at the same time

The Focaccai AI Browser Game Jam, which accepted global participants, took browser games that could be played for free and charged no entry fee. It did not require a particular creation tool. By having participants play and review other people’s games, it gave makers without a separate advertising budget a minimum set of first players.

The first round’s 29 games and 96 reviews meant an average of roughly three to four reviews per game. The third round collected 596 reviews for 83 games. A record-keeping tool that can be used repeatedly across public events may last longer than a tool attached to one specific game jam.

PlaytestCloud captures the play session itself

Germany’s PlaytestCloud recruits players who match a game team’s conditions and delivers game footage, player voice recordings, and survey responses. Its published starting professional price was US$1,025 per month on annual billing, about KRW 1.38 million, putting it closer to teams with a release budget than to people making games alone as a hobby.

Berlin-based three-person team Sonderland Games gave Bella Wants Blood to people who liked tower defence and repeat-progression genres several times. After players spent about three to five hours each with the game, the team found that boss fights felt too similar to ordinary sections and changed the work order before release. No revenue-growth figure was published, but the process for deciding what to fix is specific.

Four small things to build now

1. Device-by-device browser game run checks

• What it does: Takes a game link and checks whether buttons, the game board, and result screens are cut off or overlap across phone and laptop screen sizes.
• Who uses it: A solo maker who made a first browser game with AI and has only run it on their own laptop.
• Why now: Game-making time has fallen to days, but device-specific checks still require people to repeatedly open the same scenes.
• First screen: Place a game URL field beside check buttons for phone portrait, phone landscape, and laptop.

2. Public-page release inspection

• What it does: Checks not only the game file but also whether the title, cover image, play-window size, control instructions, and start button display correctly on the public page.
• Who uses it: A hobby maker uploading a first game to itch.io and unsure which settings to choose.
• Why now: Publishing without installation is easier, but players can leave before their first play if the game window or instructions are wrong.
• First screen: Under the public-page URL, show four items: “Runs immediately,” “Landscape works,” “Controls are visible,” and “Can restart.”

3. A five-first-player exchange

• What it does: When a maker plays five other games and leaves feedback, their own game is assigned to five people.
• Who uses it: A maker with no advertising budget or existing player community who needs first reactions from strangers rather than praise from family.
• Why now: The reciprocal-review model of game jams worked, but test opportunities close when recruitment periods end.
• First screen: Before “Register my game,” show one game to test today and the time remaining to complete it.

4. Error reproduction cards

• What it does: When a player presses a problem button, it bundles the device, browser, screen orientation, preceding actions, and screen recording into one error card.
• Who uses it: A solo maker who receives a comment such as “the screen looks strange” but cannot reproduce the issue on their own device.
• Why now: Before asking AI to make a fix, the maker needs an accurate description of what broke and under which conditions.
• First screen: Show a “Press when the problem happens” button with a note that the previous five actions will be recorded.

What to check in 30 minutes today

Open five browser games on itch.io on a phone, and rotate each once between portrait and landscape. If two or more show at least one of these issues—cropped game boards, missing start buttons, absent control instructions, or failed restarts—it is worth exploring a device-specific release-checking service further.

Why this matters where you are

Check whether people making browser games in your market can quickly test their work on real phones, browsers, and public game pages. Recruitment channels, platform rules, and pricing may differ from the examples here, but the underlying work remains the same: reproducing device-specific problems and turning early feedback into a clear order of fixes. You can begin by testing a small set of public browser games yourself and recording the failures that recur.