Sign in to follow this  

Tiling engines

This topic is 4832 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm creating a 2D (hopefully 2.5D like Diablo II) RPG game, and I've been reading up on different approches to this (ie Tiling, screen based, or big image that is just scrolled around) and I was wondering if anyone had experiance with these types of scrolling, and what you guys would recommend. Whats fastest? What looks the nicest? etc Thanks Sigma

Share this post


Link to post
Share on other sites
hey funny you should mention this. you might want to check out this thread i put up about an hour ago :)

Thread about my iso map editor

if that hasnt helped answer your question:
i believe tiles are the way to go if you can pull off a good looking scene with repetition. large maps take up a large amount of memory and can result in much more pressure on video cards.
that means that tiles are likely to be faster, but large maps can often be made prettier if the tile artist isnt up to scratch! my advice is to go with tiling if you can pull off good looking tiles.
still choose the way thats right for you :)

the_moo

Share this post


Link to post
Share on other sites
i believe so but i havent touched 3d yet so i cant tell you for sure. i remember hearing about it though.

the_moo

Share this post


Link to post
Share on other sites
As for one giant bitmap, besides being slow, have you considered how you are going to store events and places where you cannot walk etc?

Share this post


Link to post
Share on other sites
Quote:
Original post by _Sigma
Is it possible to incorperate 3D models using a tiling engine?


Certainly. I've recently abandoned my traditional 2D iso engine for Golem in favor of an engine that utilizes 3D models for character animations. I actually have two subtly different iterations of the engine; one is an isometric in all respects, with the internals being 3D driven yet the view being indistinguishable in appearance from the traditional 2D implementation (outside of the smoother animation of the 3D models); the second utilizes most of the same tech but with a perspective projected viewpoint and rotating camera. The fundamental map structure, however, remains tilebased. Tiling can be a simple way of organizing a 'simple' world. It lacks flexibility in many regards, and thus may be unsuitable for first-person style games, but action/RTS/RPG style games can benefit enormously from a tile-based engine.

Share this post


Link to post
Share on other sites
If you change your definition of 'tiles' just a bit away from the standard 2d definition of a grid of bitmaps, you can have quite complex 3d worlds. For example, dungeon siege maps were made up of tiles, but instead of some kind of grid, each tile had 'attach points' where you could stick another tile onto it. That allowed for all kinds of overhangs and fancy caves and tons of other nice geometry that wouldn't be possible in a simple heightmap/2d tile based game

Share this post


Link to post
Share on other sites
Quote:
Original post by VertexNormalCertainly. I've recently abandoned my traditional 2D iso engine for Golem in favor of an engine that utilizes 3D models for character animations. I actually have two subtly different iterations of the engine; one is an isometric in all respects, with the internals being 3D driven yet the view being indistinguishable in appearance from the traditional 2D implementation (outside of the smoother animation of the 3D models); the second utilizes most of the same tech but with a perspective projected viewpoint and rotating camera. The fundamental map structure, however, remains tilebased. Tiling can be a simple way of organizing a 'simple' world. It lacks flexibility in many regards, and thus may be unsuitable for first-person style games, but action/RTS/RPG style games can benefit enormously from a tile-based engine.


But how would you handle different heights? How could you make a tile connect to another which is on a higher level without having a gap in the terrain?

Share this post


Link to post
Share on other sites
Quote:
Original post by Extrarius
If you change your definition of 'tiles' just a bit away from the standard 2d definition of a grid of bitmaps, you can have quite complex 3d worlds. For example, dungeon siege maps were made up of tiles, but instead of some kind of grid, each tile had 'attach points' where you could stick another tile onto it. That allowed for all kinds of overhangs and fancy caves and tons of other nice geometry that wouldn't be possible in a simple heightmap/2d tile based game


I believe I once read an article on the Siege engine and some specifics on it from one of the developers.. at least I'm 99% sure I did.

Anybody have a link or know where I might find it?

Share this post


Link to post
Share on other sites
Now that you say that, I seem to remember somthing like that from working with the DS SDK. All I remember is that it was freaking unintuitive.

So if I create the 3D models in Maya, then export it as a bmp sequence, I can use thos bitmaps in my game right? And it will look like Diablo II or ther-abouts right?

Is it best to use tiling engine like Starcraft did(with the square tiles rotated 180 degrees) or one with square tiles?

Share this post


