How many players are the absolute max?

[Bastet Furry]

Just curious for an idea... how many players are handleable by the doom engine?
I know that vanilia doom is capped at 4, zdoom AFAIK at 16, but would it be possible to have 256 or more people on one huge map?
Or better in one huge HUB where people can be on any map they desire without pulling others with them?

What i thought was creating a MMORPG with the doom engine and universum and now i want to clear the possibilitys before i waste my time creating stuff and waste money ordering a server as this would not be feasable with DSL, even if i have 256kbit uplink ;)

[188DarkRevived]

Perhaps this might get achieved by some next-generation ultra limit-defying sourceport within the next decade. It would be cool to witness.
Only problem would be that the maps will need to be real real real huge. Like almost three times as large as map05 of DeusVult, otherwise the fun factor would be too low and the experience would be much too frustrating.

[Bastet Furry]

Ok, it would be enough for now having 64 or better 128 maximum players.
The maps would be hubs, so when you enter a pub you enter a new map.
If you enter a quest"dungeon" you would enter another new map where monsters would respawn every 2 minutes or so.
Monsters would drop ammo, powerups, money or just plain nothing.
You could gain experience (i fancy the WoD model for that) by going on quests. No XP for slaughtering monsters ;)
Every player can do a quest just once.

I consider the maximum map size as 256kb in only map data. BSP would be created on the usersite to minimize bandwith usage.
New maps would be downloaded when they are there and not when the players enters to ensure smooth gameplay.

Any ideas, suggestions, whatever? ;)
(Please dont hell this one... it would be a nice idea and if you dont like it then dont participate and be silent)

[Manc]

Skulltag will support 32 players max and zdaemon 16 max at the time of this writing.

[andrewj]

One problem with have many players is that each client has to be in-sync with every other client, hence the client with the slowest or most-unreliable connection can make the game lag for everybody. I don't know how that handle this in the MMORPGs, I suspect the timing requirements are a bit "looser" than in an FPS engine.

I guess if each "hub" will typically have a small number of players, and your master server manages these hubs and the connections between then, then that may work without a major rethink/rewrite of a Doom port's network code.

Perhaps another engine (specially geared towards MMORPGs) but importing the Doom universe into it would be an easier way to go.

[AndrewB]

Ajapted said:

One problem with have many players is that each client has to be in-sync with every other client, hence the client with the slowest or most-unreliable connection can make the game lag for everybody.

Is this actually true

[Jehar]

WHY did i spend almost an hour trying to get a Doom MMO across to the people on #zdoom, and got shot down continually, but here in the forums its being accepted?

/me shoots self.

[insertwackynamehere]

Heh this is a cool idea. I'd love to see a Doom online RPG. I once had the idea of turning Doom into an IRC client.. maybe I oughta try that..

[m0l0t0v]

good idea!

[Bastet Furry]

Ajapted said:

One problem with have many players is that each client has to be in-sync with every other client, hence the client with the slowest or most-unreliable connection can make the game lag for everybody. I don't know how that handle this in the MMORPGs, I suspect the timing requirements are a bit "looser" than in an FPS engine.

The thing is, the server does not care that much if the player is in sync or lagging behind. The thing is, in a MMO the client just has to display whats going on, the so called thin client model. So it is no problem sending a whole update every 5 seconds to clients that suck.
I now have two questions regarding the network code:
Is it threaded or does it run in a single thread loop?
How big is a whole update of, let say, MAP23 (Barrels Of Fun)?

Ajapted said:

I guess if each "hub" will typically have a small number of players, and your master server manages these hubs and the connections between then, then that may work without a major rethink/rewrite of a Doom port's network code.

Thats the problem.
A mayor event and everybody is in the pub/the plaza/you name it. So it must sustain 128 people on one map.

Ajapted said:

Perhaps another engine (specially geared towards MMORPGs) but importing the Doom universe into it would be an easier way to go.

Hmm, i would have said Quake but as i dont know the Quake network code i am standing with the big question mark.

@Jehar:
Maybee its the way i asked for help?
I didnt asked for letting others doi the job, i asked just for information if its possible before i do a single handclap that is for /dev/null ;)

