Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Simon Riley

Forking GZDoom for (true) Open World

Recommended Posts

Lately I have been looking at some large maps like D_O_R_v1_2.pk3, and I was wondering, what would need to be done to GZDoom or LZDoom in order to make it support true open-world maps?

 

As in, no matter how massive the map is, the engine would still be able to run it, even on older hardware?

Share this post


Link to post

You won't be able to do this without a fundamental redesign of how Doom works. And even then, on older hardware you'll stand no chance, because the limiting factor on it is polygon throughput in the GPU, once you hit the limit here all the magic in the world won't be able to make things faster. Quite the contrary in fact, when I added an optimization based on the same principle for single sectors the results were that on old hardware it become slower, on not quite old hardware it did not matter and only on recent mid to high end hardware it provided a performance increase. And it was this optimization that caused the split of the vintage build and LZDoom.

In short: on older hardware you need to cull as much stuff to draw as you can, even if it takes time to do that.

 

On newer hardware it would be possible to render the entire level as a single mesh - this however is easier said than done because Doom allows altering the map geometry at run time with doors, lifts and such. So you are going to need a large piece of information about which parts in the map are unchanging and which can change before creating such a static mesh - information which does not exist and for complex maps with ACS and ZScript cannot even be compiled because it's impossible to know which sector can move and which cannot, and which texture can change and which not, and light levels, sector colors, fog colors and several other properties you can set on a sector or wall.

Share this post


Link to post

So, it wouldn't be possible to add in level streaming, limiting the draw distance, or other methods?  Only rendering a certain area around yourself as needed?

Share this post


Link to post

Well for a start, the entire Doom engine is not geared for open world.

 

If you look at an open world game like Arena or Daggerfall (about the same age as Doom, Arena is from1994 and Daggerfall from 1996), you'll notice that the world is split into large square cells. In Arena these cells are subdivided into square tiles that are similar to those from Wolf 3D, but more advanced (varying floor and ceiling heights, possibility of "3D-floor" like bridges, sky projection, fully textured, etc.) while in Daggerfall you get a heightmap.

 

The key aspect of this cell approach is that they allow you not to load the entire world at once. You only need to load the cell the player is in, and a ring of cells around it -- perhaps the eight surrounding cells. When the player crosses a cell boundary, you unload the cells that are no longer "within range" and load those that have just entered it.

 

The Doom engine, on the other hand, works with entirely self-contained closed worlds. They're made out of sectors, as we all know, and stored in a BSP tree structure. The entire level is always loaded.

 

What you can sorta do is try to emulate the functioning of an open world game with hubs. @GooberMan worked on creating Half-Life-like seamless transitions in hubs, so you can take a look at the ACS in the Gateway Experiments. Here's how you'd do it:

  1. Conceptually, split your maps into nine parts, using a 3x3 grid approach.
  2. Only put gameplay elements in the center part. The player is not supposed to get to the surrounding eight parts.
  3. Turn the boundaries into level transitions, using the seamless transition system GooberMan designed.
  4. Create the eight maps for the eight surrounding parts.
  5. Always copy-paste the geometry from a part to the other maps where appropriate.
  6. And of course, don't forget to make it a hub.

So you'll get a lot of copy-pasted stuff, but this way you can roughly replicate the effect. And this will give you the ability to load and unload things so that the world size is virtually unlimited.

Share this post


Link to post
7 minutes ago, Gez said:

The key aspect of this cell approach is that they allow you not to load the entire world at once. You only need to load the cell the player is in, and a ring of cells around it -- perhaps the eight surrounding cells. When the player crosses a cell boundary, you unload the cells that are no longer "within range" and load those that have just entered it.

 

The Doom engine, on the other hand, works with entirely self-contained closed worlds. They're made out of sectors, as we all know, and stored in a BSP tree structure. The entire level is always loaded.

 

I know that it's a silly question to ask, but wouldn't it be possible to do something similar with those sectors?  Loading and unloading sectors?

 

I had a few project ideas that would use open world Doom:

 

1.  Doom 2's own Battle Royale mode.

2.  A more realistic survival game similar to the Long Dark, but supports multiplayer.  Hence why I'd want it to be a true open world, because I don't know if a pseudo-open world would support multiple players being in different levels.

Share this post


Link to post

Short answer: no.

 

The way Doom works the entire map needs to be loaded at all times. The renderer works on data structures that cannot be split up that way, as does the play engine. You essentially need a completely new renderer and a massively altered play engine to achieve that.

 

Share this post


Link to post

Oh, if you want it to be multiplayer, then no, forget about it. That's going to bring in so many complications.

 

