Ideas for reducing lag both client and server side
Chubby Chu
Join Date: 2012-11-20 Member: 172576Members
Join Date: 2012-11-20 Member: 172576Members
<div class="IPBDescription">Suggested changes to cysts / infestation</div><b>-edit - TL;DR-
</b>Drop entity count to speed up server tics, and speed up in game FPS by removing the resource hog that is dynamic infestation from cysts. Retain the Cyst linkage concept but now only render a single tubular vein object. Change infestation to a per room basis (based on some form of cyst control within a room), and apply it as a texture swap or applying a room wide decal.
<b>-end TL;DR-</b>
My opinion is the multiple cysts and the dynamic infestation (while very cool and atmospheric), create too many additional entities and causes more lag than is worth it. My idea is to change up the way infestation / cysts work in the interest of speeding up the game and reducing the large FPS drops a lot of player’s experience, and hopefully reduce the amount of entities servers have to keep track of to allow an increased tic rate.
So I think the way infestation is drawn / generated ought to change. Instead of having the game dynamically draw the infestation all around the cysts and alien controlled areas, change it to where aliens spread infestation a whole room at a time. Now basically infestation becomes a similar concept to the power node. Just as marine buildings need power in the room to work, so too alien structures would need infestation in the room to survive.
So to have this concept drastically save resource files, have the game have 2 different texture sets for a room. 1 set is regular, the other set is infested. Since infestation is sort of standard looking already you could probably just reuse the current infestation texture or something? This way rather than drawing a whole bunch of different infestation polygons, the game just swaps in a different texture set on a per room basis. Maybe this would be easier as a decal applied over the whole room? That way you could show the infestation "drying up" if marines gain control of a room. I know decals aren’t in the game yet, but maybe this could come with it? And simpler still, severs in theory would only need to keep track of whether a room is controlled by marines, aliens, or is neutral now. Then let the clients sort out how to draw the room instead of keeping track of where the infestation currently is.
So with the infestation change, the cysts would need to change up a bit too. I’m not suggesting to change up the current functionality of the cysts (i.e. they still need to be linked to survive). But remove the infestation generation from them. In order to still show they are linked, have a vein be shown that connects cysts to each other. If you destroy a cyst, the vein is destroyed too until you rebuild the cyst (at which point the game should re-link the cysts with veins like it currently does with infestation). I’m just envisioning a dynamic “tube†rendered to look like a vein would take up a lot less resources than the dynamic creep most likely does.
Now to get the infestation to generate in a room, I suggest 1 of 3 options.
Option 1: Once you have X amount of cysts in a room, the room becomes infested. The number either needs to be standard across the board, or shown on the mini map to avoid confusion.
Option 2: The alien commander must place a cyst into the slot reserved for the marine power node. This cyst then becomes a “mega†cyst with much more health than a standard cyst (same as a power node?), and can survive alone much longer without being linked to other cysts when a marine severs the vein connection. I favor this idea since now an entire room would be infested so you couldn’t have 2 sides build in the same room at the same time anyway.
Option 3: The alien commander has to place a cyst into 4 corner areas of a room (which should be highlighted red / green on the commander interface so he can quickly tell if a room is “cysted up.â€). Infestation of a room goes away once marines kill 2~3 of the 4 cysts.
In addition to these, a Hive automatically controls a room with no other options needed.
These cyst options would need to be balanced to keep flow of the game similar to how it is now. Since you would most likely need more cysts if left as is you might need to lengthen the allowed distance between cysts, or reduce the cost / built time.
Now I don’t know how feasible this all would be, but surely something like it could be done? Sorry if this topic has been suggested before, I did try a brief search before posting though.
</b>Drop entity count to speed up server tics, and speed up in game FPS by removing the resource hog that is dynamic infestation from cysts. Retain the Cyst linkage concept but now only render a single tubular vein object. Change infestation to a per room basis (based on some form of cyst control within a room), and apply it as a texture swap or applying a room wide decal.
<b>-end TL;DR-</b>
My opinion is the multiple cysts and the dynamic infestation (while very cool and atmospheric), create too many additional entities and causes more lag than is worth it. My idea is to change up the way infestation / cysts work in the interest of speeding up the game and reducing the large FPS drops a lot of player’s experience, and hopefully reduce the amount of entities servers have to keep track of to allow an increased tic rate.
So I think the way infestation is drawn / generated ought to change. Instead of having the game dynamically draw the infestation all around the cysts and alien controlled areas, change it to where aliens spread infestation a whole room at a time. Now basically infestation becomes a similar concept to the power node. Just as marine buildings need power in the room to work, so too alien structures would need infestation in the room to survive.
So to have this concept drastically save resource files, have the game have 2 different texture sets for a room. 1 set is regular, the other set is infested. Since infestation is sort of standard looking already you could probably just reuse the current infestation texture or something? This way rather than drawing a whole bunch of different infestation polygons, the game just swaps in a different texture set on a per room basis. Maybe this would be easier as a decal applied over the whole room? That way you could show the infestation "drying up" if marines gain control of a room. I know decals aren’t in the game yet, but maybe this could come with it? And simpler still, severs in theory would only need to keep track of whether a room is controlled by marines, aliens, or is neutral now. Then let the clients sort out how to draw the room instead of keeping track of where the infestation currently is.
So with the infestation change, the cysts would need to change up a bit too. I’m not suggesting to change up the current functionality of the cysts (i.e. they still need to be linked to survive). But remove the infestation generation from them. In order to still show they are linked, have a vein be shown that connects cysts to each other. If you destroy a cyst, the vein is destroyed too until you rebuild the cyst (at which point the game should re-link the cysts with veins like it currently does with infestation). I’m just envisioning a dynamic “tube†rendered to look like a vein would take up a lot less resources than the dynamic creep most likely does.
Now to get the infestation to generate in a room, I suggest 1 of 3 options.
Option 1: Once you have X amount of cysts in a room, the room becomes infested. The number either needs to be standard across the board, or shown on the mini map to avoid confusion.
Option 2: The alien commander must place a cyst into the slot reserved for the marine power node. This cyst then becomes a “mega†cyst with much more health than a standard cyst (same as a power node?), and can survive alone much longer without being linked to other cysts when a marine severs the vein connection. I favor this idea since now an entire room would be infested so you couldn’t have 2 sides build in the same room at the same time anyway.
Option 3: The alien commander has to place a cyst into 4 corner areas of a room (which should be highlighted red / green on the commander interface so he can quickly tell if a room is “cysted up.â€). Infestation of a room goes away once marines kill 2~3 of the 4 cysts.
In addition to these, a Hive automatically controls a room with no other options needed.
These cyst options would need to be balanced to keep flow of the game similar to how it is now. Since you would most likely need more cysts if left as is you might need to lengthen the allowed distance between cysts, or reduce the cost / built time.
Now I don’t know how feasible this all would be, but surely something like it could be done? Sorry if this topic has been suggested before, I did try a brief search before posting though.
Comments
Azaral, cant tell if it is a statement, or if you are asking a question and theorize before you found an answer :S
Looking at the code, it appears that every second, the cyst checks (serverside) if it became unconnected, and if so, tries to reconnect. But only once.
Any cyst that connects to a network with a hive, either by being placed, or because some other cyst/hive connected to it, does a check to see if it can bring other unconnected cysts into it.
But thats just how it solves being unconnected, to notice that it became unconnected in the first place, it does a check every second (serverside). This check tells its parent in the chain to check if it is connected (by asking its parent and so on), until it either reaches a hive (then it is still connected), or finds a gap in the chain (unconnected). This could obviously be optimized, but if I would guess, this does not actually eat that much performance, judging the length of cyst chains normally. Obviously it could become a problem though, since for every cyst, it checks every cyst in its chain between itself and the chains hive.
Azaral, cant tell if it is a statement, or if you are asking a question and theorize before you found an answer :S
Looking at the code, it appears that every second, the cyst checks (serverside) if it became unconnected, and if so, tries to reconnect. But only once.
Any cyst that connects to a network with a hive, either by being placed, or because some other cyst/hive connected to it, does a check to see if it can bring other unconnected cysts into it.
But thats just how it solves being unconnected, to notice that it became unconnected in the first place, it does a check every second (serverside). This check tells its parent in the chain to check if it is connected (by asking its parent and so on), until it either reaches a hive (then it is still connected), or finds a gap in the chain (unconnected). This could obviously be optimized, but if I would guess, this does not actually eat that much performance, judging the length of cyst chains normally. Obviously it could become a problem though, since for every cyst, it checks every cyst in its chain between itself and the chains hive.<!--QuoteEnd--></div><!--QuoteEEnd-->
Was asking a question and offering what I thought would be better. Every second might not seem like a lot, but it can easily add up to a lot, especially on big maps with lots of cysts. Every little bit counts.
I would have it on death send a message to the cysts the now-dead cyst is connected to to check if they are still connected. Each cyst could also hold a list of pointers (not sure what LUA does as I'm only familiar with C++) of other cysts it is connected to, and which ones it relies on to be connected to a hive. would be something like
void CheckConnection(const Cyst &this). The cysts that are checking would check the dependency list for hive connection, remove it, and if that list is empty, set itself as being unnconnected. Instead of having to check every cyst in the chain every second, you would only have to check the cysts connected to the dying cyst when it is killed. You would, however, have to check periodically, if cysts are still 'connected' and if not have them take the damage. But checking a lot of bools is faster than tracing connections. I've also read people saying their server crashed with large number of cysts (the amount mentioned was >300).
Lua has something similar to pointers, I generally call them references. very useful as it makes it possible to pass functions as arguments and such.
As far as I can tell, each cyst has a reference to its parent, but also a table of children. This table does not refer directly to the cysts, but actually contains their id. As the code says:
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->// Children can die; tragic; so only keep the id around
self.children["" .. child:GetId()] = child:GetId()<!--c2--></div><!--ec2-->
This table is however used to get a reference to the children, as there is a method Shared.GetEntity(id).
So using this, a cyst would be capable of triggering its children to update when it dies.
Apart from that, there is many things one could do to optimize, but as I said, those chains are rarely very long (rarely see ones longer than 10, and only about 5 of those at a time. What games does it reach 300? :S). They also made some effort to make the cysts not update all at the same time, but a bit more individually where each has a 1 second delay.
Explore is probably not meaningful to real gameplay since everything happens locally there. In real gameplay you have to wait for the server to tell you what you can see. You tell the server your camera location and the server tells you what entities are visible to you, so any infestation has to be regenerated when it becomes visible again instead of being kept around all the time like it's done offline.
Maybe a fog-of-war like effect would make sense here, if it stays restricted solely to infestation: as soon as a cyst is spotted, keep it known to the players that saw it (including the commander) but stop updating it's clientside status until you have a confirmed sight on it again. This way it could be kept around and only needs to be recalculated if it's status changed after the last sight.
I doubt that the blobs have any impact on the server, though, since they are only visuals and thus ideally not even computed on the server. The server only needs to know about the coverage progress of infestation for placing buildings, which can be computed without placing blobs.
<a href="http://www.unknownworlds.com/ns2/forums/index.php?showtopic=126067" target="_blank">http://www.unknownworlds.com/ns2/forums/in...howtopic=126067</a>