Skip to content
GameByGames

Publishing a game on GameByGames

What the platform expects from a game, what it does not care about, and the small amount of code needed to get your scores onto a leaderboard.

GameByGames3 min read
A memory game running inside the GameByGames play area

GameByGames does not host game code. Your game stays where you put it, on your own hosting, under your own domain, and the platform links to it. This page explains what that actually requires.

The requirements

There are three, and they are all short.

  1. It runs in a browser. Any technology you like. Canvas, WebGL, a framework, plain DOM, a Unity or Godot web export. The platform does not know or care what is inside.
  2. It is served over https. Not http, and not from a private address. Mixed content is blocked by browsers anyway, so this is not a rule the platform invented.
  3. It can be framed. Your host must not send an X-Frame-Options: DENY header or a frame-ancestors policy that excludes this site. If your game genuinely cannot be framed, it can still be listed and opened in a new tab instead.

That is the entire technical bar. Notably absent: a build step we control, a package format, an SDK you must ship, or a review of your source.

Getting listed

Your game's host has to be approved before it can be published. This is a deliberate two step control: the hostname has to exist in the platform's host list, and it has to be in the deployment's own allowlist, which is what the browser enforces. One without the other does nothing.

Once the host is approved, the game becomes a record: title, description, how to play, controls, categories, cover art. Those fields are what generate the game page, place it in category listings, put it into search and add it to the sitemap. There is no per game code anywhere in the platform, so a new game is a row and nothing else.

Reporting scores

Score reporting is optional. A game that never mentions the platform works perfectly; it just will not have a leaderboard.

If you do want one, it is three functions:

GameByGames.ready();            // the game is interactive
GameByGames.submitScore(1240);  // a score mid run
GameByGames.gameOver(1240);     // the final score

Under the hood these post a message to the parent frame. The platform checks that the message came from your game's own origin before it trusts a byte of it, so you do not need to know anything about the parent.

A few details worth knowing:

  • Scores are integers. For a time based game, send milliseconds and the platform formats it as a time.
  • A game can be configured so that the lowest score wins, which is what you want for time trials.
  • Each game has a maximum accepted score. Submissions above it are rejected, so set it somewhere above what a genuinely excellent run produces.

Cheating, honestly

Your game runs on the player's computer. Anyone determined enough can open the console and send whatever number they like. The platform binds submissions to a real play session, enforces the ceiling above and rate limits per session, which stops casual tampering and scripted spraying.

It does not stop a determined person, and no client side system does. If your game needs a leaderboard people would actually cheat for, the gameplay itself has to be validated on a server you control, and then you submit the verified result. That is a bigger project, and worth being clear eyed about before you promise players a competitive board.

Keeping your game yours

Listing a game here transfers nothing. You keep the code, the assets and the right to take it down. The platform stores a URL, some text about the game, and the scores players set on it.

developershtml5integrationpublishing
WhatsAppFacebookX

More reading