Link to post
Share on other sites
I believe Starcraft actually did use rectangular tiles, they just 'faked' the isometric perspective by using larger 'meta-tiles', which are aggregates of smaller tiles that can hold a more complicated tile configuration than a single rectangular tile holds. IIRC, the actual tile size in Starcraft was very tiny, and all the real work was done with these larger meta-tiles. This is an extension of the tile-based idea, as is the method used by games such as Dungeon Siege as previously mentioned. A tile can be as simple or as complicated as you need or want it to be, and aggregates of tiles (meta-tiles) can themselves be viewed as tiles and manipulated accordingly.

Typically, 2D isometrics utilize diamond-shaped tiles. Each tile is held in a rectangular bitmap (usually with a tile ratio of 2:1, ie 128x64) but the effective area of the tile is diamond shaped. You can see my isometric tiles tutorial here for some examples on how to construct isometric tiles if you are curious.

Diablo and many others did what you suggest, modelling their characters in 3D then rendering to a series of BMPs (I actually use Targa format, since Blender will render to that image format, with alpha channel support for transparency) for import to the game. However, this is not using 3D in your game; it's simply using 2D sprites, just like any other standard 2D game. The only difference is that the sprites were created with a 3D modelling package, rather than drawn by hand. The sprites will still be drawn using 2D techniques, and there will still be the limitations imposed by using 2D sprites. That is, for an isometric perspective, each character and object needs to be pre-rendered to bitmap file sequences in all of the possible directions the character or object can face. Typically, you render in 8, 16 or 32 possible facing directions (though, for symmetrical characters, some of these directions can be mirrored).

Truly 3D characters will store the characters as 3D meshes, to be given to the 3D hardware as sequences of textured polygons. The viewpoint camera is tweaked to match the parameters implied by the isometric perspective, so that the models are drawn in the correct location. The necessity of pre-rendering different facing directions is removed (thus vastly reducing the amount of memory needed to store a character), since rotation of the character is performed simply by applying rotation to the character's orientation matrix. The 3D hardware performs the rotation, and it is not necessary to limit to 8, 16 or 32 facing directions.

Share this post


Link to post
Share on other sites
Does anyone know what sort of spatial hierarchy system Dungeon Siege used? I would imagine something like quad-trees or oct-trees would have worked well. It's quite a heavily CPU-bound game though; it chugs on my Celeron 766 with GF4, whereas NWN is mighty smooth (although NWN is more of a "room"-based engine and you only have a party of two).

cheers
sam


Share this post


Link to post
Share on other sites
Wow! Thanks for the great info guys! I'll check out that tutorial as well.

Here is an algorithm that I made during Chem class. Its not final, and needs some work, but does it look more or less ok? Or have I completly missed the boat? ;)
http://www.members.shaw.ca/BradenC/1.jpg
http://www.members.shaw.ca/BradenC/2.jpg


Also, how do you have objects that are larger than one tile?

Cheers

Chris

Share this post


Link to post
Share on other sites
Those are some pretty large images. [grin] Tell you what... why don't you go ahead and make a small test application to see if it works?

If you read through the archives of the Isometric forum, you'll see exactly how tricky objects larger than a tile can be, especially when it comes to drawing them. Typically, an object is 'owned' by a tile, but since it overlaps tile boundaries it is possible that it can be on a tile that doesn't own it, and thus isn't incorporated into the drawing order of the overlapped tile. Strange draw-order problems can result. Also, if the tile that 'owns' a large object happens to lie off the screen and outside of the view area, but a tile that it overlaps is onscreen, then the object will not be correctly drawn and will suddenly appear in a very ugly fashion if the owner tile comes in view.

To help with some of these problems, I allow objects to be 'owned' by more than one tile. If an object overlaps a tile, a pointer to that object is inserted into the tile's contents list. Since an object may be owned by more than one tile, I can not now simply draw all of the Contents lists for every tile in the view. Instead, what I have to do is iterate all of the Contents lists, and insert objects to draw into another list. If an object is already in the list, it is not inserted again. It is a little slower this way due to list management, but it prevents some of the wierd problems of partially offscreen objects appearing and disappearing inappropriately. I can sort the draw list from back to front so that iterating the list will draw the objects in order from back to front with correct overlap. Or, at least, mostly correct overlap. There are still going to be tricky overlap issues between some objects; browse the Isometric forum for some possible solutions to such problems.

This is one of the attractions that true 3D offers. The Z-buffer automagically eliminates all of the wierd intrinsic draw-order problems that plague traditional 2D isometric engines.

Share this post


Link to post
Share on other sites
Ya they are....Sorry, I forgot to resize them! I'm trying the test app, but am having a few issues with that, which I'm working on atm. I think that I will have to find a new way to deal with objects than the way I had previously planned... Thanks for the great info, I appreciate it a lot. I will probably be back, with commments and/or erros! ;)

Chris

Share this post


Link to post
Share on other sites
Sign in to follow this