<!--quoteo(post=1744289:date=Dec 19 2009, 08:48 AM:name=Chris0132)--><div class='quotetop'>QUOTE (Chris0132 @ Dec 19 2009, 08:48 AM) <a href="index.php?act=findpost&pid=1744289"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->That depends on how the vis works, if nothing else I could just encase the room in a simple block of world geometry which is fairly basic practise in source anyway, you encase each area of an outdoor map in its own skybox block.<!--QuoteEnd--></div><!--QuoteEEnd-->
I assume you mistakenly worded that. Encasing outdoor areas in skybox blocks is one of the worst newbie techniques in level design. Even outdoor areas are meant to be build with ceilings of sky, not where you actually put a big box around the entire area... which happens to be exactly what we're talking about with this module-based randomized level.
It's slighty different with this case since the VIS would see right through the main map part since it's an entity; with the newbie sky box technique, the main level is still doing its normal vis stuff so you get all that leaf data plus the additional leaf data and face drawing of the outside, unseen areas.
But, it's not exactly a benefit, since although you lose the leaf data altogether, you now draw everything in sight and beyond (since you'd see through the walls and through whatever small doorways lead to the adjoining module areas).
Basically, it would be very, very hard on the engine, unless one of two things. (1) you make small 'vis block hallway sections', where there is a small transition hallway between each room section that actually blocks line of sight, or (2) the Spark engine somehow manages to do on-the-fly vis calculations. But the whole reason that Source uses that system is to optimize their maps by doing all those calculations during the compile process rather than real-time. Spark seems like it will be pretty damn expensive on the CPUs, so I guess we'll have to see what route Max takes.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Presumably, if the editor is to be wysiwig, then it must be able to handle vis calculations, and that means vis calculations must be doable on the fly. Also as large parts of the level are prop based it means that props must be able to do vis calculations. If you're not using precompiled vis calculations I don't think it hugely matters whether the geometry is spawnable or not, you could write Lua to define a special entity which still affects visibility and is spawnable.<!--QuoteEnd--></div><!--QuoteEEnd-->
There's a big difference between WYSIWYG in the editor and in-game. Editors are allowed to be slower (<60 fps) and don't have nearly all the additional performance hogs such as multiple characters and weapons, their multitude of animations, all the special effects and audio, etc. Vis calculations are often pre-compiled to max out performance for all those other things.
I don't actually know where Spark will go with this, but you can't simply assume that vis will be done at runtime.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Collision doesn't have to be a problem, there's no problem with collision on func_brushes in source because if they don't move you can compile special collision or something. Plus NS2 will probably handle collision on dynamic objects anyway because it has the trams which are supposed to be in the game. And NS1 also featured lots of lifts.<!--QuoteEnd--></div><!--QuoteEEnd-->
You're talking about two totally different implementations here. Func_brushes in Source are great for small uses and for things like elevators, but they were never intended to be used for the entire level geometry. Also, things like lifts and trams are almost always made to be as slow-moving as possible to lessen the collision issues. Have you ever noticed how buggy lifts look in NS when players are on them and the lift moves quickly? And just think about all the Rotating Door / Floor issues.
With the trams, I wouldn't be surprised if they moved fairly slowly and were specifically designed so as to not interact with much else. As in, DI, structures and chambers would probably be forcibly restricted from being placed / built anywhere they would collide with the tram (including on them). Sure it could be cool to place a TF and turrets on a tram and then drive it all around, but I'm guessing the collision issues would make it too crappy to be kept for the release.
But like I said, if you really want to take on such a massive and time-consuming project, power to ya. I'd love to play it if it works out. Just realize that this would probably be about 10x the work of making a normal level, which itself is quite a feat to complete.
Dynamically placing rooms is probably possible. However, would probably require more work than it's worth when you can make a large static map and dynamically open/close pathways. Maybe not quite as dynamically/random exciting, but effective enough.
For a SP mod where you want replayability, make a larger map with lots of interconnectivity and cut off paths to make it novel each round. Or, leave the paths open but make 'routes' via the objectives. That's how I'd do it for sure.
Wait a moment... Why does the room allocation have to be random?
Get everyone who maps in the community to build a room which fits a certain specification.
For example: Must use THIS corridor as ALL exits and have a downloadably corridor. (thus allowing them all to fit together.) All vents must use these dimensions. All new textures must put with the map. NO excessive use of lighting or particle effects.
Then manually put them together in 10 different ways.
You can then pick to play one of the ten different maps...
<!--quoteo(post=1744385:date=Dec 20 2009, 04:36 AM:name=spellman23)--><div class='quotetop'>QUOTE (spellman23 @ Dec 20 2009, 04:36 AM) <a href="index.php?act=findpost&pid=1744385"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->So, in summary....
Dynamically placing rooms is probably possible. However, would probably require more work than it's worth when you can make a large static map and dynamically open/close pathways. Maybe not quite as dynamically/random exciting, but effective enough.<!--QuoteEnd--></div><!--QuoteEEnd-->
No, what I'm suggesting is doing that, except also, having a few different options for some rooms.
The layout doesn't change, although some paths will open and close so the layout will SEEM to change, but in actuality it's just some corridors being unnoticably walled off, and some rooms are not the same as before.
I'm not suggesting completely randomly generating the map, just having a few different options for rooms because if you build a giant base you're going to have a lot of ground to cover, whereas replacing rooms allows you to keep the same variety in a more compact space, and considering the more room versions you make the more variety you have, you don't have to keep making bigger and bigger bases to increase variety.
There is also the possibility of having special rooms, like rooms with a big lift in them that allows access to a second level of the base, and that room could be randomly positioned or sometimes not there at all, so it's not just a matter of finding the path through the same base, but each base would really feel entirely different each time, because you have to explore every area and sometimes there might be quite a few more areas than normal, such as the elevator, or maybe even access to another tram station, or a long tunnel to another base which isn't there all the time, and maybe that base is inaccessable from the main tram line this time so you have to use the tunnel, and part of the game revolves around trying to gain access to this hidden base so you have to search all the bases for the tunnel.
It makes the entire game different every time, rather than just 'explore base kill aliens'.
<!--quoteo(post=1744361:date=Dec 19 2009, 09:26 PM:name=StixNStonz)--><div class='quotetop'>QUOTE (StixNStonz @ Dec 19 2009, 09:26 PM) <a href="index.php?act=findpost&pid=1744361"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I assume you mistakenly worded that. Encasing outdoor areas in skybox blocks is one of the worst newbie techniques in level design. Even outdoor areas are meant to be build with ceilings of sky, not where you actually put a big box around the entire area... which happens to be exactly what we're talking about with this module-based randomized level.
It's slighty different with this case since the VIS would see right through the main map part since it's an entity; with the newbie sky box technique, the main level is still doing its normal vis stuff so you get all that leaf data plus the additional leaf data and face drawing of the outside, unseen areas.
But, it's not exactly a benefit, since although you lose the leaf data altogether, you now draw everything in sight and beyond (since you'd see through the walls and through whatever small doorways lead to the adjoining module areas).
Basically, it would be very, very hard on the engine, unless one of two things. (1) you make small 'vis block hallway sections', where there is a small transition hallway between each room section that actually blocks line of sight, or (2) the Spark engine somehow manages to do on-the-fly vis calculations. But the whole reason that Source uses that system is to optimize their maps by doing all those calculations during the compile process rather than real-time. Spark seems like it will be pretty damn expensive on the CPUs, so I guess we'll have to see what route Max takes.
There's a big difference between WYSIWYG in the editor and in-game. Editors are allowed to be slower (<60 fps) and don't have nearly all the additional performance hogs such as multiple characters and weapons, their multitude of animations, all the special effects and audio, etc. Vis calculations are often pre-compiled to max out performance for all those other things.
I don't actually know where Spark will go with this, but you can't simply assume that vis will be done at runtime.<!--QuoteEnd--></div><!--QuoteEEnd-->
No I worded it correctly, you put a big skybox block over the top of the area and join it to the walls. Obviously you don't put it under the floor because the floor should be world geometry but essentially any area in source is a box made out of world geometry with stuff inside it. You can add additional visblocking geometry but usually each area is a sort of room anyway because long corridors aren't much fun to play in and they're hard to optimise.
All you have to do is ensure the room doesn't lag when you look at it, which you have to do anyway because a room is the basic rendering block of any map, those rooms in the screenshot thread are going to be mostly rendered all the time you're in them. there isn't much you can do to optimise it in terms of occlusion, you just have to not put too much stuff in it at once. As each room will be connected to corridors and the corridors don't need to be random the room will be mostly rendered and then the corridors can occlude the next room. Which is exactly how it works in a normal map.
Spark has already been stated to use on the fly occlusion culling. <a href="http://www.unknownworlds.com/ns2/news/2009/03/occlusion_culling" target="_blank">http://www.unknownworlds.com/ns2/news/2009...clusion_culling</a>
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec--><b>Because the data is precomputed, the environment can't change much at run-time.</b> And finally the PVS method is not very good when it comes to outdoor scenes. <b>To alleviate all of these problems,</b> we've chosen to use a hardware assisted occlusion culling method that <b>doesn't require precomputation.</b><!--QuoteEnd--></div><!--QuoteEEnd-->
And I have already stated that even if that were not the case, it could be easily worked around.
<!--quoteo(post=1744361:date=Dec 19 2009, 09:26 PM:name=)--><div class='quotetop'>QUOTE ( @ Dec 19 2009, 09:26 PM) <a href="index.php?act=findpost&pid=1744361"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You're talking about two totally different implementations here. Func_brushes in Source are great for small uses and for things like elevators, but they were never intended to be used for the entire level geometry. Also, things like lifts and trams are almost always made to be as slow-moving as possible to lessen the collision issues. Have you ever noticed how buggy lifts look in NS when players are on them and the lift moves quickly? And just think about all the Rotating Door / Floor issues.
With the trams, I wouldn't be surprised if they moved fairly slowly and were specifically designed so as to not interact with much else. As in, DI, structures and chambers would probably be forcibly restricted from being placed / built anywhere they would collide with the tram (including on them). Sure it could be cool to place a TF and turrets on a tram and then drive it all around, but I'm guessing the collision issues would make it too crappy to be kept for the release.
But like I said, if you really want to take on such a massive and time-consuming project, power to ya. I'd love to play it if it works out. Just realize that this would probably be about 10x the work of making a normal level, which itself is quite a feat to complete.<!--QuoteEnd--></div><!--QuoteEEnd-->
The reason players jerk around in NS is because moving geometry does not have lag prediction, not because of collision errors, players would move like that on world geometry if basic movement didn't have lag prediction. WHen the world moves a player it takes a while for the position to update and the player jumps there when it does, when a player moves a player the computer MOVES the player there so what you experience is not a jump, but simply a delayed version of what the player already did, this is why you get people complaining about being behind a crate and getting shot in CS due to 'lag', because their latency means that the person who shot them did so before they got behind the crate on the shooter's computer, but on the shootee's computer there is no lag so they were already behind the crate, however the server compensates for lag by allowing the client the shot, otherwise you would always be shooting slightly behind people if they were moving.
The room geometry does not have to move, and so it shouldn't have prediction problems, plus as NS2 is being designed with moving trams and lifts I would imagine they are adding lag prediction to those things. Something being spawnable and something being baked into the level does not mean the two are entirely different, it does in source but that's because source is source, source lights models and world brushes entirely differently as well but spark does not, it's entirely up to how the engine is built.
Considering how many iterations I go through in source when I'm making a level, making it when I can actually see what I'm doing and have a grand set of props to play with and don't have to set up all the hyperplanes manually so that it doesn't crap out when I compile it, it should be easy.
<!--quoteo(post=1744422:date=Dec 20 2009, 09:32 AM:name=Chris0132)--><div class='quotetop'>QUOTE (Chris0132 @ Dec 20 2009, 09:32 AM) <a href="index.php?act=findpost&pid=1744422"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->No, what I'm suggesting is doing that, except also, having a few different options for some rooms.
....
It makes the entire game different every time, rather than just 'explore base kill aliens'.<!--QuoteEnd--></div><!--QuoteEEnd-->
So, closer to what PsympleJester is suggesting? Swap in and out rooms (yay templates) and the occasional zomg special room?
Personally it sounds quite intense, and more power to ya if you pull it off. But people seem adequately satisfied with the L4D2's idea of "dynamic" levels and it sounds like much less work.
Work is subjective, just because you can get away with something crap doesn't mean you should. I'd rather do something difficult and good than easy and crap.
Besides I can quite happily keep making content and adding it to a map until the engine falls to bits so it doesn't bother me. In a sense it is also <i>more</i> efficient than making many different maps because let's say I make two maps worth of content in the form of room randomisation and optional areas, the random combination of these areas would produce closer to three map's worth of playability, because you have two unique maps and then a mix of the two, it is unlikely that a person would see every confiuguration until they had played it quite a lot and just a little 'oh that's new' or 'oh I didn't realise that passage was there' is enough to make the same approximate layout feel quite new.
Each map takes more effort to make, but in contrast you need fewer of them, as each area of the map can have a different theme and would be randomised and the objective changes each time and the enemies are a bit different and the hive room is in a different place each time and the route through is different and you find different pickups and your base camp is in a different place and basically I just listed everything that makes a map, so the entire map is different. Geometry, starting locations, goals, enemies, and tools all change, that's what makes nova prospekt different from ravenholm.
In fact, I would go so far as to suggest no more than two or three maps for the entire game with this structure. If you want to make more maps you should include some major change, three maps with a decent amount of layout changes, bases, and randomised rooms would pretty much cover the entire spectrum of 'bases linked by tram'. So you should be using additional maps to change things which cannot be altered otherwise, such as incorporating the entire map into a large spaceship and instead of tram connections you have to work to bring new sections of the ship online and accessable. The huge density of the geometry on that sort of map would make it feel utterly enormous, combining all the base and interconnecting space geometry from a tram map into a smaller area. A full ship realised in complete detail with all different access tunnels and sections for different tasks and an interconnecting power system, along with occasional vistas from observation decks of a vast planet around which the ship is orbiting, that would give a real sense of epic scale which hasn't been done before, and it would make it quite different from the tram maps.
My main worry is engine limits, I hope they are not as severe as HL2 Episode 2, hopefully the heavy use of prop instanced geometry and dynamic lighting will mean they are not.
Hats off if you can get that to work, it's a lot of work. But certainly, it's a great community project if people can participate in creating the mod by creating the modules for it.
when I was reading through this thread, I realised, why bother with making everything in one map? from the editor it seems that loading a map doesn't take very long (a few sec max afaik?), and seeing as it was said that the editor worked exactly the same in terms of lighting as the final game, isn't it fair to conclude that it would be viable to split up the game in more than one map?
and what brushes have to do with spark I have no idea, the whole point of spark is that it uses faces instead of brushes, lighting is always dynamic, so lightmaps aren't an issue?
but to add something constructive, I'd be willing to help with making custom models
<!--quoteo(post=1744504:date=Dec 21 2009, 11:02 AM:name=Triggerman)--><div class='quotetop'>QUOTE (Triggerman @ Dec 21 2009, 11:02 AM) <a href="index.php?act=findpost&pid=1744504"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Hats off if you can get that to work, it's a lot of work. But certainly, it's a great community project if people can participate in creating the mod by creating the modules for it.<!--QuoteEnd--></div><!--QuoteEEnd-->
I was planning on doing all the mapping myself but it would certainly lend itself to communal mapping more than a lot of maps because you can give someone a room and tell them to make a lot of different variations, without having to worry about them changing the layout or interfering with other parts of the map. It breaks down into components quite nicely.
<!--quoteo(post=1744513:date=Dec 21 2009, 02:08 PM:name=Biglines)--><div class='quotetop'>QUOTE (Biglines @ Dec 21 2009, 02:08 PM) <a href="index.php?act=findpost&pid=1744513"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->when I was reading through this thread, I realised, why bother with making everything in one map? from the editor it seems that loading a map doesn't take very long (a few sec max afaik?), and seeing as it was said that the editor worked exactly the same in terms of lighting as the final game, isn't it fair to conclude that it would be viable to split up the game in more than one map?
and what brushes have to do with spark I have no idea, the whole point of spark is that it uses faces instead of brushes, lighting is always dynamic, so lightmaps aren't an issue?
but to add something constructive, I'd be willing to help with making custom models<!--QuoteEnd--></div><!--QuoteEEnd-->
If you have multiple maps you need multiple servers running it persistantly, otherwise people have to stick together to do anything and that kinda kills the immersion.
<!--quoteo(post=1744534:date=Dec 21 2009, 02:36 PM:name=Chris0132)--><div class='quotetop'>QUOTE (Chris0132 @ Dec 21 2009, 02:36 PM) <a href="index.php?act=findpost&pid=1744534"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->If you have multiple maps you need multiple servers running it persistantly, otherwise people have to stick together to do anything and that kinda kills the immersion.<!--QuoteEnd--></div><!--QuoteEEnd--> not really, l4d also uses multiple maps in the same campaign, by having airlock type areas that lead to the next map
I think a big thing you might be missing in this discussion Chris, is that levels simply aren't meant to be made this way.
Levels and their code base are geared towards the levels being 99.9% static, which a few rare moving parts (such as elevators, doors and trams). Even levels that appear to be moving, like all those Train levels found in many games, are static with blocked off geo (no player collisions) that moves by.
You can't just say that something can work. I think the only person who can say if it would actually work would be Max. If we don't hear from max, I think it's more than safe to say that it wouldn't work, or at least not without massive headaches along the way that make the end result not worth the process.
You can't just say that mesh which is coded to be static, can just be moved around and spawned in/out without any problems. That function has to be coded in. You can bet that if Max had been building the level editor with this concept in mind, he would have done at least a few things differently. Having built the engine without that in mind, it would take much more work to integrate it into the current system that was built for a different functionality.
I do agree that it would probably be a lot easier to do in Spark than in Source. I think it may even be almost impossible in source, or at least impossible to do properly (i.e. without raising the system load by %50+).
As for using multiple maps to divide up sections, there's absolutely nothing wrong with that. The end of one map initializes the next. That way you can have a series of levels with 5-10 mins of gameplay each, rather than a big with 30-60. L4D is, as mentioned, a great example. You don't need multiple servers (per full campaign) whatsoever.
<!--quoteo(post=1744540:date=Dec 21 2009, 08:29 PM:name=Biglines)--><div class='quotetop'>QUOTE (Biglines @ Dec 21 2009, 08:29 PM) <a href="index.php?act=findpost&pid=1744540"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->not really, l4d also uses multiple maps in the same campaign, by having airlock type areas that lead to the next map<!--QuoteEnd--></div><!--QuoteEEnd-->
Yes and L4D requires that everybody stick together all the time, that's not what I want, I want a freeroaming-ish map, not 'go from this end to this end and kill everything along the way' map.
<!--quoteo(post=1744545:date=Dec 21 2009, 09:44 PM:name=StixNStonz)--><div class='quotetop'>QUOTE (StixNStonz @ Dec 21 2009, 09:44 PM) <a href="index.php?act=findpost&pid=1744545"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I think a big thing you might be missing in this discussion Chris, is that levels simply aren't meant to be made this way.
Levels and their code base are geared towards the levels being 99.9% static, which a few rare moving parts (such as elevators, doors and trams). Even levels that appear to be moving, like all those Train levels found in many games, are static with blocked off geo (no player collisions) that moves by.
You can't just say that something can work. I think the only person who can say if it would actually work would be Max. If we don't hear from max, I think it's more than safe to say that it wouldn't work, or at least not without massive headaches along the way that make the end result not worth the process.
You can't just say that mesh which is coded to be static, can just be moved around and spawned in/out without any problems. That function has to be coded in. You can bet that if Max had been building the level editor with this concept in mind, he would have done at least a few things differently. Having built the engine without that in mind, it would take much more work to integrate it into the current system that was built for a different functionality.
I do agree that it would probably be a lot easier to do in Spark than in Source. I think it may even be almost impossible in source, or at least impossible to do properly (i.e. without raising the system load by %50+).
As for using multiple maps to divide up sections, there's absolutely nothing wrong with that. The end of one map initializes the next. That way you can have a series of levels with 5-10 mins of gameplay each, rather than a big with 30-60. L4D is, as mentioned, a great example. You don't need multiple servers (per full campaign) whatsoever.<!--QuoteEnd--></div><!--QuoteEEnd-->
I wasn't planning on moving the level around, I was planning on controlling which static geometry is in the level, which as I said I already can do with source and source is five years old. If I have to I can simply make everything in 3ds max and spawn each room as a set of props only. I assume it will not be impossible to spawn props in this marvellously advanced engine. It is perfectly possilble to do in source apart from a few issues which are more to do with source being really old and outdated than they are with game engine limitations in general, and I've already listed the specifc problems source has and why, if spark can do half of what source can do, it's ideal for this sort of task.
Source has very little control over what you load in a level, we are told than NS2 has the entire game coded in Lua, which means all the things like loading and unloading models must be controllable by Lua, and therefore it must be possible to not load unneccesary models, so at the very least the most unpleasant implementation of the system (converting everything into models) is almost certainly possible. As all the level detail is done with props in spark and there is no lightmap or baked visibility to load, the levels themselves should not contain much information, all you need to load is each model and texture used and instance them across the world, and then the simple mesh which passes for brushwork in spark. Spark levels should be much smaller than source levels in terms of memory usage and the much-touted scalability of the engine supports that hypothesis. As a result, it is perfectly reasonable to assume that spark levels have the possibility to contain a lot of stuff in them very efficiently. According to the blog posts we can code our own entities for maps as we need them <a href="http://www.unknownworlds.com/ns2/news/2007/2/prosumers_and_natural_selection_2" target="_blank">http://www.unknownworlds.com/ns2/news/2007...ral_selection_2</a> and I would be rather surprised if that same entity functionality did not extend to brush entities, and even if it doesn't I can still use models which can obviously be made to spawn at will. I might not even need to convert the entire room into a model because you could spawn all the detail props using Lua and then I only need to be able to convert the brush faces into a model and then spawn that as well.
Having so much of the game controlled by lua should mean that you can control the spawning of geometry very precisely, you don't need to do what source does which is load everything into memory and then hide the bits it doesn't use, you can actually avoid loading the bits you aren't using because the level geometry is actually more like a structure than it is level geometry, a structure is just a prop with code stuck on it and because you can define your own entity classes, you can make spawnable props which don't have any provision for being moved around, don't update their positon to the server, don't animate, and basically don't eat bandwidth because they don't need to.
As I said, I don't want to make a linear campaign, I want to make something more interesting, left4dead gets extremely boring extremely quickly. If I wanted to make a svencoop clone I wouldn't have suggested this rather complex implementation. I also wouldn't suggest it if I didn't have a pretty good idea of what I'd need to do it, how to go about doing it, and that the engine would let me do it one way or another.
I guess the question is mostly, do you want to do it on your own, or make it a community effort, cuz you sound like you want to make all the decisions, meaning do it on your own? in that case, good luck and hopefully we'll see a cool single player mod from you
(just finding out your intentions)
as another note, it might be a good idea to stop referring to world geometry as brushes, as brushes in the sense of the source engine aren't in spark at all as far as I can tell
<!--quoteo(post=1744588:date=Dec 22 2009, 08:34 AM:name=Biglines)--><div class='quotetop'>QUOTE (Biglines @ Dec 22 2009, 08:34 AM) <a href="index.php?act=findpost&pid=1744588"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I guess the question is mostly, do you want to do it on your own, or make it a community effort, cuz you sound like you want to make all the decisions, meaning do it on your own? in that case, good luck and hopefully we'll see a cool single player mod from you
(just finding out your intentions)
as another note, it might be a good idea to stop referring to world geometry as brushes, as brushes in the sense of the source engine aren't in spark at all as far as I can tell<!--QuoteEnd--></div><!--QuoteEEnd-->
I know, spark works with polygons rather than solids, I just don't really know what to call them otherwise, mesh and geometry are not specific could easily mean models, brushes are what most people here would be familiar with due to that being what source and goldsrc call their non-model geometry, I also think unreal calls it that as well, so it seems as good a name as any for the moment.
I was planning on doing most of the design and mapping myself, although I'll probably need a programmer to do the code side as I have no programming background apart from a bit of a mess around with Lua once. I know vaguely enough about it to suggest methods for implementing something but not enough to actually do the implementation.
<!--quoteo(post=1744866:date=Dec 26 2009, 05:41 AM:name=sonder)--><div class='quotetop'>QUOTE (sonder @ Dec 26 2009, 05:41 AM) <a href="index.php?act=findpost&pid=1744866"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Someone should make some kind of "minigame" survival game.
Like a tower defence, just with incomming skulks (npc's), they would come in waves etc.
This could be fun competing with friends in.<!--QuoteEnd--></div><!--QuoteEEnd-->
zombie panic like mod, start with 1 skulk and everytime marine dies he goes to the alien side. Also needs something to make marines moving (bot onoses) LOL
Comments
I assume you mistakenly worded that. Encasing outdoor areas in skybox blocks is one of the worst newbie techniques in level design. Even outdoor areas are meant to be build with ceilings of sky, not where you actually put a big box around the entire area... which happens to be exactly what we're talking about with this module-based randomized level.
It's slighty different with this case since the VIS would see right through the main map part since it's an entity; with the newbie sky box technique, the main level is still doing its normal vis stuff so you get all that leaf data plus the additional leaf data and face drawing of the outside, unseen areas.
But, it's not exactly a benefit, since although you lose the leaf data altogether, you now draw everything in sight and beyond (since you'd see through the walls and through whatever small doorways lead to the adjoining module areas).
Basically, it would be very, very hard on the engine, unless one of two things. (1) you make small 'vis block hallway sections', where there is a small transition hallway between each room section that actually blocks line of sight, or (2) the Spark engine somehow manages to do on-the-fly vis calculations. But the whole reason that Source uses that system is to optimize their maps by doing all those calculations during the compile process rather than real-time. Spark seems like it will be pretty damn expensive on the CPUs, so I guess we'll have to see what route Max takes.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Presumably, if the editor is to be wysiwig, then it must be able to handle vis calculations, and that means vis calculations must be doable on the fly. Also as large parts of the level are prop based it means that props must be able to do vis calculations. If you're not using precompiled vis calculations I don't think it hugely matters whether the geometry is spawnable or not, you could write Lua to define a special entity which still affects visibility and is spawnable.<!--QuoteEnd--></div><!--QuoteEEnd-->
There's a big difference between WYSIWYG in the editor and in-game. Editors are allowed to be slower (<60 fps) and don't have nearly all the additional performance hogs such as multiple characters and weapons, their multitude of animations, all the special effects and audio, etc. Vis calculations are often pre-compiled to max out performance for all those other things.
I don't actually know where Spark will go with this, but you can't simply assume that vis will be done at runtime.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Collision doesn't have to be a problem, there's no problem with collision on func_brushes in source because if they don't move you can compile special collision or something. Plus NS2 will probably handle collision on dynamic objects anyway because it has the trams which are supposed to be in the game. And NS1 also featured lots of lifts.<!--QuoteEnd--></div><!--QuoteEEnd-->
You're talking about two totally different implementations here. Func_brushes in Source are great for small uses and for things like elevators, but they were never intended to be used for the entire level geometry. Also, things like lifts and trams are almost always made to be as slow-moving as possible to lessen the collision issues. Have you ever noticed how buggy lifts look in NS when players are on them and the lift moves quickly? And just think about all the Rotating Door / Floor issues.
With the trams, I wouldn't be surprised if they moved fairly slowly and were specifically designed so as to not interact with much else. As in, DI, structures and chambers would probably be forcibly restricted from being placed / built anywhere they would collide with the tram (including on them). Sure it could be cool to place a TF and turrets on a tram and then drive it all around, but I'm guessing the collision issues would make it too crappy to be kept for the release.
But like I said, if you really want to take on such a massive and time-consuming project, power to ya. I'd love to play it if it works out. Just realize that this would probably be about 10x the work of making a normal level, which itself is quite a feat to complete.
Dynamically placing rooms is probably possible. However, would probably require more work than it's worth when you can make a large static map and dynamically open/close pathways. Maybe not quite as dynamically/random exciting, but effective enough.
For a SP mod where you want replayability, make a larger map with lots of interconnectivity and cut off paths to make it novel each round. Or, leave the paths open but make 'routes' via the objectives. That's how I'd do it for sure.
Why does the room allocation have to be random?
Get everyone who maps in the community to build a room which fits a certain specification.
For example:
Must use THIS corridor as ALL exits and have a downloadably corridor. (thus allowing them all to fit together.)
All vents must use these dimensions.
All new textures must put with the map.
NO excessive use of lighting or particle effects.
Then manually put them together in 10 different ways.
You can then pick to play one of the ten different maps...
It aint perfect but it would work...
Dynamically placing rooms is probably possible. However, would probably require more work than it's worth when you can make a large static map and dynamically open/close pathways. Maybe not quite as dynamically/random exciting, but effective enough.<!--QuoteEnd--></div><!--QuoteEEnd-->
No, what I'm suggesting is doing that, except also, having a few different options for some rooms.
The layout doesn't change, although some paths will open and close so the layout will SEEM to change, but in actuality it's just some corridors being unnoticably walled off, and some rooms are not the same as before.
I'm not suggesting completely randomly generating the map, just having a few different options for rooms because if you build a giant base you're going to have a lot of ground to cover, whereas replacing rooms allows you to keep the same variety in a more compact space, and considering the more room versions you make the more variety you have, you don't have to keep making bigger and bigger bases to increase variety.
There is also the possibility of having special rooms, like rooms with a big lift in them that allows access to a second level of the base, and that room could be randomly positioned or sometimes not there at all, so it's not just a matter of finding the path through the same base, but each base would really feel entirely different each time, because you have to explore every area and sometimes there might be quite a few more areas than normal, such as the elevator, or maybe even access to another tram station, or a long tunnel to another base which isn't there all the time, and maybe that base is inaccessable from the main tram line this time so you have to use the tunnel, and part of the game revolves around trying to gain access to this hidden base so you have to search all the bases for the tunnel.
It makes the entire game different every time, rather than just 'explore base kill aliens'.
It's slighty different with this case since the VIS would see right through the main map part since it's an entity; with the newbie sky box technique, the main level is still doing its normal vis stuff so you get all that leaf data plus the additional leaf data and face drawing of the outside, unseen areas.
But, it's not exactly a benefit, since although you lose the leaf data altogether, you now draw everything in sight and beyond (since you'd see through the walls and through whatever small doorways lead to the adjoining module areas).
Basically, it would be very, very hard on the engine, unless one of two things. (1) you make small 'vis block hallway sections', where there is a small transition hallway between each room section that actually blocks line of sight, or (2) the Spark engine somehow manages to do on-the-fly vis calculations. But the whole reason that Source uses that system is to optimize their maps by doing all those calculations during the compile process rather than real-time. Spark seems like it will be pretty damn expensive on the CPUs, so I guess we'll have to see what route Max takes.
There's a big difference between WYSIWYG in the editor and in-game. Editors are allowed to be slower (<60 fps) and don't have nearly all the additional performance hogs such as multiple characters and weapons, their multitude of animations, all the special effects and audio, etc. Vis calculations are often pre-compiled to max out performance for all those other things.
I don't actually know where Spark will go with this, but you can't simply assume that vis will be done at runtime.<!--QuoteEnd--></div><!--QuoteEEnd-->
No I worded it correctly, you put a big skybox block over the top of the area and join it to the walls. Obviously you don't put it under the floor because the floor should be world geometry but essentially any area in source is a box made out of world geometry with stuff inside it. You can add additional visblocking geometry but usually each area is a sort of room anyway because long corridors aren't much fun to play in and they're hard to optimise.
All you have to do is ensure the room doesn't lag when you look at it, which you have to do anyway because a room is the basic rendering block of any map, those rooms in the screenshot thread are going to be mostly rendered all the time you're in them. there isn't much you can do to optimise it in terms of occlusion, you just have to not put too much stuff in it at once. As each room will be connected to corridors and the corridors don't need to be random the room will be mostly rendered and then the corridors can occlude the next room. Which is exactly how it works in a normal map.
Spark has already been stated to use on the fly occlusion culling. <a href="http://www.unknownworlds.com/ns2/news/2009/03/occlusion_culling" target="_blank">http://www.unknownworlds.com/ns2/news/2009...clusion_culling</a>
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec--><b>Because the data is precomputed, the environment can't change much at run-time.</b> And finally the PVS method is not very good when it comes to outdoor scenes. <b>To alleviate all of these problems,</b> we've chosen to use a hardware assisted occlusion culling method that <b>doesn't require precomputation.</b><!--QuoteEnd--></div><!--QuoteEEnd-->
And I have already stated that even if that were not the case, it could be easily worked around.
<!--quoteo(post=1744361:date=Dec 19 2009, 09:26 PM:name=)--><div class='quotetop'>QUOTE ( @ Dec 19 2009, 09:26 PM) <a href="index.php?act=findpost&pid=1744361"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You're talking about two totally different implementations here. Func_brushes in Source are great for small uses and for things like elevators, but they were never intended to be used for the entire level geometry. Also, things like lifts and trams are almost always made to be as slow-moving as possible to lessen the collision issues. Have you ever noticed how buggy lifts look in NS when players are on them and the lift moves quickly? And just think about all the Rotating Door / Floor issues.
With the trams, I wouldn't be surprised if they moved fairly slowly and were specifically designed so as to not interact with much else. As in, DI, structures and chambers would probably be forcibly restricted from being placed / built anywhere they would collide with the tram (including on them). Sure it could be cool to place a TF and turrets on a tram and then drive it all around, but I'm guessing the collision issues would make it too crappy to be kept for the release.
But like I said, if you really want to take on such a massive and time-consuming project, power to ya. I'd love to play it if it works out. Just realize that this would probably be about 10x the work of making a normal level, which itself is quite a feat to complete.<!--QuoteEnd--></div><!--QuoteEEnd-->
The reason players jerk around in NS is because moving geometry does not have lag prediction, not because of collision errors, players would move like that on world geometry if basic movement didn't have lag prediction. WHen the world moves a player it takes a while for the position to update and the player jumps there when it does, when a player moves a player the computer MOVES the player there so what you experience is not a jump, but simply a delayed version of what the player already did, this is why you get people complaining about being behind a crate and getting shot in CS due to 'lag', because their latency means that the person who shot them did so before they got behind the crate on the shooter's computer, but on the shootee's computer there is no lag so they were already behind the crate, however the server compensates for lag by allowing the client the shot, otherwise you would always be shooting slightly behind people if they were moving.
The room geometry does not have to move, and so it shouldn't have prediction problems, plus as NS2 is being designed with moving trams and lifts I would imagine they are adding lag prediction to those things. Something being spawnable and something being baked into the level does not mean the two are entirely different, it does in source but that's because source is source, source lights models and world brushes entirely differently as well but spark does not, it's entirely up to how the engine is built.
Considering how many iterations I go through in source when I'm making a level, making it when I can actually see what I'm doing and have a grand set of props to play with and don't have to set up all the hyperplanes manually so that it doesn't crap out when I compile it, it should be easy.
....
It makes the entire game different every time, rather than just 'explore base kill aliens'.<!--QuoteEnd--></div><!--QuoteEEnd-->
So, closer to what PsympleJester is suggesting? Swap in and out rooms (yay templates) and the occasional zomg special room?
Personally it sounds quite intense, and more power to ya if you pull it off. But people seem adequately satisfied with the L4D2's idea of "dynamic" levels and it sounds like much less work.
Besides I can quite happily keep making content and adding it to a map until the engine falls to bits so it doesn't bother me. In a sense it is also <i>more</i> efficient than making many different maps because let's say I make two maps worth of content in the form of room randomisation and optional areas, the random combination of these areas would produce closer to three map's worth of playability, because you have two unique maps and then a mix of the two, it is unlikely that a person would see every confiuguration until they had played it quite a lot and just a little 'oh that's new' or 'oh I didn't realise that passage was there' is enough to make the same approximate layout feel quite new.
Each map takes more effort to make, but in contrast you need fewer of them, as each area of the map can have a different theme and would be randomised and the objective changes each time and the enemies are a bit different and the hive room is in a different place each time and the route through is different and you find different pickups and your base camp is in a different place and basically I just listed everything that makes a map, so the entire map is different. Geometry, starting locations, goals, enemies, and tools all change, that's what makes nova prospekt different from ravenholm.
In fact, I would go so far as to suggest no more than two or three maps for the entire game with this structure. If you want to make more maps you should include some major change, three maps with a decent amount of layout changes, bases, and randomised rooms would pretty much cover the entire spectrum of 'bases linked by tram'. So you should be using additional maps to change things which cannot be altered otherwise, such as incorporating the entire map into a large spaceship and instead of tram connections you have to work to bring new sections of the ship online and accessable. The huge density of the geometry on that sort of map would make it feel utterly enormous, combining all the base and interconnecting space geometry from a tram map into a smaller area. A full ship realised in complete detail with all different access tunnels and sections for different tasks and an interconnecting power system, along with occasional vistas from observation decks of a vast planet around which the ship is orbiting, that would give a real sense of epic scale which hasn't been done before, and it would make it quite different from the tram maps.
My main worry is engine limits, I hope they are not as severe as HL2 Episode 2, hopefully the heavy use of prop instanced geometry and dynamic lighting will mean they are not.
But certainly, it's a great community project if people can participate in creating the mod by creating the modules for it.
and what brushes have to do with spark I have no idea, the whole point of spark is that it uses faces instead of brushes, lighting is always dynamic, so lightmaps aren't an issue?
but to add something constructive, I'd be willing to help with making custom models
But certainly, it's a great community project if people can participate in creating the mod by creating the modules for it.<!--QuoteEnd--></div><!--QuoteEEnd-->
I was planning on doing all the mapping myself but it would certainly lend itself to communal mapping more than a lot of maps because you can give someone a room and tell them to make a lot of different variations, without having to worry about them changing the layout or interfering with other parts of the map. It breaks down into components quite nicely.
<!--quoteo(post=1744513:date=Dec 21 2009, 02:08 PM:name=Biglines)--><div class='quotetop'>QUOTE (Biglines @ Dec 21 2009, 02:08 PM) <a href="index.php?act=findpost&pid=1744513"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->when I was reading through this thread, I realised, why bother with making everything in one map? from the editor it seems that loading a map doesn't take very long (a few sec max afaik?), and seeing as it was said that the editor worked exactly the same in terms of lighting as the final game, isn't it fair to conclude that it would be viable to split up the game in more than one map?
and what brushes have to do with spark I have no idea, the whole point of spark is that it uses faces instead of brushes, lighting is always dynamic, so lightmaps aren't an issue?
but to add something constructive, I'd be willing to help with making custom models<!--QuoteEnd--></div><!--QuoteEEnd-->
If you have multiple maps you need multiple servers running it persistantly, otherwise people have to stick together to do anything and that kinda kills the immersion.
not really, l4d also uses multiple maps in the same campaign, by having airlock type areas that lead to the next map
Levels and their code base are geared towards the levels being 99.9% static, which a few rare moving parts (such as elevators, doors and trams). Even levels that appear to be moving, like all those Train levels found in many games, are static with blocked off geo (no player collisions) that moves by.
You can't just say that something can work. I think the only person who can say if it would actually work would be Max. If we don't hear from max, I think it's more than safe to say that it wouldn't work, or at least not without massive headaches along the way that make the end result not worth the process.
You can't just say that mesh which is coded to be static, can just be moved around and spawned in/out without any problems. That function has to be coded in. You can bet that if Max had been building the level editor with this concept in mind, he would have done at least a few things differently. Having built the engine without that in mind, it would take much more work to integrate it into the current system that was built for a different functionality.
I do agree that it would probably be a lot easier to do in Spark than in Source. I think it may even be almost impossible in source, or at least impossible to do properly (i.e. without raising the system load by %50+).
As for using multiple maps to divide up sections, there's absolutely nothing wrong with that. The end of one map initializes the next. That way you can have a series of levels with 5-10 mins of gameplay each, rather than a big with 30-60. L4D is, as mentioned, a great example. You don't need multiple servers (per full campaign) whatsoever.
Yes and L4D requires that everybody stick together all the time, that's not what I want, I want a freeroaming-ish map, not 'go from this end to this end and kill everything along the way' map.
<!--quoteo(post=1744545:date=Dec 21 2009, 09:44 PM:name=StixNStonz)--><div class='quotetop'>QUOTE (StixNStonz @ Dec 21 2009, 09:44 PM) <a href="index.php?act=findpost&pid=1744545"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I think a big thing you might be missing in this discussion Chris, is that levels simply aren't meant to be made this way.
Levels and their code base are geared towards the levels being 99.9% static, which a few rare moving parts (such as elevators, doors and trams). Even levels that appear to be moving, like all those Train levels found in many games, are static with blocked off geo (no player collisions) that moves by.
You can't just say that something can work. I think the only person who can say if it would actually work would be Max. If we don't hear from max, I think it's more than safe to say that it wouldn't work, or at least not without massive headaches along the way that make the end result not worth the process.
You can't just say that mesh which is coded to be static, can just be moved around and spawned in/out without any problems. That function has to be coded in. You can bet that if Max had been building the level editor with this concept in mind, he would have done at least a few things differently. Having built the engine without that in mind, it would take much more work to integrate it into the current system that was built for a different functionality.
I do agree that it would probably be a lot easier to do in Spark than in Source. I think it may even be almost impossible in source, or at least impossible to do properly (i.e. without raising the system load by %50+).
As for using multiple maps to divide up sections, there's absolutely nothing wrong with that. The end of one map initializes the next. That way you can have a series of levels with 5-10 mins of gameplay each, rather than a big with 30-60. L4D is, as mentioned, a great example. You don't need multiple servers (per full campaign) whatsoever.<!--QuoteEnd--></div><!--QuoteEEnd-->
I wasn't planning on moving the level around, I was planning on controlling which static geometry is in the level, which as I said I already can do with source and source is five years old. If I have to I can simply make everything in 3ds max and spawn each room as a set of props only. I assume it will not be impossible to spawn props in this marvellously advanced engine. It is perfectly possilble to do in source apart from a few issues which are more to do with source being really old and outdated than they are with game engine limitations in general, and I've already listed the specifc problems source has and why, if spark can do half of what source can do, it's ideal for this sort of task.
Source has very little control over what you load in a level, we are told than NS2 has the entire game coded in Lua, which means all the things like loading and unloading models must be controllable by Lua, and therefore it must be possible to not load unneccesary models, so at the very least the most unpleasant implementation of the system (converting everything into models) is almost certainly possible. As all the level detail is done with props in spark and there is no lightmap or baked visibility to load, the levels themselves should not contain much information, all you need to load is each model and texture used and instance them across the world, and then the simple mesh which passes for brushwork in spark. Spark levels should be much smaller than source levels in terms of memory usage and the much-touted scalability of the engine supports that hypothesis. As a result, it is perfectly reasonable to assume that spark levels have the possibility to contain a lot of stuff in them very efficiently. According to the blog posts we can code our own entities for maps as we need them <a href="http://www.unknownworlds.com/ns2/news/2007/2/prosumers_and_natural_selection_2" target="_blank">http://www.unknownworlds.com/ns2/news/2007...ral_selection_2</a> and I would be rather surprised if that same entity functionality did not extend to brush entities, and even if it doesn't I can still use models which can obviously be made to spawn at will. I might not even need to convert the entire room into a model because you could spawn all the detail props using Lua and then I only need to be able to convert the brush faces into a model and then spawn that as well.
Having so much of the game controlled by lua should mean that you can control the spawning of geometry very precisely, you don't need to do what source does which is load everything into memory and then hide the bits it doesn't use, you can actually avoid loading the bits you aren't using because the level geometry is actually more like a structure than it is level geometry, a structure is just a prop with code stuck on it and because you can define your own entity classes, you can make spawnable props which don't have any provision for being moved around, don't update their positon to the server, don't animate, and basically don't eat bandwidth because they don't need to.
As I said, I don't want to make a linear campaign, I want to make something more interesting, left4dead gets extremely boring extremely quickly. If I wanted to make a svencoop clone I wouldn't have suggested this rather complex implementation. I also wouldn't suggest it if I didn't have a pretty good idea of what I'd need to do it, how to go about doing it, and that the engine would let me do it one way or another.
(just finding out your intentions)
as another note, it might be a good idea to stop referring to world geometry as brushes, as brushes in the sense of the source engine aren't in spark at all as far as I can tell
(just finding out your intentions)
as another note, it might be a good idea to stop referring to world geometry as brushes, as brushes in the sense of the source engine aren't in spark at all as far as I can tell<!--QuoteEnd--></div><!--QuoteEEnd-->
I know, spark works with polygons rather than solids, I just don't really know what to call them otherwise, mesh and geometry are not specific could easily mean models, brushes are what most people here would be familiar with due to that being what source and goldsrc call their non-model geometry, I also think unreal calls it that as well, so it seems as good a name as any for the moment.
I was planning on doing most of the design and mapping myself, although I'll probably need a programmer to do the code side as I have no programming background apart from a bit of a mess around with Lua once. I know vaguely enough about it to suggest methods for implementing something but not enough to actually do the implementation.
Like a tower defence, just with incomming skulks (npc's), they would come in waves etc.
This could be fun competing with friends in.
Like a tower defence, just with incomming skulks (npc's), they would come in waves etc.
This could be fun competing with friends in.<!--QuoteEnd--></div><!--QuoteEEnd-->
zombie panic like mod, start with 1 skulk and everytime marine dies he goes to the alien side. Also needs something to make marines moving (bot onoses) LOL