DEV Community: Malaguo

Our publishing pipeline in engineering verbs

Malaguo — Mon, 31 Aug 2026 03:42:02 +0000

Publishing pipelines are usually described in marketing verbs, so here's ours in engineering ones — the actual sequence a build traverses on Malaguo from upload to earning page, written for people who distrust diagrams with too many smiling arrows.

Precondition. One ZIP, index.html at the archive root. That file is the contract: it's what browsers will load, so it's what review will judge.

1. Quarantine. The archive lands in isolation before anything inside it executes. The ordering is the security property: we inspect a static, contained artifact, never a live one. No "scan on first run" — no first run at all until inspection is done.

2. Static inspection. Structure and dependency review: what the build is made of, what it bundles, what it reaches for.

3. Runtime inspection. The build runs — inside containment — and its behavior gets watched: what it does, what it touches, what it tries.

4. Automated playability. Loads, runs, accepts input, is playable in the machine-verifiable sense. This gate protects reviewer hours from builds that crash at boot; it deliberately claims nothing about quality.

5. Human review. A person plays the exact artifact from the precondition. Version-scoped, not account-scoped: a new build means a new review, with no credit for your track record. This is also where our own AI studio's output queues — builds generated in-house from governed blueprints get zero bypass, because any pipeline with a trusted-origin fast lane will eventually ship its worst artifact down exactly that lane.

6. Approval gate. Binary and load-bearing: no public URL exists before it. Upload is not publish here; approval is.

7. Publication fan-out. Approval triggers the distribution build: a page for the game; whole-page translation into multiple languages — full page, not a title string — with each language version indexed for search separately; deployment to a global CDN; ad integration scoped to the game's own pages; and payout accounting attributed per game, the bigger share to the creator. Attribution scoped to your pages matters more than it first sounds: your revenue tracks your game's sessions, not a fraction of some sitewide pool.

Loop. Ship an update, re-enter at step one. Same gates, every version, forever.

Notes for the skeptical, since dev.to comment sections keep people honest: we publish no earnings estimates — revenue is a function of sessions and traffic mix, neither knowable for a game we haven't seen, and any platform quoting figures upfront is writing fiction. There's no listing fee, and no exclusivity — the same ZIP can stay live on itch, Game Jolt, your own domain, anywhere. Terms are public before account creation.

If you've shipped a browser game — or have a brief our AI studio could turn into a build that faces the same gates as everything else — the pipeline starts at:

https://malaguo.com/creator?utm_source=devto&utm_medium=social&utm_campaign=draw&utm_content=en_partnership&utm_id=social_01M11YZESH7J31AE2WP479YWVG

The browser became a game runtime and nobody updated their priors

Malaguo — Sun, 30 Aug 2026 02:38:35 +0000

The most consequential performance story of the last decade is one almost nobody wrote up: the browser quietly became a legitimate game runtime, and most developers' priors never updated.

The priors were earned. Browser gaming's first era ran on plugins and interpreted JavaScript: indirect rendering, unpredictable GC pauses, audio APIs that fought you. "Laggy web game" wasn't prejudice; it was measurement.

Then the measurements changed, component by component.

Rendering: WebGL gave pages a direct path to the GPU, and its successors have pushed that access lower still. Canvas stopped being the bottleneck; scenes that once slideshow'd now hold frame rate on integrated graphics.

Compute: JIT-compiled JavaScript got fast enough for most game logic years ago, and WebAssembly ended the argument for the rest — near-native execution for the hot paths, and a compile target that let entire native engines ship to the web.

The rest of the stack came along: real-time audio graphs, gamepad input, pointer lock, fullscreen — each a small standard, together a console-shaped API surface.

Hardware moved too. A mid-range phone from a few years back — the device your actual audience owns — runs a competent HTML5 game at full frame rate in a tab, with thermal headroom to spare. The floor rose under everyone.

What makes this professionally interesting is the asymmetry it created. Technical capability arrived; commercial infrastructure didn't. A store game gets a storefront, rankings, a discovery pipeline. A browser game gets a URL. Capability without findability produced today's odd landscape: a format that outperforms its reputation, full of good games no stranger has ever seen, built by developers who blame themselves for it.

That missing layer is the one my team operates — Malaguo; disclosure, this is where the pitch lives. We publish HTML5 games: you upload a ZIP with index.html at the root. Security is not vibes — the archive is quarantined before anything executes, structure and dependencies and runtime behavior get inspected, automated playability checks run, and a human plays the exact submitted version before anything gets a public URL. Approval triggers the commercial layer the format never had: per-game pages, whole-page translation into multiple languages, per-language search indexing, global CDN distribution, ad integration on the game's own pages, and payouts, with the bigger share going to the creator. No listing fee. No exclusivity — ship the same build everywhere else you like. Terms readable before signup.

If you benchmarked the browser years ago and filed it under "toys," rerun the benchmark. The runtime kept its side of the bargain. The missing half was never the tech — and the missing half is now on offer.

