Hypersomnia: Multiplayer Shooter and Map Editor Without a Game Engine

Hypersomnia's no-engine multiplayer design

Hypersomnia addresses two related needs: playing a free, community-oriented multiplayer shooter and creating maps for it without assembling a separate level editor. The project targets one-to-one duels and larger clan battles, although it presents both modes as community-driven play rather than as a documented progression system. Players who do not want to build a C++ game client can open `https://play.hypersomnia.io/`, while map creators can open `https://play.hypersomnia.io/editor/official`.

The defining implementation choice is explicit in the README: the game is written in modern C++ "without a game engine." That makes the repository relevant to engineers studying rendering, input, networking, game state, or server packaging rather than to teams looking for a familiar editor-plus-runtime ecosystem. Hypersomnia does not claim to wrap SDL, Unity, Unreal Engine, Godot, or another engine layer. Its native artifacts are downloads for Windows, Linux, and macOS, while a separate browser deployment points to a web version.

It is also a game first and a reusable networking framework second. The repository contains the client, server artifacts, editor-facing web entry point, Docker packaging, and configuration examples. It does not present Hypersomnia as a general-purpose networking library. An engineer adopting it for infrastructure reuse would therefore be reading a complete game implementation, not a narrowly scoped service component.

Hypersomnia client, server, and WebRTC network paths

The repository layout separates the C++ implementation under `src/` and project-specific resources under `hypersomnia/`, with build instructions in `BUILDING.md`, server deployment notes in `README_SERVER.md`, and general guidance in `GUIDE.md`. The README does not describe the internal fixed-tick loop, entity model, prediction system, packet schema, or serialization format, so those details cannot be inferred merely from the repository names.

The deployment files do expose two concrete network paths. The Dockerfile describes UDP port `8412` for native clients using POSIX sockets and UDP port `9000` for Web clients using WebRTC. Its headless entry point runs `Hypersomnia-Headless.AppImage` as a non-root `hypersomniac` user. This is a packaged game server built from a Linux AppImage rather than a generic container assembled from Hypersomnia source files.

The `docker-compose.yaml` mounts host directory `/opt/hypersomnia` at `/home/hypersomniac/.config/Hypersomnia/user` inside the `hypersomnia-server` service. Consequently, maps, user configuration, or other files that Hypersomnia stores in that configuration tree can persist across container replacement. The host side of that path must already exist and be writable, because the Compose file does not create it. The service also uses `restart: unless-stopped`, which asks Docker to start it again after a daemon restart unless it was manually stopped.

This split makes network planning explicit. A deployment serving only native clients can focus on `8412/udp`. A browser-facing deployment needs `9000/udp` as well as whatever networking the WebRTC setup requires. The repository does not state that the two ports are interchangeable, and the comments explicitly assign them different purposes.

Playing Hypersomnia in a browser or on desktop

The quickest documented first use does not require installation. Open `https://play.hypersomnia.io/` and start the interactive tutorial that the README says appears when the game launches. The browser version is also the only named entry point that can be linked without choosing an operating system or downloading a file.

For native play, the README provides direct archives for each supported desktop platform. These are download URLs rather than package-manager instructions:

https://hypersomnia.io/builds/latest/Hypersomnia-for-Windows.zip
https://hypersomnia.io/builds/latest/Hypersomnia.AppImage
https://hypersomnia.io/builds/latest/Hypersomnia-for-MacOS.dmg

A reader should select the archive matching the local system. The README states that the game is only 29 MB, although that description does not replace checking the current file size. It also says every archive is digitally signed and links to verification instructions at `https://hypersomnia.io/builds/latest/`.

There is no source-build tutorial in the README. It links to `BUILDING.md`, so developers compiling from source must follow that file rather than assuming a standard package-manager install. There are also no GitHub releases associated with the repository, making the project's direct `builds/latest` files and the documented verification page more relevant to acquisition than release tags would be.

Map creation follows a similar browser route. The README links `https://play.hypersomnia.io/editor/official` as the in-game map editor. It does not document the editor's object palette, collision model, networking restrictions, save format, or browser requirements, so a prospective map creator cannot assess its full capabilities from the README alone.

Hypersomnia headless server with the Compose file

