This repository ties together the pieces required to build one distributable Hellwave game package on top of QuakeShack and LibreQuake.
It is a meta-repository that:
- installs the engine dependencies
- links the external game and data repositories into the engine layout QuakeShack expects
- builds the browser client
- compiles Hellwave maps with ericw-tools
- generates navigation meshes with the dedicated server
- assembles a curated runtime
dist/tree - optionally uploads that build with
aws s3 sync
The important submodules and directories are:
engine/: QuakeShack enginegame/: Quake game code used by the engine'sid1submodule lineagehellwave-game/: Hellwave game codehellwave-data/: Hellwave maps, textures, shaders, configs, and WADslibrequake-data/: LibreQuake runtime assets used as the base game datatools/ericw-tools/: map compiler toolchain used by the Hellwave map Makefile
The top-level Makefile is the intended entrypoint for local builds and CI.
- Git submodules initialized
- Node.js and npm available
rsyncavailableawsCLI available if you want to usemake upload
Typical initial checkout:
git submodule update --init --recursiveTo update submodules to their tracked upstream revisions:
git submodule update --init --remote --recursiveThis is the main CI target and the intended Jenkins entrypoint.
It currently expands to:
deps: runnpm ciinengine/link: symlink Hellwave and LibreQuake data into the engine treeengine: build the browser client inengine/dist/browser/maps: compile BSPs and navigation files for Hellwave mapsassets: assemble the final distributable tree indist/
In Jenkins, the simplest pipeline step should just be:
make allmake deps: install engine npm dependenciesmake link: refresh the engine symlinks for game and data reposmake engine: build the browser client onlymake maps: rebuild Hellwave BSP and NAV filesmake assets: rebuild the distributabledist/treemake clean: removedist/make upload: rebuilddist/if necessary and upload it with the AWS CLI
The top-level Makefile exposes the browser-facing build URLs as overridable variables so you can split staging and production builds without editing files.
The relevant variables are:
VITE_CDN_URL_PATTERN: defaults tohttps://hw-assets-{shard}.quakeshack.dev/assets/{filename}VITE_SIGNALING_URL: defaults towss://master.quakeshack.dev/signaling
Examples:
make all \
VITE_CDN_URL_PATTERN="https://staging-cdn.example.com/assets/{filename}" \
VITE_SIGNALING_URL="wss://staging-master.example.com/signaling"make all \
VITE_CDN_URL_PATTERN="https://cdn.example.com/assets/{filename}" \
VITE_SIGNALING_URL="wss://master.example.com/signaling"For Jenkins, these can be injected as job or pipeline environment variables and passed through to make all.
The packaged output is intentionally curated for runtime use.
It includes:
- browser build output from
engine/dist/browser/ - LibreQuake runtime assets:
gfx,progs,sound,gfx.wad, and base item BSPs - Quake base config files from
engine/data/id1/*.cfg - Hellwave runtime configs
- Hellwave
gfx,shaders, andtextures - Hellwave map runtime artifacts only:
*.bsp*.nav*.lit*.qsmat.json
It intentionally excludes build junk and source-only files such as:
.git- map compiler logs
.prt.content.json.texinfo.json- source
.mapfiles - arbitrary WAD copies from the Hellwave data tree
The upload step is environment-driven so it can be fed by Jenkins.
The upload target uses these variables:
S3_BUCKET: requiredS3_ENDPOINT_URL: optionalS3_PREFIX: optionalAWS_PROFILE: optional, handled by the AWS CLI itself
Makefile no longer hardcodes an AWS profile. If Jenkins wants a profile, export AWS_PROFILE before calling make upload.
Example:
export AWS_PROFILE=hellwave-r2
export S3_BUCKET=hellwave-production
export S3_ENDPOINT_URL=https://example.r2.cloudflarestorage.com
export S3_PREFIX=hellwave
make uploadIf S3_PREFIX is empty, the upload goes to the bucket root.
Hellwave map compilation is delegated to hellwave-data/Makefile, but the top-level repository overrides the important runtime paths:
BASEDIR=../librequakeTOOLS_DIR=../tools/ericw-toolsDEDICATED="node --preserve-symlinks --preserve-symlinks-main ../engine/dedicated.mjs"
Those overrides matter because:
- the dedicated server needs symlink preservation to load
hellwave-game/correctly - nav generation must boot with the requested map
- nav generation must resolve LibreQuake assets as the base game data
A minimal Jenkins job can do:
git submodule update --init --remote --recursive
make all
make uploadIf upload credentials and destination are injected by Jenkins, set at least:
export S3_BUCKET=your-bucket
export S3_ENDPOINT_URL=https://your-endpoint
export S3_PREFIX=optional/path
export AWS_PROFILE=optional-profile
export VITE_CDN_URL_PATTERN=https://cdn.example.com/assets/{filename}
export VITE_SIGNALING_URL=wss://master.example.com/signalingThen invoke:
make all \
VITE_CDN_URL_PATTERN="$VITE_CDN_URL_PATTERN" \
VITE_SIGNALING_URL="$VITE_SIGNALING_URL"
make uploadengine/README.md: QuakeShack engine detailshellwave-data/Makefile: map compilation details- top-level
Makefile: CI and packaging orchestration
The music is taken from LibreQuake and converted from ogg to opus.
for i in $(seq 2 11); do
ffmpeg -i "$(printf "track%02d.ogg" "$i")" -c:a libopus -b:a 128k $i.opus
doneThis meta-repository assembles and packages work from several upstream projects, and redistribution should preserve their attribution and license terms.
engine/is QuakeShack, the engine used to build and run the packaged game. The engine repository declaresGPL-2.0-only; seeengine/package.jsonandengine/LICENSE.tools/ericw-tools/is the ericw-tools map compiler suite used for BSP and lighting builds. Its README states it is licensed under the GNU GPL version 2 or, at your option, any later version. Builds using Embree are noted there as GPLv3+ for Apache-license compatibility.librequake-data/provides the LibreQuake base runtime assets used by this package. LibreQuake's asset set is covered by the BSD 3-Clause license; those assets remain credited to and governed by the LibreQuake project's copyright, license, and contributor notices.hellwave-game/andhellwave-data/contain the Hellwave-specific game code and content packaged by this repository.
In short, this repository should be treated as build and packaging glue around separately licensed components rather than as a single-license distribution.