For example, multiplayer games stay synchronized in the same way that demos stay synchronized: by only sending player inputs. Everything else -- from monster actions to script results -- is deterministic so each "client" (not the proper terminology since it's not a client/server model) can figure out what happened as long as they know what each player did. But now you take this model, and you throw in it the big wrench that is "some monsters are not going to be active because they're in sectors that are not loaded for player 1, but they'll be loaded and active for player 2, have fun keeping things in sync!"

 

Also, GZDoom multiplayer is limited to 8 players anyway.

 

Now maybe you could try Zandronum instead. It's got a client/server network architecture and a max player count of 255 I believe. But even then, you'll still need to entirely rewrite the renderer and worldsim.

Share this post


Link to post

Great. Now I know to do such projects in a different engine.  Unless people want to throw around crazy ideas on how to rewrite the Doom engine.

 

Thanks for patiently explaining these things to me.  <:3

Edited by Mike Anderson

Share this post


Link to post

The idea sounds good, but I think you should first have the mega-maps before you modify an engine to suit them. Maybe for your game you won't need more than what DOOM supports.

Share this post


Link to post

You don't necessarily need all that cell loading to have an open world. I really liked the way Strife was organized, it felt close to being an open world fps, at least back in 1996. I loved that if you messed around in the city you could get all the guards to attack you and essentially break the game. I think what gives me the feeling of an open world is the freedom to mess around and move between areas, the transitions between zones do not necessarily need to be seamless.

 

Though I'm not sure how the hub system works in multiplayer.

I'm guessing as soon as a player activates an exit all players will go to the corresponding map no matter where they are at, so you probably can't have players in different maps simultaneously.

Share this post


Link to post
51 minutes ago, Ferk said:

You don't necessarily need all that cell loading to have an open world. I really liked the way Strife was organized, it felt close to being an open world fps, at least back in 1996. I loved that if you messed around in the city you could get all the guards to attack you and essentially break the game. I think what gives me the feeling of an open world is the freedom to mess around and move between areas, the transitions between zones do not necessarily need to be seamless.

 

Though I'm not sure how the hub system works in multiplayer.

I'm guessing as soon as a player activates an exit all players will go to the corresponding map no matter where they are at, so you probably can't have players in different maps simultaneously.

I think by "open world" he's referring to something more along the lines of Elder Scrolls, Fallout, etc.

 

But if he doesn't mind the hub system (like Strife/Hexen) then yeah that's obviously doable.

Share this post


Link to post

i second Graf here. you *can* change some sourceport to work with streamed cell-based world (but forget about network, unless it is a client/server port), but after you done with that, there won't be any Doom code inside. that is, it is way easier to write a 2.5D engine from scratch with your project requirements in mind than to bend Doom tech to that. also, map editing will not be the same, so you'll have to modify (read: rewrite) some map editor, and essentially build a new content creation pipeline.

 

while doing this may be interesting from programmer's PoV, this is prolly not what you want to do, amirite? ;-) so at this stage it is better to go with some other engine that has all the tech you need.

Share this post


Link to post
4 hours ago, Mike Anderson said:

We already explained why the hub system wouldn't work for what I want to do with it.

Then abandon all hope ye who enter Doom Engine. Better to stick with Unity or roll your own engine or something then, because essentially by the time you finished modding a sourceport to support a true open world, you'd have broken all sorts of fundamental assumptions all source ports make about the level data and at that point it basically ceases to be something anything but your own port could access or make use of.

Share this post


Link to post

also, the closest thing to "open world game with Doom engine" is prolly Scattered Evil. it is still hub-based, and doesn't support multiplayer, but i believe that it is as close to "multimap open world" as you can get even with highly modified id tech 1.

Share this post


Link to post
3 hours ago, ketmar said:

the closest thing to "open world game with Doom engine" is prolly Scattered Evil.

It'd probably actually be Hexen and Strife, with all the caveats already said in the thread.

Share this post


Link to post

Some time ago Graf was actually working on refactoring map handling in the hope of allowing several maps to be loaded at once. But some of the issues couldn't be resolved.

Share this post


Link to post

I wonder how Diablo (1996) managed hub multiplayer. You're always in one of the 17 areas and whenever you exit one, you need to wait a pretty long loading time, so they're probably not left in RAM. But in multiplayer, all 4 players can roam any map of the hub without disturbing the others. I'd like to see this capability in the DOOM engines some day.

Share this post


Link to post

Well if you design an engine to be able to load several zones at once, it'll be able to do that much better than if you design an engine to load only one zone at once and then try to retrofit it into loading several zones at once. A big part of the problem in extending the Doom engine for that kind of things is the reliance on global variables. I'm sure that with your work on Eternity fixing portals and vanilla demo compatibility you've ran into the kind of issues this creates several times.

Share this post


Link to post

I still enjoy singleplayer open world games. As long as you are not thinking MMO with a hundred players (which would not work anyway) I don't think it's such a problem to organize with a small group of friends to move on to a different area together. Combine that with having relatively big maps (as long as you are not targeting a potato I expect you could still go over vanilla limits) and I think it would not be a huge issue, if the content of the game was good I expect it would still be fun.

 

Something that could perhaps be made is requiring all players to be near the exit in order to change maps so there are no unexpected changes, or have some sort of voting system.

Edited by Ferk

Share this post


Link to post

actually, in Vavoom all map data is already incapsulated in VLevel class, and each thinker has the link to the corresponding Level object. the same with some other game info. there are some global vars yet, tho, but not that many. that is, making k8vavoom to have several maps loaded and simulated shouldn't be that hard to implement, as Janis already did most of the work for me. ;-)

 

still, the engine have to do all simulations in a single thread due to VM (and i broke networking, oops), so simulating a huge world will be very slow. but i may try it in some distant future (when i'll finish other features i want to implement, i.e. somewhere around year 2442).

Share this post


Link to post

 

 

23 minutes ago, ketmar said:

actually, in Vavoom all map data is already incapsulated in VLevel class, and each thinker has the link to the corresponding Level object.

 

I did the same earlier this year in GZDoom but it's not fully workable, because too much code still relies on global access to these, most importantly ZScript.

When starting with a code base that takes global singletons for granted, it can be a gargantuan task to undo this.

Share this post


Link to post
1 hour ago, Ferk said:

Something that could perhaps be made is requiring all players to be near the exit in order to change maps so there are no unexpected changes, or have some sort of voting system.

"You must gather your party before venturing forth.

You must gather your party before venturing forth."

 

Even though I said "I'd like to see this cool multiplayer thing in DOOM", my difficulty with implementing any such capability is that I need buddies to playtest with (I might use my bot though...)

Share this post


Link to post
1 hour ago, Graf Zahl said:

When starting with a code base that takes global singletons for granted, it can be a gargantuan task to undo this.

yeah. yet i mostly finished it in k8vavoom. what is left are mostly various temp buffers which reused for some calls (like hitscan tracing). Janis had to convert most of those things, so his serialisation engine can simply serialise VM objects. even current game settings and flags were put into separate class for serialiser. and as there are no globals in VavoomC at all (and no static fields; that's why each thinker holds a reference to a level object), most of the code is "multilevel-ready".

 

of course, making finishing touches to make it actually work may take at least as much time as all previous conversion took -- we're talking about Doom codebase after all! ;-)

Share this post


Link to post
11 hours ago, Graf Zahl said:

Luckily it's only the Doom code base. If this was Duke Nukem 3D it'd be ten times worse... ;)

 

What would it be Like then? I would Love to Hear it!

Share this post


Link to post
11 hours ago, Graf Zahl said:

Luckily it's only the Doom code base. If this was Duke Nukem 3D it'd be ten times worse... ;)

with D3D code it is actually much easier, only 3 steps required.

1. try to do that.

2. go to asylum.

3. stay there for the rest of your life.

 

p.s.: i thought about polymost-like renderer for k8vavoom. and i understand what polymost is doing, but cannot make heads or tails out of Ken's code. not that i was going to use it anyway, and i have my own GPL implementation of the basic algo, but i thought that i'd be able to learn something new there... and i actually did! i learned to never look into Ken's code, it has no sense.

Edited by ketmar

Share this post


Link to post
5 hours ago, ketmar said:

with D3D code it is actually much easier, only 3 steps required.

1. try to do that.

2. go to asylum.

3. stay there for the rest of your life.

 

I think the Duke Nukem game code is even worse than the Build engine. It looks like if this was Doom you'd take all the A_*functions from p_enemy.cpp and put them into a huge switch/case block and signify which one is to be called by putting a magic number somewhere. But considering that DN3D has a lot more variety in actor and sector actions than Doom, these end up being huge walls of code with poor commenting and worse structuring.

 

 

Share this post


Link to post
7 hours ago, ketmar said:

and i actually did! i learned to never look into Ken's code, it has no sense.

 

Yeah, even as a non-programmer that's not a difficult conclusion to reach... I've seen various pieces of code posted by Graf and... I wonder how could the developers of the Build games as well as the source ports work with that cryptic stuff.

 

Never seen so many "if"s in just a couple of lines of code either.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×