Plugin Pixel Movement

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

  1. This is definitely a work-in-progress Plugin and there's definitely no release - preview or otherwise - available at the moment.

    [​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).
     
    • Agree Agree x 2
    • Like Like x 1
    • 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. #7 Xilefian, Jun 4, 2017
    Last edited: Jun 11, 2017
    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.
     

Share This Page

Loading...