Dedicated WZ-Server?

[Ryo]

Wouldnt it be nice if to have one?

- hosting multiple games
- commandline-controllable
- usw

You are redoing the networkcode and metaserver usw ... so put a dedicated Server together ,-)

Thanks for your Work!

Ryo

[Kyor]

It will not be dedicated, but will be called Master Server or something like (Check the WZ multiplayer actractivity topic)

[Kamaze]

A lobbyserver.
It only lists the hosted games.
Like the serverbrowser in some other games.

[Giel]

It will not be dedicated, but will be called Master Server or something like (Check the WZ multiplayer actractivity topic)

As Kamaze said, this master server is not a dedicated game-hosting server. Just a lobby server.

As for creating a dedicated server. I do think it would be nice to have one, yes. Although one very important thing would be: who (and how) would create & set-up the different games ?

[Ryo]

Hm thought that it should be able to have some options for setting up a dedicated game:

1. the Server-Admin can set the gametype/map usw
or
2. the first client connected can change these options like he is hosting a normal MP-Game

I dont know, but if there would be a lobby-server it should be possible for one dedicated server to host multiple matches (running under one IP) listed at the lobby?

[Kamaze]

Anyways, i don't see any reason for a dedicated gameserver for a rts game.
This doesn't make sense.

[kage]

one reason: if a dedicated server is well coded, then there's only one person you can really blame when it comes to cheating.
another reason: the warzone netcode, as we all know, is pretty damned bad. ideally, we'd make it so that one client was entirely authoritative, thus working out synchronization problems -- if we went that far, making a dedicated server is not a long shot.
third reason: the warzone code is, or at least was, not very granular. so if we rewrote the entire netcode, it might just be easier to rewrite the game logic cleanly and piece together a "from scratch" dedicated server. from this, we can patch together something like wz2100 3.0 (or 4.0, or whatever), made entirely of granular, sometimes modular components that were written entirely from scratch, or at least refactored into a clean and readable state.

[Kamaze]

Compare the advantages and disadvantages of a dedicated server.
Well, for me, a dedicated server for a - from the client initialized- RTS game is totally miss placed.

Even if you host the Dedicated server on the clients machine itself, then why not build it into the engine?
Did you ever seen a RTS game which had a dedicated server? I didn't and i think for some reasons

It's hard for me to explain it, sorry.

[Ryo]

As i have a rootserver i thougt it would be nice if I could run a WZ dedicated server on it: the client-server-latency should be mutch less then the client-client-latency (i think so ,-).

On the other hand i have many friends i play WZ with and most of them are not able to do things with their PC then playing. Entering a Game hosted on a deticated server with a Lobby etc should be easier then using some Kind of VPN-Client.

The third thing: a Game lives with the community. I think a DS for a Game like Warzone shouldnt use very mutch ressources, so that i would let it run on my server for the public... and i think there would be a bunch of other people do the same. Its allways a good fealing entering the internet-lobby of an old game and seeing servers and games running ,-)

[DevUrandom]

Another reason: Debugging and regression tests.
I.e. "automated" regression tests, balancing evaluations and the like would be easier if you just had to fire up a server and run 1000 games in turbo mode.

[kage]

Compare the advantages and disadvantages of a dedicated server.
Well, for me, a dedicated server for a - from the client initialized- RTS game is totally miss placed.

Even if you host the Dedicated server on the clients machine itself, then why not build it into the engine?
Did you ever seen a RTS game which had a dedicated server? I didn't and i think for some reasons

It's hard for me to explain it, sorry.

commercial developers almost exclusively avoid coding them because:

• like it or not, they view the average rts gamer as less technologically inclined than average fps gamers, and even if there were dedicated servers available, they feel that rts gamers wouldn't be inclined enough to set them up
• there's the concept that a round in an rts game has a very distinct start and finish: if you join in mid-way, you will lose... nearly every game a dedicated server is made for is more fuzzy than that: your chance of getting brutalized is not so assured when joining in part way through a round in an fps game.

number 1 is offset by the capabilities of the average foss user: foss users tend to see the benefit of using foss, even when it is often at the expense of some ease of use.
number 2 partially invalid because commercial developers tend not to consider scalability. dev was talking about running 1000 games concurrently -- in any program, resource usage can be divided into at least two categories: stuff that has to be done regardless of how many times you run an instance of a program, such as resource management (in warzone's case, also storing component stats, structure functions, etc), and the other is instance specific memory and code, like keeping track of each individual unit for each specific instance of a running game. if well designed, we could make it so you could run 3 servers out of one process for the memory cost of one, and for the processor cost of two seperate "one concurrent game" servers, as opposed to just the very minimal shared mem benefits you'd get by running multiple instances an fps-style "one game per server" dedicated server.

i agree, it'd not be worth the effort and would have little benefit to try to take the standard fps-style dedicated server and port the concept to an rts game, but we can do so much more...

more key benefits of a scalable dedicated server:

• as ryo said: dedicated servers == more servers sitting in the global lobby. if we made a good dedicated server, then the whole problem with having to find someone else and arrange a specific time becomes entirely moot, and moreover, it works without the assistance of a (usually commercial) "player matchmaking" service like gamespy or won, and even with a foss matchmaking service, were one to support warzone, warzone players would have to rely on both projects to be maintained for their multiplayer gaming experience to remain smooth over the years. with a dedicated server infrastructure, as multiplayer for warzone will never degrade in usability, whether or not wz is maintained. if we had a dozen or so dedicated servers running all the time, this community would most likely double in size.
• with the right redesign of some things, it'd be the perfect way to showcase mods... with a dedicated server, some mods wouldn't even have to get sent to the client; if done in a very specific way, only custom pies, texpages, and sounds would need to get preloaded on the client, as all stats would be exclusively handled by the server, and stat data would only get sent to a client (and cached by that client) when they're in the design window.

a good way to make a multi-game server would be to have one thread for an in-game event queue, and one thread for lobby server handling -- when the players in the pre-game lobby choose to start the game, a signal gets passed to the in-game thread to initialize another instance in memory, and another lobby instance is posted on the master server (subject to any "max-concurrent-games" settings). all games running on the server should share a single event queue (though any actions initiated by an event occurs only within it's own isolated gameworld), since it is by far the most efficient way to do it.

if you're wondering why i don't think we should have one thread per running game: too many bugs, and it's actually too damned slow. look at apache2 (multi-threaded version), with its "groundbreaking performance" due to its one-child-thread-per-request policy. each thread takes up about a full mb of overhead ram, and machines running high-volume apache2 servers tend to crash because it takes memory to free memory, and the apache server has guzzled all of your available ram. on the other hand, lighttpd uses no more than 1 thread, ever, and it handles requests faster than any version of apache ever made, whether it's one request or 100,000 concurrent requests, it still beats the multi-threaded philosophy (sometimes by a landslide), even on machines with over a dozen processors, not to mention uses almost no memory by comparison.

in our case, threads are definitely good, but more as a design-modularity tool than a performance tool.