DI as brush
Simon493
Join Date: 2011-02-20 Member: 82724Members
Join Date: 2011-02-20 Member: 82724Members
IMO spreading the DI with the the point and click system doesn't really work that well. You should be able to paint it on starting from already existing DI and it spreads from there. This gives a more accurate/faster/easier to use system.
IE you want a ref node in another room. Instead of having to click 4-5 times guestimating where the DI will spread to you can just paint a path from your hive to the ref and it grows out from the hive to there along the path you painted.
IE you want a ref node in another room. Instead of having to click 4-5 times guestimating where the DI will spread to you can just paint a path from your hive to the ref and it grows out from the hive to there along the path you painted.
Comments
you dont even need waypoints, you could use the regular bot path finding code, you just got to tell the infestation the location it should grow its way to, and the rest does the "super slowed down DI path finding" burning up resources depending on the ammount it has to grow to reach that spot.
but knowing the current bot pathing , the DI would grow once around the map, straight through the marine base, and up to the spot it was meant to grow to, even if its just around the corner of the start hive :p
What? It would be a completely negligible amount of processing power/bandwidth. You have a circle, you paint from there where you want the DI to cover and energy cost is shown in middle of the brush as you paint, DI grows along that path much quicker than normal starting from the "powered" DI. Circle stays yellow while painting if its not connected to existing "powered" DI, turns green if the patch you are painting is connected to the DI and turns red if you can't paint DI on that area.
All that the server needs to do is keep record of what is already down (which it already does) and growth (which it already does) except the growth would occur slightly differently. It is about as demanding as a minimap, if that.
-1
-1<!--QuoteEnd--></div><!--QuoteEEnd-->
Thank you for your very informative input. It was about as constructive as "DO NOT WANT"...
Performance wise I can see it being a bit of an issue, but then DI was always going to be a performance issue due to the nature of how it works (considering it is supposed (going to) to look like that old tech demo from way-back when). Keeping track of DI infestation will probably be an issue. There are a few solutions such as DI creating a sort of multi-link linked-list type "node" for which each "node" has health and what-not, and has links to other nodes which it is connected to and those links also have health and other info like that. But there is still the issue of how to use the nodes/links in conjunction with 3D mesh deformation...
Whatever they do I'm sure DI will be vastly improved.
I hope the 3D deformation isn't any higher than say, half a skulk's height.
That way the DI entities (or whatever they "actually" are) can all be created in one swoop rather than worry about link management between DI nodes, and the server won't hate the client very much.
I imagine DI can be implemented as two types of entities, the static DI node (like how it currently works), and the mobile DI spreader, that creates DI as it moves to the location marked by the commander.
Free drawing takes virtually no server resources to do. It has been used in plenty of multiplayer games for at least a decade. For all sorts of thing. Minimap annotating. Path marking. Strategical markups. It has never been a demanding thing to implement.
That said, I like the idea. If it can be done without considerable overhead, I am all for it.
P.S. I "love" it when people say something is a bad idea because the perceived implementation would be laggy or unbalance the game (my personal favorite). A bit of brainstorming and time are often all is needed to come up with a creative solution that doesn't break the game.