Concept Idea

[toneddu2000]

Hi guys, I'll put in here, because I'm not sure what I've to do is feasible in QuakeC. I'm creating a tech demo on FTE (and MAYBE DP) and the goal is to build an environment where player[s] advances in a real time generated dungeon. I imagined a 512 units side grid. In every grid cell I spawn a random hull mesh (with walls,floor and ceiling). As you take a look at this masterpiece scheme I just realized you see the red cell is where player is, yellow cells is proximity hulls that MUST be shown, azure cells are very far and maybe low LOD's and grey cells shouldn't be renderer, because the ambient light would be 0 with only a dinamic light tied to the player. So basically it's fuXXXng dark.
All the player and monsters code(Weapon, movement,AI, physics) will be made in CSQC but imagine the "random generated level cells" part should be done in SSQC. Do you think is doable with qc or is it a C work? Anyone was involved in something similar before? There's some open source code I can steal?
Thanks in advance

PS: orientation (connections of doors and stuff) of hulls cage is still WIP, it don't even bothers me right now!

[frag.machine]

Heh, what can I say ? Yeah, it's totally possible, because that's pretty much the project I'm working on for some time: a procedurally generated open, persistent, partially destructible world composed of 256 interconected "sectors" (in a toroidal configuration as you would see in a Zelda styled world) each one composed by 256 square "cells" with 512 qu side in a 16 by 16 grid.

