Can NetCraftGames host my game?

The short answer

NetCraftGames hosts a multiplayer game that already works. It needs a server program, one that runs on its own machine without a window, on Linux. We do not write multiplayer, we do not turn a single-player game into a multiplayer one, and we do not host games that run on an online service such as Photon or PlayFab. If an AI built your game, read this page before you build anything else for hosting.

You get one of three answers:

• Yes, ready. Your game has the pieces we need. Next you run a check on your own computer, then submit.
• Almost. One change is missing. You get the change in one sentence and a prompt to give your AI.
• Not yet. We cannot host this today. We tell you why now, instead of after you upload.

Check your game

Pick the answer that fits best. Not sure is always fine: it leads to a way to find out.

Not sure? Ask your AI to find out

This prompt makes your AI read your project, change nothing and print one JSON answer. Paste that answer into the box above, and every "Not sure" is filled in. The answer is checked inside this page and never sent anywhere.

TASK: Read this project and tell me what it is. Do not change any file.
Answer by printing ONE JSON object and nothing else, in exactly this shape (schema ncg.qualify-answers/1):
{
  "schema": "ncg.qualify-answers/1",
  "engine": "unity" | "unreal" | "godot" | "browser-js" | "python" | "other",
  "language": "<main language>",
  "networking": "none" | "dedicated-server" | "host-or-p2p" | "third-party-service",
  "networkingLibrary": "<name found in the code or package files, for example Mirror, Netcode for GameObjects, ws, socket.io, Colyseus, Photon, Steam, none>",
  "twoPlayerTestExists": true | false,
  "serverModeWithoutWindow": "yes-linux" | "yes-windows-or-mac-only" | "no",
  "hasHealthEndpoint": true | false,
  "readsPortFromSetting": true | false,
  "handlesSigtermAndSaves": true | false,
  "evidence": ["<file path and line for each answer, at most 12 items>"]
}
Rules: base every answer on files you actually opened. If you cannot tell, use the most cautious value (for example "none" or false) and say why in evidence.
Do not include secrets or file contents beyond one short line per evidence item.

What we host and what we do not

We would rather tell you now than after you have spent a weekend on it. The glossary explains any word you do not know.

• We do not write multiplayer. NetCraftGames runs servers for games that already have multiplayer working. We never add networking to a game, and a single-player game is held when it is uploaded.
• Games where one player is the server. The thing we run is a dedicated server program that you own, one that runs on its own machine without a window. A game where one player hosts the others (a listen server, host mode or peer to peer) needs a dedicated server mode first. The one exception is a browser game that already uses WebRTC: we offer room signaling for it, but we do not relay the game traffic itself.
• Games built on an online service. Photon, PlayFab, Steam, Epic Online Services, Firebase and Supabase realtime run their own cloud. Our lane runs a server program that you wrote and own. If your game also has its own server code, that part can qualify.
• Colyseus and other frameworks that need web requests before the WebSocket. Our gateway passes WebSocket connections only. Colyseus asks for a room over plain HTTP first, so it does not work through the gateway and we say so before you submit. socket.io does work, but only with WebSocket-only transport (long polling is not passed) and the fixed path you declare in the manifest.
• Servers whose WebSocket path changes for every room or player. The gateway connects to your server at one fixed path: the root path "/" unless you declare a wsPath in the manifest (for example "/ws" or "/socket.io/?EIO=4&transport=websocket"). It cannot follow a path that changes for each room or each player, it does not forward anything a player puts in the address, and it passes WebSocket connections only, never plain web requests.
• Other Node versions, Deno, Bun and servers that call other websites. Our servers run Node.js 24.21.0 and Python 3.12. Nothing is installed on our side, so your packages travel inside your upload, built for Linux x64 (ncg pack does this on your own computer). Another Node version, Deno or Bun must be shipped inside the upload as a Linux x86-64 program. A server cannot look up other websites by name: DNS is closed to game servers on purpose, so a game that calls an outside address by name will fail. Node.js 26 is planned after it becomes a long-term-support release, with no date and no promise.
• Windows or macOS servers and servers that need a screen. Dedicated servers must be Linux x86-64 builds that run without a window or a graphics card. Windows, macOS and ARM server builds are not hosted.
• A "Yes" here is not a certification. This page checks your answers. We have not seen your code and nothing has been run. A real server start and a real player join are checked only after you submit a build.

