ID:138414
Aug 30 2000, 9:07 pm
|
|
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? 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 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 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. |
Sort of; they tried to make it automatic, but with a lot of things on screen it still doesn't work too, er, smoothly.