Concept Idea
-
- Posts: 1395
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
Concept Idea
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!
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!
Meadow Fun!! - my first commercial game, made with FTEQW game engine
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Re: Concept Idea
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.
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.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)
-
- Posts: 1395
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
Re: Concept Idea
That's rightHeh, 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.
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! )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.
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!I'm off my computer right now but I suppose it's time to post some update on this later.
Meadow Fun!! - my first commercial game, made with FTEQW game engine
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Re: Concept Idea
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...
Believe me, it *is* weird, and very disorientating (specially if the sectors look and feel are very different).tonnedu2000 wrote: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 know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)
-
- Posts: 1395
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
Re: Concept Idea
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.Sorry if I sounded angry or defensive, that's absolutely NOT the case
Whoa, that would be great, thanks a lot!And of course I can share any code I developed so you can at least have a start point to your project.
yeah, maybe would be more polishedMaybe I should create a thread in the indie projects section and post my stuff, since I intend to recreate everything from scratch...
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?Believe me, it *is* weird, and very disorientating (specially if the sectors look and feel are very different).
Meadow Fun!! - my first commercial game, made with FTEQW game engine
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Re: Concept Idea
"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.
Also, here's the link to the project thread.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)
Re: Concept Idea
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.
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.
-
- Posts: 1395
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
Re: Concept Idea
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!"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.
Thanks a lot man!frag.machine wrote:Also, here's the link to the project thread.
much obliged for the link, thanks Spike!Spike wrote: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.
Ummm... you're tempting me..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)
Atm, I'm creating a tech demo that shows FTE's beauty so DP compatibility is my least problemwhile dp will have to make do with a stub ssqc.
Yeah, don't need demos!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.
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
Meadow Fun!! - my first commercial game, made with FTEQW game engine
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Re: Concept Idea
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 know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)
Re: Concept Idea
tbh its large unvised rtlights that really kills framerates in that mod.
-
- Posts: 1395
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
Re: Concept Idea
I wonder if with static meshes the situation would be better or worsefrag.machine wrote: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.
yeah, I imagined that .Spike wrote:tbh its large unvised rtlights that really kills framerates in that mod.
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?"
Meadow Fun!! - my first commercial game, made with FTEQW game engine
Re: Concept Idea
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.
-
- Posts: 1395
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
Re: Concept Idea
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)
Meadow Fun!! - my first commercial game, made with FTEQW game engine
Re: Concept Idea
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).
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).
-
- Posts: 1395
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
Re: Concept Idea
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"!with a q3bsp shell thing
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?
I searched for "openportal" in csqctest but I didn't find anything. Sorry but I couldn't find it.you can then use the openportal builtin to open/close the portal between the two areas
Sure, that'd be great!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.
Well, it could be fine. I just delete every sector far from player, once the player left the "neighbour sectors" (grey squares)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).
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?
Meadow Fun!! - my first commercial game, made with FTEQW game engine