I’ve decided to start working on a new source port called Doom2K or
“D2K” for short. My goal is to build a state-of-the-art multiplayer source
port capable of being the standard-bearer for multiplayer Doom. This, in my
mind, means a couple of things.
Message-Based Netcode Is Broken
ZDaemon, Zandronum, and Odamex all use message-based netcode. For example,
there is (historically) a function called
P_SpawnMobj which spawns a new
actor into the game. Serverside, inside of
P_SpawnMobj is a call to a
function that broadcasts a “mobj spawned” message; let’s call it
SV_BroadcastMobjSpawned. For illustration’s sake, it generally looks
something like this:
| ID |
| X |
| Y |
| Z |
| Angle |
| Type |
This model “works” for any number of game events. EECS, for example, has 44
messages. Odamex has 112. The way message-based netcode “scales up” is
message proliferation, and there are a number of downsides to this.
You have to litter your code with network messages
Ugly, error-prone, and overly complicates extending the engine (scripting).
You have to exempt huge swaths of code from running clientside
Same as above.
Consistency is complicated
Unless you package up all your message into a single packet (assuming it will
all fit), consistency requires sequencing and a “tic ended” message.
Doom Scripting Is Busted
Probably the best scripting out there is Doomsday. Otherwise, you can use
EDGE/3DGE and COAL, or you can use ZDoom and ACS. I think you can use
FraggleScript in Legacy.
The situation isn’t great though.
With a powerful scripting language, it would be possible to implement new game
modes (like CTF), convert most of Doom’s physics and original game play, and
represent assets and configuration in scripting also. PWO, for example, could
simply be a user-provided function in a config.
ASCII Is Out, Unicode Is In
Unless Doomsday uses UTF-8, I’m unaware of any source ports that are
Unicode-aware. This has serious implications for Doom’s popularity outside of
Software Rendering Is Limited And Slow
Software rendering is much slower than hardware-accelerated OpenGL rendering.
In general, people who prefer software rendering do so because it’s more
faithful to Doom’s original renderer (which almost no port uses anymore, due to
its bugs and limitations). However, with display pixel count rising, software
rendering is becoming less and less feasible.
Software renderers also have various limitations: lack of support for portals,
3D architecture (slopes, room-over-room, etc.), bad math (wobbling flats,
problems with long walls, inaccurate flat rendering, etc.), and so on.
My major goals are to fix all of this.
Instead of network messages, D2K will use delta-compressed game states, which
avoids all of the problems with message-based netcode (at the expense of
increased CPU usage and RAM consumption).
D2K will use Lua for scripting. Current plans include:
- Implement console in scripting
- Implement new game modes in scripting
- Move Doom physics, game play, and assets to scripting
D2K will use UTF-8 instead of ASCII.
Regarding the renderer, I haven’t entirely decided to remove the software
renderer. My main focus will be on the OpenGL renderer, however, because it’s
easier to add advanced renderer features to it. Further, I will work on
implementing a shader for the OpenGL renderer that accurately emulates Doom’s