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?
Comments
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.
Cheers!
It seems from a functionality standpoint it would be better to use a 3d engine with 2d vectors.
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.
It might work with orx though, I haven't tried it.
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.