[andrewj]

Bastet Furry said:

The thing is, in a MMO the client just has to display whats going on, the so called thin client model. So it is no problem sending a whole update every 5 seconds to clients that suck.

Interesting.

I now have two questions regarding the network code:
Is it threaded or does it run in a single thread loop?

Doom ports (as clients) are single threaded, with a few calls to E_NetUpdate sprinkled about to keep things flowing.

How big is a whole update of, let say, MAP23 (Barrels Of Fun)?

About the same size as a savegame file, which in EDGE is around 24K. Partial updates could be even smaller of course.

Btw, I'm not an expert in networking code, but have recently been working on a server for EDGE (using the "thin server" model, i.e. server is mainly a packet passer and doesn't do any game simulation itself).

[Bastet Furry]

Ajapted said:

Doom ports (as clients) are single threaded, with a few calls to E_NetUpdate sprinkled about to keep things flowing.

Thats dumb :-(
There should be a thread running in the back that fetches new game data all time as they come in and answer to something like "GimmeWhatUserDoes".
Pro: Game doesnt jump around
Con: If you lag then you get only half of 1/4 of all updates and the objects are very jerky.

On the server side there should be a thread for every player in the game.
Pro: If one thread ahngs because a player lags the other wont have problems with that single player.
Con: Roughly 10% more CPU needed for every player. So if a 4 player game costs (housenumber!) 5% of CPU on a K7-3000+ it would cost 5.5% with my aproach. Now count this for 50 players and then for 100 players. ;)
But i doubt that more than 50 people would be interested in a doom mmorpg.

Ajapted said:

About the same size as a savegame file, which in EDGE is around 24K. Partial updates could be even smaller of course.

Way too much.
What is of interest after all what would not be sent after all?
- State of doors/lifts/crushers/... (We only need the z here unless its a poly, then we would need x,y and z but for easiness dont allow polys)
- Table of all objects with just x,y,z and death or alive for monsters

This heads to following overhead: (Asuming game uses,worst case, long for all variables and only a byte is send for state)
Every object needs 25 byte. Lets say there are roughly 250 objects on a map. 6250 bytes for these.
Every mapfeature needs 8 byte. Roughly 50 mapfeats on a map. 400 bytes.
6650 bytes ~= 6,5 kByte.
Now we could look if we can compress that, lets say we make 4 kByte out of this. Thats a handleable number even for 56kbaud users.

Send all time would be direct happenings but only as they happen.
The server would need to calculate if a player can see another so that redunant data wont be send. For what do we have a BSP tree and other fancy precalculations coming with every map ;)
I for myself arnt interested if a player opens the exit door of e1m1 when i am in the area of the green armor that is near the start.

Ajapted said:

Btw, I'm not an expert in networking code, but have recently been working on a server for EDGE (using the "thin server" model, i.e. server is mainly a packet passer and doesn't do any game simulation itself).

This would open doors for fakers and cheaters. Unless your server at least tracks health and ammo of every player then everyone could cheat invul with tools like ArtMoney or GameWizard.

[Gokuma]

Regular ZDoom's limit was expanded to 16? Last I knew, it was 8. Then there's Doom Legacy which has had a limit of 32 for years. Of course the only times I ever played more than a four player game anyway was on csDoom and ZDaemon.

[impClaw]

insertwackynamehere said:

Heh this is a cool idea. I'd love to see a Doom online RPG. I once had the idea of turning Doom into an IRC client.. maybe I oughta try that..

me too!

[Gokuma]

Strife would make an awesome base for a MMORPG with its towns and single gigantic hub of a game world plus its other RPGish features. A MMORPG may be a bit much to attempt at first. Just a MORPG would be cool as hell.

Phantasy Online is a cool game that's kind of in between MORPG and MMORPG. You go into lobbies where there can be tons of people and then up to four people can go into a game at once.

[Manc]

Jehar said:

WHY did i spend almost an hour trying to get a Doom MMO across to the people on #zdoom, and got shot down continually, but here in the forums its being accepted?

