Movement in the Z direction

edited October 2014 in Help request
Since the scenes are built from a 3D scene graph, I was wondering if it was possible for objects to traverse the Z direction. Using this, I want to make a game with an environment similar to the castle crashers game by behemoth(characters can move in x y and z directions despite being rendered in 2d).

Since all the force and speed functions take in 3 dimensional vectors, it seemed to imply that they could be used to move objects in the Z direction. So far, however, they don't seem to be working for me. Am I misunderstanding the intended implementation of these functions?


  • edited October 2014
    Hi riak157 and welcome here!

    You're mostly correct: you can indeed move objects along the Z axis, using direct position/speed access or FXs.

    However if your objects have a physics body on them, the Z component of speed will get ignored as the only available physics plugin at the moment is based on Box2D, which doesn't handle the 3rd dimension.
    It's even worse for forces as Box2D won't still handle the 3rd dimension and, in addition to that, forces applied to non-physics objects will simply be entirely ignored (with a warning in debug).

    For all objects, modifying their Z coordinate will impact on their rendering order (within the same object group, every object groups are rendered separately).
    If you have set the DepthScale and/or AutoScroll properties of your objects, their relative Z position (to the camera) will also affect their perceive scale and position (used for differential scrolling).

    Now for a "2.5D" akin to Castle Crashers (or any good ol' Capcom-style beat'em up from the 80s/90s), you will want to modify both Y and Z coordinate at the same time to get a similar result: when going down, Y increases and Z decreases.

    You could probably get a similar effect by simply using the AutoScroll property on the Y axis, but I found it hard to control, especially later on if you add more than a single viewport/camera couple (which is very useful in order to do compositing, Post-FX rendering and/or support multiple resolution/aspect ratios).

    The issue, again, given that Box2D is 2D only, is that you'd need to find a way to filter out collisions. There are different approaches available for that (including changing the collision flags based on the Z depth of objects or doing manual filtering after receiving all the events), but I think this is better left for a future discussion. ;)

    Let us know if you have any other questions or if what I just wrote was unclear.

  • edited October 2014
    Thanks for the response. What you say makes sense. I was trying to do the same thing with the ClanLib engine (adjusting the y to simulate z) and the collision issue turned out to be a breaking factor (the method it used for collisions ended up being too finicky and the engine wouldn't re test the collision when it cleared the z threshold).

    It seems from a functionality standpoint it would be better to use a 3d engine with 2d vectors.
  • edited October 2014
    That could be a viable option (3D engine + 2D physics constraints), though I have the feeling it'd come with its share of issues as well.

    I can't say how it's done for Castle Crashers, however, in the past, collision shapes were often simply adapted to fake the depth perception.
    What I mean is, if we take the simple example of collision boxes, instead of covering a whole character's body or weapon, they'd be narrowed vertically so that they would only collide if the sprite are only slightly on different Y values and miss when they are too far away, faking the impression of depth.

    Now that wouldn't necessarily be the way I'd do it myself, I have the feeling I'd rather do a manual filtering based on the objects' Z coordinate. I haven't implemented that method myself, but it sounds rather straightforward and makes it easier to create the collision shapes as they'd be the same as for a regular pure 2D side scrolling game:

    - Use sensor physics part (BodyPart.Solid flag set to false)
    - Add an event listener for physics events (orxEVENT_TYPE_PHYSICS)
    - When receiving events with ID orxPHYSICS_EVENT_CONTACT_ADD, do a quick check on both colliding objects (the orxOBJECTs are directly sent as parameters of the event callback: hSender & hRecipient) on their position's Z component
    - Ignore the event if over a specific threshold, otherwise continue to processing it (apply damage, etc...)

    The whole setup (listener + filtering) should be about 10 lines of code.

    PS: As a side note, if one is using Scroll on top of orx, ScrollObject get directly notified via their ScrollObject::OnCollide() virtual method, which simplifies the whole setup.
  • edited October 2014
    I also tried the smaller hitboxes approach. I ran into trouble when I wanted to have the objects stack on top of other objects (since their hitboxes were smaller this collision wouldn't work correctly). Based on this It would be better to do Z filtering, my first approach. But of course I couldn't make collisions test properly using Clan Libs engine.

    It might work with orx though, I haven't tried it.
  • edited October 2014
    If you choose the smaller hitboxes approach, you can have separate boxes for the actual "physical" collision and the hit registration.

    That being said, if you want to give a try to the filtering approach with orx and you encounter any problems, don't hesitate to let us know.
Sign In or Register to comment.