Hi everyone. I bought Tan''s book not too long ago, and it''s got some great content. Unfortunately, Tan left three very important things uncovered: line of sight, elevation, and sloping tiles. While elevation is simple to achieve, LOS is far more difficult to do properly, and I still haven''t found the proper way to handle sloping tiles. Which brings me to my question: how do I handle sloping tiles? Mech Commander and Rock ''n Roll Racing are both great examples of isometric games that use sloping tiles. The vehicles in both of these games react to the slopes appropriately. I''d like to achieve this in my own project, but I''m not quite sure how. Let''s see if we can''t find a solution right now. We''ll consolidate our slopes to a preset number of directions and grades-of-incline. Let''s use the four intermediate directions (NE, NW, SE, SW) and three grades of slope (30, 45, 60 degrees). This means we end up with 12 possibilities. It would be enough to hard-code these 12 slopes into our engine. When we want to determine the height of any object on a sloped tile, we could take the four corners of the tile and use them as vertices for a quad, and then simply find where the base of the object intersects that quad. Of course, I don''t know how to do this, and surely there are better ways than bringing analytic geometry into the equation. If anyone has any useful ideas, please send ''em my way!

I've never done an iso engine before, nor sloping tiles for that matter, but what I would do is determine the maximum height that a game map could go to. From this I would then create what I would call height levels.

You can ditch the whole concept of having to compute anything. It's really not that tough of a problem. What we do now that we have a concept called levels is we label level 0 as ground level (or the lowest level) and we label main flat levels as multiples of four. We'll call the levels that a flat tile OR a sloper can reside on a "main level" and the level that ONLY an incline can reside on a "sub-level."


This means that we have flat levels at ONLY 0,4,8,12,etc. Don't worry about exact 45deg/60deg/30 deg stuff. It is much to complicated and the user will never measure your angles and this should be close enough. With my method they actually come out to be like 45deg, 22.5deg and 11.25 degree's. You could modify this system for 60 degree one too I suppose.

Draw a diagram to help with this next part. Now in between main levels we have sublevels. Sublevels are levels that slopers can populate. A 45deg sloper would span from level 0 to level 4 and that would be part of its definition. A 22.5deg would be from 0 to 2 and a 11.25deg would be from 0 to 1.

As you pointed out, you have 12 possibilities of tiles plus one type for flat tiles. Now when you do your map you don't store pictures or anything like that in the data structure. You actually store a struct object in each cell(structure or record or class) containing the tile type (on of the 13 tile types, the sub-level, plus a way of referencing the image, etc.)

Now flat tiles ALWAYS reside on major levels (0,4,8,12,etc) and slopers can exist on main or subtiles.

What you now have is a 2D representation of the game map stored in a datastructure. Now when you actually draw the map you start at the top left and draw the map cells from left-right top-bottom. Lets say that tile [0][0] is the top left block and it is flat and at height 4(4 sub levels higher than ground level but only one main level higher than the first main level.)

This means that in order to make it down to level 0 in only one square we have to have a 45 degree sloper. This means that cell [1][0] is a 45 degree sloper and it is at level zero. In other words, its right side touches the main level of zero and its left side touches the main level of 4.

Now abstractly envision that four sublevels in height is equivalent to the length and width of 1 map cell. Hence, the 45degree sloper described above spans 4 sublevels in one map cell.