Everything generated by QuakeC, and being persisted using FRIK_FILE (so far the only required engine extension, so the concept should work in most modern engines). I even posted some shots and a video or two from an early prototype (it's in the 5th incarnation now) in the "what are you working on?" thread.

Every sector has a main theme (right now identified by color only in mock models, I scraped all artwork I used before and will focus on this later) and two complimentary themes so the adjacent sectors kinda "blend" in a non abrupt way. I'm off my computer right now but I suppose it's time to post some update on this later.

[toneddu2000]

Heh, what can I say ? Yeah, it's totally possible, because that's pretty much the project I'm working on for some time: a procedurally generated open, persistent, partially destructible world composed of 256 interconected "sectors" (in a toroidal configuration as you would see in a Zelda styled world) each one composed by 256 square "cells" with 512 qu side in a 16 by 16 grid.

That's right

Everything generated by QuakeC, and being persisted using FRIK_FILE (so far the only required engine extension, so the concept should work in most modern engines). I even posted some shots and a video or two from an early prototype (it's in the 5th incarnation now) in the "what are you working on?" thread.

Yeah, I don't even need the "persistence" of world. After player is passed in some sector, it could be destroyed (but, if I think a little deeper, multi-players would see different things, no.. it would be wierd! )

I'm off my computer right now but I suppose it's time to post some update on this later.

Whoa, that would be great! I don't want to steal your idea, but as a programmer I can say I'm starting right now and an initial setting could help me starting the base code. Thanks for your inputs frag.machine!

[frag.machine]

Sorry if I sounded angry or defensive, that's absolutely NOT the case - after all, I cannot claim the concept as original because I am in fact trying to mimic Minecraft procedural world generation, and I remember watching a video of another similar Quake-based indie game set in randomly generated dungeons (can't remember the name, aaargh). And of course I can share any code I developed so you can at least have a start point to your project. Maybe I should create a thread in the indie projects section and post my stuff, since I intend to recreate everything from scratch...

Yeah, I don't even need the "persistence" of world. After player is passed in some sector, it could be destroyed (but, if I think a little deeper, multi-players would see different things, no.. it would be wierd! )

Believe me, it *is* weird, and very disorientating (specially if the sectors look and feel are very different).

[toneddu2000]

Sorry if I sounded angry or defensive, that's absolutely NOT the case

No, no, you didn't sound none of them! it's only that I hate newbies that ask doing their job to others, so I didn't want to appear like one of them! I'm learning a lot thanks to all the devs here and this is my biggest challenge atm.

And of course I can share any code I developed so you can at least have a start point to your project.

Whoa, that would be great, thanks a lot!

Maybe I should create a thread in the indie projects section and post my stuff, since I intend to recreate everything from scratch...

yeah, maybe would be more polished

Believe me, it *is* weird, and very disorientating (specially if the sectors look and feel are very different).

But, when you say:"persistent", do you mean that when I disconnect and reconnect the world is still there? Or, that, as long the players are connected, the world is structured in that way?

[frag.machine]

"Persistent" as in there's a "data" folder in the mod folder where I will store the sector contents every time the player "travels" to another sector. If the destination sector was never visited before, it's generated on the fly, otherwise is just read from a data file (one file per sector). So yeah, you can play today, stop playing, and resume one month or one year later in the exact point you were.

Also, here's the link to the project thread.

[Spike]

http://www.daemonforge.org/?i=rlyehcity is another dynamically-generated content mod (for dp).
and of course, the fore-runner - frikac's bigmap mod. okay, so it has a different aim, but other than the random generation the rest is basically the same.

if you're generating the map truely dynamically such that multiplayer is screwed, perhaps you should consider ditching ssqc completely? in fte, you can set 'pr_csqc_formenus 1' and make a full single-player game without ever connecting to a server (note: I ought to test input in this mode), while dp will have to make do with a stub ssqc. not having to relay entities from ssqc all the time would help simplify the game. demos will be screwed completely, but that was bound to happen anyway when your ssqc doesn't do anything.

[toneddu2000]

"Persistent" as in there's a "data" folder in the mod folder where I will store the sector contents every time the player "travels" to another sector. If the destination sector was never visited before, it's generated on the fly, otherwise is just read from a data file (one file per sector). So yeah, you can play today, stop playing, and resume one month or one year later in the exact point you were.

Umm.. I see. This is a big difference from what I had in mind. I want that every time a player leaves a group of cells, those cells need to be "recostructured". Sure, there's the problem already said: in multiplayer it would be non-sense.. what a mess!

Also, here's the link to the project thread.

Thanks a lot man!

http://www.daemonforge.org/?i=rlyehcity is another dynamically-generated content mod (for dp).
and of course, the fore-runner - frikac's bigmap mod. okay, so it has a different aim, but other than the random generation the rest is basically the same.

much obliged for the link, thanks Spike!

if you're generating the map truely dynamically such that multiplayer is screwed, perhaps you should consider ditching ssqc completely? in fte, you can set 'pr_csqc_formenus 1' and make a full single-player game without ever connecting to a server (note: I ought to test input in this mode)

Ummm... you're tempting me..

while dp will have to make do with a stub ssqc.

Atm, I'm creating a tech demo that shows FTE's beauty so DP compatibility is my least problem

not having to relay entities from ssqc all the time would help simplify the game. demos will be screwed completely, but that was bound to happen anyway when your ssqc doesn't do anything.

Yeah, don't need demos!

I tried R'lyeh City and it's an awesome mod, no doubt. The creation at startup of the dungeon, the inventory, all super cool stuff.. but the performance are... terrible. The generated map (with standard options) literally took my pc on the ground. 30 fps outside and 11 into the dungeons. This is something I need to care about A LOT. I want to create static meshes (into the cell) with some sort of vis portal shader applied, so to mantain a decent frame rate

[frag.machine]

Yeah, all those unVISed BSP entities can easily make a decent machine to crawl (let alone more modest/older hardware). This is far less problematic in topdown/isometric perspective though.

[Spike]

tbh its large unvised rtlights that really kills framerates in that mod.

[toneddu2000]

Yeah, all those unVISed BSP entities can easily make a decent machine to crawl (let alone more modest/older hardware). This is far less problematic in topdown/isometric perspective though.

I wonder if with static meshes the situation would be better or worse

tbh its large unvised rtlights that really kills framerates in that mod.

yeah, I imagined that .
I'm completely ignorant about visibility in Quake engine (in every engine, must admit) so I would like to ask: "there ìs a way, only with static meshes, to create hulls of meshes with shaders applied, that seal their sectors, so that lights lit only their own sectors?"

[qbism]

Rtlights are probably the only good-looking way to light models in a qc-generated environment, unless bsp model lighting, tile spacing, and lighting of the world floor align on a grid. This is because alias models (like monsters) are illuminated based on the pointlight of the world below and not the floor of the bsp model they're standing on.

[toneddu2000]

indeed, infact I'll use only RTLights, my only doubt is if it's possible to create through shaders a "vis cage" around the light and the portion of meshes it can lit, so to optimize lighting and frame rate (pardon my raw terms)

[Spike]

with a q3bsp shell thing, you could chop the world into an 8*8 grid of 'areas', with some entity sitting between each two areas. you can then use the openportal builtin to open/close the portal between the two areas. if the portal is closed, vis is blocked too. lights behind the portal will no longer be drawn. this is what q2/q3 use on doors to dynamically close the pvs.
the 8*8 grid is because there's a limit to the number of areas you can have. in theory I could boost it to 256*256, but that's a loooot of memory, and even more entities to track the portals (though I guess with q3bsp you could just use setorigin to find the two areas dynamically, which might help reduce the number of entities).

[toneddu2000]

with a q3bsp shell thing

What's that? I mean, I know (partially) what q3bsp is (it should be the Quake3 map to bsp compiler, right? - but I can't distinguish it from q3map2), but I completely ignore what is a "q3bsp shell"!
wait, for shell, do you mean shell command? Like a q3bsp command sent via command line? So it's something that is precompiled, not dynamically created at runtime, right?

you can then use the openportal builtin to open/close the portal between the two areas

I searched for "openportal" in csqctest but I didn't find anything. Sorry but I couldn't find it.

if the portal is closed, vis is blocked too. lights behind the portal will no longer be drawn. this is what q2/q3 use on doors to dynamically close the pvs.

Sure, that'd be great!

the 8*8 grid is because there's a limit to the number of areas you can have. in theory I could boost it to 256*256, but that's a loooot of memory, and even more entities to track the portals (though I guess with q3bsp you could just use setorigin to find the two areas dynamically, which might help reduce the number of entities).

Well, it could be fine. I just delete every sector far from player, once the player left the "neighbour sectors" (grey squares)

Tonight I had an idea: to avoid that other players could see different sectors I set a rule. Once the game has started, first player connects (this maybe will be a little complicated to code) is the Leader. Other 3 players (for a total of 4 players like Left4Dead)that connect after him MUST follow him and don't lose him! If a player is outside gray bounds when the player run, he dies. So game will be DEFINITELY a coop mode and every player will see the same group of sectors!
What do you think guys?

EDIT: I was thinking... but if I delete the group of sectors when it's not needed anymore, lights would be deleted too, right? So the light computation would be always of 3/4 rtlights into a 512/1024 environment at time, right?