"Infinite" map approach

[Chip]

How would you approach a huge, huge map, something like all original levels combined into one?

Is it possible? Does Q3BSP or BSP2 offer this?

Note #1: I've been "out of" Quake for a while and I can't exactly remember the map limitations.

Note #2: It just dawned to me that limitations might occur inside the map editor or the compiler. I'll definitely have to test some maps.

[qbism]

Yes, would be good to check some huge maps of recent years. Mind-blowing size and complexity compared to original maps. Someone actually combined episode(s) into one map iirc.

[frag.machine]

I combined all maps from episode 1 into one single .BSP once.
It was a quick and dirt task, only as a proof of concept: no monsters or items, only the bare minimal entities to allow navigation from start to end (would be interesting to allow the player to go back though).
I suppose one willing to dive into the totally boring task of refactoring the resulting huge .BSPs into the limits of Darkplaces or FTE could do the same for the other episodes and/or DM maps.

[Spike]

both q3bsp and bsp2 use 32bit data types for everything.
there are still limits, but they're generally not the file format itself.
its definitely not infinite, you'd still be expected to vis it, etc.

10000 monsters all checking to see if they can see the player 10 times a second can be quite a lot of tracelines and thus quite expensive.
Processing time does not always scale well. Many things (like monster thinks) scale linearly. Other things scale exponentially (ie: find() calls are more likely with more entities trying to search for other entities in a bigger list).
These things can often be mitigated with sensible/nonstandard gamecode logic, but this typically means more work not only for the coders but also for the mappers (setting up triggers).

both fte and rmqe support a hub system which can be used for an effectively truely massive playing area, but the catch is that it requires all players to move between maps together, and effectively pauses the other parts of the game. if backtracking in single player is your only aim, then it can work just fine.

not that long ago, I started working on a 'mapcluster' command in fte dedicated servers. essentually the server forks itself as required to host multiple maps simultaneously, and transfers players from one map to another. You still get loading screens, but the various parts of the 'map' are all running simultaneously with players in any part they want. The downside is that currently the players can't actually talk cross-map, and gamecode can't easily do so either (and needs to be modified to do some player transfer logic instead of normal map changes). Basically, it still needs lots of polish. The upside is that the player limit becomes per-map, server ticks can be throttled on individual maps that have no players or shut down(reset) completely, and gamecode could transfer a group of players to a private/instanced map (if you like grindy stuff).

[ceriux]

That's some interesting stuff spike. I used to really be into this RPG mod for Half-Life and back in the day they would talk about stuff like that. But the only way they could do it is buy and host multiple different servers. But by now they have soany different maps that, that's probably unrealistic.