Question about isometrics
by Teck Lee Tan · in Torque Game Builder · 03/26/2005 (12:19 pm) · 35 replies
Before you shoot me down for adding to the cacophany of voices asking if and when the iso tile object will be added, that's not what I'm asking. :)
I'm simply curious about what the object will add. From my limited understanding of isometric engines, and some tutorials at SpriteArt.com, iso engines are effectively 2:1 tiles carefully constructed and placed with clever layering and collisions. From what I gather, iso boards are doable in the current tilemap system (just gotta spend a little more time on the collisions and layering than straight 2d maps). Am I oversimplifying the process, and there's really much more to it? Or is that more or less on the money?
Either way, what kind of features are we looking at when it comes to the future iso tile additions? Once again, these questions come from the curious mind of the uninformed. :)
I'm simply curious about what the object will add. From my limited understanding of isometric engines, and some tutorials at SpriteArt.com, iso engines are effectively 2:1 tiles carefully constructed and placed with clever layering and collisions. From what I gather, iso boards are doable in the current tilemap system (just gotta spend a little more time on the collisions and layering than straight 2d maps). Am I oversimplifying the process, and there's really much more to it? Or is that more or less on the money?
Either way, what kind of features are we looking at when it comes to the future iso tile additions? Once again, these questions come from the curious mind of the uninformed. :)
#2
And to answer your question, yes, Melv has stated he will add it, but it's a little further down his list than the more fundamental issues.
03/26/2005 (12:35 pm)
My first sentence in this thread clearly stated that I was not asking if and when the iso tile support would be added, so please don't turn this into a discussion about that.And to answer your question, yes, Melv has stated he will add it, but it's a little further down his list than the more fundamental issues.
#3
03/26/2005 (12:49 pm)
This doesn't answer your question either but, I've started a pseudo-isometric game so I know it's possible as T2D is now. I'm having trouble with collisions(doing them the right way) though, but that's because I'm new to TorqueScript.
#4
It all depends on how you want to do isometrics. Starcraft, for example, is not really isometric; it's a square tilemap. It simply has art and collisions designed to make it seem isometric (terrain art. Building art is designed to fit into squares, which is why building placement is sometimes wierd). Meanwhile, Ultima 8 is truly isometric; it has a specific belief in the isometric nature of the world. Tiles are diamond shaped and rendered in bottom-to-top ordering.
The Starcraft varient you could do in T2D just fine.
I hate to dis Melv, since he gave us this wonderful T2D, but I don't think he quite understands what isometric maps are really about. His commentary in the FAQ about, "Trouble is, in this ISO layer, we've got a virtual 3D world." is wrongheaded.
Properly implemented, isometric maps are not 3D. They aren't even a 2D/3D hybrid. They are a slight modification of square-tiled 2D rendering forms. The major modification is rendering the tiles and sprites in a layer simultaneously, and in order from bottom to top. Culling would have to be modified, as tiles need to be able to extend beyond their normal established boundaries (pillar tiles and so forth). But there's no need for swept rectangular prism collision, 3D physics, or any of that sort of thing.
There's no need to go through and give everything a z-value. Regular layers, as used for square 2D tiles, can allow for going on top of a building or something to that effect. And that is needed only if there is something under or behind that building that wouldn't normally be obscured.
Basically, until Melv figures out what isometric maps really mean, there's know way to know how he will go about implementing them.
03/26/2005 (1:56 pm)
Quote:From my limited understanding of isometric engines, and some tutorials at SpriteArt.com, iso engines are effectively 2:1 tiles carefully constructed and placed with clever layering and collisions.
It all depends on how you want to do isometrics. Starcraft, for example, is not really isometric; it's a square tilemap. It simply has art and collisions designed to make it seem isometric (terrain art. Building art is designed to fit into squares, which is why building placement is sometimes wierd). Meanwhile, Ultima 8 is truly isometric; it has a specific belief in the isometric nature of the world. Tiles are diamond shaped and rendered in bottom-to-top ordering.
The Starcraft varient you could do in T2D just fine.
I hate to dis Melv, since he gave us this wonderful T2D, but I don't think he quite understands what isometric maps are really about. His commentary in the FAQ about, "Trouble is, in this ISO layer, we've got a virtual 3D world." is wrongheaded.
Properly implemented, isometric maps are not 3D. They aren't even a 2D/3D hybrid. They are a slight modification of square-tiled 2D rendering forms. The major modification is rendering the tiles and sprites in a layer simultaneously, and in order from bottom to top. Culling would have to be modified, as tiles need to be able to extend beyond their normal established boundaries (pillar tiles and so forth). But there's no need for swept rectangular prism collision, 3D physics, or any of that sort of thing.
There's no need to go through and give everything a z-value. Regular layers, as used for square 2D tiles, can allow for going on top of a building or something to that effect. And that is needed only if there is something under or behind that building that wouldn't normally be obscured.
Basically, until Melv figures out what isometric maps really mean, there's know way to know how he will go about implementing them.
#5
As for Melv, I'm not so sure that he doesn't know what isometric engines involve. My take on what he hopes to do with the iso tile object would be a streamlined method of placing tiles with proper collision, etc. On a base level, sure, they're simply 2D tilemaps with clever collisions and occlusions. To implement them easily, on the other hand, would require some work at the engine (or at least, tilemap) level. With all the occlusion and collision work, it effectly becomes a 2.5D thing.
03/26/2005 (2:04 pm)
Thanks for the explanation, Smaug, that more or less confirms my suspicions that isometric maps, at least to some extent, are simply clever layering and collision work that can be done with stock T2D.As for Melv, I'm not so sure that he doesn't know what isometric engines involve. My take on what he hopes to do with the iso tile object would be a streamlined method of placing tiles with proper collision, etc. On a base level, sure, they're simply 2D tilemaps with clever collisions and occlusions. To implement them easily, on the other hand, would require some work at the engine (or at least, tilemap) level. With all the occlusion and collision work, it effectly becomes a 2.5D thing.
#6
Oh, it'll require some engine work (mounted objects need to know whether they should be y-ordered like the rest of the images or be drawn just before or after the sprite to which they are mounted, and some other stuff), most definately. It's not the kind of thing that you would want to implement in TScript. But the kinds of things Melv was suggesting, like doing 3D physics, collisions, and so forth is hardly required in implementing isomaps.
03/26/2005 (2:15 pm)
Quote:With all the occlusion and collision work, it effectly becomes a 2.5D thing.
Oh, it'll require some engine work (mounted objects need to know whether they should be y-ordered like the rest of the images or be drawn just before or after the sprite to which they are mounted, and some other stuff), most definately. It's not the kind of thing that you would want to implement in TScript. But the kinds of things Melv was suggesting, like doing 3D physics, collisions, and so forth is hardly required in implementing isomaps.
#7
I don't think its that Melv doesn't understand, moreso he probably was just simplifying it for a quick comment.
03/26/2005 (2:34 pm)
Right now my team and I are working on a psuedo-iso RPG, Diablo style... but we're just sidestepping it with clever collision and art :)I don't think its that Melv doesn't understand, moreso he probably was just simplifying it for a quick comment.
#8
Sure, an isometric view can be a regular grid, rotated 45-deg and scaled 0.5 in height. Set-up a convex polygon around the diamond-base, render from top-down so you get proper occlusion and there you go. I do understand what they are. Why wouldn't I? They are pretty simple concepts, you should give me a little credit. Besides, I'm really sick with cold at the moment and I'm feeling pretty sorry for myself so stop picking on me! boooohooo, mmwwarrhhhhh. *sniff*
As you say, rendering regular T2D layer-centric sprites within this virtual space is really problematic as the objects (including a whole tile-layer) typically render within a single T2D layer. Z-ordering is done by simple render-order, not Z-buffering so getting the object to render to the 32 layers and distributing the ISO tile-layers through T2D layers would be difficult and very limiting anyway.
It is not as easy as it first sounds.
All in good time,
- Melv.
03/27/2005 (6:13 am)
@Smaug: I stand by everything I've said about ISO tilemaps and I do understand their different forms. In the original plans, I had something special in design for the ISO tile-layers and that led to a complication of how we'd implement it, including the swept collision stuff. That's the problem for not posting a 10,000 word description of what is going on behind the scenes and clarifying every detail I guess.Sure, an isometric view can be a regular grid, rotated 45-deg and scaled 0.5 in height. Set-up a convex polygon around the diamond-base, render from top-down so you get proper occlusion and there you go. I do understand what they are. Why wouldn't I? They are pretty simple concepts, you should give me a little credit. Besides, I'm really sick with cold at the moment and I'm feeling pretty sorry for myself so stop picking on me! boooohooo, mmwwarrhhhhh. *sniff*
As you say, rendering regular T2D layer-centric sprites within this virtual space is really problematic as the objects (including a whole tile-layer) typically render within a single T2D layer. Z-ordering is done by simple render-order, not Z-buffering so getting the object to render to the 32 layers and distributing the ISO tile-layers through T2D layers would be difficult and very limiting anyway.
It is not as easy as it first sounds.
All in good time,
- Melv.
#9
03/27/2005 (8:09 am)
Heya Melv, don't sweat it, we all love ya. :-p You didn't address my original question, though. Though now that I think about it, it's not entirely important. I guess I was just idly thinking, and my question was more out of curiosity rather than a need for hard data for development purposes. Anyways, I'm getting really full with all these scones. That update better come soon before I burst. :)
#10
Could you maybe explain a little more who I would go about doing the Starcraft type variation in the stock T2D?
03/27/2005 (8:13 am)
Quote:It all depends on how you want to do isometrics. Starcraft, for example, is not really isometric; it's a square tilemap. It simply has art and collisions designed to make it seem isometric (terrain art. Building art is designed to fit into squares, which is why building placement is sometimes wierd). Meanwhile, Ultima 8 is truly isometric; it has a specific belief in the isometric nature of the world. Tiles are diamond shaped and rendered in bottom-to-top ordering.
The Starcraft varient you could do in T2D just fine.
Could you maybe explain a little more who I would go about doing the Starcraft type variation in the stock T2D?
#11
03/27/2005 (8:22 am)
SpriteArt.com has a good overview in the tutorials section on how isometric tiles are split up and rendered, and hence, how to prepare them.
#12
I didn't say that; you did. I'm saying that it is not problematic. And it isn't a "virtual space" either; don't think of it that way. Remember: isometric 2D is just a hack. There's no real 3D anything going on here. It's a precision hack.
Rendering is trivial. As we both said, you render the tiles in a layer and the sprites in that layer simultaneously. You render them in top-to-bottom order by y-value (not some Z-value. BTW I said bottom-to-top earlier, and I was mistaken. That may have confused someone).
Render to 32 layers? How's that going to happen?
I have an object (a sprite). It lives in an isometric layer. When that isometric layer gets rendered, it gets rendered. There's no need to distribute anything into isolayers or anything of the sort.
Basically, if you're thinking of isomaps as anything more than a rendering trick, you're not implementing them correctly. Isometric tilemaps are just like regular 2D tilemaps. They only do their per-layer rendering in a different way.
Maybe you wrote the tile layer and sprite layer rendering code in separate places, which makes conjoining them in an isomap renderer difficult. Well, it can't be that hard to bring them together. It'll require cross-talk between two systems that used to have some separation between them, but that's no big deal.
Each isolayer is independent of the others. In fact, it's perfectly possible to have an isolayer on one tilemap layer, and have a regular square 2D layer on the next. It may not be reasonable for an entity actually walking up there, but if you need to put some decorations somewhere (a few trees in the foreground that cover up regular terrain), it's easier (on the tool/art side. The code side doesn't care) to just put them into a square layer than deal with an isolayer.
It's like I said: a matter of art and collision detection. Your tiles need to not use square collision; they need to have different collisions for their specific shape. Look at Starcraft maps in the map editor, and start placing stuff on the map. It places things in squares, not isometric tiles. Your tiles will need to mimic that look, and each tile will need to use an appropriate collision region, so that part of it is walkable and part of it is not (for tiles where this is appropriate).
03/27/2005 (12:23 pm)
Quote:As you say, rendering regular T2D layer-centric sprites within this virtual space is really problematic as the objects (including a whole tile-layer) typically render within a single T2D layer.
I didn't say that; you did. I'm saying that it is not problematic. And it isn't a "virtual space" either; don't think of it that way. Remember: isometric 2D is just a hack. There's no real 3D anything going on here. It's a precision hack.
Rendering is trivial. As we both said, you render the tiles in a layer and the sprites in that layer simultaneously. You render them in top-to-bottom order by y-value (not some Z-value. BTW I said bottom-to-top earlier, and I was mistaken. That may have confused someone).
Quote:Z-ordering is done by simple render-order, not Z-buffering so getting the object to render to the 32 layers and distributing the ISO tile-layers through T2D layers would be difficult
Render to 32 layers? How's that going to happen?
I have an object (a sprite). It lives in an isometric layer. When that isometric layer gets rendered, it gets rendered. There's no need to distribute anything into isolayers or anything of the sort.
Basically, if you're thinking of isomaps as anything more than a rendering trick, you're not implementing them correctly. Isometric tilemaps are just like regular 2D tilemaps. They only do their per-layer rendering in a different way.
Maybe you wrote the tile layer and sprite layer rendering code in separate places, which makes conjoining them in an isomap renderer difficult. Well, it can't be that hard to bring them together. It'll require cross-talk between two systems that used to have some separation between them, but that's no big deal.
Each isolayer is independent of the others. In fact, it's perfectly possible to have an isolayer on one tilemap layer, and have a regular square 2D layer on the next. It may not be reasonable for an entity actually walking up there, but if you need to put some decorations somewhere (a few trees in the foreground that cover up regular terrain), it's easier (on the tool/art side. The code side doesn't care) to just put them into a square layer than deal with an isolayer.
Quote:Could you maybe explain a little more who I would go about doing the Starcraft type variation in the stock T2D?
It's like I said: a matter of art and collision detection. Your tiles need to not use square collision; they need to have different collisions for their specific shape. Look at Starcraft maps in the map editor, and start placing stuff on the map. It places things in squares, not isometric tiles. Your tiles will need to mimic that look, and each tile will need to use an appropriate collision region, so that part of it is walkable and part of it is not (for tiles where this is appropriate).
#13
Please, if it's no big deal, feel free to implement but please make sure that you don't break existing functionality, don't make it uncessarily difficult for people to use, especially people without as much experiences as you've got and also don't forget to not simply copy what's gone before. In the meantime I'll carry on working on the hundreds of other things that need to be done.
Oh well, back to it.
- Melv.
03/27/2005 (2:46 pm)
Quote:Maybe you wrote the tile layer and sprite layer rendering code in separate places, which makes conjoining them in an isomap renderer difficult. Well, it can't be that hard to bring them together. It'll require cross-talk between two systems that used to have some separation between them, but that's no big deal.
Quote:Rendering is trivial
Quote:I'm saying that it is not problematic.I'm well aware of the issues here, like I said, trust me. I'm also aware of the problems of reworking scenegraph code so that we get this "trivial" change to make ALL T2D objects work in an ISO tile-layer, essentially so that they work within the ISO-space coordinate-frame (virtual space anyone?). Unless, of course, you're happy moving sprites around in a rectilinear fashion and want to convert your movements into ISO-space manually.
Please, if it's no big deal, feel free to implement but please make sure that you don't break existing functionality, don't make it uncessarily difficult for people to use, especially people without as much experiences as you've got and also don't forget to not simply copy what's gone before. In the meantime I'll carry on working on the hundreds of other things that need to be done.
Oh well, back to it.
- Melv.
#14
*tosses Melv a cream scone*
(Ha! One less scone to work through before the update hits! Success! :)
03/27/2005 (3:25 pm)
Heya Melv, don't take it so hard. Here, have one of my cream scones! :)*tosses Melv a cream scone*
(Ha! One less scone to work through before the update hits! Success! :)
#15
Guess it's making me tetchy.
The cream scone helped. :) Yay!
- Melv.
03/27/2005 (4:01 pm)
Sorry if I sound a little harsh in that post. I've had a bad cold for the last 4 days (so has wife/baby) and it's really starting to grind me down. Trying to get everything in T2D finished as well as trying to spend some bank-holiday with my wife.Guess it's making me tetchy.
The cream scone helped. :) Yay!
- Melv.
#16
So, instead of getting a hack now (which is, as you said, trivial) we'll get a nicely working system later. In the meantime, you can implement the trivial hack yourself by adjusting the source slightly.
And voila: you have the best of both worlds: you can render your iso maps now by just hacking the current system and you'll get a iso system later on. Isn't life wonderful?
-Lenny
03/27/2005 (6:42 pm)
Quote:Remember: isometric 2D is just a hack. There's no real 3D anything going on here. It's a precision hack.If you just want to add it as a hack, all you have to do is to change the way the maps are drawn. But the problem is that once the iso support is there, people will use it. If it is just a hack, people will complain that it is just a hack. And since GG is supporting t2d, they'd have to support that "hack" as well.
So, instead of getting a hack now (which is, as you said, trivial) we'll get a nicely working system later. In the meantime, you can implement the trivial hack yourself by adjusting the source slightly.
And voila: you have the best of both worlds: you can render your iso maps now by just hacking the current system and you'll get a iso system later on. Isn't life wonderful?
-Lenny
#17
Oh, so that's what you're talking about with "virtual space" and so forth. This has to do with physical collision response and so forth.
I don't think it matters; at least, not for what you might consider "normal" isometric games. Remember; most 2D games, isometric or not, don't use physics-correct collision responses anyway. As such, I wouldn't worry too much about it. The user handles setting the velocity/acceleration of various objects anyway. It's hardly unreasonable for the user, who has to handle collision response anyway, to take care that objects that bounce move in the proper direction.
Don't forget that 2D games don't tend to be physics simulations. Movement in arbitrary directions and proper physics collision responses is hardly necessary or required, especially for isometric games. Most games that need the later are full-range space shooters (see Asteroids/Starscape), pinball games (not isometric, or even really tile-based at all), and a few others.
It'd be sad to see an entire type of 2D game not supported by T2D simply because of how it might interact with a system that the users of that type will never use.
03/27/2005 (7:07 pm)
Quote:Unless, of course, you're happy moving sprites around in a rectilinear fashion and want to convert your movements into ISO-space manually.
Oh, so that's what you're talking about with "virtual space" and so forth. This has to do with physical collision response and so forth.
I don't think it matters; at least, not for what you might consider "normal" isometric games. Remember; most 2D games, isometric or not, don't use physics-correct collision responses anyway. As such, I wouldn't worry too much about it. The user handles setting the velocity/acceleration of various objects anyway. It's hardly unreasonable for the user, who has to handle collision response anyway, to take care that objects that bounce move in the proper direction.
Don't forget that 2D games don't tend to be physics simulations. Movement in arbitrary directions and proper physics collision responses is hardly necessary or required, especially for isometric games. Most games that need the later are full-range space shooters (see Asteroids/Starscape), pinball games (not isometric, or even really tile-based at all), and a few others.
It'd be sad to see an entire type of 2D game not supported by T2D simply because of how it might interact with a system that the users of that type will never use.
#18
03/27/2005 (7:09 pm)
Smaug, let it go already. Melv's already stated that iso support may be in sometime in the future. As has been said numerous times in this thread alone, if you truly need it, and truly feel it'd be a simple thing to add in, you've got the source code. Go ahead and add it in. Post it up as a resource, if you so please. Let Melv get back to the important stuff.
#19
I wasn't talking about how to add it; I was talking about what isometic maps are. They're a hack to make a 2D map look more like a 3D rendering.
Which, as I pointed out, is sad. Because you're saying that an entire group of 2D games and gameplay is not possible without reworking the T2D engine.
I don't care about isometric maps; I'm not interested in making games with them. I don't even like the look of isomaps; I prefer more traditional 2D tilemaps. However, this doesn't mean that they shouldn't be in T2D.
My comments here were discussing what isometric maps are and how they could/should be implemented in T2D. I disagree with Melv on the idea that it would require significant reworking of lots of code. I, also, disagree with is apparent stance that isomaps are not important enough to justify the work required to implement them.
BTW, I think people are a little too quick to say, "Well, why don't you just add it" as a "solution" to inadiquacies in T2D. The entire point of an engine is to have the basics of a game built for you so that you don't have to implement it yourself. I could write T2D if I really felt like it. But, since it already exists, there isn't much point in my doing so.
To me, the proper answers from developers of an engine to a feature request is one of the following:
1: I understand what you've asked for, and it's already on our to-do list, or we will add it and prioritize it appropriately.
2: I understand what you've asked for, and it is outside the scope of our game engine (asking T2D for polygonal scan conversion, for example).
3: I understand what you've asked for, but while it is in the explicit scope of our game engine, it's use is not sufficiently general-purpose enough to be added to our engine.
4: I don't understand what you've asked for.
#1&2 are, for the most part, findings of fact, not opinion. Either a feature belongs in an engine or it doesn't. #3 is a matter for debate. Some features are obviously more generally useful than others. While it might be nice if T2D had automatic support for minimaps and such (ie, spawned objects appear automatically on the map, etc), it is not a generally useful feature. Maybe for an RTS engine, but not for a general 2D engine.
The answer, "I understand what you've asked for, but, even through it is within the scope of our engine and general-purpose enough to warrent adding, we're not going to do it. However, we're going to give you the source code, so you can implement it if you want" is not a reasonable answer. Back before polygonal 3D games became popular, a good 20-30% of PC 2D games used isometric tilemaps. It was very popular for PC RPGs. As such, it is definately within the scope of a 2D engine to provide this functionality. While not quite as fundamental as collision, or having any kind of tilemaps, it still deserves to be a part of a serious 2D engine.
It's the equivalent of the TGE guys locking the camera onto one specific object, thus preventing the user from positioning the camera in an arbitrary location. You get all kinds of first-person games, but you can't make 3rd person ones. Granted, such a change is far more trivial compared to implementing isomaps (especially the tilemap tool for it), but the concept is still the same: restricting the genre of what can be made on the engine.
03/27/2005 (8:41 pm)
Quote:If you just want to add it as a hack, all you have to do is to change the way the maps are drawn.
I wasn't talking about how to add it; I was talking about what isometic maps are. They're a hack to make a 2D map look more like a 3D rendering.
Quote:Smaug, let it go already. Melv's already stated that iso support may be in sometime in the future.
Which, as I pointed out, is sad. Because you're saying that an entire group of 2D games and gameplay is not possible without reworking the T2D engine.
Quote:As has been said numerous times in this thread alone, if you truly need it, and truly feel it'd be a simple thing to add in, you've got the source code.
I don't care about isometric maps; I'm not interested in making games with them. I don't even like the look of isomaps; I prefer more traditional 2D tilemaps. However, this doesn't mean that they shouldn't be in T2D.
My comments here were discussing what isometric maps are and how they could/should be implemented in T2D. I disagree with Melv on the idea that it would require significant reworking of lots of code. I, also, disagree with is apparent stance that isomaps are not important enough to justify the work required to implement them.
BTW, I think people are a little too quick to say, "Well, why don't you just add it" as a "solution" to inadiquacies in T2D. The entire point of an engine is to have the basics of a game built for you so that you don't have to implement it yourself. I could write T2D if I really felt like it. But, since it already exists, there isn't much point in my doing so.
To me, the proper answers from developers of an engine to a feature request is one of the following:
1: I understand what you've asked for, and it's already on our to-do list, or we will add it and prioritize it appropriately.
2: I understand what you've asked for, and it is outside the scope of our game engine (asking T2D for polygonal scan conversion, for example).
3: I understand what you've asked for, but while it is in the explicit scope of our game engine, it's use is not sufficiently general-purpose enough to be added to our engine.
4: I don't understand what you've asked for.
#1&2 are, for the most part, findings of fact, not opinion. Either a feature belongs in an engine or it doesn't. #3 is a matter for debate. Some features are obviously more generally useful than others. While it might be nice if T2D had automatic support for minimaps and such (ie, spawned objects appear automatically on the map, etc), it is not a generally useful feature. Maybe for an RTS engine, but not for a general 2D engine.
The answer, "I understand what you've asked for, but, even through it is within the scope of our engine and general-purpose enough to warrent adding, we're not going to do it. However, we're going to give you the source code, so you can implement it if you want" is not a reasonable answer. Back before polygonal 3D games became popular, a good 20-30% of PC 2D games used isometric tilemaps. It was very popular for PC RPGs. As such, it is definately within the scope of a 2D engine to provide this functionality. While not quite as fundamental as collision, or having any kind of tilemaps, it still deserves to be a part of a serious 2D engine.
It's the equivalent of the TGE guys locking the camera onto one specific object, thus preventing the user from positioning the camera in an arbitrary location. You get all kinds of first-person games, but you can't make 3rd person ones. Granted, such a change is far more trivial compared to implementing isomaps (especially the tilemap tool for it), but the concept is still the same: restricting the genre of what can be made on the engine.
#20
For one, no offense, but I highly doubt you could write T2D... one of the main reasons being its based off of TGE which has years of development and tweaking behind it, the start of which being Tribes then Tribes 2... two major commercial games which most game engines dream about boasting about.
next, this is not a month project, this has been months and months of solid work by an ingenious coder (teamed with a great publishing company/game engine company)...
two, if you had problems with another engine and told them they need to spend a lot of time and add new features they will most likely laugh or simply ignore you, heck I doubt you'd even get close to this much attention from the creator of it...
you can't get Unreal engine and then go say you want all these features, or a single major feature... thats why the "do it yourself" attitude exists, if you don't want to wait, then you do it yourself... most engines you don't get the source to even have that option.
not hardly... the camera in T2D isn't "locked"... that would have to be the comarison... you can't compare the "camera" in one engine to a whole rendering process... you can only compare a camera to a camera... what your saying is like asking TGE to add 2d rendering layers to truly support ISO style games in TGE... and that is more than a simple request that would probably result in the same answer, "do it yourself".
plus this is completely void... many games are actually 2d games with clever art and collision... some of the best were and it all comes down to fun gameplay, not ISO tile maps etc... if your game sucks it sucks... if its fun its fun, simple as that, truly is
03/27/2005 (8:50 pm)
Quote:BTW, I think people are a little too quick to say, "Well, why don't you just add it" as a "solution" to inadiquacies in T2D. The entire point of an engine is to have the basics of a game built for you so that you don't have to implement it yourself. I could write T2D if I really felt like it. But, since it already exists, there isn't much point in my doing so.
For one, no offense, but I highly doubt you could write T2D... one of the main reasons being its based off of TGE which has years of development and tweaking behind it, the start of which being Tribes then Tribes 2... two major commercial games which most game engines dream about boasting about.
next, this is not a month project, this has been months and months of solid work by an ingenious coder (teamed with a great publishing company/game engine company)...
two, if you had problems with another engine and told them they need to spend a lot of time and add new features they will most likely laugh or simply ignore you, heck I doubt you'd even get close to this much attention from the creator of it...
you can't get Unreal engine and then go say you want all these features, or a single major feature... thats why the "do it yourself" attitude exists, if you don't want to wait, then you do it yourself... most engines you don't get the source to even have that option.
Quote:It's the equivalent of the TGE guys locking the camera onto one specific object, thus preventing the user from positioning the camera in an arbitrary location. You get all kinds of first-person games, but you can't make 3rd person ones
not hardly... the camera in T2D isn't "locked"... that would have to be the comarison... you can't compare the "camera" in one engine to a whole rendering process... you can only compare a camera to a camera... what your saying is like asking TGE to add 2d rendering layers to truly support ISO style games in TGE... and that is more than a simple request that would probably result in the same answer, "do it yourself".
plus this is completely void... many games are actually 2d games with clever art and collision... some of the best were and it all comes down to fun gameplay, not ISO tile maps etc... if your game sucks it sucks... if its fun its fun, simple as that, truly is
Torque Owner Travis Womack
Any thoughts?