Networks

[Karsten75]

I really like the networking aspect of CW a lot. It makes me think of the Internet in some ways, especially now that I've found the Easter Egg saying how the network algorithms work.

But it brings me to at least two issues I'd like to discuss or make a suggestion for.

The first is for trunk lines that perhaps can span any length of distance between nodes, but the user has to pay for it by length, so a very long connection will cost much more than a short connection. Something like the relays, but over longer distances. The trunk line does not connect to other objects between its termination nodes, so all packets that enters it at one end will travel the entire length of the trunk line. It may be possible that the user can insert a "connector" in the trunk line to tap it at a certain point.

The other is that I've noticed that even if I have a substantial reserve of energy, build time is not substantially reduced for a single object, especially if the object is very far from the city. It seems that each packet has to arrive before another packet is sent? I would think that if I have substantial reserves of energy, some form of buffering can be employed to send all the required packets in a single burst?

[Aurzel]

your 'trunk lines' idea has been mentioned before though the addition of having to pay more for longer connections is a new concept but personally i dont like that part
as for the network you're off about the packets, they're not sent one at a time, the buildings request them at a constant rate, say 1 every second, in a very long network it's entirely possible to have all the packets a building requested threading their way through the netqork before the first actually reaches its detination

[nic nac]

i wonder what happens if the building is destroyed before the packets arive? never paid much attention.

[knucracker]

If there are packets in-route for a destination and then that destination is destroyed (or there is no path to it), the packets evaporate into the ether....  This can happen fairly commonly whenever you move a weapon over big distances that is still receiving ammo packets.  I'm often mindful of this when moving weapons so I don't waste ammo packets.

I've thought about adding a little visual 'pop' whenever this happens to a packet so you would be more aware of it...

[nic nac]

shouldn't it rather reroute to the city?

a few questions:
i wonder what the power-to-packet ratio is?

shouldn't the collectors and generators send blue packets to the city / storage (and the storage to the city if their supply is dwindling).

will there be a limit on how much packets can travel on a line? I made a network so dense and concentrated that i had hundreds of packets traveling through a singe connection.


btw: The link to kongregate you posted gives kudos to whiteboard warfare. remove the ?referrer=whiteboardwar parameter if you dont want to.

[Aurzel]

if there were all those extra packets it would just make things more confusing and laggy, and there's no limit to how many packets can be on a single network though there is a limit to how many packets odin city can produce at any one time, atm this is 32

[Karsten75]

The other aspect of gameplay that might be interesting would be if, like on a network, one could prioritize packets, either in speed or in production, so that production of packets could be focused to keeping weapons supplied over building new units, so maybe say 75% weapons packets and 25% producction packets if there is insufficient supply of packets?

[knucracker]

The whiteboardwar referrer on the link is my user name on kongregate (I made it a long time ago before Knuckle Cracker existed).  I've been too lazy to create another account.

As for packets...
I decided to have the packets evaporate, since there may not even be a route back to the city (it could have moved or the paths might have been cut).  You could end up in a situation where the packets have no place to go or return to, so they'd just have to stop or bounce between nodes (which was another option I considered).  In the end I opted for evaporation since it is one more little thing that you can watch out for as a really advanced player.

The collectors and generators produce 'energy' which is conducted back along the lines to the city.  The city takes this energy and manufactures little packets for construction, ammo, and energizing the totems.  This is why you don't see stuff moving from the collectors to the city (they just make 'electricity').

The power to packet ration is 1:1.  One packet represents 1 unit of energy.

And as Aurzel said, there is no limit to the number of packets that can travel on a line.  

[Karsten75]

there is no limit to the number of packets that can travel on a line.  

Well, there *is* something there. I've played on maps and for the heck of it I overdevelop after I have capped off the emitters. Unfortunately I don't have the smarts to do video capture, but the scenario is roughly like this, I have 100 or more nuclear units as well as the entire map covered with well-spaced collectors, I have lots of speed units and storage units of maybe >1,000 units. Additionally I have central relay lines running for fast packet delivery. Even in this scenario, if I build a far-off unit, I see only a few packets at a time on the network. THey go fast, but only a few goes. I'd expect to see a dense flow of packets, since everything is in place?

I see like maybe 5 or 7 packets on the network for that one new unit.

[knucracker]

Any given structure will only build so fast.  A structure will request a packet about once per second.  To watch a giant flood of packets, cap all of the creeper (or create a map without any), then save up tons of energy.  Pause the game, and then build as many things as you can (make sure they are all connected to your graph).  Unpause the game and watch the packets fly.  Note that Odin City can only produce up to 32 packets per second (this is a limit of the city's production plant).  But 32 per second is a machine gun of packets.

[Karsten75]

Done that. It's fun to watch.

[Aurzel]

alternately, make the empty map and build a very long winding network before the 32 objects at the end and watch even more packets flow through the network

[nic nac]

The other aspect of gameplay that might be interesting would be if, like on a network, one could prioritize packets, either in speed or in production, so that production of packets could be focused to keeping weapons supplied over building new units, so maybe say 75% weapons packets and 25% producction packets if there is insufficient supply of packets?

i just wanted to suggest that: priority gates, that can be toggled. like making a special relay line and toggling them into priority mode for your forward locations.

heck, even prioritizing it from the city would be neat (like asigning ammo to build ratio and rift-tower supply on/off).

allways hate it when i lose a relay because the generator(s) did draw to much energy and the turrets ran out of ammo.