TCBM: The Captain's Balance Mod
TheCaptain
Join Date: 2002-12-02 Member: 10390Members
Join Date: 2002-12-02 Member: 10390Members
<div class="IPBDescription">Doing a little beta balancing and bugfixing</div>Poking around in the code is a great way to both find bugs and explore balance issues. This mod started out as me being frustrated Sentries always faced 'east', so I tried to see if I could make them face the same direction as the building MAC...
Some of these changes mirror changes the devs will make in an upcoming build. I'm sure the devs will make many balance changes once they add more features and iron out technical issues. In the meantime, I'd like to see how the game plays with some of the balance issues ironed out.
The goal for TCBM is to rebalance the game for the current playable map sizes and player counts, while trying to decrease the influence of lag on the game. Right now the target is for a small game and map (5v5 and Rockdown). I want to increase the importance of res nodes, and increase the interdependence between players and commanders, as well as decreasing the lag-inducing power of some units, and the balance breaking power of some weapons.
I've focused mostly on the marines for this patch, but I'm open to changing some elements of the Kharra (crag health? lerk spike snipe mode balancing?). It's entirely possible that with the economy slowed down in general, and with marines having a longer transition to T2, that they will be much more vulnerable in the early game.
TCBM was written for build 155, so I still need to merge my changes with 156 and test them.<b> As far as I know, since server lua files are downloaded to the client, only the server needs the mod installed.</b> I have only tested it overwriting the default lua files, but I'm fairly certain that the server will be able to run it as a 'mod' and still let vanilla players connect.
Here are the changes I've made for the first release (Some bugfixes, some features in line with what the devs have intended, some features that are similar to NS1, and some fairly radical changes as well)
I should be able to post it later tonight after the merge and testing.
<blockquote>problem: flamer too powerful against players
<blockquote>changed: decrease flamer power against players / initial damage
(Flame damage type now acts like 'light' and 'structural', so is most effective against unarmored structures. Damage is halved so the 2x damage vs structures is equal to the old value. As a 'light' weapon, it only does 1/4th damage to armor points, making it ineffective against units with heavy armor like the fade. Flamer damage is still 100dps against buildings and 50dps (mitigated by armor) against players.)
</blockquote><blockquote>changed: decrease size of screen obscuration effect
(This is just an effect played at your model origin. This uses 'small' burn' for players so it obscures less of your vision)
</blockquote><blockquote>added: chance to put out flames depends on percentage of armor
(This follows the assumption that kharra armor will protect the alien from flames, but as that armor gets broken, the flammable bits of the alien become more vulnerable. Heavily armored units with full armor, like the fade, will extinguish in 1-2 seconds. Units which have lost their armor, like structures, may burn for up to 10 seconds or more. This has a neat side effect: sicne pistols hurt armor, you can use a pistol to take off a fade's armor, then set it on fire more easily.)
</blockquote><blockquote>added: fade blink puts out flames
(This seems reasonable, as a fade which is reconsitutting somewhere else probably won't include the fire. This should help decrease the debilitation of the fade by fire)
</blockquote><blockquote>fixed: Flames are now blocked by walls and other geometry
(This uses traces to all 6 faces of the extents of a unit, so that a unit with its center blocked by a wall, but still sticking out on one side, can still be hit by flames)
</blockquote>problem: hydra lags server, can be spammed by gorges
<blockquote>changed: hydra uses bullet traces instead of projectiles
(Spike traces are 'delayed' by one update cycle, so it is still possible to dodge. This should decrease the serverkilling power of the hydras which used to spawn one networked projectile for each attack. When the networking improves this could be changed back to a projectile.)
</blockquote><blockquote>added: Hydras lose health over time
(240 seconds. This is based on an idea from this post: <a href="http://www.unknownworlds.com/ns2/forums/index.php?showtopic=111470&hl=" target="_blank">http://www.unknownworlds.com/ns2/forums/in...=111470&hl=</a> . A Gorge can still spam hydras in this model, but he is encouraged to stay near his hydras to heal them, or build them near crags in a defensive layout)
</blockquote>problem: gl is too powerful against skulks and other low health units
<blockquote>changed: decrease damage radius of grenade
(now squared instead of linear falloff, but with range 10. At 0m, you take 150 damage, but at 5m you only take about 40)
</blockquote><blockquote>fixed: add occlusion checks to grenade explosions
(This uses traces to all 6 faces of the extents of a unit, so that a unit with its center blocked by a wall, but still sticking out on one side, can still be hit by explosion.)
</blockquote><blockquote>changed: add bouncing
(Grenades behave like NS1 grenades, exploding when coming when coming into contact with players/structures, bouncing otherwise, and detonating after a set time or when speed drops too low. This decreases the utility of the grenades in a panic situation against fast moving enemies)
</blockquote><blockquote>fixed: change damage type to 'structural', halve damage.
(Since grenades were laid out as structural in the 'damage_types' blog post, I assumed this was an oversight and changed it. grenades now do 150 damage to players and 300 against buildings (structural gives x2))
</blockquote>problem: too many resources at game start / too many resources after short period of playing
<blockquote>changed: decrease starting res (10 plasma, 50 carbon)
(Since commanders only spend resources on command items, this gives them a pool of resources geared only towards paying for "team" items, assuming that players are getting the other half of the res. This should increase the interdependence between players and commanders, and force commanders to make a choice between expanding tech points, teching, or booming in the early game)
</blockquote><blockquote>changed: decrease harvesting rate (from 6 seconds to 5, decrease carbon income to 0.5 from 1, plasma income stays at 1 per 5 seconds)
(This decreases the harvesting rate to about half, giving commanders the "team" half of the income, and players the "individual" half, roughly relative to NS1 rates. Slowing down the economy should decrease the number of buildings, and thus the lag.)
</blockquote><blockquote>added: max carbon/plasma (200/100)
('kMaxResources' refers to model animations, not plasma/carbon, and was set to 10000. This sets a reasonable resource limit so players stalemating will not suddenly have 500 plasma or carbon. Considering making max team carbon dependent on CC's, but
</blockquote>problem: players accumulate too much plasma and 'break' res model
<blockquote>changed: distribute plasma among teammembers instead of to every team member
(This is a controversial change, moving the res model back towards NS1. It seems most reasonable to me that each tower provides a fixed amount of income, no matter how many people are playing, split among the team members. This serves to make plasma more valuable, and holding res nodes more important. Larger teams will need more res nodes to keep income per player high. Ideally the commander could drop a 'plaspack' which would convert carbon to plasma, so players with low plasma could afford important items)</blockquote><blockquote>added: subtract plasma each time players spawn (percentage or flat rate, or all)
(This is relatively controversial. Since the only thing that plasma is spent on is buying a weapon or alien upgrade, there is never any player fear about losing plasma or a desire to 'conserve' it. This deducts 2 plasma each time players die and respawn. With only one RT, and 5 players, it will take you 50 seconds (0.2 plasma/5 seconds) to earn 2 plasma back. With 3 RT's, it will only take you 16 seconds. With three fully upgraded RT's, it will take you 8 seconds. Deepest apologies to those who get stuck and need to /kill in console.)
</blockquote>problem: sentries get attacked from behind/bypassed too easily
<blockquote>changed: rotate sentries faster
(Sentry rotation rate is 4x faster, but the 'powerup/powerdown' time is the same.)
</blockquote><blockquote>added: set direction of sentry to direction of mac
(It's not perfect (eg, we can't set the direction of structures while placing), but it's fairly easy to position the MAC in the correct direction before building.)
</blockquote><blockquote>changed: increase sentry arc (120*?)
(This gives sentries a bit more wiggle room in defending bases and hallways)
</blockquote><blockquote>changed: Increase sentry ROF
(This doubles sentry ROF but halves damage, so it can get in more attacks and more knockback while a unit is in front of it. This could add to server lag, however.)
</blockquote><blockquote>added: Add "minigun" style knockback to sentry rounds
(Sentries now 'push back' units they hit as described in an upcoming task. Combined with the increased ROF, this can be more effective at blocking skulks in their frontal arc.)
</blockquote><blockquote>changed: Double sentry cost
(to decrease number of sentries, and hopefully lag)
</blockquote>problem: replicate is too effective during assaults and as 'cheese'
<blockquote>changed: create unbuilt instead of built structures
(This makes replicate more of an NS1 commander type ability, and removes the ability for commanders to spam, for example, fully built sentries and armories in the enemy base (especially on rockdown, where the hive has no marine power node to destroy). Marines are still required to spend a few seconds building the items. Since no MACs are required, this allows for ninjaing and emergency building, while still creating interdependence between players and commanders)
</blockquote><blockquote>changed: decrease the price of replicate
(Since replicate now no longer creates fully built structures, its cost was decreased by 60% (EG armory from 50 to 20, base price of an armory is 10))
</blockquote><blockquote>fixed: make replicate use the REPLICATE cost rather than the STRUCTURE cost
(This was a bug. Replicated structures were using the original item's cost instead of the replicated item's cost.)
</blockquote>problem: armor code doesn't work!
<blockquote>fixed: Health subtracted now takes into account damage blocked by armor
(Previously, armor points blocked damage, but the health points subtracted were calulated incorrectly. Now, 70% of damage goes to armor, 30% to health, and any damage not blocked by armor goes to health. This creates more variation in the weapon damage types.)
</blockquote>problem: no information about personal or team resources unless commanding or buying
<blockquote>added: add plasma, carbon, #resourcers and #techpoints information to top of player UI
(Also displays carbon/plasma gather rate, number of harvester upgrades, and level of highest techpoint)
</blockquote>problem: hivesight shows when switching from alien to marine, during the same or subsequent games on the same server
<blockquote>fixed: Hivesight no longer displays for marines or marine commanders
(This is a hack within Alien_Client that does not display hivesight if the player is a marine or marine commander. It seems that alien client is not terminating when you switch teams directly or via the readyrom.)
</blockquote>problem: marine armor/health hud shows when switching to alien
<blockquote>(Not fixed yet, needs a hack within GUIMarineHUD)
</blockquote></blockquote>
Some of these changes mirror changes the devs will make in an upcoming build. I'm sure the devs will make many balance changes once they add more features and iron out technical issues. In the meantime, I'd like to see how the game plays with some of the balance issues ironed out.
The goal for TCBM is to rebalance the game for the current playable map sizes and player counts, while trying to decrease the influence of lag on the game. Right now the target is for a small game and map (5v5 and Rockdown). I want to increase the importance of res nodes, and increase the interdependence between players and commanders, as well as decreasing the lag-inducing power of some units, and the balance breaking power of some weapons.
I've focused mostly on the marines for this patch, but I'm open to changing some elements of the Kharra (crag health? lerk spike snipe mode balancing?). It's entirely possible that with the economy slowed down in general, and with marines having a longer transition to T2, that they will be much more vulnerable in the early game.
TCBM was written for build 155, so I still need to merge my changes with 156 and test them.<b> As far as I know, since server lua files are downloaded to the client, only the server needs the mod installed.</b> I have only tested it overwriting the default lua files, but I'm fairly certain that the server will be able to run it as a 'mod' and still let vanilla players connect.
Here are the changes I've made for the first release (Some bugfixes, some features in line with what the devs have intended, some features that are similar to NS1, and some fairly radical changes as well)
I should be able to post it later tonight after the merge and testing.
<blockquote>problem: flamer too powerful against players
<blockquote>changed: decrease flamer power against players / initial damage
(Flame damage type now acts like 'light' and 'structural', so is most effective against unarmored structures. Damage is halved so the 2x damage vs structures is equal to the old value. As a 'light' weapon, it only does 1/4th damage to armor points, making it ineffective against units with heavy armor like the fade. Flamer damage is still 100dps against buildings and 50dps (mitigated by armor) against players.)
</blockquote><blockquote>changed: decrease size of screen obscuration effect
(This is just an effect played at your model origin. This uses 'small' burn' for players so it obscures less of your vision)
</blockquote><blockquote>added: chance to put out flames depends on percentage of armor
(This follows the assumption that kharra armor will protect the alien from flames, but as that armor gets broken, the flammable bits of the alien become more vulnerable. Heavily armored units with full armor, like the fade, will extinguish in 1-2 seconds. Units which have lost their armor, like structures, may burn for up to 10 seconds or more. This has a neat side effect: sicne pistols hurt armor, you can use a pistol to take off a fade's armor, then set it on fire more easily.)
</blockquote><blockquote>added: fade blink puts out flames
(This seems reasonable, as a fade which is reconsitutting somewhere else probably won't include the fire. This should help decrease the debilitation of the fade by fire)
</blockquote><blockquote>fixed: Flames are now blocked by walls and other geometry
(This uses traces to all 6 faces of the extents of a unit, so that a unit with its center blocked by a wall, but still sticking out on one side, can still be hit by flames)
</blockquote>problem: hydra lags server, can be spammed by gorges
<blockquote>changed: hydra uses bullet traces instead of projectiles
(Spike traces are 'delayed' by one update cycle, so it is still possible to dodge. This should decrease the serverkilling power of the hydras which used to spawn one networked projectile for each attack. When the networking improves this could be changed back to a projectile.)
</blockquote><blockquote>added: Hydras lose health over time
(240 seconds. This is based on an idea from this post: <a href="http://www.unknownworlds.com/ns2/forums/index.php?showtopic=111470&hl=" target="_blank">http://www.unknownworlds.com/ns2/forums/in...=111470&hl=</a> . A Gorge can still spam hydras in this model, but he is encouraged to stay near his hydras to heal them, or build them near crags in a defensive layout)
</blockquote>problem: gl is too powerful against skulks and other low health units
<blockquote>changed: decrease damage radius of grenade
(now squared instead of linear falloff, but with range 10. At 0m, you take 150 damage, but at 5m you only take about 40)
</blockquote><blockquote>fixed: add occlusion checks to grenade explosions
(This uses traces to all 6 faces of the extents of a unit, so that a unit with its center blocked by a wall, but still sticking out on one side, can still be hit by explosion.)
</blockquote><blockquote>changed: add bouncing
(Grenades behave like NS1 grenades, exploding when coming when coming into contact with players/structures, bouncing otherwise, and detonating after a set time or when speed drops too low. This decreases the utility of the grenades in a panic situation against fast moving enemies)
</blockquote><blockquote>fixed: change damage type to 'structural', halve damage.
(Since grenades were laid out as structural in the 'damage_types' blog post, I assumed this was an oversight and changed it. grenades now do 150 damage to players and 300 against buildings (structural gives x2))
</blockquote>problem: too many resources at game start / too many resources after short period of playing
<blockquote>changed: decrease starting res (10 plasma, 50 carbon)
(Since commanders only spend resources on command items, this gives them a pool of resources geared only towards paying for "team" items, assuming that players are getting the other half of the res. This should increase the interdependence between players and commanders, and force commanders to make a choice between expanding tech points, teching, or booming in the early game)
</blockquote><blockquote>changed: decrease harvesting rate (from 6 seconds to 5, decrease carbon income to 0.5 from 1, plasma income stays at 1 per 5 seconds)
(This decreases the harvesting rate to about half, giving commanders the "team" half of the income, and players the "individual" half, roughly relative to NS1 rates. Slowing down the economy should decrease the number of buildings, and thus the lag.)
</blockquote><blockquote>added: max carbon/plasma (200/100)
('kMaxResources' refers to model animations, not plasma/carbon, and was set to 10000. This sets a reasonable resource limit so players stalemating will not suddenly have 500 plasma or carbon. Considering making max team carbon dependent on CC's, but
</blockquote>problem: players accumulate too much plasma and 'break' res model
<blockquote>changed: distribute plasma among teammembers instead of to every team member
(This is a controversial change, moving the res model back towards NS1. It seems most reasonable to me that each tower provides a fixed amount of income, no matter how many people are playing, split among the team members. This serves to make plasma more valuable, and holding res nodes more important. Larger teams will need more res nodes to keep income per player high. Ideally the commander could drop a 'plaspack' which would convert carbon to plasma, so players with low plasma could afford important items)</blockquote><blockquote>added: subtract plasma each time players spawn (percentage or flat rate, or all)
(This is relatively controversial. Since the only thing that plasma is spent on is buying a weapon or alien upgrade, there is never any player fear about losing plasma or a desire to 'conserve' it. This deducts 2 plasma each time players die and respawn. With only one RT, and 5 players, it will take you 50 seconds (0.2 plasma/5 seconds) to earn 2 plasma back. With 3 RT's, it will only take you 16 seconds. With three fully upgraded RT's, it will take you 8 seconds. Deepest apologies to those who get stuck and need to /kill in console.)
</blockquote>problem: sentries get attacked from behind/bypassed too easily
<blockquote>changed: rotate sentries faster
(Sentry rotation rate is 4x faster, but the 'powerup/powerdown' time is the same.)
</blockquote><blockquote>added: set direction of sentry to direction of mac
(It's not perfect (eg, we can't set the direction of structures while placing), but it's fairly easy to position the MAC in the correct direction before building.)
</blockquote><blockquote>changed: increase sentry arc (120*?)
(This gives sentries a bit more wiggle room in defending bases and hallways)
</blockquote><blockquote>changed: Increase sentry ROF
(This doubles sentry ROF but halves damage, so it can get in more attacks and more knockback while a unit is in front of it. This could add to server lag, however.)
</blockquote><blockquote>added: Add "minigun" style knockback to sentry rounds
(Sentries now 'push back' units they hit as described in an upcoming task. Combined with the increased ROF, this can be more effective at blocking skulks in their frontal arc.)
</blockquote><blockquote>changed: Double sentry cost
(to decrease number of sentries, and hopefully lag)
</blockquote>problem: replicate is too effective during assaults and as 'cheese'
<blockquote>changed: create unbuilt instead of built structures
(This makes replicate more of an NS1 commander type ability, and removes the ability for commanders to spam, for example, fully built sentries and armories in the enemy base (especially on rockdown, where the hive has no marine power node to destroy). Marines are still required to spend a few seconds building the items. Since no MACs are required, this allows for ninjaing and emergency building, while still creating interdependence between players and commanders)
</blockquote><blockquote>changed: decrease the price of replicate
(Since replicate now no longer creates fully built structures, its cost was decreased by 60% (EG armory from 50 to 20, base price of an armory is 10))
</blockquote><blockquote>fixed: make replicate use the REPLICATE cost rather than the STRUCTURE cost
(This was a bug. Replicated structures were using the original item's cost instead of the replicated item's cost.)
</blockquote>problem: armor code doesn't work!
<blockquote>fixed: Health subtracted now takes into account damage blocked by armor
(Previously, armor points blocked damage, but the health points subtracted were calulated incorrectly. Now, 70% of damage goes to armor, 30% to health, and any damage not blocked by armor goes to health. This creates more variation in the weapon damage types.)
</blockquote>problem: no information about personal or team resources unless commanding or buying
<blockquote>added: add plasma, carbon, #resourcers and #techpoints information to top of player UI
(Also displays carbon/plasma gather rate, number of harvester upgrades, and level of highest techpoint)
</blockquote>problem: hivesight shows when switching from alien to marine, during the same or subsequent games on the same server
<blockquote>fixed: Hivesight no longer displays for marines or marine commanders
(This is a hack within Alien_Client that does not display hivesight if the player is a marine or marine commander. It seems that alien client is not terminating when you switch teams directly or via the readyrom.)
</blockquote>problem: marine armor/health hud shows when switching to alien
<blockquote>(Not fixed yet, needs a hack within GUIMarineHUD)
</blockquote></blockquote>
Comments
also in case you didn't know, from what i understand for the server to distribute files it needs to be created <b>as a mod</b> and not just changing the standard game files. I'm not sure what this entails, I believe it has to do with having all relevant game files for the mod in another folder, but there's more to it than just that, possibly tweaking some xml files. I took a look at the Launchpad.exe and it looks like it might handle some of that for you but i'm not sure the extent of how that works.
If a dev could shed some light on how this is all set up that'd be awesome.
also, if you'd like to test the server download functionality, set up a server and make a post and i'm sure more than enough people would be willing to test it out.
Also, you might want to make the skulk flight a bit better, like maybe make holding space enough instead of having to spam it (hurts my thumb D:).
I would also love some info on when a server should use a mod or just add a single lua file. This is part of the documentation I want the most.
Is a mod only the lua code you put in that folder, or does it inherit stuff from core folder? If so, does it inherit from the ns2 folder aswell?
And will a mod give the client differ from server warning?
After I finish the merge I'll try the mod method to make sure it works. I assume that the mod will break each time the devs update a build, and I'll have to do a manual merge.. so a separate mod folder would be the best solution.
I also need to add motd/console messages/popup hints so users understand they are using a mod as opposed to the vanilla game. Since we're primarily supposed to be testing the beta, it's important that players aren't confusing official with unofficial.
I don't fully agree with some of the changes myself (it appears for example that marines will be underpowered in the early game, and the jury is definitely out on the economy changes.). Where possible I tried to match the spirit of either dev blogs/features or the NS 3.0 manual (http://www.unknownworlds.com/ns/static/Natural_Selection_Manual.html). In the meantime, I can't wait to test with a full game.
Speaking of Sentries, would it be possible to test the viability of allowing Marines to +use on a turning Sentry to accelerate rotation?
Two caveats to serversidemodding: While it seems that all gameplay code seems to have propagated (weapons, effects, damage, balancing), cost values are not sent to the client, nor are gui scripts. So if I've changed costs on the server, they aren't updated by default on the client unless I add something in (eg: transmit the server's constants to the client). I had hoped to run a display on the client's gui showing the resources, but that appears to not be running, so I'll have to figure out a slightly more hacky way.
I'll be putting the mod up for testing on the [IAM] clan server tomorrow morning, and if testing goes well I'll post to the boards here.
<ul><li>Some of this completely alters the core mechanics of ns2 -> its <u>not</u> really a balance mod only, its a ns2/ns1 hybrid.</li><li>Hope servers will be named properly, because ppl cant see if a server is vanilla or modded atm. making newcomers believe its vanilla (maybe)</li></ul>
------
<ul><li>Nerfing nade dmg + giving bounce + less aoe range + the slow reload time and only one in the chamber mechanic = useless nadelauncher against anything non static. Its like the ns1 nadelauncher, just worse... u managed to hold an get a 2nd Techpoint and all u get is 2 anti structure weaponresearches - yay.
(what this balance does = 1 guy takes the flamer for blind + structure dmg, the rest shotguns... nobody uses gl. - or at least only very very situational - since there wont be 20hydras in a room anyways)
</li><li>Maxcap (200) is a bad idea, the cap has to be adjusted depending on players on the server... and if a team manages to hold lots of rts and gets techpoints... they should get a bonus from it to overcome the enemy. (higher cap + lots of res... because they got more mapcontrol)</li></ul>
(what this balance does = 1 guy takes the flamer for blind + structure dmg, the rest shotguns... nobody uses gl. - or at least only very very situational - since there wont be 20hydras in a room anyways)</li></ul><!--QuoteEnd--></div><!--QuoteEEnd-->
the GL in ns2 is obviously meant for a slightly different role. I think the changes work well considering the gl is an addon for the machine gun, instead of its own weapon.
I think it helps to compliment testing. It tests the modability of the game and may even expose bugs in the engine that the official game code does not.
Yes, the features that this mod overwrites don't get tested, so we still need vanilla servers, but in the long run, this is a benefit to testing because it will make the game more enjoyable and keep servers filled.
Not at all. The fixes a modder makes in the script could very well be things that the devs haven't tried yet. If TheCaptain makes periodic updates to this thread and comments how things work, and a dev checks in from time to time, they might get additional data with no extra work. Maybe the mod will wind up providing a fix for something.
Even if none of that happens, and it's just a mod, the players get to have fun with the game. Worst case scenario - the players get something different, and devs continue to work on the game at full speed.
From what I can tell, it does appear that hydras no longer kill the server!
It seems the changes to the resource model, GL, flamer, sentry, and hydra helped bring the balance enough in line so that early game and mid game were evenly matched between 4 and 5 player teams of marines and aliens. Each comm had to make the decision to tech, or expand early, instead of the normal early game "drop 3 hives and as many harvesters as you can asap", so the early game lasted from 10 to 15 minutes, with a lot of tense marine/skulk battles. Even with the slower resource rate (1/2 carbon rate, plasma split among team members), the server started lagging heavily once both marines and aliens had built lots of buildings (sentries, whips, crags). In our first successful (30+ minute?, 5v5) game, once the marines had knocked the aliens down to one hive, the severe rubber-banding lag improved, and we torched the last hive to win.
In our third game (3v3, rockdown), the marines were boxed into marine start after about ten minutes in, and were stalemated against a lerk/fade combo, and double whips/crags down each hallway leaving marine start. We had managed to build enough (~10) sentries to keep the skulks out (sentries with double rof, half damage, and 'pushback'), but we were unable to push out of our stalemate with only LMG's and shotguns.
It was a good ol' NS1 type stalemate, with marines boxed into marine start, barely hanging on.. however with only fades and lerks, aliens couldn't break the stalemate, and the lag caused by sentries continuously firing at the alien structures eventually brought down the server. If the aliens had access to an Onos, they would have been easily able to break through the stalemate and win.. something I'm looking forward to in future versions.
With low building numbers, the lag was mostly just short jitters, and combat felt fairly balanced... but with high building numbers and players interacting with buildings all over the map, we got severe rubber banding and warping.
With relatively low player numbers and a lower resource rate, the only tool in the marine commander's arsenal that helped us survive was carefully placed sentries... but covering the most important angles required very careful turret farming and expansion (Locking down marine start required no fewer than 6 turrets). As much as I like directional sentries, the biggest way to cut down on lag would be to make sentries 150, 180, 225, 270, or 360 degrees so that fewer entities could cover a much larger area. A drastic per-area building limit of said sentries would keep overall numbers down (say, 5 sentries per area).
We had the most success lag-wise when the number of buildings was kept to a minimum. Even though the game is fun when there are structures covering the map and a there's lot of ground to slog through, it makes the game unplayable for more than 4-6 players. When the lag increases, buildings become the only reliable method of locking down areas, which further exacerbates the lag problem. Perhaps making the building limit much stricter per-area, per team (say, down to 5 from the 25 currently) would help keep 8-10 player games playable into an end game.
Perhaps charging plasma income for each building would create a resource-based soft cap on buildings. Buildings without available plasma income would either power off (marine) or lose health until death (alien). As is, carbon is now nicely balanced, but plasma still can flow in excess... so draining plasma based on buildings would create a tradeoff between player 'power' in terms of guns or lifeforms, and building creation. Right now there's no reason to recycle old buildings after you've built them... this would create that reason, and help to keep from overloading the server.