feature: 'Pixel-based' movement

[weremickey]

Overview

Associated issue: #2650

The current tile-based movement system in the Intersect Engine limits the engine’s potential for an action MMORPG—lacking the fluidity and depth from the genre. Moving to a 'pixel-based' system will not only free us from the constraints of fixed tile length/width steps but will also open the door to richer physics interactions and more nuanced combat mechanics.

Problem

The existing tile-based movement restricts:

• Movement fluidity: The fixed grid system hinders responsive, physics-based gameplay.
• Combat precision: Collision detection tied strictly to tile prevents complexity, reducing the potential for skill-based combat (increasing reliance in features such as attack telegraphs & stat-checking, whether that be in having more strength, defense or evasion than the enemy).
• Map design flexibility: Map elements must conform to tile boundaries, limiting organic layouts, dynamic environmental interactions, and leading to strange behavior with diagonal movement.

Use-Cases & Benefits

1. Enhanced Movement Freedom:

• Fluid exploration: Players can traverse environments smoothly, with the more precise movement control feeling more satisfactory & in control of the player, and movement speed gains newer importance.

2. Advanced Combat Mechanics:

• Complex hitboxes: Attacks can feature nuanced hitboxes (e.g., a spike affecting only the center of a tile) and allows higher complexity in attack patterns (such as bullet hell-type attacks).

• Skill ceiling enhancement: More precise hit detection means that positioning and timing are rewarded, increasing the depth of combat.

3. Organic Map Layouts:

• Flexible collision boundaries: Map objects such as walls, hazards, or terrain features can be defined with custom shapes rather than default tile-sized block.

• Dynamic obstacles: Environmental elements can affect movement in targeted ways without forcing the entire tile to change behavior.

4. Customizable Enemy & Object Interactions:

• Segmented enemy hitboxes: Large enemies can have varied damage responses based on which body part is hit (e.g., critical damage on the head or weaker damage on the tail).

• Adaptable map objects: Assigning unique hitboxes to NPCs, spells, projectiles, and map objects enables diverse interactions and strategic gameplay.

Proposed solution

Implement a pixel-based (i.e. partial tile traversal) movement system by:

1. Movement Update:

• Transitioning from tile-step (tile width x height) movements to partial tile movement.
• Adjusting the camera system to handle variable speeds and ensure smooth tracking of the player character.
• Alter movement speed to scale off of a fixed distance based on tile height/width rather than whole tiles.

2. Collision and Hitbox Management:

• Default to tile width * height hitbox;
• Consider using spatial partitioning for collision checks (quadtrees);

3. Networking Enhancements:

• Implementing client-side movement prediction and time/geo-stamped input simulation.
• Ensuring that the server can periodically correct any discrepancies between client-side simulations and authoritative state.
• Collision Optimization Techniques:
  • Utilizing AABB (Axis-Aligned Bounding Box) colliders and fixed-distance raycasting for precise interactions (e.g., computing dash distances).
  • Considering spatial partitioning (such as quadtree filtering) for collision detection to maintain performance at scale.

Additional Considerations

1. Legacy Support:

• Ensure legacy maps & gameplay modes are still supported, and that migrating to the new movement paradigm is relatively painless/automatic.

2. Future-Proofing:

• Plan for the possibility of dynamic hitbox resizing (beyond the standard tile-sized default) to accommodate evolving gameplay mechanics.
  Ensure the system is modular enough to incorporate further physics-based mechanics or custom collision shapes as needed.

Nice-to-haves:

1. AI and Pathfinding:

• Updating enemy AI to work with the new collision logic, ensuring that pathfinding and attack behaviors are correctly aligned with pixel-based hitbox data.

2. Hitbox management

• Enabling a hitbox editor within the Intersect Editor. Developers can define collision shapes (e.g., squares, circles, lines) and composite hitboxes (multiple shapes combined) for any game object.
• Assigning hitbox properties such as relative position (offset from the sprite’s center) and dimensional scaling (e.g., radius for circles, width/height for rectangles).
• Even better if we can draw the hitbox on top of a specific sprite as reference.

3. Extended Object Integration:

• Adding an editor to create map objects, with assigned hitboxes.
• Allowing custom hitboxes to be assigned to projectiles, weapons, spells, NPCs and animations.
• Offering in-editor preview functionality so developers can see hitbox alignment with sprites/animations in real time.

---

Please leave your thoughts, feedbacks and ideas below.

[53957105]

Yes, based on the movement of the blocks, it does seem strange
It would be nice to have a 'Pixel-based' movement

But...

I feel that with the current state of feature development and content creation, it would be better to make it a turn-based game like Final Fantasy,

First, it can avoid complex physical collisions and drawings,
In terms of content creation, it can avoid complex 4-direction resource problems
And a lot of weird details

Turn-based combat also doesn't require much latency on servers,

So turn-based mmorpg games
Should be a better choice

[53957105]

The current engine, I don't want to increase the difficulty of development and content creation,

I want it to be easy to use, easy to understand, and everyone can make their own games

[weremickey]

Fully agreed, and I think it's a valid concern. One of the main goals will be to keep development as simple as possible; and if the user doesn't want to add hitboxes or anything like that, then they won't have to. Ideally we'll make it so that everything has a default hitbox defined by tile width and height, but they have the option to add hitboxes if they want to.

We can also make tutorials explaining this when the feature is out!

[weremickey]

Opened issue. #2650