A server operator can use the headless Linux AppImage directly, or use the server Docker path referenced by the README. The repository's `Dockerfile` downloads `Hypersomnia-Headless.AppImage` from the project's latest-build location, installs `libpsl5` and `libssl3`, creates a dedicated non-root account, and starts the AppImage with `--appimage-extract-and-run`.

The repository defines this exact service:

services:
  hypersomnia-server:
    image: ghcr.io/teamhypersomnia/hypersomnia-server:latest
    pull_policy: daily
    volumes:
      - /opt/hypersomnia:/home/hypersomniac/.config/Hypersomnia/user
    ports:
      - '8412:8412/udp'
      - '9000:9000/udp'
    restart: unless-stopped

Before using it, create `/opt/hypersomnia` on the host with suitable ownership and place the intended Hypersomnia user configuration there. The Compose file does not specify a startup shell command, and the README does not include the full server-configuration tutorial. The complete operational instructions therefore belong in `README_SERVER.md`, not in an invented command sequence.

After the service starts, a native client must be able to reach host UDP port `8412`, while a WebRTC client depends on host UDP port `9000` and the rest of that client's connectivity requirements. The Compose example maps both ports but does not provision DNS, a TLS certificate, a reverse proxy, or firewall rules. It also uses the `latest` image tag with a daily pull policy, so rebuilding or recreating the service can change the image used. Pinning would require a concrete tag that the repository does not identify.

Operational limits of Hypersomnia's packaged server

The server packaging is convenient but leaves important operations unspecified. The repository has no GitHub releases, and the Compose example tracks `ghcr.io/teamhypersomnia/hypersomnia-server:latest`. That combination makes it difficult to establish a named upgrade target from the release history. The `pull_policy: daily` also means that leaving the image unpinned creates a dependency on upstream image changes.

The single bind mount is simple, but it centralizes persistence in `/opt/hypersomnia`. The Compose file does not distinguish configuration from maps, player data, logs, or other runtime state. Operators need to inspect the directory before deletion or migration. Destroying and recreating the volume path could remove state regardless of whether the container itself is replaced.

No health check appears in the Compose file. `restart: unless-stopped` can restart the container after failure, but it does not establish whether the headless server is ready to accept native or browser clients. The Dockerfile exposes the two UDP ports but does not document concurrency limits, bandwidth expectations, log locations, database requirements, metrics, or backup procedures. The README also does not document rollback. For a public service, these omissions matter because a running container is not equivalent to a functioning multiplayer endpoint.

Hypersomnia's repository maintenance record is current: the repository is not archived and the last push was on 2026-10-16. That is evidence of recent repository activity, not proof of the server image's provenance, upgrade compatibility, or long-term support policy.

Hypersomnia licensing and the engine-based alternative

Hypersomnia is distributed under `AGPL-3.0`, not a permissive license. The repository includes `LICENSE.md`, and the README labels the project AGPL v3. For organizations considering network deployment, modification, or redistribution, the license text governs obligations. This review does not provide legal advice, but it identifies a relevant contrast with many proprietary engine products: AGPL includes source-provision requirements commonly associated with modified network programs, subject to the actual license terms.

The practical alternative is an engine-based multiplayer shooter built with Unity, Godot, or Unreal Engine. Those products provide an established editor and integrated project format, while Hypersomnia requires readers to evaluate a game-specific C++ codebase, its own resources, and its in-game browser editor. An engine-based approach can also carry separate licensing and platform costs, which is the principal trade-off against Hypersomnia's AGPL-licensed distribution.

Another alternative is to use Hypersomnia only as a playable system and retain an existing engine toolchain for level design. That avoids assuming the editor endpoint is a replacement for an artist's established pipeline, but it does not turn Hypersomnia into an engine integration. The README confirms the presence of direct downloads, Steam, browser play, and an editor, but it does not document import pipelines for Blender, external tile editors, or engine plug-ins. Those workflows would require independent verification.

Editorial conclusion

Hypersomnia fits players who want an immediately accessible browser shooter and developers who want to study a multiplayer game built without a conventional game engine. It is a poor choice for teams that need a conventional engine integration, a documented dependency setup, or clear rollback procedures for hosted deployments. Before adoption, verify the relevant signed build or container image, confirm that both UDP ports can pass through the intended network path, and inspect the server configuration files mounted from `/opt/hypersomnia`.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. Project website
4. README
5. TeamHypersomnia/Hypersomnia on GitHub