Forced Movement Animation

Page: 1 2
ID:93060
 
Mar 18 2010, 9:56 am (Edited on Mar 18 2010, 10:30 am)
Redundant
Applies to:Dream Maker
Status: Redundant
This feature has already been implemented, or is already achievable with existing methods.
With pixel movement now a viable option; The built in movement-state animations can't really be put to use. So the best way to show a continuous movement animation is to set an icon_state.
However, this causes multiple problems:
A. All existing icons have to be redone.
B. This changes the icon_state on the atom.
A way to force a movement state animation to play would remedy this issue, and could be handy in various other situations as well. A simple var like atom.play_movement=1 or something could work.
Jun 29 2010, 10:36 am
BUMP
Jun 29 2010, 3:55 pm
Yeah I second this
Jun 29 2010, 5:03 pm
What's changed to make pixel movement easier?
Jun 29 2010, 7:11 pm
Warlord Fred wrote:
What's changed to make pixel movement easier?

Nothing changed to make it easier.
The networking was fixed/upgraded, so now games with pixel movement won't look like unplayable crap in multiplayer.
Jun 29 2010, 7:15 pm
there used to be an option to force movement, or to halt all movement but it was client sided I believe.
Jun 30 2010, 6:50 am
I like this idea. Not sure exactly on the implementation, but it's definitely an easy way to use movement states. As per the current implementation, we'd probably want to make sure the movement state still displayed for one frame when movement stopped. I think it'd also make sense to separate this from normal Appearance vars since it's more atom-specific.
Aug 10 2010, 2:17 pm (Edited on Aug 10 2010, 2:42 pm)
atom/var/movement_state=-1/0/1
This variable changes when the movement state animations of an icon will play:
1: Always
0: Only when moving (default, how it is now)
-1: Never
Dec 2 2010, 5:46 pm
BUMP again...
Dec 2 2010, 7:48 pm
BYOND's built-in movement system has to handle movement state animations because it would be very difficult for the server to handle manually. The server knows when a move starts but doesn't necessarily know when it ends. With a pixel-based movement system you'd know when a move starts and ends so you'd be able to manually switch to the animated icons when the player is moving and switch back when they stop.

The only issue I can see is with the icon states themselves. You can create a utility that creates two states for each movement state: one is the animation (as a non-movement state) and the other is the still icon (just the first frame of the movement animation).

Unless I'm missing something there doesn't appear to be anything major that's stopping you from implementing an easy workaround.
Dec 2 2010, 8:37 pm
You'd have to change the icon_state, that is the problem, especially with existing projects. Not to mention, this should only take 10 minutes to implement, and its been almost 9 months. I don't get your point about the server manually handling animations.
Dec 3 2010, 4:01 am
With BYOND's default movement system the server knows when a mob's move starts because Move is called. You don't really know when the move ends. With a pixel movement system the server will know when the player starts and stops moving. For example:

mob/proc/move_loop()
    if(the player is holding an arrow key)
        // move in that direction
        icon_state = "[base] moving"
    else
        icon_state = "[base] still"


Yes, the server needs to switch the mob's icon_state but this is an easy thing to do. It can certainly be done in less than 10 minutes.