/me shoots self.

I don't think it's being "accepted" here either. Your talk in there was "shot down" because you obviously don't really know what goes in to attempting someting like that, and doing it even with an existing client/server doom type engine would be quite a task and almost not worth doing at all.

[DaniJ]

Doomsday implements full client/server networking with in-game joining for jDoom with currently a 16 player limit. I think the limit is "artifical" as the code certainly looks like it could handle a lot more.

The packet sizes are very small in Doomsday and only deltas (changes to the existing world) are sent. The code also supports different types and priorities of packet including confirmation on important packets.

There are "delta pools" both on client & server side and deltas can be combined dynamicaly so that data is sent at the optimum rate/frequency.

The game world exists on the server and clients mirror the server world based on their current state. Each client therefore connects to the server as fast as possible.

I've spent little time looking at the Doomsday net code so there is probably a lot more going on that I haven't mentioned.

Currently the client-side prediction code is a bit basic but that will improve.

[fraggle]

Theoretically you can set any limit you want on the number of players: it is only a constant value defined inside the engine. You can change that to whatever you want.

More practically, however, the engine will not scale beyond a few players because of the syncronous nature of the Doom networking engine. If one player stops or is delayed in sending data, the game will freeze. Combined with the unreliable nature of the Internet, the original networking engine will not scale beyond (this is a guess) around 4-5 players maximum.

Some ports (such as ZDaemon) utilise the Quake-style approach of an authoritative server sending updates to the clients. If a single client becomes disconnected, the game keeps running.

With a system like this, you are only limited by the bandwidth of the server itself. You could improve on this by designing a more distributed system. For example, have one "master server" where the whole game runs, then several "sub servers". The master server would replicate its world state to each of the sub servers. Clients connect to one of the sub servers and are forwarded on the data that they receive.

This kind of thing is theoretically possible with my Irmo networking library which I wrote as my University project.

[fraggle]

By the way, writing a source port to handle hubs with players on different hubs at the same time is difficult because of the way the Doom source code is structured. There are large numbers of global variables which hold the level state. To be able to have multiple levels running simultaneously you would have to either:

• Refactor large amounts of source code (make it object-oriented with one level object per level in the hub)
  
• Have multiple servers running and be able to jump between servers (and then you have the problem of tracking player stats - health, weapons, etc)
  

[andrewj]

fraggle said:

With a system like this, you are only limited by the bandwidth of the server itself. You could improve on this by designing a more distributed system. For example, have one "master server" where the whole game runs, then several "sub servers".

How does this system save bandwidth on the master server? If the master server has to simulate all players, then it seems the volume of update data between master and subs == volume of update data between a single server and all the clients.

[Bastet Furry]

Ajapted said:

By the way, writing a source port to handle hubs with players on different hubs at the same time is difficult because of the way the Doom source code is structured. There are large numbers of global variables which hold the level state.

My aproach would be something like having a virtual server for all maps.
As long as the map is not used the server dosnt run, if somebody goes on a map then a virtual server spawns, loads the map data and a savegame and then let the player(s) do whatever they want.
Pro: Relative easy solution
Con: How big is the impact on the CPU when there are ~50 virtual servers running, with max 300 people on all servers togheter?

Ajapted said:

How does this system save bandwidth on the master server? [...]

By not sending redunant data.
I dont care what someone does on the other end of a map. For what do we have such nifty things as a blockmap and reject data?
Unless the server decides that i see an object i dont have to know about it.
The only drawback on this aproach would be, how do we handle sounds? ;)

[deathbringer]

As far as i know, Legacy aupports 32 players, but you could probably code a port to support more. There may be some 'hidden limit' on the number that is rooted in complicated computer terms, like 3264324 players or something

[DaniJ]

More practically, however, the engine will not scale beyond a few players because of the syncronous nature of the Doom networking engine. If one player stops or is delayed in sending data, the game will freeze. Combined with the unreliable nature of the Internet, the original networking engine will not scale beyond (this is a guess) around 4-5 players maximum.

