Game dev

Cum publici un joc HTML5 pe portaluri: CrazyGames, Poki și build-urile duale

Publicat 10 iulie 2026 · 7 min citire

Cel mai greu lucru la un joc în browser nu e să-l construiești — e să-l vadă cineva. Site-ul tău pornește de la zero trafic; portalurile de jocuri (CrazyGames, Poki, GameDistribution) au deja zeci de milioane de jucători și împart cu tine veniturile din reclame, de obicei în jur de 50%. Concluzia la care am ajuns cu Neon Arcade: site-ul propriu e platforma, portalurile sunt distribuția — și ai nevoie de amândouă. Articolul acesta descrie exact cum livrăm același joc în ambele lumi dintr-un singur codebase, fără două versiuni de întreținut.

De ce nu poți urca pur și simplu build-ul de pe site

Portalurile au reguli stricte, iar cele două care schimbă arhitectura sunt:

Fără linkuri externe. Jocul rulează în iframe-ul lor și nu are voie să trimită jucători în afară — nici către site-ul tău, nici către pagini de privacy proprii. Butonul nostru „înapoi la arcade" trebuie să dispară complet din build-ul de portal.
Fără monetizare proprie și fără conturi terțe. Pe site vindem jetoane prin Stripe și ținem progresul în Firebase. În portal, ambele sunt interzise: monetizarea se face exclusiv prin SDK-ul portalului (reclame recompensate), iar progresul stă în localStorage.

Deci ai nevoie de două build-uri cu comportamente diferite la fiecare punct de contact cu banii și cu identitatea — dar dintr-un singur cod, altfel îți dublezi costul de mentenanță pentru totdeauna.

Arhitectura build-ului dual

Soluția noastră, cu Vite și TypeScript, are trei piese:

1. Un flag de compilare

Build-ul de portal se face cu o variabilă de mediu (PORTAL=crazygames npx vite build) care setează un define global. Tot codul poate întreba IS_PORTAL la compile-time, iar bundlerul elimină ramurile moarte — build-ul de portal nici măcar nu conține codul de Stripe sau Firebase.

2. Module interschimbabile

Punctele de contact sensibile — portofelul de jetoane și navigarea către hub — trăiesc în module cu aceeași interfață publică, în două variante: wallet.ts / wallet-portal.ts, back-to-arcade.ts / back-to-arcade-portal.ts. Un plugin de Vite face schimbul la build. Restul jocului nu știe și nu-i pasă în ce lume rulează: cere „deblochează personajul", iar dedesubt asta înseamnă fie o tranzacție de jetoane pe server, fie o reclamă recompensată prin SDK-ul portalului.

3. Curățenia HTML-ului

Același plugin șterge din index.html al build-ului de portal linkurile de privacy/terms și orice navigare externă, și șterge fișierele aferente din output. Înainte de orice submisie rulăm un „purity check" simplu:

grep -c "firebase\|numele-domeniului-tau" dist-crazygames/assets/*.js
# trebuie să afișeze 0

Dacă grep-ul găsește ceva, build-ul nu pleacă. E un test de trei secunde care ne-a scutit de respingeri.

Adaptorul de SDK: o singură interfață pentru toate portalurile

Fiecare portal are SDK-ul lui, dar toate vor cam aceleași semnale. Le-am ascuns după o interfață unică — pe site toate funcțiile sunt no-op, în portal deleagă către SDK-ul real:

portalInit() la pornire și loadingStop() când apare meniul — portalurile își măsoară timpul de încărcare și penalizează jocurile lente;
gameplayStart() / gameplayStop() la granițele unei runde;
midgameAd() între runde — niciodată înainte de prima rundă; prima impresie a jucătorului nu trebuie să fie o reclamă;
rewardedAd(): Promise<boolean> pentru bonusuri alese de jucător — resurse extra, revive, deblocări;
onAdMute(cb) — cerință de portal: audio-ul jocului trebuie tăiat pe durata reclamei.

Detaliu util pentru testare: SDK-ul CrazyGames rulează în mediu „local" când jocul e servit de pe localhost și simulează reclamele — vezi fluxul complet fără să fii publicat. Poți valida integrarea înainte de submisie.

Submisia: cum arată procesul pe fiecare portal

CrazyGames — submisie deschisă, cel mai bun punct de start. Arhivezi conținutul folderului de build (index.html la rădăcina zip-ului), adaugi un cover 1920×1080, nume, descriere, categorie, controale. Review-ul durează câteva zile și e non-exclusiv.
Poki — aplicație curatoriată; preferă jocuri proaspete, deci aplică devreme, nu după ce jocul e vechi. SDK propriu (încă un caz în adaptor). Acceptarea e selectivă, dar traficul merită.
GameDistribution / itch.io — mai târziu: GD sindicalizează către sute de portaluri mici, itch e bun pentru prezență și feedback.

Economia: ce câștigi de fapt

Pe site-ul propriu păstrezi ~97% din vânzările directe, dar aduci singur fiecare jucător. Pe portaluri primești ~50% din veniturile din reclame, plăți lunare cu praguri mici, dar jucătorii vin singuri. Nu e o alegere — e o secvență: portalurile îți aduc volumul și numele, site-ul tău monetizează fanii. Build-ul dual e prețul tehnic al acestei strategii, și e surprinzător de mic odată ce arhitectura e la locul ei.

Checklist înainte de prima submisie

Build de portal separat, cu flag la compile-time, nu cu if-uri la runtime.
Zero Firebase / conturi / Stripe / linkuri externe în build-ul de portal — verificat cu grep, automat.
SDK-ul portalului integrat prin adaptor: loading, gameplay, midgame, rewarded, mute.
Nicio reclamă înainte de prima rundă.
Progres în localStorage; jocul complet jucabil fără cont.
Cover 1920×1080 + descriere + controale pregătite pentru formular.
Fluxul de reclamă simulată verificat local înainte de upload.

Construiești un joc în browser și te gândești la distribuție? Jocurile noastre sunt pe games.hashcoreai.com, iar la contact@hashcoreai.com răspundem cu plăcere la întrebări despre proces.

The hardest thing about a browser game isn't building it — it's getting anyone to see it. Your own site starts from zero traffic; game portals (CrazyGames, Poki, GameDistribution) already have tens of millions of players and share ad revenue with you, typically around 50%. The conclusion we reached with Neon Arcade: your own site is the platform, portals are the distribution — and you need both. This article describes exactly how we ship the same game to both worlds from a single codebase, with no second version to maintain.

Why you can't just upload your website build

Portals have strict rules, and two of them reshape your architecture:

No external links. The game runs in their iframe and must not send players away — not to your site, not to your own privacy pages. Our "back to arcade" button has to disappear entirely from the portal build.
No own monetization and no third-party accounts. On our site we sell tokens via Stripe and keep progress in Firebase. On a portal, both are forbidden: monetization happens exclusively through the portal's SDK (rewarded ads), and progress lives in localStorage.

So you need two builds with different behaviour at every money and identity touchpoint — but from one codebase, otherwise you've doubled your maintenance cost forever.

The dual-build architecture

Our solution, with Vite and TypeScript, has three pieces:

1. A compile-time flag

The portal build runs with an environment variable (PORTAL=crazygames npx vite build) that sets a global define. Any code can check IS_PORTAL at compile time, and the bundler eliminates dead branches — the portal build doesn't even contain the Stripe or Firebase code.

2. Swappable modules

The sensitive touchpoints — the token wallet and hub navigation — live in modules with an identical public interface, in two variants: wallet.ts / wallet-portal.ts, back-to-arcade.ts / back-to-arcade-portal.ts. A Vite plugin swaps them at build time. The rest of the game neither knows nor cares which world it runs in: it asks "unlock this character," and underneath that means either a server-side token transaction or a rewarded ad via the portal SDK.

3. HTML cleanup

The same plugin strips privacy/terms links and any external navigation from the portal build's index.html, and deletes the corresponding files from the output. Before any submission we run a simple purity check:

grep -c "firebase\|your-domain-name" dist-crazygames/assets/*.js
# must print 0

If the grep finds anything, the build doesn't ship. It's a three-second test that has saved us from rejections.

The SDK adapter: one interface for every portal

Each portal has its own SDK, but they all want roughly the same signals. We hid them behind a single interface — on the website every function is a no-op, on a portal it delegates to the real SDK:

portalInit() at boot and loadingStop() when the menu appears — portals measure load time and penalise slow games;
gameplayStart() / gameplayStop() at run boundaries;
midgameAd() between runs — never before the first one; a player's first impression must not be an ad;
rewardedAd(): Promise<boolean> for player-opted bonuses — extra resources, revives, unlocks;
onAdMute(cb) — a portal requirement: game audio must be muted while an ad plays.

A useful testing detail: the CrazyGames SDK runs in a "local" environment when the game is served from localhost and simulates ads — you see the full flow without being published. You can validate the integration before submitting.

Submission: what the process looks like on each portal

CrazyGames — open submission, the best starting point. You zip the contents of the build folder (index.html at the zip root), add a 1920×1080 cover, name, description, category, controls. Review takes a few days and is non-exclusive.
Poki — a curated application; they prefer fresh games, so apply early, not after your game has aged. Own SDK (one more case in the adapter). Acceptance is selective, but the traffic is worth it.
GameDistribution / itch.io — later: GD syndicates to hundreds of small portals, itch is good for presence and feedback.

The economics: what you actually earn

On your own site you keep ~97% of direct sales, but you bring every player yourself. On portals you get ~50% of ad revenue, monthly payouts with low thresholds, but the players come to you. It's not a choice — it's a sequence: portals bring you volume and a name, your site monetizes the fans. The dual build is the technical price of that strategy, and it's surprisingly small once the architecture is in place.

Checklist before your first submission

A separate portal build with a compile-time flag, not runtime ifs.
Zero Firebase / accounts / Stripe / external links in the portal build — verified by grep, automatically.
Portal SDK integrated through an adapter: loading, gameplay, midgame, rewarded, mute.
No ad before the first run.
Progress in localStorage; the game fully playable without an account.
1920×1080 cover + description + controls ready for the form.
The simulated ad flow verified locally before upload.

Building a browser game and thinking about distribution? Our games are at games.hashcoreai.com, and at contact@hashcoreai.com we're happy to answer questions about the process.