Skip to content

How to read these docs

These docs describe how Wulfram II works: its network protocol, file formats, physics and game rules. They come from reverse engineering the original client and from people who played on the official servers.

The original Wulfram II client still exists, so much of its behavior can be recovered precisely: what each packet contains, how it is decoded, and what the client does with it. The official servers are gone, and their code was never available. Server rules therefore have to be pieced together from what the client expects, from shipped help text and data files, and from players’ memories.

Because those sources are not equally strong, every claim that matters carries a label.

  • recoveredRecovered. Established from the original Wulfram II client or its shipped files: disassembly, packet decoders, data files or observed original-client behavior. Addresses such as 0x0046EC50 point at the function in the original executable.
  • testimonyTestimony. A player’s recollection of how the official servers behaved. Valuable where nothing else survives, but memory can be wrong about details such as exact timings.
  • policyPolicy. A choice made by our server where the evidence does not decide the question. Policies are configurable and can change when better evidence appears.
  • W1 leadWulfram 1 lead. Material from Wulfram 1.0, the predecessor game. It suggests what to look for in Wulfram II, but it is not Wulfram II evidence.
  • Addresses are preferred virtual addresses in the original Wulfram2.exe, written as 0x00400000-based hex.
  • Packet layouts give body offsets, excluding the opcode and the transport envelope. Opcodes are written in hex, such as 0x29.
  • Multi-byte packet values use network byte order (big-endian) unless a page says otherwise. Types are written u8, u16, u32, i32 and so on; fixed-point values are signed 16.16.
  • Protocol strings are a u16 length that includes the terminating NUL, followed by that many bytes, so an empty string normally has length 1.
  • Pages list open questions at the end. An unresolved detail is stated as unresolved rather than guessed.
  • Protocol: packets, their layouts and how the client consumes them. Start with cargo and docking.
  • Archive: history, interviews and the cutting room floor.
  • Build: the roadmap for the reconstructed client and server.

A fan preservation project, not affiliated with the original developers. No original game files are hosted. Text licensed CC BY 4.0; site code MIT.