Indeed, which is why proper client/server implementations, such as Doomsday's don't have that problem(did you know demos in Doomsday are actually recorded packet streams (rather than Doom's dodgy input based stuff)).

The way it works with Doomsday's client/server is that the master server acts independantly sending out packets at a pretty much fixed interval rate. If a particular client is behind a slow connection then either the server will simply not bother sending them packets as frequently as it could or it sends less in each packet.

Multiple maps being served by the same master for eg hubs is not a terribly difficult thing to achieve in a proper OOP client/server architecture.

[fraggle]

Ajapted said:

How does this system save bandwidth on the master server? If the master server has to simulate all players, then it seems the volume of update data between master and subs == volume of update data between a single server and all the clients.

Whenever an object moves (or anything changes), you need to send an update to all players informing them of this. If you had 400 players connected to a server, all on the same map, you would need to send the same data 400 times to each node. With a "tree" type system like I described, the central server only needs to send updates to its sub-servers (eg. 20), and each sub server would only need to send updates to each of the players connected to it (ie. 20).

You could also scale it up by having each server serve a different level, and moving between servers to move between levels (it would be difficult to fit 400 players on a single level anyway, I expect :-).

Then you have the problem of how to move between levels properly: for example, how do you maintain your health, ammo, etc., but in a secure way? I'm guessing you'd need some kind of "master server" that each server would have to communicate through.

[andrewj]

fraggle said:

With a "tree" type system like I described, the central server only needs to send updates to its sub-servers (eg. 20), and each sub server would only need to send updates to each of the players connected to it (ie. 20).

Makes sense.

Then you have the problem of how to move between levels properly: for example, how do you maintain your health, ammo, etc., but in a secure way?

I don't really see what the problem is. Moving a player between servers will require coordination between those servers, just send the player stats in the "PlayerJumpedServer" packet. Or do you mean preventing hacking?

[andrewj]

DaniJ said:

The way it works with Doomsday's client/server is that the master server acts independantly sending out packets at a pretty much fixed interval rate. If a particular client is behind a slow connection then either the server will simply not bother sending them packets as frequently as it could or it sends less in each packet.

Does this mean that slow-connection clients get a kind of "low FPS" view of the world, for example a circle-strafing monster will (in the packet stream) be making big jumps which the client then interpolates to make it look OK, and a fast-connection client would get the same monster making many small jumps?

[DaniJ]

Does this mean that slow-connection clients get a kind of "low FPS" view of the world, for example a circle-strafing monster will (in the packet stream) be making big jumps which the client then interpolates to make it look OK, and a fast-connection client would get the same monster making many small jumps?

Thats close enough yeah. The trick with prediction is in how you interpolate between what you know (current world state) and what you think will happen if things stay the same based on what you know currently. Then when you "know" a value again it's how you interpolate between your current "fuzzy" world and your "sharp" world.

One example is in Doomsday the visible player is not directly rendered at the EXACT position it really is. The vectors are interpolated so that it can "travel" more freely.

All clients don't need to know everything thats happening in every part of the map to every player. It should be possible to limit the data sent to each client to that which is most useful. A simple implementation of that would just omit unecessary data but a more advanced system might decide that instead it will send useful packets more frequently to take advantage of that, or maybe increase the number of confirmed packet requests instead.

Similarly there is no need to constantly send the position of every fireball on the map. With these you can get away with "long" periods of interpolated movement especially if they don't change trajectory.

[andrewj]

DaniJ said:

All clients don't need to know everything thats happening in every part of the map to every player. It should be possible to limit the data sent to each client to that which is most useful.

Yeah that's where a PVS (Potentially Visible Set) could come in handy, like the one that a Vavoom tool can make (or a good reject builder).

Thanks for the descriptions, it's interesting stuff.

[DaniJ]

The problem with glVIS is that it just takes so damn long to calculate PVS data. In Vavoom's implementation this data must be calculated for an entire megawad before play can begin which is a bit of a pain but really I would imagine a "just-in-time" implementation before each level would be even more irritating.

Obviously I know the idea behind generating the PVS data but so far it's only really Vavoom that benefits from that due to the way it works.