A Non-Coder's Brotato-Style Roguelite on a 2013 Laptop: What the Garlictos Maker Reports

According to the maker's own posts, the answer to "can AI make a Brotato clone in Godot with no coding?" is a qualified yes. A self-described non-coder shipped Garlictos, a Brotato-style wave survival roguelite, to Google Play. They built it in Godot 4 with Gemini on a 2013 laptop. The same posts show that "no coding" still meant a lot of debugging. They also show that getting players, and keeping them, was harder than building the game.

This specimen reads the maker's three dev.to posts side by side. It separates what the maker says they did from what their numbers show, and it points out where the posts don't agree.

The project in brief: Garlictos, a survivor roguelite for Android

The maker posts on dev.to as Orlalalala. Their main post on building the game describes Garlictos as a Brotato-like wave survival roguelite. It was made in Godot 4 and released free on Google Play. All credit for the game and the write-ups goes to them. The Play Store listing is linked from their posts, and readers who want screenshots or footage should look there and in the original posts.

The maker is open about where the game came from. They say it started as a near-clone of Brotato. Over time they added features to set it apart:

• active character skills
• permanent upgrades between runs
• weapon merging
• danger levels, which arrived with the 1.9 update along with three new characters, daily login rewards and quests

The main post says the graphics are AI assisted. It also describes the ads: full-screen ads after waves 8 and 14, plus optional rewarded ads.

Why Godot on a 2013 laptop?

The maker says they worked on a laptop with a GTX 660M GPU. They write that Unity and Unreal ran badly on it, so they chose Godot because it was free and light.

They also mention that Brotato was made in Godot, and they quote a figure of $17 million in earnings for it. That number is the maker's claim. The sources read for this piece don't confirm it, so treat it as motivation for their choice rather than as a fact.

The main post says the maker learned Godot from tutorials first and added AI help after that. That order matters. The maker wasn't starting from nothing inside the editor when AI-generated code started arriving.

The account of hardware limits comes from the maker alone. It isn't a benchmark, and the post gives no frame rates, load times or editor performance figures. What it does support is a practical point: an engine your machine can actually run beats a more powerful one it can't.

How was the AI used, and where did it fail?

The main post says the maker used Gemini through Google Antigravity because it was nearly free. They put their total AI subscription spend at about $20.

The post isn't a success story about the AI. The maker reports that the AI claimed to have fixed bugs it hadn't fixed. At one point the debugger showed 1,431 errors. They describe learning by repairing what the AI had broken, and say the AI explaining its code became a large part of how they learned.

So "zero coding skills" in the title means zero at the start. By the maker's account, they couldn't ship without learning to read and fix GDScript along the way.

The posts back a modest claim. A motivated beginner with an AI assistant can get to a working Godot game. That beginner still has to check every "fixed it" the model reports. The posts don't include prompts, project files or code, so it's impossible to say which tasks Gemini handled well and which it handled badly.

If you want fewer made-up fixes, two guides on this site are a sensible next step:

• making the game legible to the agent, which covers giving an assistant clear project context
• installing the godot-ai MCP server, which covers deciding which editor tools an agent may write to

For checking an agent's claims against the running game, see the test plan in Can an AI Agent Playtest Your Godot Game?.

Shipping and marketing: what numbers does the maker report?

The three posts cover different stages and give different figures. Here they are side by side, as the maker reports them.

The first campaign

The main post says the 5,000 downloads came mostly from countries where phones couldn't run the game well, which led to a high crash rate. The maker puts total costs at about $20 for AI and $50 for ads, against roughly $5 of income over two months.

The App campaign

The Google Ads post gives tighter numbers. The maker also passes on two lessons about how the campaign billed. They say App campaigns charge for clicks rather than installs, and that the daily budget is an average rather than a hard cap. Solo developers should check both points against Google's own documentation before setting a budget.

The same post gives a day-one funnel from GameAnalytics:

1. 51 players started wave 1.
2. 38 reached wave 2.
3. 23 reached wave 3.

That means more than half of the players who started had dropped out by wave 3.

Retention by country

The 1.9 post breaks retention down by country:

• Iraq, India and Bangladesh returned at 3-4% on day 1.
• Iran, Turkey, the Philippines and Germany returned at 15-20%.

The maker also reports that after an Oct 1 update, 43-58% of players reached wave 5.

The lesson that holds up across all three posts is that cheap installs from the wrong places didn't become players. The low cost per install in the first campaign mostly bought devices that crashed or players who left.

Where don't the posts line up?

Read together, the posts leave several questions open.

Who is the maker? The main post describes a 35-year-old. The ads post says "I'm a student." The two can both be true, but the posts don't say so.

Which campaign is which? The main post reports about 5,000 downloads for around $50 of ads. The ads post reports 133 installs for about $46. These may be two separate campaigns with different settings. The posts don't reconcile them, so treat every figure as self-reported.

How literal is the tone? The main post is comic and exaggerated, including a joke about income of fractions of a cent per day. Treat its numbers as the maker's rough account, not audited data.

Can the no-coding claim be checked? No. None of the posts share the code, the project files or the prompts, so the claim rests on the maker's word.

How close is it to Brotato? Very close in concept. The maker says so plainly and lists the mechanics they added to set it apart. Readers can compare the two games themselves.

Verdict: who is this specimen useful for?

Useful for:

• Non-coders on weak hardware who want evidence that Godot plus a cheap AI assistant can lead to a shipped Android game.
• Solo developers who want an honest look at small-budget mobile user acquisition, including the parts that didn't work.

Less useful for:

• Readers who want a technical walkthrough. The posts don't include one.
• Anyone who needs verified performance, revenue or retention data.

Three takeaways follow from the posts:

1. Choose the engine your hardware can run. Godot's light footprint is the reason this project exists at all, by the maker's account.
2. Expect to debug AI output. The 1,431-error episode and the false "fixed" claims are the most useful details for beginners.
3. Plan for retention and targeting before buying ads. Country targeting and early-wave drop-off shaped the results more than the cost per install did.

For other projects where AI did much of the build, see Poke Party and Penguin Smack. More Godot coverage is on the Godot tag page.