(New) Grid-Based Motion [captaincomic?]

I noticed that Grid-Based Motion is listed in "The Master List" as being open but with captaincomic's name at the header of the section, and then in the pre-shipped behaviors for 3.0 thread as being directly attributed to him again. I'm willing to work on this if it's still needed and actually open. It's been several months since either thread were updated so I wanted to check first.

I also noticed that the "Snap To Grid" was needed and I could throw that together as well if also needed.

If I work on this, here's the basic functionality/needs as I understand them. If I've missed anything just point it out - I'll be coming back here to reference these notes if I work on this...

Required Features
1. Is an Actor Behavior
2. When enabled, locks the actor's position to a square grid cell.
3. The position of the actor within/around the cell can be customized with X,Y offset attributes (centering the actor is the default location, and then -/+ offsets).
4. The square grid itself can be customized for width and height of the cells, with the current scene's tile size as a default option.
5. The behavior will accept inputs to permit motion of the actor between cells.
  a. The user will be able to permit or disallow diagonal motion, or other specific directions (in chess, pawns only move in one direction, for example).
  b. Keyboard controls will be configurable for movement to all valid adjacent cells, or continuous motion if held down (if movement is instant, a configurable timer will be needed for this).
  c. The behavior will also accept messages from other behaviors to initiate the motion (so a separate touch or mouse-based behavior could send commands for motion, for example)
  d. The behavior will also accept a message to send the actor directly to a specific, non-adjacent cell (for teleportation or other long-distance moves). Custom Block required?
6. Motion between cells can be configured with a speed, or be instantaneous.
7. If a collision occurs, the actor should return to the nearest cell and stop.

Additional features
7. The behavior could broadcast a message (for other behaviors to receive) every time a move is made. Roguelikes could use this to initiate monster movement (as nothing happens in a roguelike until the player acts). Other uses could be to decrement a "Moves Available" counter, trigger special effects, etc.
8. Select a sound effect for use during motion or when a move is made.

I started working on a grid-based motion behavior for 2.something, but I never managed to finish one that I was satisfied with. One thing I wanted to add was the ability to push other actors (along the grid) and I only managed to do this reliably with code (using the getActorsAtPoint function.) And then it would have been Flash-only. Now it wouldn't be a problem anymore to use that function, but I never tried to update my old attempt to 3.0.

Anyhow, feel free to take this.

The only thing I would add to the feature list is pushing other actors. I think this is really common in grid-based games.

Edit: btw. this list http://community.stencyl.com/index.php/topic,13709.0.html hasn't been updates since 2.2, so the information there is not up-to-date at all, but the Master List is.

I agree with the ability to push actors, which is something I've used in two of my grid-based games.  I also didn't use the collision engine, but with simple physics it should be much easier to do so.

I could include a simple Boolean exposed to the user for "Pushable" and then instruct them to not configure keyboard controls for pushable actors. Since the behavior will be designed to accept input via messages, we just design it so that if a collision happens, the behavior checks if the collided actor has that behavior as well; if it does, just send a message for movement which will be enough to get the actor moving on it's own but appearing to be pushed. In fact, this would permit a chain of actors to be pushed as each one collides with it's neighbor. My only concern is handling the feedback if you try to push something in a direction that it shouldn't be able to be moved in (say pushing up on a horizontal-only movement block) because something's got to get back to the primary actor saying "Nope, can't do that".

If you take a look at my Tile Based Movement pack on Forge, that has actor pushing and it works rather well. I wouldn't say it's the most fantastic implementation, but you can look at it for ideas or borrow any code you wish.