Path vs. Moveto and Separable Commands

After discussing with a few people on one thread, I decided to make it a new thread so we can normally discuss this matter more. I am making a few systems for my game, however, I stumbled upon few problems that my scripting prowess can't handle, so I am here to seek advice to the fellow scripters who are better than me in this aspect.

My problem are as follows:

Is there a way to make the commands separable so I can select them at different locations? Or are commands only linear by column and rows that you can't separate them?

Here is a mock up of what I wanted to achieve:

This is for me to make commands that are only from the UP, LEFT, RIGHT, and DOWN locations.

Is there a way to move sprites in an arc, curvy lines, zigzags and different patters using a certain formula? I also would like to ask if its possible to hook the commands into it so I can do the same system like this one:

All those marked to red are commands, so basically, they are locations where the player can go. How can I move the sprite following those lines? Normally you can't event this (due to the locked movements that the sprite will follow according to the lines).

I tried using the method

#-------------------------------------------------------------------------- # * Move to Designated Position #-------------------------------------------------------------------------- def moveto(x, y) super center(x, y) make_encounter_count vehicle.refresh if vehicle @followers.synchronize(x, y, direction) endbut it makes the sprite automatically go to a certain position, not MOVE to that position.

Any thoughts about these?

I am not familiar with the other threads and I probably misunderstand this.

But I would just keep the move and just cancel it whenever you need to assign a different direction. For the arc just add some math-function to make it move in an arc. It's basically a small jump.

You can just override/alias methods to 'unlock' their movement.

There is a script somewhere that allows 'free movement'. But I don't know what you want to achieve exactly. You still want them to align to the 32x32 grid but with arc-movement? Or do you want totally free movement? Anyway, both are possible. And you can just extend the script to allow for commands in the moveroute to accept something like move_arc_up(2).

Thanks for the feedback Napoleon. Which among the math function should I necessarily use? Math.asin or Math.acos? I have been thinking of just using jumping by using move to but I guess the only thing I have to deal with it is just it doesn't show movement. I might or will be using an 8D sprite for this. To further explain the movement, I provided a sample video from a long play:

http://youtu.be/BfBV8QCeEKE?t=9m49s

I already have the video started where the system I wanted is to happen.

Thanks.

8D-movement, diagonal 2.5D perspective and snap2grid and 32x64 sized characters and etc. That is quiet the transformation. I would personally not use RPG Maker for this. It looks like so much custom work that it would be faster and of higher quality to do this in some other engine or language.

But it is certainly doable with a lot of thinking and work and a lot of custom graphics/investment.

As for the mathematic function, you will have to chose the one that fits your needs. We can't help you with that. There are so many in existence and even Wikipedia has several. All with their own curves.

I tried doing this on events with a regular sprite and it somehow gives me the limit of only doing 4 movements, with an 8D movement script and 8D sprites (basic from the tactical battle system assets out there), it somehow turns out way off from what I expected, since it goes off the map. I guess my main problem on the second one is that it doesn't follow the line smoothly. In the events, I have to put up Same As Characters empty events to restrict the player from going off the lines.

Sorry for such a late response; I'm finalizing a script I'm about to release. It seems this is more complicated than I thought, and as soon as I get the chance I'll be writing a proper response, but for now:

Your commands and how you arrange / display them honestly doesn't have anything to do with how the actor sprite should be positioned / drawn on screen; or rather, they shouldn't be intertwined with it. The system code and graphical code should be split into two parts, not intertwined. The graphical part of the system should use the systematic part to work, not the other way around. This is why Spriteset_Map isn't available anywhere but in Scene_Map, and there is Game_Character and also Sprite_Character; it keeps things organized and tidy, and easier to maintain. I would recommend following this archetype, it works really well for our sanity :p

Like so:

class Scene_Navigate def start @paths = <some code to make paths> @actor_sprite = Sprite_NavigateCharacter.new # some special non-32x32 movement actor sprite @command_window = <your command window here>.new(x, y).deactivate ...other stuff, etc... end def update super return if @command_window.active if Input.dir8 != 0 update_actor_sprite_position end if @paths.any? {|path| path.endpoints.include?(@actor_sprite.x, @actor_sprite.y) } @command_window.activate end end def on_command_window_ok path = @paths[@command_window.symbol] @actor_sprite.start_to_walk_on(path) endendSe what I did there? I separated the two parts of the system, the path code and the graphical code, and manipulate the graphical part in the scene.Here's some more tips:

• The 8D movement can definitely be emulated. Simply add 4 more rows to the sprite graphic and alter Sprite_Character#set_character_bitmap and Sprite_Character#update_src_rect accordingly.
• Don't use Sprite_Character directly. Either subclass it and rewrite the update_position method, or write a new Sprite_MapCharacter or something; we need to be able to set the sprite's coordinates directly.
• I would recommend creating a Path class, which holds a bunch of points (which constitute a path), and adapt the code below to it.

Here's some code(read: food for thought) that should kickstart you on how you can determine where the sprite should be at when:
This code creates a Line class that lets you get the next point in the line <step> distance away from where you are on that line. Another adaptation of this is Jet's tween script. Basically we calculate the next position depending on a delta change in some value, an overall change, the start value, and a duration (which in this case is the overall change as well). eg:
Does that help a bit? I'll definitely be back in a bit after I wrap up my script so any more questions will be answered then. :)

It gave me much idea than I wanted. Thanks. About this though, does it mean that this doesn't affect the game player fully? Simply put, what I did was to create different set of commands instead (so different windows) and then access them via the event instead. How can I apply this exactly? My code is just as simple, so I don't exactly know how to add this on mine.