feature: Pixel-by-pixel movement (i.e. "pixel-based movement")

[weremickey]

Description

Overview

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.

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.

Intended Use-Case

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.

Duplicate Check

• This feature request is not a duplicate to the best of my knowledge.