Isometric Engine with TX2D?

#1 I've always been fond of the isometric perspective and would also be interested in this.

I don't have the builder with me here, so I can't check but a possible work around (not very ideal) would be to save your materials in iso form and use 2 overlapping, offset tilemaps in TXB.

If you don't want to save them that way or use tilemaps, maybe you could rotate and stretch your materials and template them, but you'd have to spawn every tile.

I would like to know if there's a better way "out of the box".

#2 You might want to have a look at
Green Robot
www.torquepowered.com/community/blogs/view/18089

and

www.torquepowered.com/community/blogs/view/17141

Should be what yer looking for. Its all in the way you handle layers and sort points =)

#3 Not to deter you, so feel free to ignore this post. Personally though I have found its easier to do an isometric game in real 3d as apposed to faking it with 2d.

Its just that you do so much to fake the view its easier to let the engine handle it.

Also its easier to get believable physics with rigid bodies and such when you go to real 3d as its hard to fake the movement in fake 3d.(if that's something your interested in)

That being said though you have to go with a solution that is good for your team. So if your artists are more comfortable with 2d or you have some special aesthetic your going for then ignore the above ;).

#4 Hello community!

thanks for all the input. So it seems TX is able to do isometric views
with a bit of hacking. Very interesting links, i will check the code
for their implementation.

I will also take some time to look into TX3D to check if Matthews
suggestion is also working for us (atm we just like the "feel" of
2D/2.5D better, but this may change). And funny thing is... yes, we
really have an 2D only artist, but i will ask him how much time he
would need to handle Blender/3D Studio (i think too much ;)

If anybody has more code samples, tutorials or ideas for isometric views, please feel free to post them here.

I will post updates on the progress here from time time, i think there is some interest in the community.

#5 This is very easy to do, and there is no hacking involved.. :-)
To achieve this you would make a game just like any other top scroller, side scroller, ect. The only difference is the angle of your objects (3D stills with the same angle).

1) The camera angle on a 2d game is dependant of your scene objects, so YES.
2) This tutorial will teach you a lot! And the first part is setting up an isometric character! https://sites.google.com/site/soyouwanttomakeanarenashooter/
3) I will leave this one for you to research. :-)

But seriously this is extremely easy, and was one of the first things I learned to do on TX2D. Email me if you have any other questions.

#6 hi all,

little question regarding the way TX2D draws it's objects...

1) Is there a way to define at which order the objects from the database are drawn? Since i need overlapping, i have to draw the tiles and stuff row by row starting from 0,0 (otherwise a player could not stand infront or behind soemthing i guess). Or is this handled by the engine somehow?
I mean "z-ordering" if that helps to understand what i want ;)

@Aaron
Thanks. That is a nice trick, but not really that kind of isometric engine i am looking for. It is more a isometric "fake fake" ;) I am really looking for this oldschool "diamond shape 45/26.xxx degrees 2.1:1" look and feel. Or did i miss something?

#7 I understand what your saying, but still, the look and feel depends on your art assets/scene object(2D images of 3D objects in this case), no matter what method you use.

So to achieve these 2D images of 3D objects in isometric view you would need your artist(3D artist) to setup your camera angle in whatever 3D program their using to the isometric angle you want, and then use that same angle on all 3D objects when making 2D images for your game.

After you have created your game assets this is what you would do in TX2D:

First, I would only use the tiles for the ground.

Then just start throwing your scene objects onto the scene. To allow your character to go behind objects, set your player layer back a few layers and here is the magic part -> Edit the objects collision polygon's to give new collision limits (base of walls and objects), allowing a 3d look and feel when walking around or behind things.

However, if you do end up using tiles for objects, You would still have to throw blank scene objects into the scene to setup collision poly's (why make an extra step?)

Hope this helps.

#8 Thanks again for the response!

Sounds like a good idea to only use tiles for the floors and default TXB objects for the rest, but i have some question if this is possible for my kind of game:

