Of course but I think this only for the users who have cards older than nVidia X8800's both from ATi and nVidia. There is still enougth of them about to still avoid this new idea unless its dynamic, meaning the CPU will be used if the graphics card is not very powerful and if that happens and NS2 has rich sounds these low users might have to sacrafice either sound audio quailty or more most likely very low graphics settings on shadows etc for a good frame rate if their CPU is a bit slow too? It really depends on what propotions we are talking about here and what the performance of this is on old cards that already might be struggling like an ATi X800 PRO or 9600 There are still plenty of computers with these old cards, they dont have the tech like a modern nVidia card and there CUDA technology and Physics processing capabilites..
Therefore it might be better to spend the little bit of extra time required to enclose our maps to avoid penalizing people who carnt afford a decent PC. Thats all am saying. This new method might want to be held back for another 1 - 2 years whilst the last of the few old remaing systems drop off the scene if they cant handle it.
Like Max has said, It costs more to do these more complex calculations on the models, the graphics card does it better then the CPU but its no good if the graphics card is already struggling and cant handle it the same way as a modern card.
Maybe Max should ask the community if they would like to donate their old cards to use for tests, I have 2 I could give him for nothing. They are no use to me at all so why not.
When creating games I personally wouldn't cater for anyone with a GPU older than 3 years. Why? Gamers know how the technology changes and if they game, they will cater for it.
Sure you have some people still using technology from 2004 like Geforce 6-series but really, at a minimum, you need to upgrade to something like a 8-Series at a minimum for new games. That is unfortunately the way the industry rolls and how technology develops, particularly when taking advantage of things such as Direct X enhancements.
<!--quoteo(post=1754942:date=Feb 24 2010, 05:28 PM:name=Thaldarin)--><div class='quotetop'>QUOTE (Thaldarin @ Feb 24 2010, 05:28 PM) <a href="index.php?act=findpost&pid=1754942"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Nodraw is an enifficient and time consuming process for the designer to have to worry about.
I'm rather appreciative and think it's a pretty good idea that meshes and geometry act in a similar way.<!--QuoteEnd--></div><!--QuoteEEnd-->
Nodraw allows intelligent and perfect control over the optimisation, it is a neccesary and highly efficient process, or at least it can be if you know what you should know about the game when mapping for it.
I would be rather upset if we couldn't manually control the optimisation.
As an example, having to seal your geometry off with nodraw is inefficient and time consuming. Just because you're not in control of some of the optimisation doesn't mean it's going to immediately be a bad thing.
<!--quoteo(post=1754952:date=Feb 24 2010, 06:53 PM:name=Draco_2k)--><div class='quotetop'>QUOTE (Draco_2k @ Feb 24 2010, 06:53 PM) <a href="index.php?act=findpost&pid=1754952"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Congratulations, you have grasped the core idea behind scientific progress.<!--QuoteEnd--></div><!--QuoteEEnd-->
Actually in games a lot of things are performance and effort based.
Normal mapping for example, it's easy to model high detail stuff but it isn't efficient, so you model high detail and then model low detail and bake the high detail into the low detail but that places restrictions on your UV mapping and also is a bit fiddly.
Games are hard to make, because they need a lot of effort to look good and be playable.
<!--quoteo(post=1755081:date=Feb 25 2010, 04:46 PM:name=Thaldarin)--><div class='quotetop'>QUOTE (Thaldarin @ Feb 25 2010, 04:46 PM) <a href="index.php?act=findpost&pid=1755081"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->As an example, having to seal your geometry off with nodraw is inefficient and time consuming. Just because you're not in control of some of the optimisation doesn't mean it's going to immediately be a bad thing.<!--QuoteEnd--></div><!--QuoteEEnd-->
As an example, in almost any situation you can streamline the optimisation calculations and achieve the same culling effects by using nodraw rather than taking every bit of geometry into account, it takes longer for the designer but gives you better results, and you can also fix any errors that will occur very easily. That is the point of the designer, you could randomly generate all your maps, but if you get a designer to do it you get better results even though it takes longer.
Until you can invent something that can do optimisation better than an intelligent human, intelligent human input is always going to be better than the alternative, especially because intelligent human input in the design phase is precalculated, you work out what would be an efficient optimisation setup beforehand and build it into the level, rather than getting the game to work out an efficient process in runtime, or simply not bothering with finding efficient processes and just including everything in the optimisation calculations. Games are made with skilled input in mind, removing menial tasks like having to write text files and run batches to compile models is OK and can be done with no loss in performance, but removing things which exist for a reason is not. Designer optimisation control is and will be for some time to come, a neccesary and important feature in any game you want to get the best performance out of.
Laziness is not acceptable when it comes to making games, because laziness does nothing but cause poor performance, gameplay, and visuals.
<!--quoteo(post=1755079:date=Feb 25 2010, 07:37 PM:name=Chris0132)--><div class='quotetop'>QUOTE (Chris0132 @ Feb 25 2010, 07:37 PM) <a href="index.php?act=findpost&pid=1755079"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Nodraw allows intelligent and perfect control over the optimisation<!--QuoteEnd--></div><!--QuoteEEnd--> It's a bit like sewing your own clothes. You can do it, and if you're good enough it'll certainly be better... But would you really?
<!--quoteo(post=1755082:date=Feb 25 2010, 07:47 PM:name=Chris0132)--><div class='quotetop'>QUOTE (Chris0132 @ Feb 25 2010, 07:47 PM) <a href="index.php?act=findpost&pid=1755082"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Actually in games a lot of things are performance and effort based.<!--QuoteEnd--></div><!--QuoteEEnd--> Yes. Which has tremendous negative impact on production times, stability and mod-friendliness.
<!--quoteo(post=1755082:date=Feb 25 2010, 07:47 PM:name=Chris0132)--><div class='quotetop'>QUOTE (Chris0132 @ Feb 25 2010, 07:47 PM) <a href="index.php?act=findpost&pid=1755082"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Until you can invent something that can do optimisation better than an intelligent human<!--QuoteEnd--></div><!--QuoteEEnd--> Um. No optimisation procedures are performed in full manual. There are build programs... Portalling itself - what you're talking about - is, one way or another, unambiguously outdated.
The actual difference here is performing the calculations in real-time or pre-calculated way: first up eats up more processing, while another eats up more memory, which in turn put different limits on both. In case of CHC, it's the trade-off between better optimisation for slight performance hit over no performance hit and crappier optimisation.
<!--quoteo(post=1755082:date=Feb 25 2010, 07:47 PM:name=Chris0132)--><div class='quotetop'>QUOTE (Chris0132 @ Feb 25 2010, 07:47 PM) <a href="index.php?act=findpost&pid=1755082"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Laziness is not acceptable when it comes to making games, because laziness does nothing but cause poor performance, gameplay, and visuals.<!--QuoteEnd--></div><!--QuoteEEnd--> Too late. Our civilisation is built on laziness, and unless you grow your own veggies, I say, join the club.
Other than that, we'll see what it causes when NS2 is out.
<!--quoteo(post=1755099:date=Feb 25 2010, 05:44 PM:name=Draco_2k)--><div class='quotetop'>QUOTE (Draco_2k @ Feb 25 2010, 05:44 PM) <a href="index.php?act=findpost&pid=1755099"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->It's a bit like sewing your own clothes. You can do it, and if you're good enough it'll certainly be better... But would you really?<!--QuoteEnd--></div><!--QuoteEEnd-->
If I was a tailor, yes, because that would be my job. If I am a level designer I must optimise the level because the computer cannot do it as well on its own and it is part of my job to do it. That's how it works, you each put in your own effort to make the best result possible, a level designer who does not put the effort in to making the best level in terms of gameplay, visual appeal, and performance, is simply a <i>bad</i> level designer.
Oh and we do grow some of our own vegetables, not that it matters.
<!--quoteo(post=1755373:date=Feb 26 2010, 03:56 PM:name=Chris0132)--><div class='quotetop'>QUOTE (Chris0132 @ Feb 26 2010, 03:56 PM) <a href="index.php?act=findpost&pid=1755373"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->If I was a tailor, yes, because that would be my job.<!--QuoteEnd--></div><!--QuoteEEnd--> Analogy is a non-literal explanation assigning traits of one subject to that of another, used in discourse to elaborate on the meaning of an unknown subject using known objects.
Nodraw is outdated. Other forms on manual visleaf optimisation are unacceptable for an indie and mod-friendly project.
<!--quoteo(post=1755373:date=Feb 26 2010, 03:56 PM:name=Chris0132)--><div class='quotetop'>QUOTE (Chris0132 @ Feb 26 2010, 03:56 PM) <a href="index.php?act=findpost&pid=1755373"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Oh and we do grow some of our own vegetables, not that it matters.<!--QuoteEnd--></div><!--QuoteEEnd--> Good for you. You might actually need it.
So have we decided whether maps need sealing with walls behind models out of necessity or just for performance reasons? For example is there a 'void' that needs sealing from or is it more like ut3 engine where aslong as the player can't see the HOM that's out there it's fine?
InsaneAnomalyJoin Date: 2002-05-13Member: 605Members, Super Administrators, Forum Admins, NS1 Playtester, Forum Moderators, NS2 Developer, Constellation, NS2 Playtester, Squad Five Blue, NS2 Map Tester, Subnautica Developer, Pistachionauts, Future Perfect Developer
You don't need to seal off from the void. You won't see a HOM effect when you look into it either (just the same grey as in the editor), but obviously you'll want to avoid visible holes for aesthetic reasons.
Well that's just good news all round then :) Hopefully no HOM will also mean no blatant looking and eye catching holes to the outside then. That'll be a nice change.
Well in that case, Make the void in-game black? Keep it grey in the editor. I can see hairline gaps in most of the models. Unless the skybox is global?
<!--quoteo(post=1757001:date=Mar 4 2010, 12:09 PM:name=SgtBarlow)--><div class='quotetop'>QUOTE (SgtBarlow @ Mar 4 2010, 12:09 PM) <a href="index.php?act=findpost&pid=1757001"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Well in that case, Make the void in-game black? Keep it grey in the editor. I can see hairline gaps in most of the models. Unless the skybox is global?<!--QuoteEnd--></div><!--QuoteEEnd--> no, it should stay WYSIWYG. Though I wouldn't argue with an option to make the void hot pink in the editor to make sure there are no visible gaps
InsaneAnomalyJoin Date: 2002-05-13Member: 605Members, Super Administrators, Forum Admins, NS1 Playtester, Forum Moderators, NS2 Developer, Constellation, NS2 Playtester, Squad Five Blue, NS2 Map Tester, Subnautica Developer, Pistachionauts, Future Perfect Developer
<!--quoteo(post=1757001:date=Mar 4 2010, 03:09 PM:name=SgtBarlow)--><div class='quotetop'>QUOTE (SgtBarlow @ Mar 4 2010, 03:09 PM) <a href="index.php?act=findpost&pid=1757001"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Well in that case, Make the void in-game black? Keep it grey in the editor. I can see hairline gaps in most of the models. Unless the skybox is global?<!--QuoteEnd--></div><!--QuoteEEnd-->
The skybox is global. It's basically projected onto the void.
Thanks, Insane. So hide gaps as best you can or put a black plane behind it.
Also this must mean that with a global sykbox these is no self contained outdoor arenas. Just viewports (Windows) no outside access? Unless you build a transparent enclosure to stop lorks flying away?
<!--quoteo(post=1757061:date=Mar 4 2010, 10:55 PM:name=Insane)--><div class='quotetop'>QUOTE (Insane @ Mar 4 2010, 10:55 PM) <a href="index.php?act=findpost&pid=1757061"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->The skybox is global. It's basically projected onto the void.<!--QuoteEnd--></div><!--QuoteEEnd--> Very nice. Any chance we can switch sky-boxes mid-game, through scripting or something?..
Not exactly an engine question, but will it be possible to add extra animations to the stock player models (I know very little about animation/rigging/etc.)
<!--quoteo(post=1757087:date=Mar 4 2010, 03:21 PM:name=Draco_2k)--><div class='quotetop'>QUOTE (Draco_2k @ Mar 4 2010, 03:21 PM) <a href="index.php?act=findpost&pid=1757087"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Very nice. Any chance we can switch sky-boxes mid-game, through scripting or something?..<!--QuoteEnd--></div><!--QuoteEEnd-->
They mentioned dynamic skyboxes being a serious idea. I think this definitely could happen.
<!--quoteo(post=1757329:date=Mar 5 2010, 10:11 PM:name=Cyanide)--><div class='quotetop'>QUOTE (Cyanide @ Mar 5 2010, 10:11 PM) <a href="index.php?act=findpost&pid=1757329"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->They mentioned dynamic skyboxes being a serious idea. I think this definitely could happen.<!--QuoteEnd--></div><!--QuoteEEnd--> I gather that's "dynamic" as in: 3D, animations, particle effects, so on. But you're right, I don't see any reason it wouldn't be possible.
Will we have an option to change geometry or a prop to be able to be only seen by players and not the commander?
The top down view works well because obviously outside of rooms you won't have faces on the other side of the ceiling and I figure we can't build level over level because the commander won't be able to place objects on a level below another, or set waypoints etc.
But say you have a room lower down and another room with windows higher up, towering right beside it, looking out of the window you can see through the ceiling of the lower room. Would it be possible however to place a prop roof, or model one out in geometry, place it over the lower room, but have an option so it doesn't render in the commander view, so the commander can still see into the lower room? It would also be useful for other things, like props on the ceiling that have back faces.
<!--quoteo(post=1757072:date=Mar 4 2010, 08:39 PM:name=SgtBarlow)--><div class='quotetop'>QUOTE (SgtBarlow @ Mar 4 2010, 08:39 PM) <a href="index.php?act=findpost&pid=1757072"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Thanks, Insane. So hide gaps as best you can or put a black plane behind it.
Also this must mean that with a global sykbox these is no self contained outdoor arenas. Just viewports (Windows) no outside access? Unless you build a transparent enclosure to stop lorks flying away?<!--QuoteEnd--></div><!--QuoteEEnd-->
Same as in NS1 I would imagine, you need to add geometry as appropriate, either give the entire level an exterior or enclose your outdoor areas.
Nothing like a good old fashioned SPACE DOME! anyway.
<!--quoteo(post=1757087:date=Mar 4 2010, 09:21 PM:name=Draco_2k)--><div class='quotetop'>QUOTE (Draco_2k @ Mar 4 2010, 09:21 PM) <a href="index.php?act=findpost&pid=1757087"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Very nice. Any chance we can switch sky-boxes mid-game, through scripting or something?..<!--QuoteEnd--></div><!--QuoteEEnd-->
I would imagine you can write your own materials with Lua, I think it was mentioned a while ago in one of the moddability news updates, so I would guess that you could apply the same effects to the sky as you can to say, the vertexlitgeneric material in source.
Source has things called texture proxies which let you do things to the textures the material uses, like scroll them, animate them, scale them etc. I would expect NS2 to have similar things available because they're quite handy.
If all else fails you can just put a cylinder in the skybox and stick a panorama mountain range or something on it, that's a fairly staple method of increasing skybox variety by making them composite. They use exactly that method in cs_nuke if you're curious.
I'm missing a couple of things that were pretty much "basic stuff" in almost every engine for the last years and I'd like to know if we will see them in Spark soon:
Will we get "Texture Lighting" (textures can emit light. Useful for sky textures as well as light textures behind grates, so it diesn't feather out like it does now with a point/directional light)
<!--quoteo(post=1759161:date=Mar 13 2010, 12:06 PM:name=Lord Schnitzel)--><div class='quotetop'>QUOTE (Lord Schnitzel @ Mar 13 2010, 12:06 PM) <a href="index.php?act=findpost&pid=1759161"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I'm missing a couple of things that were pretty much "basic stuff" in almost every engine for the last years and I'd like to know if we will see them in Spark soon:
Will we get "Texture Lighting" (textures can emit light. Useful for sky textures as well as light textures behind grates, so it diesn't feather out like it does now with a point/directional light)
Will there be any sort of liquid? water? lava?
What about glass (breakable and unbreakable)?<!--QuoteEnd--></div><!--QuoteEEnd--> There won't be texture lighting because that demand pre-computed lighting, but there will be projectors; liquid will be cosmetically implemented prior to release and in physical quality post-release; glass will be implemented sometime around alpha/beta
This is some what of a follow-up question to the late Friday update video. I am extremely satisfied with some of the questions you confirmed. A few others and I are very attracted to the capabilities of the engine and ease of modability Natural Selection 2 will have. We currently use Garry's Mod for our current aspirations since it we can script in lua and is obviously much less time consuming, when we heard wind of the lua extension that this game is boasting we became drawn to it. I'm asking these questions in hopes that you or anyone can answer with a comparison to Garry's Mod and the Source engine.
1. How much can we do with lua in this game? Garry's Mod is pretty impressive, but there are some things that we find difficult to do, such as inventories, character creation and saving (my SQL), and adding new UI features.
2. What is the maximum size for a map? Additionally, about how much entity data can a map contain in comparison to Source? (Props, Point Entities)
3. How will we make natural terrain? Things like cliffs, hills, plateaus, etc. Will it be any similar to Source in which you make displacements from the Hammer editor? Additionally, will you be able to paint terrain surfaces with multiple (more than 5) textures, rather than two like Source?
4. Lastly, for optimization reasons in Source, we fade our props so they transition smoothly and become rendered at appropriate distances. Will we be able to do the same in this game eventually?
We have a large community who play our game mode that are in need of some features that are currently not possible because of engine limitations. The dynamic lighting and real time occlusion culling is god-sent for the kind of work we are doing, if you or anyone could confirm that we can at least do what Source and Garry's Mod can do, we will without a doubt begin some projects on Natural Selection 2. We thank you in advance.
1) What Seker said really. The blogs have told us that as much of the game code as possible has been LUA scripted to enable easy modibility.
2) Download Spark. It's impressively massive. Using Source and UED as an example, compared to those two it is massive.
3) Again download Spark. So far we only have prop and texture usage. There is more than likely a plan post-game development to incorporate a more intuitive geometric creation feature. I think somewhere along the line, this has been said in a blog as a "for the future".
4) An LoD question is just that. In Spark you currently can not set this. It shouldn't be a problem with sort of environments NS2 brings.
Are you looking at switching your modification to the Spark engine in the future? If so, I'm interested to know exactly what modification it is if you have a link to a current site, information etc? It's pretty interesting someone may already plan to use the engine for modding :)
We have a game mode for Garry's Mod which attempts to recreate the S.T.A.L.K.E.R. game experience in an online fashion. Players can trade, join factions, look for artifacts, etc. Most importantly though, and what separates in from mainstream games, you have to play your character. This is not a death-match game mode, there are rules of engagement and reasons why you should not get in a fight all the time. We have administrators on all the time to enforce this and make sure that players do not start death-matching.
Comments
It really depends on what propotions we are talking about here and what the performance of this is on old cards that already might be struggling like an ATi X800 PRO or 9600 There are still plenty of computers with these old cards, they dont have the tech like a modern nVidia card and there CUDA technology and Physics processing capabilites..
Therefore it might be better to spend the little bit of extra time required to enclose our maps to avoid penalizing people who carnt afford a decent PC. Thats all am saying.
This new method might want to be held back for another 1 - 2 years whilst the last of the few old remaing systems drop off the scene if they cant handle it.
Like Max has said, It costs more to do these more complex calculations on the models, the graphics card does it better then the CPU but its no good if the graphics card is already struggling and cant handle it the same way as a modern card.
Maybe Max should ask the community if they would like to donate their old cards to use for tests, I have 2 I could give him for nothing. They are no use to me at all so why not.
Sure you have some people still using technology from 2004 like Geforce 6-series but really, at a minimum, you need to upgrade to something like a 8-Series at a minimum for new games. That is unfortunately the way the industry rolls and how technology develops, particularly when taking advantage of things such as Direct X enhancements.
I'm rather appreciative and think it's a pretty good idea that meshes and geometry act in a similar way.<!--QuoteEnd--></div><!--QuoteEEnd-->
Nodraw allows intelligent and perfect control over the optimisation, it is a neccesary and highly efficient process, or at least it can be if you know what you should know about the game when mapping for it.
I would be rather upset if we couldn't manually control the optimisation.
Actually in games a lot of things are performance and effort based.
Normal mapping for example, it's easy to model high detail stuff but it isn't efficient, so you model high detail and then model low detail and bake the high detail into the low detail but that places restrictions on your UV mapping and also is a bit fiddly.
Games are hard to make, because they need a lot of effort to look good and be playable.
<!--quoteo(post=1755081:date=Feb 25 2010, 04:46 PM:name=Thaldarin)--><div class='quotetop'>QUOTE (Thaldarin @ Feb 25 2010, 04:46 PM) <a href="index.php?act=findpost&pid=1755081"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->As an example, having to seal your geometry off with nodraw is inefficient and time consuming. Just because you're not in control of some of the optimisation doesn't mean it's going to immediately be a bad thing.<!--QuoteEnd--></div><!--QuoteEEnd-->
As an example, in almost any situation you can streamline the optimisation calculations and achieve the same culling effects by using nodraw rather than taking every bit of geometry into account, it takes longer for the designer but gives you better results, and you can also fix any errors that will occur very easily. That is the point of the designer, you could randomly generate all your maps, but if you get a designer to do it you get better results even though it takes longer.
Until you can invent something that can do optimisation better than an intelligent human, intelligent human input is always going to be better than the alternative, especially because intelligent human input in the design phase is precalculated, you work out what would be an efficient optimisation setup beforehand and build it into the level, rather than getting the game to work out an efficient process in runtime, or simply not bothering with finding efficient processes and just including everything in the optimisation calculations. Games are made with skilled input in mind, removing menial tasks like having to write text files and run batches to compile models is OK and can be done with no loss in performance, but removing things which exist for a reason is not. Designer optimisation control is and will be for some time to come, a neccesary and important feature in any game you want to get the best performance out of.
Laziness is not acceptable when it comes to making games, because laziness does nothing but cause poor performance, gameplay, and visuals.
It's a bit like sewing your own clothes. You can do it, and if you're good enough it'll certainly be better... But would you really?
<!--quoteo(post=1755082:date=Feb 25 2010, 07:47 PM:name=Chris0132)--><div class='quotetop'>QUOTE (Chris0132 @ Feb 25 2010, 07:47 PM) <a href="index.php?act=findpost&pid=1755082"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Actually in games a lot of things are performance and effort based.<!--QuoteEnd--></div><!--QuoteEEnd-->
Yes. Which has tremendous negative impact on production times, stability and mod-friendliness.
<!--quoteo(post=1755082:date=Feb 25 2010, 07:47 PM:name=Chris0132)--><div class='quotetop'>QUOTE (Chris0132 @ Feb 25 2010, 07:47 PM) <a href="index.php?act=findpost&pid=1755082"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Until you can invent something that can do optimisation better than an intelligent human<!--QuoteEnd--></div><!--QuoteEEnd-->
Um. No optimisation procedures are performed in full manual. There are build programs... Portalling itself - what you're talking about - is, one way or another, unambiguously outdated.
The actual difference here is performing the calculations in real-time or pre-calculated way: first up eats up more processing, while another eats up more memory, which in turn put different limits on both. In case of CHC, it's the trade-off between better optimisation for slight performance hit over no performance hit and crappier optimisation.
<!--quoteo(post=1755082:date=Feb 25 2010, 07:47 PM:name=Chris0132)--><div class='quotetop'>QUOTE (Chris0132 @ Feb 25 2010, 07:47 PM) <a href="index.php?act=findpost&pid=1755082"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Laziness is not acceptable when it comes to making games, because laziness does nothing but cause poor performance, gameplay, and visuals.<!--QuoteEnd--></div><!--QuoteEEnd-->
Too late. Our civilisation is built on laziness, and unless you grow your own veggies, I say, join the club.
Other than that, we'll see what it causes when NS2 is out.
If I was a tailor, yes, because that would be my job. If I am a level designer I must optimise the level because the computer cannot do it as well on its own and it is part of my job to do it. That's how it works, you each put in your own effort to make the best result possible, a level designer who does not put the effort in to making the best level in terms of gameplay, visual appeal, and performance, is simply a <i>bad</i> level designer.
Oh and we do grow some of our own vegetables, not that it matters.
Analogy is a non-literal explanation assigning traits of one subject to that of another, used in discourse to elaborate on the meaning of an unknown subject using known objects.
Nodraw is outdated. Other forms on manual visleaf optimisation are unacceptable for an indie and mod-friendly project.
<!--quoteo(post=1755373:date=Feb 26 2010, 03:56 PM:name=Chris0132)--><div class='quotetop'>QUOTE (Chris0132 @ Feb 26 2010, 03:56 PM) <a href="index.php?act=findpost&pid=1755373"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Oh and we do grow some of our own vegetables, not that it matters.<!--QuoteEnd--></div><!--QuoteEEnd-->
Good for you. You might actually need it.
no, it should stay WYSIWYG. Though I wouldn't argue with an option to make the void hot pink in the editor to make sure there are no visible gaps
The skybox is global. It's basically projected onto the void.
So hide gaps as best you can or put a black plane behind it.
Also this must mean that with a global sykbox these is no self contained outdoor arenas. Just viewports (Windows) no outside access? Unless you build a transparent enclosure to stop lorks flying away?
Very nice. Any chance we can switch sky-boxes mid-game, through scripting or something?..
They mentioned dynamic skyboxes being a serious idea. I think this definitely could happen.
I gather that's "dynamic" as in: 3D, animations, particle effects, so on. But you're right, I don't see any reason it wouldn't be possible.
The top down view works well because obviously outside of rooms you won't have faces on the other side of the ceiling and I figure we can't build level over level because the commander won't be able to place objects on a level below another, or set waypoints etc.
But say you have a room lower down and another room with windows higher up, towering right beside it, looking out of the window you can see through the ceiling of the lower room. Would it be possible however to place a prop roof, or model one out in geometry, place it over the lower room, but have an option so it doesn't render in the commander view, so the commander can still see into the lower room? It would also be useful for other things, like props on the ceiling that have back faces.
So hide gaps as best you can or put a black plane behind it.
Also this must mean that with a global sykbox these is no self contained outdoor arenas. Just viewports (Windows) no outside access? Unless you build a transparent enclosure to stop lorks flying away?<!--QuoteEnd--></div><!--QuoteEEnd-->
Same as in NS1 I would imagine, you need to add geometry as appropriate, either give the entire level an exterior or enclose your outdoor areas.
Nothing like a good old fashioned SPACE DOME! anyway.
<!--quoteo(post=1757087:date=Mar 4 2010, 09:21 PM:name=Draco_2k)--><div class='quotetop'>QUOTE (Draco_2k @ Mar 4 2010, 09:21 PM) <a href="index.php?act=findpost&pid=1757087"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Very nice. Any chance we can switch sky-boxes mid-game, through scripting or something?..<!--QuoteEnd--></div><!--QuoteEEnd-->
I would imagine you can write your own materials with Lua, I think it was mentioned a while ago in one of the moddability news updates, so I would guess that you could apply the same effects to the sky as you can to say, the vertexlitgeneric material in source.
Source has things called texture proxies which let you do things to the textures the material uses, like scroll them, animate them, scale them etc. I would expect NS2 to have similar things available because they're quite handy.
If all else fails you can just put a cylinder in the skybox and stick a panorama mountain range or something on it, that's a fairly staple method of increasing skybox variety by making them composite. They use exactly that method in cs_nuke if you're curious.
Will we get "Texture Lighting" (textures can emit light. Useful for sky textures as well as light textures behind grates, so it diesn't feather out like it does now with a point/directional light)
Will there be any sort of liquid? water? lava?
What about glass (breakable and unbreakable)?
Liquid: Sometime after the release of NS2 iirc.
Glass: Sometime in the future too.
Will we get "Texture Lighting" (textures can emit light. Useful for sky textures as well as light textures behind grates, so it diesn't feather out like it does now with a point/directional light)
Will there be any sort of liquid? water? lava?
What about glass (breakable and unbreakable)?<!--QuoteEnd--></div><!--QuoteEEnd-->
There won't be texture lighting because that demand pre-computed lighting, but there will be projectors; liquid will be cosmetically implemented prior to release and in physical quality post-release; glass will be implemented sometime around alpha/beta
At least that's what I gather.
1. How much can we do with lua in this game? Garry's Mod is pretty impressive, but there are some things that we find difficult to do, such as inventories, character creation and saving (my SQL), and adding new UI features.
2. What is the maximum size for a map? Additionally, about how much entity data can a map contain in comparison to Source? (Props, Point Entities)
3. How will we make natural terrain? Things like cliffs, hills, plateaus, etc. Will it be any similar to Source in which you make displacements from the Hammer editor? Additionally, will you be able to paint terrain surfaces with multiple (more than 5) textures, rather than two like Source?
4. Lastly, for optimization reasons in Source, we fade our props so they transition smoothly and become rendered at appropriate distances. Will we be able to do the same in this game eventually?
We have a large community who play our game mode that are in need of some features that are currently not possible because of engine limitations. The dynamic lighting and real time occlusion culling is god-sent for the kind of work we are doing, if you or anyone could confirm that we can at least do what Source and Garry's Mod can do, we will without a doubt begin some projects on Natural Selection 2. We thank you in advance.
2.)AFAIK there was virtually no limit.
Ps got some questions myself... does steamworks include a voice package ?
If not can't you use Teamspeak 3 ?
1) What Seker said really. The blogs have told us that as much of the game code as possible has been LUA scripted to enable easy modibility.
2) Download Spark. It's impressively massive. Using Source and UED as an example, compared to those two it is massive.
3) Again download Spark. So far we only have prop and texture usage. There is more than likely a plan post-game development to incorporate a more intuitive geometric creation feature. I think somewhere along the line, this has been said in a blog as a "for the future".
4) An LoD question is just that. In Spark you currently can not set this. It shouldn't be a problem with sort of environments NS2 brings.
Are you looking at switching your modification to the Spark engine in the future? If so, I'm interested to know exactly what modification it is if you have a link to a current site, information etc? It's pretty interesting someone may already plan to use the engine for modding :)
Thank you for the answers.
We have a game mode for Garry's Mod which attempts to recreate the S.T.A.L.K.E.R. game experience in an online fashion. Players can trade, join factions, look for artifacts, etc. Most importantly though, and what separates in from mainstream games, you have to play your character. This is not a death-match game mode, there are rules of engagement and reasons why you should not get in a fight all the time. We have administrators on all the time to enforce this and make sure that players do not start death-matching.