Thinking about adding a Z-coord to T2D
by Bryan Edds · in Torque Game Builder · 04/19/2005 (12:10 pm) · 6 replies
Hey guys, this is just me thinking out loud here :)
I'm trying to think up a way to add a z-axis to T2D objects in an isometric game. What I'm thinking is I'll have is a setPosition("x y z") function, a setLinearVelocity("x y z"), a setConstantForce("x y z") and a setImpulsForce("x y z") in a high level ScriptObject that is composed of T2D objects. The big difference in these new functions is that y will be transformed with the z value. For example, y will be += z. The other difference is that the layer and group is set depending on what the z is. If z > 0, layer and group will be 20, if z >= 10, layer and group will be 19, if z >= 20, layer and group will be 18... and so on.
Anyhow, I'm hoping something like that could be pulled off.
What do you guys think about this approach / what different approach might you take if you didn't want to take this one?
I'm trying to think up a way to add a z-axis to T2D objects in an isometric game. What I'm thinking is I'll have is a setPosition("x y z") function, a setLinearVelocity("x y z"), a setConstantForce("x y z") and a setImpulsForce("x y z") in a high level ScriptObject that is composed of T2D objects. The big difference in these new functions is that y will be transformed with the z value. For example, y will be += z. The other difference is that the layer and group is set depending on what the z is. If z > 0, layer and group will be 20, if z >= 10, layer and group will be 19, if z >= 20, layer and group will be 18... and so on.
Anyhow, I'm hoping something like that could be pulled off.
What do you guys think about this approach / what different approach might you take if you didn't want to take this one?
#2
I'm not sure why it is that you feel the need to have a z coordinate for isometric games. I've spoken about this before, but isometric views are created as a modification to the order of rendering tilemaps and sprites; nothing more is required. Isometric games are 2D games; they are not 3D games that just happen to be rendered in 2D.
Your tilemaps are going to need to have multiple layers of collision geometry (and you're going to need to deal with "collisions" caused by a 2D object attempting to cross into a layer in the middle of some object's collision volume).
It's almost certainly far more trouble than it is worth attempting to foist a z-coordinate into T2D's physics simulation. If you really need to accurately simulate 3D motion, consider using a 3D engine. If you just need the illusion of 3D (which is what isometric games provide), modifications to the rendering system are mostly what you will need, not 3D velocities and such.
BTW: what you're suggesting (having 3D forces and such) probably isn't doable in script. Or, if it is, you're going to need a tick function on every scene object to allow it to convert the 3D velocity you set into a 2D velocity that the engine understands, and to convert the 3D position into a 2D postion + layer + group. It'd be better to hack the engine directly to provide such functionality.
04/19/2005 (1:26 pm)
Quote:What do you guys think about this approach / what different approach might you take if you didn't want to take this one?
I'm not sure why it is that you feel the need to have a z coordinate for isometric games. I've spoken about this before, but isometric views are created as a modification to the order of rendering tilemaps and sprites; nothing more is required. Isometric games are 2D games; they are not 3D games that just happen to be rendered in 2D.
Your tilemaps are going to need to have multiple layers of collision geometry (and you're going to need to deal with "collisions" caused by a 2D object attempting to cross into a layer in the middle of some object's collision volume).
It's almost certainly far more trouble than it is worth attempting to foist a z-coordinate into T2D's physics simulation. If you really need to accurately simulate 3D motion, consider using a 3D engine. If you just need the illusion of 3D (which is what isometric games provide), modifications to the rendering system are mostly what you will need, not 3D velocities and such.
BTW: what you're suggesting (having 3D forces and such) probably isn't doable in script. Or, if it is, you're going to need a tick function on every scene object to allow it to convert the 3D velocity you set into a 2D velocity that the engine understands, and to convert the 3D position into a 2D postion + layer + group. It'd be better to hack the engine directly to provide such functionality.
#3
Really, all I need is a simple fake iso world which does not necessarily include advanced physics like in T2D. Think Final Fantasy 2 or 3 or Chrono Trigger... You know, simple fake iso type stuff which simply allows different characters to walk on different world layers, and allow them to 'jump' on the z-plane so they can hop to other platforms (like Mystic Quest). Simple stuff, really.
Thank you for you suggestions though! More suggestions / advice welcome!
04/19/2005 (2:36 pm)
Yeah, I may skip all the 3D forces and just have velocity functions to make things simpler.Really, all I need is a simple fake iso world which does not necessarily include advanced physics like in T2D. Think Final Fantasy 2 or 3 or Chrono Trigger... You know, simple fake iso type stuff which simply allows different characters to walk on different world layers, and allow them to 'jump' on the z-plane so they can hop to other platforms (like Mystic Quest). Simple stuff, really.
Thank you for you suggestions though! More suggestions / advice welcome!
#4
Technically, layering is not the same as isometric rendering. Isometric is more about looking at a 45-degree angle on the world than anything else. Games like Final Fantasy have an angled view, not an isometric one.
To accomplish this, you want to use the already existing T2D layering features. Jumping from place to place can be easily implemented by shifting the character (for the duration of the jump) into a really high layer (so that he doesn't collide with anything), then determing the layer of the tile that they wind up on after the jump concludes.
As for having a typical Final Fantasy esque view (where characters can partially obscure other characters and terrain, and where terrain can obscure characters), this can be achieved by making a modification to the engine, on the assumption that it doesn't do this already. I haven't investigated how the engine currently decides which sprite comes before which other one in a single layer. In any case, change how the engine renders sprites in the same layer to render them in order based on their y-axis; render from top down. That allows sprites farther down on the screen to obscure sprites higher up.
The terrain obsuring issue is just a trick of properly building your tilemaps using layers. If you have a pillar, such that the base of it is collidable, and you want characters to appear to walk behind it, what you do is put the base tile of the pillar in the layer with the characters on it, and put the top part of the pillar in a higher layer. The same can be done for the backs of houses/castles and any other such things. Sprites will obscure terrain on their layer automatically, and sprites above their layer will obscure them.
04/19/2005 (3:36 pm)
Quote:You know, simple fake iso type stuff which simply allows different characters to walk on different world layers, and allow them to 'jump' on the z-plane so they can hop to other platforms (like Mystic Quest).
Technically, layering is not the same as isometric rendering. Isometric is more about looking at a 45-degree angle on the world than anything else. Games like Final Fantasy have an angled view, not an isometric one.
To accomplish this, you want to use the already existing T2D layering features. Jumping from place to place can be easily implemented by shifting the character (for the duration of the jump) into a really high layer (so that he doesn't collide with anything), then determing the layer of the tile that they wind up on after the jump concludes.
As for having a typical Final Fantasy esque view (where characters can partially obscure other characters and terrain, and where terrain can obscure characters), this can be achieved by making a modification to the engine, on the assumption that it doesn't do this already. I haven't investigated how the engine currently decides which sprite comes before which other one in a single layer. In any case, change how the engine renders sprites in the same layer to render them in order based on their y-axis; render from top down. That allows sprites farther down on the screen to obscure sprites higher up.
The terrain obsuring issue is just a trick of properly building your tilemaps using layers. If you have a pillar, such that the base of it is collidable, and you want characters to appear to walk behind it, what you do is put the base tile of the pillar in the layer with the characters on it, and put the top part of the pillar in a higher layer. The same can be done for the backs of houses/castles and any other such things. Sprites will obscure terrain on their layer automatically, and sprites above their layer will obscure them.
#5
I'll have to look to see if I need to do some engine changes to acheive proper render ordering for sprites on the same layer... Instead of ordering by position, though, it should order by the bottom of the sprite. Since positions in t2d are in the middle of the sprite instead of at the bottom like some engines, the bottom of the sprite will need to be found, and ordered with that value instead. No big problem, I'm sure.
I wonder if T2D will help accomodate this game style in future updates if it hasn't already?
BTW, thanks for the help Smaug!
04/19/2005 (3:50 pm)
Yeah, I want the scene to be viewed with the y-axis 'rotated', not the x-axis.I'll have to look to see if I need to do some engine changes to acheive proper render ordering for sprites on the same layer... Instead of ordering by position, though, it should order by the bottom of the sprite. Since positions in t2d are in the middle of the sprite instead of at the bottom like some engines, the bottom of the sprite will need to be found, and ordered with that value instead. No big problem, I'm sure.
I wonder if T2D will help accomodate this game style in future updates if it hasn't already?
BTW, thanks for the help Smaug!
#6
If you want to get the position based on the bottom of the sprite, you can actually do this quite simply in script, though a little engine hack may work better.
That should do the trick (don't have a chance to test it until later). From there you can either play with setLayer or setLayerDrawOrder.
As for pseudo-jumping, it'll depend on what exactly you're trying to achieve, though switching layers would be unnecessary, since you can simply turn off collisions temporarily.
04/19/2005 (5:08 pm)
I reckon you're overcomplicating things, at least from a layman's point of view (I'm a rather inexperienced programmer). You've got 32 layers currently in T2D (I believe Melv said a future update would have support for many more). Beyond that, you have sprite order within those layers (setLayerDrawOrder()), and indeed the entire scenegraph (setSceneDrawOrder()).If you want to get the position based on the bottom of the sprite, you can actually do this quite simply in script, though a little engine hack may work better.
%objectbase = getbase($player);
function getBase(%object)
{
%objpos = %object.getPosition();
%objoffsetX = (getWord(%object.getSize(), 0)) / 2;
%objoffsetY = (getWord(%object.getSize(), 1)) / 2;
%objbase = 2dvectorSub(%objpos, %objoffsetX SPC %objoffsetY);
return %objbase;
}That should do the trick (don't have a chance to test it until later). From there you can either play with setLayer or setLayerDrawOrder.
As for pseudo-jumping, it'll depend on what exactly you're trying to achieve, though switching layers would be unnecessary, since you can simply turn off collisions temporarily.
Torque Owner Gabor Borbely