1) In my game i can control the chars by mouse. Movement is planned like
this:
MouseClick in battlefield throws event with the clicked object=floor (done)
State Machine checks for next possible action (done)
If choosen field is empty tile AND player was selected bevore, check
the shortest route to the target tile (using A* algorithm) (todo)
Animate the movement to the new tile if char has enough movement points (todo)

In my current idea, i would have checked the shortest route by marking floors with mounted objects as "not passable", so the player needs to walk around them.

With this in mind, is it possible to use your way of placing objects not
as tiles? How can i determine whats on a floor without mounting an object (for example: wall) on the floor to access it later?

2) I don't get how collision polygones can help me with z-ordering and
visibility... can you explain that with a sample please? I see what the collision is good for, but if my chars walks behind such a object, he is still rendered infront of it... what am i missing?

3) For the case it does not work for me, how can i tell TXD to render the tiles in a given order (row by row in my sample)?

I really appreciate your help, your way could simplify a lot of stuff
if it works for me.

#9 1)I believe Mathew Hoesterey added what your asking for to the community repository A* path-finding, access requires the source version (paid version) of Torque X.

2)You could change your char layer so that its behind the object, but if you want your char to appear above the object if in front then you will have to figure out the z-ordering (if you dont change the characters polys to feet then you dont need z-order, but then your limited to walking area above your feet up to your head). z-ordering has to do with the "Sort Point" on the object and the sort method for the layer. I am lacking on this topic, this might help? Sort Points

#10 Thanks again, i will play around a little bit with your suggestions
and then tell if it worked for me.

Another, maybe very basic, question:

For this kind of game i need a lot of maps (level instances) that will be called later on purpose. At the moment i just have a very small testmap with everthing drawn directly in TXB (tiles, obstacles, players,...) and saved to a level.

What is best practice here if things get bigger (so say i need to have
about 100 map instances which i call randomly on events inside the gui):

1) do i "design" all these maps with TXB directly (using only static sprites) and spawn my players and enemies later on the level when it is loaded? In this case i have no templates or spawners (thats what i am doing currently).

2) do i just put my materials and animations in TXB, make them templates and call them from C# with clone() to design my maps from settings in XML code or something else?

What are drawbacks between using TXB as "LevelEditor" or cloning from templates in code? Is 1) legal at all?

#11 For this type of game I would do almost everything with TXB, design the map, create your animations, create the templates, and place your spawners. Then I would get it fully functional, code some new components and delegates to add to my player/enemies and collisions(like gunfire, death, AI, etc). Then finally make copies of the scene and make changes for each level.

#12 Its probably best to have your characters and shared objects in a separate scene file.

You can load multiple .txscene files at the same time in code.

For my game I have all shared character and game-play data that exists across levels in a game.txscene file. I then have all shared fx in a separate fx.txscene file. Gui in another gui.txscene file.

Then each level is its own .txscene file

When I load the game I just load and unload the .txscenes I need and dump all the info into a shared scene graph.



Whats important is all the above .txscene files are SEPARATE PROJECT FILES!!!!! ( I will explain why below)


If you have a large project you will NEED to do the above. Right now TX2D builder has horrible content management. As such it loads all textures in the project file. If you have a big project with a lot of art then TX2D builder will crash if you don't split your game into multiple project files. Luckily the project files are not actually loaded in code and are just used by the builder.

Using the above technique you will be able to avoid having to re-create things in the builder once you get into the iteration phase of your project. Another option would be to create templates in code as you mentioned.

I would highly recommend buying the source if you haven't and getting Pinos engine and Duncans Async loader. (at least if your working on a serious project).

Good Luck.

#13 Also my A* might get you started but it will need heavy modification. It was made specifically for my plat-former. Your biggest challenge is going to be building a A* path-map that works in 2.5D. After that its easy.

#14 ".txscene files are SEPARATE PROJECT FILES!!!!!"

You mean .txproj files? (some confusion here?)

#15 .txproj = project file
.txscene = scene files

#16 I would suggest creating a .txproj file for every .txscene file. Or at least one for your shared game stuff and one for each level.

My fighting game has only 4 levels and 4 characters and TX2D Builder would crash (or run so slow it was unusable) if I did not divide it this way. ;)