snot flow in Off Topic

ID:194569
 
Oct 20 2000, 5:52 pm

Question for the DragonSnot crew. Have you experimented with using flick() to handle the flow rather than rapidly updating the icon state? The dissadvantage is that you might have to fudge the timing, since you won't know exactly when the flick will finish from the user's point of view (and it may even be very slightly different to different people).

The advantage is that the flow would be driven on the client-side--avoiding a big stream of rapid icon state changes. I could be wrong, but I think this could noticably improve the responsiveness of the game.

I haven't thought about the specifics too carefully, so perhaps you have already discovered the flaw in this approach. Roughly speaking, I think you would start the flow flick(), set the icon_state to "full", and sleep until the flick should be finished. Unless I am overlooking something, that should produce the same effect with a lot less network data.

--Dan
#1 Oct 20 2000, 8:45 pm (Edited on Oct 20 2000, 9:33 pm)
On 10/20/00 6:52 pm Dan wrote:
Question for the DragonSnot crew. Have you experimented with using flick() to handle the flow rather than rapidly updating the icon state? The dissadvantage is that you might have to fudge the timing, since you won't know exactly when the flick will finish from the user's point of view (and it may even be very slightly different to different people).

I'm not on the DragonSnot crew, but I believe I know the answer to this one: Deadron needs to be able to control the flow timing because the game speeds up from level to level (and sometimes inside a level). The best way to do this I believe would be to have control over the delay property for icons-- Deadron in fact wanted to do it this way but alas I informed him that this was not accessible at the time, and suggested the current alternative. Here's that conversation.

Your suggestion, however, brings about a possibly simple feature request that would solve this problem without having to add new functions or types. What if flick() could take a delay argument (defaults to delay of icon) that could be used to control the timing of the movie? This would also be handy for flicking a pixmap for a finite time; it currently just pops in a black square I believe. If my math is correct it would reduce the network overhead by a factor of num_icon_states/2, which would probably improve things, especially at the super-speedy levels.

Or if adding new properties is acceptable (and I always foible over our stance on this!), than Deadron's original proposal of icon_delay would also do the trick I suppose. It, like icon_state, will probably move into the wayside of backwards-compatiblity routines if we ever have a specific 'icon' type, which will classify these properties more cleanly.

Of course in either of these cases Deadron will have to move around all of his icons just to test this, so he might get pissed at me! Anything for progress.
#2 Oct 21 2000, 12:29 am (Edited on Oct 21 2000, 12:51 am)
In response to Tom H. (#1)
On 10/20/00 9:45 pm Tom H. wrote:
I'm not on the DragonSnot crew, but I believe I know the answer to this one: Deadron needs to be able to control the flow timing because the game speeds up from level to level (and sometimes inside a level).

Tom has all the facts down on this one.

The DragonSnot crew is likely to have a code review in the near future, and I suspect my animation model will be one of the things examined!

Until then, anyway, I'm still rather addicted to icon states even if finer icon control comes along, at least in some cases, because it provides so much power over what is happening. In my first design, for example, if you did a crossover in a square trench, at the point that the flows collided I would have you lose. Such power is not possible without icon states.

However, I don't believe it should be that much of a bandwidth problem. Here are the statistics:

Each flow has 16 icon states.

At most there are 4 flows going.

At fastest, each flow moves once per tick. On the beginning level they only move every 4 ticks.

So for the flows themselves, the highest amount of bandwidth would be four icon states per tick. However, to help smooth this out, earlier today I put each flow on a differentiated timeline -- so until people get to the fastest state (which they usually lose at anyway), the icon state changes should be happening at 1 or 2 per tick.

In addition to flows, there are the image() calls used for the selection items. In general this is not significant, because you can only operate on one selection at a time.

However, when the game starts, you are hit with all your selections being placed on the board at once. So that's 5 image() calls to every player in the same tick. I suspect this may be contributing to the client lock up that Z experienced. My plan is to distribute the initial selection image() calls out at one per tick to see if this helps.

But am I wrong that nothing about this scenario should be problematic? (Keep in mind that during the GoB the flow differentiation was not in place.)

[edit] For the sake of completeness, I should mention the other possible contributor to lag: trench placement. Trenches are created ahead of time, when they become a selection, along with their flow objects. A trench has 1 or 2 flow objects; the more complicated trenches need the second object to handle flows going in the reverse direction. When the player places a trench, the 2 to 3 pre-created objects are moved onto the board.
#3 Oct 21 2000, 6:48 am
In response to Deadron (#2)
In my first design, for example, if you did a crossover in a square trench, at the point that the flows collided I would have you lose. Such power is not possible without icon states.

Well, you _could_ have movies for full-flow and half-flow and only call the half-flow one when you detect that a collision is going to occur. Also, you could have pre-built movies that run at different speeds to get around the current lack of a speed parameter in flick().

However, I agree with your bandwidth calculations. It shouldn't be a big problem to continue managing the flow from the server. If there were a lot more active flows, it would be essential to do more of the processing on the client, though.

I suspect that there is a glitch somewhere, because the clients really seemed to be over-reacting, as though there was a lot more going on than met the nose, I mean eye.

--Dan