ID:138414
 
It would be nice to be able to adjust the speed of the transition for the smooth movement of tiles, this would allow different movement speeds, but all continuous and smooth. I seem to remember something like this being requested a while ago, is it still on the list?
On 8/31/00 1:07 am Al wrote:
It would be nice to be able to adjust the speed of the transition for the smooth movement of tiles, this would allow different movement speeds, but all continuous and smooth. I seem to remember something like this being requested a while ago, is it still on the list?

Sort of; they tried to make it automatic, but with a lot of things on screen it still doesn't work too, er, smoothly.
On 8/31/00 1:07 am Al wrote:
It would be nice to be able to adjust the speed of the transition for the smooth movement of tiles, this would allow different movement speeds, but all continuous and smooth. I seem to remember something like this being requested a while ago, is it still on the list?

The smooth movement is a real bugger of a problem. We tried to mess around to make it look better, but that experiment was a failure.

One thing to realize is that the smooth-movement is strictly a client-side effect (that the user can even turn off) so it would be kind of weird to have a setting on the server to control it. The moment the guy starts animating he is actually already at the adjacent tile; that is, the animation has no bearing on the actual position. Thus, it is not really a "movement speed.

On the other hand, I realize what you are saying. It sounds like you want a way to have critters move around at different speeds. In the current system calling walk() with different lags causes a walk-pause-walk-pause-... effect. It would be better to have it continuously walk, with the rate dependent upon the lag. That's certainly a reasonable request.

I'm not sure how it would work with players (using the keyboard). I would think that to implement a controlled-player-movement you might want to call walk() anyway, and then the above system would work. That's more efficient too.
In response to Tom H.
I take your point about controlling the client actions, I was kind of hoping for tiles to be given a speed variable that the client could use when it plays the 'slide'. It's not critical and I'm sure there are more important issues.

I asked because I feel it does detract from the natural smoothness of a traditional game and secondly because I've produced a little driving game (I was aiming at Car Wars - Steve Jackson Games), which drives quite nicely apart from the on/off movement.

As a side line, there does appear to be scope for better event timing in Byond - it is quite hard to coordinate a series of events. I just thought I'd forward (if I can use that word) my ideas to you. :-)
In response to Tom H.
On 8/31/00 9:14 am Tom H. wrote:
I'm not sure how it would work with players (using the keyboard). I would think that to implement a controlled-player-movement you might want to call walk() anyway, and then the above system would work. That's more efficient too.

walk() is a nice little convenience function, but I'm not sure how many games can make use of it.

All the games I've worked on end up requiring a greater degree of control over a mob's turn, and walk() kind of subverts that by having the mob move around as a background process.

Integrating walk() into a normal mob event cycle would require complicating the code with checks in Move() and such, as opposed to making movement simply be controlled by the mob's event loop.

I guess the model is supposed to be "have the mob walk to this location using this time lag, and if something else comes up, just stop the movement", which I guess could work for many games.

The only thing holding up the mythical next release of the Deadron library is me implementing a simple cover to the path generation system to provide a dd_Step_Toward() function that uses complex pathing to keep from getting stuck. But to allow maximum flexibility, the developer is expected to call it each time they want the mob to take a step, which it sounds like it subverts some of the smooth movement facilities.

Anyway just thinking out loud...
I was trying to softcode this change directly in
North(), South(), etc. But I lost the track,
however I am sure this is doable in DM.

It's even simpler than that... I think it goes something like this.

client
var/lastMove = 0
var/delay = 4

Move()
if(lastMove + delay <= world.time)
. = ..()
if(.) lastMove = world.time
On 8/31/00 12:50 pm Julio Monteiro wrote:

Anyway if it was hardcoded it could be a nice way
to tune movement smoothness. Also the client could
calculate the duration of the smoth animation using
this value, the higher the value the longer it takes
to "reach" the next square (I know you will be there
already from the beggining). And if the client
disables the smooth feature, he gets more and more
pause between moves as the "movelag" var increases.

What do you say?

I like this idea a lot. As Guy T. noted, you can easily soft-code a movement delay snippet, but it won't account for the visible animation. Your suggestion would presumably do this.

Since the walk() functions have a "lag" argument, it seems only natural that movable objects would have a corresponding "lag" property. This could be the default lag when one isn't provided to walk().

The only issue is where to account for the lag. We could use Guy's approach and use Move(), but since that is an all-purpose movement function it would cause undesireable effects. For instance, you would likely be using Move() to teleport objects and wouldn't want this to be restricted to timing lags.

So I'm thinking that this probably belongs as a property of the default keyboard procs like North(), South(), etc. The "lag" var would literally be "how much time must elapse before I can hit the movement keys?" That may be a bit confusing, but I think for most purposes it is practical.

We'll have to give it a bit of thought. It sounds good, though.