1. Dismiss Notice
  2. Within our Resources section we have over 150 Audio files, with room to grow. You may find exactly what you have been looking for. Just CLICK HERE to start your listening adventure.
    Dismiss Notice
  3. Why would you want to upload your resources directly to RMMV.co? It makes it easier for other members to download them. Click HERE for more information.
    Dismiss Notice
  4. Click HERE to see our four new featured resources by TheUnproPro, Starbird, iblamevictoria, and VGM MarkH.
    Dismiss Notice
  5. Here are the The Resource Rules.
    Dismiss Notice
  6. Please read these RULES before posting.
    Dismiss Notice

Plugin Pixel Movement

Discussion in 'Resources in Progress' started by Xilefian, May 6, 2017.

  1. #1 Xilefian, May 6, 2017
    Last edited: Oct 23, 2017
    EDIT: There is now a test version over on RPG Maker Web: https://forums.rpgmakerweb.com/index.php?threads/altimit-pixel-movement-0-02α.85408/

    Give it a whirl, report back any problems so they can be added to the GitHub bug tracker.

    Most of the thread below is discussion of old test ideas and no longer applies to this alpha test

    [​IMG]

    Click to see longer video

    Motivation

    The idea behind this Plugin is to take the first step towards a complete 3D maps Plugin. Originally, I was working on 3D maps, but there's so many smaller problems to solve first, so I've decided to spend my weekends solving these problems as individual Plugins on their own.

    Pixel-accurate (and sub-pixel!) collision detection is one of these features.

    Research

    The first thing I did was check out if other, similar Plugins already exist. I found Super Orange Movement, an abandoned Plugin that's rather buggy and restricted.

    I was unable to find any other MV Plugins that allow pixel-movement, which is surprising as pixel-movement scripts in older RPG Maker versions were very popular. If anyone knows of any MV Plugins for pixel movement, please tell me of them.

    Features

    Colliders

    The collision physics are not handled by the Game_Character; any Game_Character with pixel movement enabled can have a collider object attached to them; when moving with pixel movement the collider itself is what calculates the movement, not the Game_Character.

    This means that different types of colliders can be used. At the moment I have a "box collider", which allows a single bounding-box of any size to be used for calculating the collision.

    You can even have large colliders, so a Game_Character can be two tiles wide and unable to move down paths that are one tile wide, perfect for large-sprites or perhaps even if the player is inside a large-vehicle.

    This also allows colliders to be created of varying shapes. I plan on creating a circle collider, which will allow the collision detection to slide and "guide" the player into gaps if they are slightly misaligned (will make moving around easier). I also plan on supporting multiple colliders on a single Game_Character.

    Toggling

    This Plugin can be enabled/disabled at will. When disabled, the Game_Character will slide back onto the grid and revert to default movement, which is going to be helpful for choreographing cut-scenes (disable pixel-movement, move the player along tiles, enable pixel-movement, move the player along pixels).

    This Plugin can target any Game_Character, which means the player can have pixel movement, as-well as events and vehicles.

    Collision debug mode

    This is an additional Plugin right now, but it is very useful. This renders the colliders as shapes on the map, so you can see for yourself exactly how the collision is working.

    [​IMG]

    Any feature suggestions are entirely welcome!

    Considered features

    There are a few nice-to-have features that I am thinking about, but have no plans to develop at the moment.

    Map collision

    At the moment, I'm planning on sticking to the regular old grid for the map movement. Map collisions will be difficult (how would you define the colliders for map tiles?). There's a lot to think about with this one.

    For now, I think events should be the only ones that can have custom colliders, which means that events with map-tiles can be used for complex geometry on the map.

    Bitmap collision masks

    Javascript sucks for this one due to performance. There's a lot to think about, especially if you want the collision masks to "guide" the player, similar to the circle collider.

    If I were to do this, it would need a lot of development to find a suitable method (Right now I'm thinking about using polygon colliders that generate at a fixed resolution around the bitmap, but there's a lot of problems to solve here).

    Current progress

    I spent a couple of weekends investigating the most ideal way for me to implement this Plugin, which resulted in a lot of experiments being done and general discovery of what the challenges and problems are.

    I'm now building a working (not-test) version that uses my findings and ideas. I want this to be as clean as possible, so I am going to take my time and make sure everything works fine.

    Right now, pixel-movement can be toggled for any Game_Character and they can move off-grid and collide correctly with the map's grid. Events are not working at the moment, that is the next thing for me to work on (event collision and event triggers).

    Vehicles and followers are also not working. My idea is to re-write followers to use a different method of following the player (I'm thinking distance-based).
     
    • Like Like x 3
    • Agree Agree x 2
    • List
  2. Quadsi's movement plugin has had this feature for a while
     
  3. Thank you very much for telling me this, I have not see Quasi's Plugin before.

    I downloaded and tried it out, changed some of the settings to configure it as much as possible, but I've found it still has many bugs. For one, non-collision events incorrectly have collision by default. The movement correction does not work along a lengthy span of tiles. The collision is not pixel-perfect, it seems to "push" away from the colliding object, rather than slide and correct along its surface normal.

    It pretty much has all the features and ideas that my Plugin has, which is a good insight in what to do and what not to do. It's given me some good pointers on what to avoid.
     
  4. Ok, so, glad that i helped you something. At least that plugin of his works flawlessly on my project although with all the flaws you mentioned. But if you can make a better plugin, i'm very eager to see the outcome, lol.
     
  5. Progress update!

    I've re-written the Plugin for a 6th time, finally settled on an architecture that works well and doesn't produce strange bugs.

    I'm currently working on circle collision, you can see what that looks like with the debugging collision enabled below with me swapping from a 1x circle to a 2x circle, it's very cool being able to slide between the tiles as a circle

    [​IMG]
    Click to see larger video


    I'll 1x circle the default collision for the player as it retains the original collision size of the player from MV so turns it into an easy drop-in pixel movement option.

    I am working on the directional tile collision for circles, which is broken at the moment.

    Todo list is currently (in order of priority) for the first test version:
    • Event collision
    • Event triggers
    • Everything related to vehicles
    • New party following technique
    • New mouse movement technique
    • API, Commands & Parameters
    • Documentation
     
  6. Looking good! I enjoy pixel collision quite a bit, it gives the characters a better feel when walking around. I'm curious how the performance is? Assuming you've made it to the performance tweaking phase lol
     
  7. Good question. My development machine is very powerful, so I haven't optimised for performance yet (beyond my optimised algorithms), my plan was originally to optimise last (which is standard practise with software development).

    Most people would probably raise an eyebrow at the idea of pixel-movement being a performance concern, but the way RPG Maker MV works doesn't lend much to optimised event management. Basically every time something with pixel-movement moves it will loop through every event on the map dozens of times, which isn't very good. I'd rather that it only cycles once - at most - which is a tall order. Combine this with the fact that my pixel-movement uses real physics for perfect accuracy collision, there is certainly a concern for performance, but I'm not sure what that concern is at the moment as my computer is insanely powerful so I only lose 1ms of performance when the player is moving in a basic map (1ms, to me, is too much).

    This situation has resulted in me coding specific optimisations for the map tiles, events and the player - which has gone really well, until today when I've started to realise that this methodology, whilst fast on my development machine, is difficult to maintain and develop atop and it won't scale well for maps with many events.

    I have been considering for a while the idea of trading some performance for a unified collision architecture, which would simplify a lot of the logic at the expense of memory and some performance (but will gain performance for maps with many events).

    Giving this 5 minutes of thought, I think my current implementation is actually better than unified, but I definitely need to improve the Game_Character collision (which at the moment is player:event collision only, not event:event or event:player). I am considering once again re-writing for the 7th time, but this time doing things "properly" for the Game_Characters by implementing a collision system that scales better for maps that are absolutely filled with events (what I have mind would scale event better than MV's default event collision system, so you might event gain performance with my Plugin on maps that are filled with events versus vanilla MV).

    Conclusion
    My map tile collision is great (100% perfect physics, works in every single MV map exactly how you'd expect with zero bugs) - but has room for improvement in terms of architecture. The player:event collision works nicely, but is a mess and scales badly for maps with multiple events. It also has some failure cases for looping maps with large colliders; a problem I'll need to think about, and I've managed to leave zero space for event:event and event:player collision - this was from writing optimised player:event collision.

    I am very happy with my Plugin so far, but I'm definitely taking my time on it as I need to it to be 100% flawless for the 3D maps Plugin that I have planned for the future and I want it to be massively optimised.

    Implementing a bounding volume hierarchy is what I'll probably do to optimise the Game_Character collision.

    Update: Today I implemented an experimental BVH, the concept seems very solid, but my test implementation was flawed.
    The bounding boxes must have a reference to their owning Game_Character. My initial thoughts where to have the colliders own the bounding boxes, but now I'm thinking they should be separate, which means that Game_Character instances without colliders still have the potential to benefit from BVH optimisations.

    I'm not going to worry about BVH update performance (every time a Game_Character moves outside its parent volume there's potential for up to half of the tree to update). The reason for using BVH is to reduce the amount of loops over all the map events - which will be more expensive now as I'm now adding an extension to Game_Map that collects all the Game_Characters on the map - and optionally excludes a given Game_Character, so the BVH is even more important.

    I've accidentally built a sweet point of entry for adding Game_Characters to the BVH; the initialisation for all this is done on the first time Game_Character.update is called - at this point the position of the character is known and the character can be added to the BVH sequentially.

    This time around, I'll focus on implementing Game_Character collision before map collision; map collision is easy and proven - the characters are the hard part. I'm also going to not bother with the complex colliders until tile-sized colliders are perfected.
    --- Double Post Merged, Sep 21, 2017, Original Post Date: Jun 4, 2017 ---
    I'm back and working on this again.

    Here's a video of the current version with debug display enabled:


    This is way cleaner, simpler and more solid than the previous versions, but there are still some wobbly moments related to colliders being really close to each other.

    You'll notice that I've got polygon collision sorted out now. I've actually removed tile collision and now tiles really on the same logic as polygons, it makes things easier. Map collisions are now treated exactly the same way as event collisions.

    Fixed the looping map collision bugs with events, need to do more testing before I can confidently say it's fixed for maps too.

    I've removed event interaction for the time being. Once I get event movement working again and solve the collision weirdness related to move routes I'll get interaction back in and release an alpha.
     
  8. Thank you. You've clearly been working hard on this. Please keep up the good work.
     
  9. Done a fair amount of stuff today.



    First thing I did was fix bugs related to wobbly collision with the map. Had some issues of polygons getting stuck if they were too close to the end of a line, rather than sliding past as it should. I modified the collision algorithm a bit to make it 2-pass, which by itself didn't solve the problem, I had to combine that with the order in which the map collision polygons were testing, which I solved by changing the collision mesh generation algorithm.

    I also implemented a bounding volume hierarchy for the collision mesh. This is not a quad-tree at the moment as I had to be careful with how the tree is aligned to keep it optimised for the collision algorithm. There's no reason why a quad-tree can't be implemented in the future, it was a matter of speeding up development time.

    I then added looping map collision support in. This has the same logic as the looping character collision, so everything worked very nicely with this. Looping maps was a major issue in my previous experiments with pixel-movement.

    Finally, I decided to get vehicles working. I chose to implement vehicles now to test out the collision mesh generation as vehicles have different collision properties. I haven't done anything fancy with animations here, it just dumps the player wherever it wants if the player is able to disembark. You can see in the video the different collision meshes activating depending on your mode of transport.


    I think what I'll do is "complete" the vehicles by adding in the animations and improving the logic for getting on/off the vehicle. After that, I'll start work on getting the party followers to actually follow.
     
  10. Oh no, look at that wall of text. I'm sure nerds would love that so much lol. It seems like you are even rewriting the whole feature all over again. This should be MV's collision movement's standard, not that 1 step per tile.
     
  11. Vehicles are now complete (there'll be more stuff to do later on I expect when everything else is added).


    In this video I try out the idea of having different-sized vehicles. The ship is too large to fit down the stream, so the player must find the boat if they want to go down the stream and reach the airship.

    This also features collision mesh caching to disk, which saves a hefty load-time on map change (first time will be a hefty load - unless you decide to ship your game with pre-cached collision meshes - from then on its a rather expensive disk-access).

    Now it's time to work on the followers to get them to actually follow. That should also lay the foundations for getting event movement working.
     
  12. I am looking forward to seeing how that'd go.
     
  13. Here's a progress video:


    Coming close to an alpha release. Need to make sure all the event movement options work, then add the action-trigger, then configure the encounter step (which is probably a little broken, I need to test it out).
     
  14. I freaking love how that npc was stuck and like, tried to step aside. Looked pretty natural to me. Keep up the good work.
     
  15. I've actually posted an alpha version of the Plugin over on RPG Maker Web: https://forums.rpgmakerweb.com/index.php?threads/altimit-pixel-movement-0-01α.85408/

    So you can go ahead and try it with your project now.

    Demo project available here: https://altimit.systems/projects/vectormovement
    Plugin available here: https://github.com/AltimitSystems/mv-plugins/tree/master/movement
    Along with issue tracker, so if you find a bug you can make a new issue for it, just make sure to label it as "Altimit Movement" and "bug".


    Once that alpha version is done (mouse input sorted out) I'll start work on an API for developers and I will make a Plugin thread here for it.
     
  16. Sweet! I will check that thread now, and will test it out whenever i have time. Cheers buddy!
     
  17. This looks fantastic! Best of luck working out the kinks.
     
  18. The kinks are mostly worked out now, just need people to test it out in their own projects so more kinks can be identified and fixed (if there are any).

    Here's the link to the current test: https://forums.rpgmakerweb.com/index.php?threads/altimit-pixel-movement-0-02α.85408/
    Still need to make a resource post here.



    Web demo available here

    Now that I've got mouse input done, I'm going to be working on the API for developers, which would be the first beta version.

    Custom Character Colliders
    I think I'll be using QMovement's standard for this. People are used to QMovement's colliders, so the transition should be easier. I'll also be making a new standard that's more powerful and better suited for my Plugin. This feature would also include the ability to change the player/vehicle/follower colliders during run-time.

    Move-Route Commands
    The current version of my Plugin actually has some custom move-route stuff, namely toggling side-way tile alignment (so moving up when you're part-way on two tiles will move you diagonally to align with a tile). I will likely also include a move-to-location option (without path finding, for now) so choreographing fine movement would be doable.

    The second beta version will include features that are still in the discovery stage for me.

    Custom Map Collision Mesh
    I still don't know what I want to do with this. It is definitely possible and easy to implement, but the hard part is defining a standard that is easy for developers to use for their games.
    One option I'd like to do is have per-pixel collision mesh generated from an image mask. Entirely possible, but quite the intensive algorithm for Javascript. It would be cached just like the default map collision mesh currently is. I think I'd like to support both a collision mask tileset and an arbitrary collision mask (like a parallax map); this would provide the most flexibility. Red channel would be walk, green-channel would be boat, blue-channel would be ship.
     
  19. I'd downloaded your plugin and play tested it a little bit a while ago, but then I got a lot of things to do so I basically I have found no bugs, sorry for not being so useful, lol.
     
  20. #20 Xilefian, Oct 23, 2017
    Last edited: Oct 23, 2017
    Finding zero bugs is useful, as long as you post back here that you've found zero bugs.

    It seems that a lot of people seem to think this Plugin is buggy (or that there are "kinks" to work out) and are avoiding it/waiting for an updated version, I need people to actually try it for themselves, see that there aren't any bugs and then come back and say that.

    I'm asking people to report bugs because we're not finding bugs at the moment, if we were finding bugs, then I wouldn't need to ask people to report them as we'd see them for ourselves! I am confident that this is the least-buggy pixel movement Plugin available for RPG Maker MV - even as an alpha version.

    I even have praise from the creator of OrangeMovement:
    EDIT: I made a video that compares existing movement Plugins with vanilla MV and Altimit Movement.

    The following Plugins are compared, with their time codes in bold so you can quickly check it out:
    • Galv's Pseudo Pixel Move (v.1.0) 1:35
    • QMovement 1.4.3 3:25
    • SuperOrangeMovementEx 1.5.1 5:14
    • Altimit Movement 0.02 alpha 7:05
     

Share This Page

Loading...