Odamex Seeking Lead Developer (and others)

Over the past few months, Odamex development has come to a grinding halt as our lead developer and other notable people who worked on the code have been caught up with other things. The Odamex team is looking for someone to join up and be able to take the reigns on a project with so much potential. This person should have a solid grasp of C++ and, experience with net code, not easily defeated by frustration, and as a plus, knowledge of the Doom engine.

Odamex is the most popular client/server Doom engine that is licensed under the GPL. Founded in 2005, Odamex still does many things that the other popular multiplayer engines do not, including but not limited to, on-the-fly wad loading (allowing for servers with an infinite number of maps in rotation) and wad downloading. Odamex has been ported to just about every platform that supports SDL, even including consoles like the XBox.

Ultimately, I'm making the post because there is a significant player base looking for Odamex to be better. The players want it, but Odamex is not where it needs to be yet to support them. The engine is in a good position but still needs work put in to make it as great as it can be.

As far as immediate concerns, Odamex needs to get to version 0.5. There's a list of bugs that we wish to have closed before 0.5 is released. We are seeking patches for all of these bugs.

If you feel that you can help the Odamex project and its community, please contact me by email, through our message boards, or through irc (irc.oftc.net #odamex). There are many players that need your help!

I'll try and see if I can get the big CTF problem fixed in a week. It's not on the list, but Hex told me it was important.

I may try my hand at some stuff, I dunno about lead developer but I will definitely give some patches.

Idea: Merge the net game logic developed for Odamex with an actively developed port (one which is lacking in the multiplayer department).

I have always been of the opinion that the goals of the Odamex project do not necessarily need a complete port to accomplish.

Alternatively, turn Odamex into a net game library plus protocol which can be plugged into other ports.

DaniJ said:

Idea: Merge the net game logic developed for Odamex with an actively developed port (one which is lacking in the multiplayer department).

I have always been of the opinion that the goals of the Odamex project do not necessarily need a complete port to accomplish.

Alternatively, turn Odamex into a net game library plus protocol which can be plugged into other ports.

*cough* Eternity Engine *cough*

MP2E said:

*cough* Eternity Engine *cough*

*hack* *wheeze* Ahem, I wholeheartedly second this notion.

I, for one, would miss Odamex being its own port. However I do agree that Eternity and Odamex would both benefit greatly from a merge. Odamex would still support vanilla/Boom, but would have a slew of editing features, raven support, cardboard, portability, and bug fixes. Eternity would have Client/Server netcode, CTF support, and Hyper_Eye, who was fantastic at porting Odamex to consoles and other platforms :p

Also I think a multiplayer surrounding would be just what Eternity needs to make it as popular as the ZDoom ports to the average joe user.

Vulture said:

I, for one, would miss Odamex being its own port. However I do agree that Eternity and Odamex would both benefit greatly from a merge. Odamex would still support vanilla/Boom, but would have a slew of editing features, raven support, cardboard, portability, and bug fixes. Eternity would have Client/Server netcode, CTF support, and Hyper_Eye, who was fantastic at porting Odamex to consoles and other platforms :p

Also I think a multiplayer surrounding would be just what Eternity needs to make it as popular as the ZDoom ports to the average joe user.

Yeah, that would be really awesome. But perhaps the major netcode-related bugs should be fixed first. I'll try to work on that.

Vulture said:

I, for one, would miss Odamex being its own port. However I do agree that Eternity and Odamex would both benefit greatly from a merge.

I don't think "merge" meant to have Odamex become Eternity in this case. As I understand it Quasar has no interest in being multiplayer oriented any ways. What I believe was suggested is that Odamex move away from being based on an ancient version of ZDoom and instead use Eternity as it's base.

Personally I think that would be a good move since honestly I never saw the point in basing a port on such an old version of ZDoom.

Blzut3 said:

I don't think "merge" meant to have Odamex become Eternity in this case. As I understand it Quasar has no interest in being multiplayer oriented any ways. What I believe was suggested is that Odamex move away from being based on an ancient version of ZDoom and instead use Eternity as it's base.

Personally I think that would be a good move since honestly I never saw the point in basing a port on such an old version of ZDoom.

The main question is, which I've been thinking about for probably more than a year now - would it be easier to graft Odamex's netcode onto Eternity Engine, or Eternity Engine's features onto Odamex?

Blzut3 said:

honestly I never saw the point in basing a port on such an old version of ZDoom.

Odamex is based off of CSDoom, which was based off an older ZDoom. They didn't start the port from scratch on an older ZDoom.

Vulture said:
However I do agree that Eternity and Odamex would both benefit greatly from a merge.

Are you sure? Eternity may benefit some from the net code, but Odamex less, and development would get more complex either way, stalling releases for reasons outside the distinct needs of each current port. It would have little to do with "setting standards" as noted on the Odamex page (which means keeping competitive play in the focus) because it would be a function of a WAD-making oriented port.

myk said:

Are you sure? Eternity may benefit some from the net code, but Odamex less, and development would get more complex either way, stalling releases for reasons outside the distinct needs of each current port. It would have little to do with "setting standards" as noted on the Odamex page (which means keeping competitive play in the focus) because it would be a function of a WAD-making oriented port.

The issue is how to attract more users to Odamex, I think. Fixing the most glaring bugs and being open source might not be enough to compete with Skulltag and ZDaemon, though it will definitely help a lot.

A lot of people have been pushing for Skulltag to allow 3D floors in competitive game modes. Even so, they only work in OpenGL mode.

Meanwhile, Eternity Engine's portals work in software mode, so given sufficient mapper interest, 3D competitive maps could be made for Odamex, if Odamex had portals.

I can't think of a better way to attract people to Odamex than having great Odamex-exclusive maps. Given the Odamex team and UD sort of overlap, and UD is known for its great maps, things should be great as long as UD expresses interest in mapping with portals.

Of course I can't speak for UD, but the general idea is that it could be both competitive and WAD-making. After all, additions like bridge things and flags have been accepted into the competitive scene in the past. That is, infinite height needed to be removed, and thus original DOOM mechanics changed, for bridge things to work.

edit: on the other hand, Odamex should probably pick and choose useful features, since some features may significantly complicate Vanilla DOOM compatibility.

I think Odamex has a huge amount of potential, purely because it's GPL. If a dedicated maintainer appeared I think Odamex could easily become the #1 C/S doom port. It's already the most portable (by far), and the code itself is pretty clean compared to other C/S ports.

A lot of things that developers might be interested in wouldn't be that hard to add to Odamex, because of the awesome array of other GPL ports that exist. A lot of bugs that would normally result from adding things like portals, slopes, 3D floors, OpenGL rendering, etc. could be avoided just by grabbing the work from other excellent Doom coders. I'm not saying it'll be a walk in the park, but it's 1000x easier than completely re-implementing each feature.

I strongly encourage any interested programmer to take a look. There's no shortage of interest in Odamex, it's simply a matter of someone with the skills and time applying themselves to the project. It could be a lot of fun!

Spleen said:

The issue is how to attract more users to Odamex, I think. Fixing the most glaring bugs and being open source might not be enough to compete with Skulltag and ZDaemon, though it will definitely help a lot.

It's not. The sad fact is that although Odamex wants to be a port that is more 'classic' than ZDaemon, most of the people who are still playing classic doom think that ZDaemon is "good enough" and trying to cater to them is impossible because they're already used to many of ZDaemon's quirks. For example, how are you going to prove that Odamex's netcode is "superior" to someone who is used to how ZDaemon's netcode works and starts missing shots because they're not used to how Odamex works? Or that the plasma bump works "better" when someone who has been playing ZDaemon for years tries to repeatedly plasma bump and can't do it because although it's more correct it's not how ZDaemon does it.

Skulltag already runs into this when it comes to CTF. Lots of players don't bother with playing Skulltag CTF on ZDCTF maps because many motions they're used to on ZDaemon (the bridge jump on Ralphis' Magical Ice Forts, for example) are different on Skulltag. Try to get anyone in #idl to do a priv on Skulltag and they'll laugh at you.

And let's not kid ourselves, people do not care if a port's source is open or not. They care if it works already, and if it's being active and worked on. Being open source is not really that big of an advantage when it relies on a dataset that you still have to buy.

Personally, my dream is for a Doom port to be based on one of the Quake engines, which has Client/Server as a fundamental paradigm (where Single Player is simply connecting to a local server), and then implement Doom as a gametype on top of it. Forget completely about trying to emulate "classic" gameplay at all, take a "good enough" approach like ZDoom does. Doesn't Vavoom do this already?

AlexMax said:

Personally, my dream is for a Doom port to be based on one of the Quake engines, which has Client/Server as a fundamental paradigm (where Single Player is simply connecting to a local server), and then implement Doom as a gametype on top of it.

Keep an eye on Doomsday 2.0 in that case as thats the architecture we're using.

Here are some specific bugs that really need to be fixed for us to get to 0.5. So if any experienced programmers around here are feeling generous:

Boom Compatibility Issues

These two bugs have been documented since about 2006 and definitely need to be corrected as they prevent completion of Freedoom along with many other issues. If any specific fix will break vanilla doom compatibility, it should receive a compatibility flag cvar (prefixed by co_*).

Boom Enhanced Errors

BOOMEDIT Bugaboos

Boom: Generalized linedef type doesn't work

Boom: Things won't fall off ledges

Segfaults

rjumpn.wad map08 segfault

Spleen said:
The issue is how to attract more users to Odamex, I think. Fixing the most glaring bugs and being open source might not be enough to compete with Skulltag and ZDaemon, though it will definitely help a lot.

Attract who? Making it an Eternity derivative would make it into a Skulltag competitor, attracting the same people or some people who have slightly different tastes. Odamex is looking like an online parallel of PrBoom, which is one of the more popular "single player" ports. In that sense, who wants to play with weapon sprites that don't synch, flawed vanilla behavior or incomplete Boom features?

It would be great to have a down-to-earth, vanilla and Boom compatible client server engine usable for basic competitive play (deathmatch, CTF and speedrunning) and "extra editing features" do not contribute to that.

Later, when the engine becomes solid, its networking could be ported to other engines, like Eternity, much like PrBoom's vanilla and Boom compatibility improvements made their way to it (or to Odamex itself.)

Random view of a passerby:

Seems to me like it would be a better route to develop Odamex as its own port rather than deal with the hassles and glitches that are likely to result from a merge. It's a better priority to focus on a rock-solid classic multiplayer experience. As cool as MP-Eternity would be, if one wants extra editing features, that's what Skulltag is for.

Ralphis said:

rjumpn.wad map08 segfault

This seems to be covered here, in the last point: http://www.doomworld.com/vb/eternity/37056-ee-progress-report/

It's a matter of going through and changing the type of a bunch of shorts to ints. It doesn't fix all related rendering glitches like moving to Cardboard would, but it sure beats segfaults.


As for the Boom generalized linedefs and "bugaboos", some of the code responsible for generalized linedefs seems to be missing altogether. I think what might be simplest is to do is start copy-pasting things that are missing and work out any bugs that result (with credit where it is due, of course).


Also, compatibility variables should have Boom behavior as 0 (default), and Vanilla behavior as 1, correct? For example co_vanillaledges, defaulting to 0.


Odamex seems to be moving along nicely. I'm hoping we can fix most of the blocker bugs this month and release some time in August.