Theoretical mod of NS2 - NS2 revised.
Soul_Rider
Mod Bean Join Date: 2004-06-19 Member: 29388Members, Constellation, Squad Five Blue
Mod Bean Join Date: 2004-06-19 Member: 29388Members, Constellation, Squad Five Blue
in Modding
Active discussion on the forums is very much about NS2 in it's current state and what needs to be done in the future.
As a modding community, we are in a fairly unique position, in that if there are things we feel could do with changing, we can change them and try them out.
Most of us have our own thoughts on decisions that were made during the development of NS2, so I thought, how about theory-crafting a revised NS2 as modders see it. Note, this is only relevant to Spark, I don't want discussions about the choice of engine, just the way the engine was used and the game produced. How would you develop it differently?
I don't mean this to be divisive and welcome everyone's input, but I wanted to focus the input in the forums from the modding community. The comp and general forums have enough of these types of thread already, dealing with gameplay choices etc. I will start with the one design decision which I think hamstrung NS2.
Game World Size::
I brought this up very early in the games development when we got access to the editor and the mapping guidelines were produced. My initial gut reaction back then, and my firm belief to this day, is that NS2 went way too big on player sizes.
If you think of all the problems that were hit in the early days, then think how many would have been reduced by having a player of 50% smaller than currently.
Less polys required to have detailed models, smaller texture/normal map sizes needed for every piece of content, smaller model files. These would have reduced the colossal install size and the memory requirements/draw calls etc.
Smaller world size means occlusion is scaled so each occlusion area is now half the size that it was, putting less strain on the system. As a side effect draw distance is also doubled. As an extra bonus it takes less time to greybox a map.
A 50% reduction in game world size means a 50% reduction in speed, to maintain current movement speeds. this puts much less strain on the collision and hit detection, making it more accurate.
There is much more that a reduced model size would have helped with in this game, but of course, like any thing, it is a double edged sword, and things like detail mapping in the editor etc would have been a pain...
As an aside, I did lots of experiments with shrinking models in Gorgecraft, and I did see a lot of benefits, however, model poly's, texture sizes etc weren't reduced as they were vanilla.
So, my addition into the theory crafted NS2 revised mod would be massively reduced (but same scale) game world.
What significant, or not so significant, things would you do differently if you were making a revised NS2 from a development perspective.
As a modding community, we are in a fairly unique position, in that if there are things we feel could do with changing, we can change them and try them out.
Most of us have our own thoughts on decisions that were made during the development of NS2, so I thought, how about theory-crafting a revised NS2 as modders see it. Note, this is only relevant to Spark, I don't want discussions about the choice of engine, just the way the engine was used and the game produced. How would you develop it differently?
I don't mean this to be divisive and welcome everyone's input, but I wanted to focus the input in the forums from the modding community. The comp and general forums have enough of these types of thread already, dealing with gameplay choices etc. I will start with the one design decision which I think hamstrung NS2.
Game World Size::
I brought this up very early in the games development when we got access to the editor and the mapping guidelines were produced. My initial gut reaction back then, and my firm belief to this day, is that NS2 went way too big on player sizes.
If you think of all the problems that were hit in the early days, then think how many would have been reduced by having a player of 50% smaller than currently.
Less polys required to have detailed models, smaller texture/normal map sizes needed for every piece of content, smaller model files. These would have reduced the colossal install size and the memory requirements/draw calls etc.
Smaller world size means occlusion is scaled so each occlusion area is now half the size that it was, putting less strain on the system. As a side effect draw distance is also doubled. As an extra bonus it takes less time to greybox a map.
A 50% reduction in game world size means a 50% reduction in speed, to maintain current movement speeds. this puts much less strain on the collision and hit detection, making it more accurate.
There is much more that a reduced model size would have helped with in this game, but of course, like any thing, it is a double edged sword, and things like detail mapping in the editor etc would have been a pain...
As an aside, I did lots of experiments with shrinking models in Gorgecraft, and I did see a lot of benefits, however, model poly's, texture sizes etc weren't reduced as they were vanilla.
So, my addition into the theory crafted NS2 revised mod would be massively reduced (but same scale) game world.
What significant, or not so significant, things would you do differently if you were making a revised NS2 from a development perspective.
Comments
Only Additive Abilities.
Abilities currently have pros and cons. In my revised version, abilities would only be additive.I don't mean stacking damage, but weapons wouldn't have weight penalties etc.
Of course this would require everything to be rebalanced, but everything should progress and you should be improving in all areas as you increase, not sacrificing speed for a limited role weapon etc.
To control this and stop it descending into chaos, the upgrades would need to be more level based. I don't mean all tied to levels like armor or weapons, but specific tech should be available at certain 'soft levels' enabling strategy variations.
This should reflect into combat situations (using the levels of armor as an example but to be considered a soft, not explicit example) as follows, assuming equal skill:
Level 0 v Level 0 50% chance of victory
Level 1 v Level 0 66 v 33%
Level 2 v Level 0 75 v 25%
Level 3 v Level 0 80 v 20%
Note this is % chance in each individual battle of equals, and cannot be reliably measured in any way, so it's a design ideal only.
Grouping into efficient meta levels, is required to make this work, but the aim is to make the levels as invisible as possible in actual gameplay. It should just feel right.
I love advanced movements, and even if I don't seem to have the co-ordination to do them these days, I still think they are a fundamental part of getting a game like NS2 right. Having a load of high skill moves available is great, but if you only have simple moves and god-like moves, it creates a chasm in the game which doesn't exist in individual player skill, but purely because of no mid-level mechanics.
It's all very well to design a high end movement mechanic, but the most important part of any mechanic is the skill curve you introduce to train the player in that mechanic. That means for every advanced movement mechanic you have, you should make smaller parts of it individually provide boosts, so it's not entirely Do it right or stop dead, but if you do it right, you get the maximum benefits.
This should apply across the whole lifeform, so in theory level 1 abilities should be training you towards using the level 2 abilities, etc. There needs to be more consistency within each individual lifeform, so a sensible skill curve can be made to allow player to learn the mechanics through natural trial and error, rather than through searching forums etc for hidden mechanics on how to do what all these hackers are doing!! (Of course hidden mechanics make players think others are hacking, when they can't see or don't know how a player is doing something like that, instantly cheat is called.)
If you have a good skill curve, you can make the skill ceiling as high as you want, it just means those willing to put the work will get there, but players will be split across multiple levels rather than the 3 tiers we have at the moment.
These posts could apply to any game as design principles I guess..