Virgil, I tried searching for the A* algorithm that one of the game pods mention what you use for routing, but I have had no luck. Maybe I forgot the correct name of the algorithm?
Anyway, I was messing around and saw what I thought was packets that did not follow the shortest route to their destination.
Here is a short YouTube vid: http://www.youtube.com/watch?v=dxNqHv6BaOw
If you look carefully at the packets traveling to the blaster on the bottom left, you will see that they take more nodes going via the collectors than they could have taken going via the relays. Some of the packets on the second line exhibits similar behavior.
Am I missing something? I thought I saw something similar in a game I was playing, but in the game I did not have the luxury to stop and try to figure things out.
I can recreate this better if you need to, or I can send you the base map, if you prefer.
A* explained:
http://en.wikipedia.org/wiki/A*_search_algorithm
You may also want to read about dijkstra's algorithm:
http://en.wikipedia.org/wiki/Dijkstra%27s_algorithm
Note that packets do not follow the path with the fewest nodes, they follow the overall shortest path (distance measured). The two paths in your video to the lower left blaster are very close to the same length I would guess. But the lower path might be every so slightly shorter (the first relay is higher up than the first collector is low).
Hmmm... Thanks for the links. Dijkstra is like a god.
I thought it would count hops only, not also distance. In electrical terms, all distance is meaningless, it is only the delay in encountering a router/hop.
this isnt electricity though remember ;)
So these are not energy packets?
i fail to see how energy packets are even remotely like electricity apart from that they're both used to power stuff (though in very different ways)
and btw if you want to play the electricity card, lets remember that longer distances mean that the electricity has to travel through more electrical wires, which cause some resistance, therefore shortest distance is still preferable
Quote from: Aurzel on January 13, 2010, 05:23:43 PM
i fail to see how energy packets are even remotely like electricity apart from that they're both used to power stuff (though in very different ways)
and btw if you want to play the electricity card, lets remember that longer distances mean that the electricity has to travel through more electrical wires, which cause some resistance, therefore shortest distance is still preferable
Doesn't the speed of electrons through a medium such as copper depend more on the thickness (diameter) of the medium than the distance? And what if these are fiber-optic links? Why would you fight a future war with stuff that offers more impedance than at least, say, fiber-optic?
even assuming optimal transport there will always be some resistance, therefore you need to have as small a distance for it to travel as possible
Quote from: Aurzel on January 13, 2010, 05:34:19 PM
even assuming optimal transport there will always be some resistance, therefore you need to have as small a distance for it to travel as possible
Now we get back to routing algorithms. There are some similarities here to GPS routing. When you use a GPS, you can choose "Shortest Distance" or "Shortest time." The time-based algorithm might route you a little way longer, but use more highways (less traffic lights and stop signs).
So if you want to start calculating distance-based delays, you cannot exclude routing delays that might occur drom additional nodes on the shortest path. if you route with relays, there are about 2 collectors for the reach of every relay.
If I remember right, Virgil somewhere said that there was a small delay at every node (I think this may be because the packet has to calculate the route if I understand the A* algorithm correctly) and hence a packet traveling over more relays might travel faster even if it does have to travel a little further.
no the package calculates its route before it leaves odin city i believe, and if you consider GPS, there are too many variables on roads to be comparable traffic/lights/speed bumps/speed limits/road condition/number of lanes/etc
There's a delay at each node, if you watch carefully the package stops at the node for a couple milisecs or something, just long enough to be noticeable if your paying attention but not if your not looking.
The only delay imposed by a node in a path is that the packet can't skip over a node. At slow speeds, this is zero or negligible. As you build speed structures the packets speed up. But, no matter how fast they travel (speed is distance moved per game update) they will always stop at each node. In this case, the nodes impose an effective transmission delay.
The path routing algorithm does not assign a weight to the nodes. I could have done that, but to be accurate it would have needed to factor in the effect of the speed structures. The delay imposed at a node is also not necessarily constant as the 'delay' imposed on a given packet depends on how fast the packet goes and the distance between two nodes in the graph. Each game update the packet hops so far down a link. Sometimes, the distance between two nodes will be exactly 5 hops (for instance). Sometimes it might be 5.01 (which would require 6 game updates to get the packet between nodes).
Factoring all of this into the routing algorithm might have produced a more accurate result in some situations, but it isn't always the most visually intuitive. It also would only matter at higher packet speeds. These things together made me decide to set the node delay to zero in the routing algorithm.
Oh didn't know that. It's just that before you build any of the speed upgrades it looks like the package slows down or stops, if only briefly (couple milisecs if that) , whenever it hits a collecter or relay.
even if it did stop for a couple of miliseconds, you're in no position to say deathly, the human eye cant detect anything shorter than into the tenths of a second lol
True I forgot about that. So then why does it always look like (before speed upgrade) that is stops or slows down whenever it hits a collecter or relay?
Quote from: deathly_god5 on January 14, 2010, 06:07:00 PM
True I forgot about that. So then why does it always look like (before speed upgrade) that is stops or slows down whenever it hits a collecter or relay?
Could be an effect of how it is rendered? In other words, an illusion? :)
I have noticed that if I build ridiculously many speed enhancers, it seems as if some packets spend a markedly long time right in the center of a collector. But I'm sure it is simply a visual illusion.
its only because the packets 'jump' across the network so every spot it 'stops' at looks like its slowing down, maybe
Quote from: Aurzel on January 13, 2010, 05:43:44 PM
the package calculates its route before it leaves odin city i believe
Hmmm, I thought I've seen packets change their route after a new node got completed, offering a shorter route. Am I wrong?
And another question: I've seen packets take a different route when the Creeper destroyed the shortest one, but when I destroy a node myself, the packets on this route just dissapear, instead of taking a different route. Is it supposed to be like this?
Edit: typo
yeah i made that comment before i read the wiki article on how this sequence works, the packets do stop and calculate where they're going at each node, though this should still be an unnoticeable stop since i would think it would only take a few microseconds, hence the big cpu hit
as for the other question, if the node is destroyed before the packet has passed from a node to head for the destroyed one then it will re-route, if the packet has already calculated which node is closest and that node is destroyed after that, then the packet will evaporate
Thanks Aurzel, that makes sense.