https://malaguo.com/creator

From plain-language brief to reviewable build

Malaguo — Sat, 29 Aug 2026 04:52:06 +0000

The most common objection we hear from developers about AI-generated games is also the best one: "so you're publishing unreviewed generated code?" No — and the architecture of that "no" is worth writing up, because it's the difference between a pipeline and a slot machine.

Malaguo has two intake routes. Route one is classic publishing: you upload a finished HTML5 ZIP. Route two is for people with no build: they write a plain-language brief — objective, mood, controls, difficulty curve, audience — and our AI game studio produces a playable version. Route two is the one that makes engineers squint, so here's how it actually works.

Step one: the brief becomes a structured design specification. Free-form prose is a terrible artifact to build from directly, so we don't. The spec pins down the entities the prose implied — what the player controls, what the loop is, what state matters, what winning and losing mean. Ambiguity dies here rather than at runtime.

Step two: the runtime is assembled from governed blueprints. This is the load-bearing design decision. The generative layer's job is choosing, configuring, and composing from a library of reviewed components — not free-handing arbitrary code that ships to players. Think of it as a model filling in a well-typed configuration for machinery that's already been audited, versus a model writing the machinery. Untrusted generated code doesn't get published, period.

Step three — architecturally the most important one — the output enters the same pipeline as a stranger's uploaded ZIP. Identical, not parallel: quarantine before anything executes, inspection of structure and runtime behavior, automated playability checks, then a human playing that exact build. We deliberately gave our own studio zero bypass privileges. Any pipeline with a trusted-origin fast lane eventually ships its worst bug through that lane; the only review gate that stays honest is the one with no exceptions, including for the house.

If the build passes, publication machinery kicks in like it does for any game: a page per game, whole-page translation into multiple languages, per-language search indexing, global CDN, ad integration on the game's own pages, payouts with the bigger share going to the creator. If it doesn't pass, it doesn't ship — in-house origin buys nothing.

Why build route two at all? Because "can code" and "can design a game people enjoy" are different skills that only sometimes cohabit. Route one serves people with both. Route two serves designers without the engineering half — the same population that engine ecosystems and no-code tools have been serving for years, but with a review gate at the end instead of an anything-goes export button.

For the developers reading this: route one is probably yours, and it's boring in the good way — ZIP with index.html at the root, no listing fee, no exclusivity, terms readable before signup. But if you've ever had a design idea you didn't feel like spending three months implementing, the paragraph door exists, and what comes out the other side faces the same judge your ZIP would.

https://malaguo.com/creator

subtract your friends from your analytics

Malaguo — Thu, 27 Aug 2026 16:20:09 +0000

Here's an uncomfortable query to run against your side project's analytics: subtract everyone who knows you.

Filter out the sessions from your own devices. Then the ones that arrived from your Discord server, your group chats, your coworkers' lunch-break courtesy plays, the traffic bump that maps exactly to the hour you posted in a community you're active in. What's left is your organic reach — players who found the game with no social connection to its developer.

For most shipped side projects, the remainder rounds to zero. If you've never run this exercise, it stings; run it anyway, because the two figures it separates are answering different questions. The friends-and-followers figure measures your likability and your posting schedule. Only the remainder measures your distribution — and if you never built distribution, that zero was determined before you wrote your first line of code.

It helps to spell out what "distribution" concretely is for a browser game, because the word sounds vaguer than it should. It's a page per game with stable markup a crawler can rank. It's that page translated — the whole page, not a title string — into languages you don't speak, then indexed per language, because your potential players mostly aren't searching in English. It's the build served from a CDN edge near the player instead of your single-region host. It's monetization attached to the game's own pages so sessions convert to revenue attributable to your game specifically. Each piece is unglamorous. Together they're the difference between a game that exists and a game that can be found — and none of it is reasonable to build and operate for one project, which is why solo devs never have it, and why their remainder is zero.

That layer is what we operate. Malaguo publishes HTML5 games: you ship us a ZIP with index.html at the root. The pipeline is deliberately paranoid — the archive is quarantined before anything executes, we inspect structure, dependencies, and runtime behavior, automated playability checks run first, and then a human plays the exact build you submitted. Nothing is published automatically; approval is what triggers the page, the whole-page translations, the per-language indexing, the CDN placement, the ad integration, and the payouts. The bigger share of what your game's pages earn goes to you. No listing fee, no exclusivity — your existing pages elsewhere stay up. Terms are readable before you create an account, and we don't do earnings estimates: revenue rides on sessions and traffic mix, and neither is knowable for a game we haven't seen.

If you only have a half-idea and no build, there's a second entrance — a plain-language brief our AI studio turns into a playable version via governed blueprints, which then walks through the same human review as everything else.

Then, a few weeks after your game is live, run the query again. The figure after the subtraction is the one we're in business to change.

https://malaguo.com/creator

https://malaguo.com/creator?utm_source=devto&utm_medium=social&utm_campaign=draw&utm_content=en_bottleneck