You can write a utility that splits each movement state into two new states with the "moving" and "still" suffixes. The icon proc has an argument (I think it's called "moving") to get only movement states. You can set this flag and check the icon you get back to determine if it's a movement state.
Dec 3 2010, 5:40 am
Falacy wrote:
You'd have to change the icon_state, that is the problem, especially with existing projects. Not to mention, this should only take 10 minutes to implement, and its been almost 9 months. I don't get your point about the server manually handling animations.

Your concept of how long it takes to implement features is unrealistic. Even if we had an implementation plan in place for this, which we do not yet, it would take longer than that just to get a new var added, let alone hook it up and make it do useful work.

As I said I like the idea, but I'm not sure how we'd go about implementing it. One thing Tom is keen on is avoiding the addition of new vars left and right for the sake of one-off features. And because there is a simple workaround, this would be fairly low on the priority list.
Dec 21 2010, 5:34 pm (Edited on Dec 21 2010, 5:41 pm)
Lummox JR wrote:
And because there is a simple workaround, this would be fairly low on the priority list.

The "simple" workaround mentioned doesn't work worth a crap. Its not very simple, nor is it effective, efficient, or something I would even consider an acceptable method for handling this situation.
Dec 22 2010, 3:25 am
Falacy wrote:
The "simple" workaround mentioned doesn't work worth a crap. Its not very simple, nor is it effective, efficient, or something I would even consider an acceptable method for handling this situation.

If you couldn't get it working you should be posting in the Code Problems forum instead of here.
Dec 23 2010, 8:52 am
Falacy says: I could get it working, in less time than it will take me to write this comment. What I mean when I say it isn't simple, is that your proposed "work"around would pointlessly over-complicate the use of icon_state, and the process of designing icons. Implementing your suggested "work"around into existing projects would either break them, require a ton of conversion effort, or just not work at all.
Dec 24 2010, 1:30 pm
DarkHus wrote:
Falacy says: I could get it working, in less time than it will take me to write this comment. What I mean when I say it isn't simple, is that your proposed "work"around would pointlessly over-complicate the use of icon_state, and the process of designing icons. Implementing your suggested "work"around into existing projects would either break them, require a ton of conversion effort, or just not work at all.

Switching a game to use pixel movement is s non trivial task. Falacy just wants the BYOND staff to do the work instead of having to do it himself. Laziness is not a good basis for a feature request.
Dec 24 2010, 11:32 pm
Falacy says: This would be the easiest part of making a pixel movement system, it would also be one of the most pointlessly over complicated ones if handled the way you suggest. Laziness doesn't factor into it nearly as much as functionality and common sense do. The library you built for pixel movement may set a low standard, but a properly built one could easily be added into just about any game with little to no effort on the developers part. To get the best plug-and-play functionality, we would need to be able to override all built in procs, like step() and locate(), but that's another topic. On top of all that, this feature would provide functionality beyond just its use for pixel movement.
Dec 27 2010, 3:10 am
This would be the easiest part of making a pixel movement system, it would also be one of the most pointlessly over complicated ones if handled the way you suggest.

My suggestion was very simple. Maybe Developer How-To is the better forum for getting help about this.

a properly built [pixel movement library] could easily be added into just about any game with little to no effort on the developers part

Pixel movement isn't something that should be added to a game on a whim, it's a crucial aspect of gameplay. If you think about how it complicates things you'd quickly realize that it would never be a trivial transition. It would be impossible to plug a pixel movement library into an existing project of sufficient size and have everything work. Tile-based movement lets you make many assumptions and simplifications. It's like truncating decimals when doing math - you can't get the right answer because you lose some information. The best you can do is make it easy to use the pixel movement library from the project's start.
Jun 24 2011, 8:33 pm (Edited on Jun 24 2011, 8:52 pm)
Forum_account wrote:
My suggestion was very simple. Maybe Developer How-To is the better forum for getting help about this.
lol I like how you keep trying to talk down to me when you're the one doing it wrong. The problem isn't if/how it can be done, its that it shouldn't be done, because your suggested implementation is bad design.

Pixel movement isn't something that should be added to a game on a whim, it's a crucial aspect of gameplay.
A crucial aspect of gameplay that most BYOND games are designed around to begin with, but then stretched to 32x32 because that's the only option.

If you think about how it complicates things you'd quickly realize that it would never be a trivial transition. Tile-based movement lets you make many assumptions and simplifications. It's like truncating decimals when doing math - you can't get the right answer because you lose some information.
Except in this case, you'd be going from integers to decimals, so you wouldn't be losing any information.

It would be impossible to plug a pixel movement library into an existing project of sufficient size and have everything work.
It worked just fine for my implementation, sorry that your attempt isn't intuitive?

The best you can do is make it easy to use the pixel movement library from the project's start.
That may be an acceptable, though undesirable alternative, but your library doesn't even meet those standards.
Page: 1 2