If we wanted to use our 30degree (22.5) slant we have to realize that it will take at least 2 map cells in between main levels to do this. So lets say we start at [0][0] again with the tile at height 4 (main level 1.) The tile directlyt to the right [1][0] is going to be a 30deg sloper at sub-level 2 (this means that it's right edge is at sub level 2 and it also means that its left edge is at sublevel 4.) To the right of this tile at map cell [2][0] we have another 30deg sloper at level 0 which means that its right edge touches main level 0/sub level 0, which is what we want and its left edge touches sub level 2. As you can see we then make a flat tile at [3][0] and we have our 30 degree sloper(series of two) between the two main levels.

The same can be done for the 15 (11.25) degree slant you just do the same thing, but realize that there has to be 4 map cells in between flat tiles.

In case you haven't noticed, this way of doing things requires a power of two more tiles between flat tiles as you get smaller.

Now if you want to go with four types of inclines you'll have to expand your sublevels to 8 per main level. This would mean that the first level where a flat tile can be is at sub-level 0 and the second level where a flat tile can be is at sublevel 8.

Now if you did this you could get another smaller level of incline of approx 5.625 degrees you'd have exactly eight sloping tiles of 5.625 degrees each between flat levels.

So you see you need: 2^x map cells between flat tiles as x (the number of tile subdivisions divisble by two) increases.

x degrees : spans y sublevels : z map cells between flat tiles.
45 : 8 : 1
22.5 :4 : 2
11.25 :2 : 4
5.625 : 1 : 8

Notice also that z is the number of sub-levels required per main level if you want to support inclines of that height. So if you want 4 levels of inclines, you must have 8 sublevels per main level.

In order to envision this correctly take piece of lined paper. Draw a square that is eight lines tall and eight lines long. Now draw a line from the lower right corner to the upper left corner. Now draw a line from the lower right corner to the 4th line on the left edge. Now draw a line between the lower right corner and the 2nd line on the left edge. Now do the same between the lower right and the first line on the left edge. Now you can see the system. You're looking at the tiles in the x/z plane, or the y/z plane (x/y being the plane that the map cells sit on, z being the height.)

Ok this is bordering on overly complex so I'll leave it there. There may be a much simpler method as well.

I hope this works for you. If you do a binding of sub-levels to pixels you can figure out exactly where to draw your extras like pc's and npc's, etc.

RandomTask


Edited by - RandomTask on May 15, 2001 1:27:51 AM

Actually there''s a solution even simpler than that.

The solution allows for nonsymetrical tiles, wells within a single tile, hills, walls, ladders and pixel pefect collision detection in real time. All in less than 250 lines of code. It requires as much code to do a wall as it does to do all the above.

I''ll eventually post a tutorial at my site but I think it''d be more interesting to see what kinds of solutions could be used to achieve the same results I did.

You just have to think 2 dimensional.

Ben
http://therabbithole.redback.inficad.com

I suppose I should just come out and tell you what kind of project I have in mind. Being a die-hard childhood fan of Rock n'' Roll Racing on the SuperNES, I want to remake the game and improve on its shortcomings. The maps had ramps that would launch you into the air, which is something I must duplicate in my own version.

The cars reacted fairly realistically to inclines. That is, they would sail through the air based on the speed at which they hit a ramp, and they would stop moving if they did a nose dive into one. Each car is going to need some velocity and orientation data if I am to recreate this aspect of the game.

However, one of the greatest things about RRRacing was its graceful simplicity. The designers managed to squeeze a passably-realistic physics model through a 3.58 MHz processor without any slowdown or visible glitches. (Turning and smacking into walls was not handled realistically, but we''re only talking about ramps for the time being.) As I would like to support up to eight players per network server, fast physics code is a must.

I like Random''s idea for separating the track into levels, but this doesn''t offer a solution to my problem. My problem is, how do I determine the exact elevation of an object at any given point on a sloping tile? Using our 12 tile types, we could embed this into the engine as a lookup table. If we do this, another problem arises when we want to add more slopes to the engine. We''ll have to rebuild the executable, rather than let the game engine do its own calculations based on map data.

I''m thinking about scrapping the whole "tile" idea and just using sectors to represent the track. I''m not sure if this would make things any easier, but it would give me another way of looking at the problem.

I use D3D (version 7 thank you very much) to do ISO tiles. It couldn''t be easier to do elevation. Just change the Z coord of the points.

Plus the framerate''s faster, I can do hardware alpha, lighting, and other effects not possible with 2D.

-M

That''s where with my solution slopes aren''t hard coded and never need to be defined really. I have near infinite possibilities when it comes to defining how a character moves over a tile and never have to touch code to do it.

As for the physics, you''ll have to work in X, Y and Z velocities and constantly apply gravity to the Y. There would be no special code for ramps.

Ben
http://therabbithole.redback.inficad.com