Hypothetical multiplayer game with huge maps

[Danfun64]

I was curious as to what the best FLOSS engine for a multiplayer game with huge outdoor maps would be.

Cube 2? (Octree)
Red Eclipse (Improved Cube 2)? (Octree)
FTEQW? (Heightmaps and BSP)
Id Tech 4? (MegaTextures and BSP)
Doom 3 BFG? (MegaTextures and BSP)
Torque 3d*? (No idea)

Lets say... 64 players at once. Secondly, all tools must be open source and linux compatible. In addition, something like sv_pure should be either avaliable or easy to code into said engine.

The reason I say hypothetical is because I have little to no coding experience whatsoever and it's highly unlikely I would even do such a thing. Just curious what your recommendations are for multiplayer games with large servers.

Also, feel free to mention any engine I left out.

*May not have complete linux support

[Spike]

define 'huge'...
for me, huge is something that takes an hour or two to walk from one side to the other.
with a map that large, you'll have all sorts of other issues of course, but that's all part of the fun.

tbh, if you're aiming for huge maps, you should probably focus on the tools more so than the engine itself, as that's the only real way to remain sane.

[goldenboy]

I like Enemy Territory: Quake Wars quite a bit. Is that about what you mean when you say "huge outdoor areas"?

Unfortunately the ETQW engine was the next one scheduled for a source release, which we will probably never get now... of course you could do your game as an ETQW mod. The tools for that are free and linux-friendly (ie Radiant.) But that would probably limit you.

I'm not sure if the Doom 3 engine supports megatextures via some mod; if it does, nice. Not sure how suited Doom 3 is to doing what you have in mind, I think they added quite a bit of stuff to the ETQW version of idtech4 that made it very suitable for that kind of thing.

The Doom 3 BFG engine, you might want to ask at doom3world.org about how feasible the entire thing would be and what the toolchain is.

FTE with its heightmaps is very easy to create large (really large) terrain maps with, but some features like realtime sunlight (rtlights can't be directional / no falloff atm) and some GLSL for rtlights + alpha masked textures (foliage) is still missing. On the upside, if you had a GLSL capable person on your hypothetic team, you could quite possibly extend FTE to do a number of very cool things. Its heightmaps also allow punching holes in the terrain and thus joining it up with indoor areas (BSP or mesh) much like ETQW, really. It doesn't do megatexture, but it allows for practically painting the terrain (a little like Crysis.) The entire outdoor terrain thing is a bit work-in-progress in FTE right now, so if you could bring a capable coder you might more easily get somewhere. But that might be true for all options...

No idea about the others.

[Danfun64]

[Spike]

you can make maps that would supposedly take 3.6 hours to walk across in fte. more if you go diagonally or around hills. that huge enough? :s
hurrah for stream-loading.

[gnounc]

*gets to work on his "marco polo with megaphones" mod*

[leileilol]

Darkplaces can also load overly large OBJ maps with ENT files and rtlight entities. No moving brushes or vis data though, but the scale is unprecedented. I tried to do a hover vehicle game thing on such a map, with realtime light it was actually immersive-ish. If it only had been a decent looking vehicle hovering over decent looking textures instead of programmer art that looks like the typical 1991-1994 CGI cdrom game... (though it's also awesome we got to the point of doing that in real-time too)


also i'm not sure if it ever fixed the flip bug.

[Danfun64]

Didn't know that darkplaces supported obj.

@Leileilol: Is Darkplaces' OBJ map support better than FTEQW's heightmaps In Your Opinion?

[Danfun64]

bump, because nobody would look at the thread if i didn't

I have a couple questions before this thread is completely forgotten.

How well can fteqw support 64 players?

Does fteqw support sv_pure?

How easy is it for darkplaces have voip and sv_pure implemented?

[leileilol]

[Spike]

sv_playerslots 64 will allow fte servers to support 64 clients. it goes up to 255. blank defaults to 32 if deathmatch or coop is set, and 1 otherwise.
sv_pure does exist, but its not well tested and probably has a few oversights that make it unusable one way or another. cl_pure also exists. both forms depend upon the client for security, which is no security at all, potentially useful as a debug feature though.

fte's heightmaps do support holes. you can embed external bsp objects for buildings or caves.
gb's maps use heightmaps combined with bsps. the heightmap is embedded within the bsp and the sections are only drawn when within the bsp's pvs. this does of course require a bsp with a huuuuge open area. hurrah for q3bsp's light grids...
either way, entity placement can be a major issue.

[Danfun64]

sv_pure would be meant to have the same task that it would on an id tech 3 or id tech 4 game, by restricting the content to what is provided by the server to prevent wallhacks or similar cheating problems. As such, it couldn't rely on how the game engine is compiled, or be strictly a "debug" feature.

And the voice chat (voip) issue wasn't mentioned at all

[Spike]

id tech 3 or id tech 4 both used a closed protocol+engine.
open source engines have the issue that disabling sv_pure stuff is trivially easy even when its 100% correctly implemented.
if you think it'll solve wallhack issues then you really need to do your research.
from what I've seen, you could easily change files around in a pk3 and still pass the sv_pure test. you just have to write special tools for it and to put up with standard zip programs complaining about it. seriously, sv_pure only has the value of a debug feature even in quake3.

fte already supports voip. if you want to port that over to DP yourself you'll need to provide some sort of audio streaming, as well as make all the appropriate calls to let the voip stuff do its thing.
I've no idea about dp+sv_pure. again, it would be nothing more than a debug feature as its essentually completely pointless with an open source engine. If you wanted support, you'd likely need to write it from scratch.

[Danfun64]

so...what do you recommend for open source anti cheat and file consistency, if possible?

[Spike]

not possible, false security.
use user logins and reputation instead. there's no technical solution, so you'll have to depend upon social solutions instead.
we've had flamewars about this sort of thing in the past over on quakeworld.nu - it got reverse engineered about 4 times (note: this is just the times that I know of), and trivially bypassed a few times too, it contained GPLed code violating copyrights, etc. There were at least two proxies that use a 'secure' client to authenticate for a cheat client. Its really just a joke.
which is basically why I cba verifying that sv_pure actually works properly.

Incidentilly, wall-hacks on an outdoors/heightmap game? are there actually going to be enough walls for a wallhack to really be particuarly useful? or are you just trying to get rid of those pesky retexturing/remodeling projects that tend to spring up from time to time...

there's nothing you can really do about aimbots either.