The decision table

This is the whole check as a table, for readers who skip the buttons and for search tools. Read down it: the first row that describes your game is your result.

Prompts that set up your server

Each prompt tells your AI exactly what the host needs: a port that can be set, a health probe, a join probe, a clean stop on SIGTERM, no secrets in code, and an ncg.json file with the exact settings. Every setting in them is checked against the real validator before this site is built. A prompt marked "Manifest checked" has passed that check; none of them has yet been tried against a real AI, so read what your AI changes.

The prompts page lists them all, including one for socket.io (WebSocket only, with a fixed path in the manifest).

Test it with two players first

TASK: Prove that two real players can play together before anything is hosted. Do not change gameplay.
1. Add a script (an npm script, or the equivalent for this engine) that starts the server on your own computer and connects two clients, headless or scripted. Each client sends a move or an action, and the script checks that each client receives the other's state.
2. Run it and show me the real output. If it fails, tell me which part of multiplayer does not work yet. Do not paper over it.
3. Add the result to the project README in two lines.

Plan multiplayer, with no code

TASK: Do not write multiplayer code yet. Write MULTIPLAYER-PLAN.md for this game covering:
1. Which parts of the game state must be shared, who is authoritative (the server), how often the server updates, and what a client may send (inputs, not positions).
2. Which networking library fits this engine and language, and how a dedicated server can run without a window on Linux.
3. What changes in the client: a list of files and a realistic size estimate in days of work.
4. A test plan with two real clients.
Be honest that adding multiplayer to a single-player game is a large change. Show me the plan and wait.

Move from Colyseus to plain WebSocket

TASK: This project uses Colyseus or python-socketio. The hosting service passes WebSocket connections only, to one fixed path. It cannot pass HTTP long polling or HTTP matchmaking, which Colyseus and the default python-socketio mode need before the WebSocket opens. (socket.io for JavaScript does not need this move: it has its own prompt.)
First write a short migration plan in MIGRATION.md: list every event, room and message the game uses, how rooms and reconnection will work on plain WebSocket (JSON messages with a "type" field), and which client files change. Show me the plan and WAIT for my approval before you edit any code.
After my approval: replace the realtime layer with the "ws" package on one HTTP server (JavaScript) or the "websockets" library (Python), keep the game rules unchanged, update the client to use new WebSocket(url), and add a test with two clients that proves two players see each other. Do not add features. Then ask me to run the hosting prompt for this stack.

What happens to your answers

Nothing. The check runs in your browser with the same code the dashboard and the command line use. The page tells your browser, through its security policy, that it may not make any network request, so even a bug could not send your answers away. There are no cookies, no analytics and no stored answers. The page also works with JavaScript turned off: the questions, the decision table and every prompt are plain text you can select and copy.

How to find out if your game qualifies

1. Answer five questionsSay what your game is built with, whether two people can play together over the internet, how players connect, whether the server runs without a window, and which server basics it already has. The page gives Yes, Almost or Not yet.
2. Make the one changeIf the answer is Almost, copy the prompt to your AI. It changes only what the prompt lists. Test the result with two real players.
3. Check it on your own computerWhen you have the ncg tool, ncg check reads your files locally and tells you what the service would say. It uploads nothing.
4. Submit when we openNetCraftGames is not accepting customers yet. Join the waitlist, keep your ncg.json, and submit when the doors open.

Frequently asked questions

Written by Charging Bull Software. Facts on this page are checked against the product source and dated sources listed above; where something is not proven, the page says so.