Hi folks, I'm standing at the jumping-off point of a student game dev group, and I'm trying to hammer out some of the core technical details before I start tasking the programmers to start writing the skeleton of the game engine, but as I think and plan, I keep debating how to represent the world of our game. Basically, the idea was to have a game that "felt" similar to classic RTS control schemes, and had that wide-angled, isometric look to it. We want to invoke a Diablo or Gauntlet feel out of the game, from the camera and character control to "tile based" maps. However, we aren't making an RTS...squad and unit-control is de-emphasized, and the game is more of a direct-control scenario, like Diablo. Maps will have to allow for height(within reason, not wildly deformed terrain) and since the players will be in direct, real-time control of their characters, feeling like they have a lot of freedom in motion and action. So, I'm not sure which paradigm to go with. Something strictly tile-based, like a 2D game would be (1 discrete movement moves you between map tiles) is far too restrictive and would look and feel silly with modern 3D cameras and multiplayer control. But, if we completely de-emphaisized tiling and went fully-roamable 3D landscapes, it would start to act like a top-down 3D shooter, which is not the idea we want to capture. So, where do these two lands meet? Example: tiles on the screen are a discrete size, but people have the freedom to roam within the tiles, and absolutely position in 3D-space may dictate whether they are succeesfully interacting with something...and yet, within the game logic, surely they are always "in" one tile at a time. Not knowing how to approach this, I almost see two sets of logic: aboslute game logic (in/out of tile. Path as determined by walking the tiles), but "above" that level of logic is a looser set of rules that work in 3D-space(rules of interaction, wether a weapon has been swung through an enemy or not). In a nutshell, I'm not experienced with designing the full technical details of a game like this, and every time I start to think of it one way (well, lets think about tiles), I start finding all the reasons why it cant be the only way to look at the problem. If I think of it from another angle, same story. What are the questions I should be asking myself, or articles I should read or whatnot to help pinpoint some of the critical implementation details for melding this tile-based concepts into an engine that also works in true-3D? Perhaps it would be best to approach this as a strictly 3D game, but constrain movement/object/scenery/pathing/etc in such a way that invokes the "feel" we are looking for, rather than trying to meld the concepts in such a core manner? Thanks for your input.

Well, I don'tknow if I really understood what you are talking about, but I believe Warcraft III works the way you want to. Shouldn't be to hard to do it, just have a 2D tile map, and each unit has it's x, y, z coordinates. Then you use x and y (or z, depends) to calculate wicth tile the unit is standing over. When rendering the map, however, thenm you can go for 3D.

Sounds more like a design decision than a technical one.

I'd go with full-3D, no restircting movement to tiles. It would give you more flexibility, and would be easier to switch from later if you don't like it. However, we haven't really heard a whole ton about what this game is going to be like, other than it's an RTS, but not really. Mabye more info would help.

Well, I guess I'm primarily confused about the skew between the fact that things allowed to move in a 3D world are not bound by discrete movement, versus the fact that tile-based gameplay would seem to constrain it otherwise.

Taken to an extreme, lets say a tile was 6 feet to a side. According to the "tile logic" of the game, any point in that tile is equivalent to another, so it wouldnt matter if I was standing on a corner, or dead center, etc. This makes sense, for things like breaking down the world for pathfinding, basic terrain design, etc. But, in the world on screen, it certainly wouldnt make sense for me to be 6 feet from an object but still be interacting with it as if it was real.

At this point, I'm pretty much ready to ditch the attempts to try to box the idea into the tile-based mindset and go full 3D, but Im still curious about this split of ideas.

When I think of older games, like Dragon Warrior, things were obviously tiled. If I nudged upward, he walked a half inch upward. The granularity of the world was very large, and things made sense that way, because there was an obvious "here" and "there" and two things couldnt occupy the same space.
Did games just get better at hiding that?

If you play Diablo(going by memory here), the maps are clearly dvided into tiles of a certain size, but the characters and mobs seem to be able to move more freely, and their interactions dont seem, to my eyes, to be based purely on wether they are in adjacent tiles, but also on spatial rules (within swinging distance, example).

So, I find myself wondering, are they actually strictly adhering to rules based on tiles (must be adjacent by tile, etc), and everything is just pretty smooth and good at obscuring that, or is there a higher level of logic on top of the tiled game system, one that responds to the graphical representation and their spatial relationships?

Hey, thanks a lot for the info, I'll read up.

Quote:Original post by krikkit
Well, I guess I'm primarily confused about the skew between the fact that things allowed to move in a 3D world are not bound by discrete movement, versus the fact that tile-based gameplay would seem to constrain it otherwise.

If you play Diablo(going by memory here), the maps are clearly dvided into tiles of a certain size, but the characters and mobs seem to be able to move more freely, and their interactions dont seem, to my eyes, to be based purely on wether they are in adjacent tiles, but also on spatial rules (within swinging distance, example).

Hey Krikkit, here's my twopenn'th:
Firstly Diablo actually does stick to the "you're either on a tile or you're not" approach. There was a transition between tiles (as you walked from one to the other) but you always ended up in the middle of the tile, and you could only ever walk on lines that connected the centre of a tile with the centre of its eight neighbours. What you're probably thinking of is Diablo II, where you can stand and walk whereever you like. The downside to this approach is immediately obvious, as the pre-rendered animations for the main character are only for discrete directions within the possible range of 360 degrees and so, unless you happen to be walking in one of those directions, your character sort of "slides" a bit as s/he walks along. Not too bad really I guess, but it annoyed the hell outta me.

The simplest way to implement this is to store each entity's location not as a whole tile value (eg. [3,2]) but as a real value (eg: [3.25, 2.5]) - you can use floating point, or fixed point or whatever. If you need to know what tile the player (or whatever) is on, you simple drop the fractional part of their coordinates. And, as you've already mentioned, you use spatial calculations for things like hitting (eg. a short sword has a swing radius of 0.9; a long sword, of 1.3; etc). Once you know the radius, and the location, it's obviously very easy to calculate which tiles are at least partly covered by the swing.

Similar to you, I'm working (whenever I can grab the time) on a 3D-graphics based Diablo II style engine. My solution to the sliding problem is to simply do a mixture of 2D and 3D - 2D for the walls and tiles (floor), and 3D for the "objects" (ie. monsters, players, chests, dropped axe, etc. etc.). The 3D objects are rendered with an axiometric view so that they mesh with the tiles and walls which are drawn as textured triangles. The z (ie height) of an object is used for z-buffering (in an isometric view, an occluding object will always be at a higher z value than the object it's occluding), so your transformation matrix will output a vertex with changed x,y values but leave the z untouched.

Internally, though, the game entities are stored as described before (ie. real valued coordinates), except with the third coordinate, z. Currently the z value isn't taken into account in interaction between entities, although it would be easy enough to add in: once you've calculated a collision between, say, a projectile and a creature in terms of the traditional [x,y] tilemap, you could check the height of the projectile against the upper and lower bounding z values of the entity and either return a hit or a miss. This isn't proper collision testing of course - it doesn't take into account the 3D model of the entities at all (I view the 3D model as decorative, not representative of the entity). In terms of collision detection, it's treating all entities in the map as vertical cylinders if you think about it. Which is fine for the purposes of a Diablo-style game, of course.

Hope that helps in some way...

I do appreciate your thoughts, AP< and its given me some things to think about. Thanks.

The other two big replies hit on the points I would make, mainly that you should always consider the gameplay "map" distinct from the rendering "map." In your scenario, you can most certainly have a conceptual 2D map rendered in 3D, and even have a tile-based world where that operates in 3D (as the AP described).

You mentioned looking for the "feel" of a 2D game without the rigidity. One of the most influential "tricks" I've ever discovered by examining classic games was the movement of Link in the original Legend of Zelda (NES). It demonstrates the brilliance with which Miyamoto, et al at Nintendo, were able to create character mechanics that were intuitive, nuanced, and fluid on while being constrained by the hardware of the NES (Super Mario Bros. 3 being perhaps the pinnacle of this achievement).

But to the specifics: anyone looking at the Legend of Zelda (LoZ) could easily discern that it's a 2D, tile-based game. In fact, just looking at a screenshot you can break down the onscreen grid:



Image taken from ZeldaClassic.com, a spectacularly accurate LoZ engine.

This image makes the grid pretty clear. The overall screen is divided into a 16x14 tile grid (including the 3 tiles that make-up the status bar at the top of the image), with each tile being 16x16 pixels (total screen resolution, 256x224).

Now, some folks think of LoZ and imagine Link being rigidly bound to the tile grid, while other remember it being more fluid than that. In fact, it's kinda a bit of both!

When Link moves around the screen, he gravitates towards a half-tile grid. He doesn't "snap" to the grid. When you press up on the gamepad, he doesn't jump to the next tile, he moves one pixel up. And if you press left on the gamepad, he moves one pixel left. *But*, if you hold down left on the gamepad, as he continues moving to the left, pixel-by-pixel, Link will shift either up or down a pixel until he lines up with the half-tile grid (which consists of 8x8 tiles, or a grid of 32x28 half-tiles). Of course, if he's already lined up, he won't correct any.

What's the upside of this? Well, attacking in LoZ is very "discrete," in that you can only attack objects adjacent to you and you have to line up with them (you can't attack diagonally or at arbitrary angles). Most games that have discrete attacks also have discrete movement, otherwise the player ends up have to fine tune their movement to line up with the coarse grain required for attacking. This is, surprise surprise, hard and annoying.

So, LoZ's solution was the automatic "fine tuning" that I mentioned earlier. The result is that as you head left to get that bad guy, you automatically either line up with him exactly or line up in a way that you'll clearly be missing him, but you won't end up in the case where you're off by a pixel (which would be frustrating and unintuitive).

I've never found a good description of this fine tuning, but its definitely there in the game if you a play the original and its definitely there in the ZeldaClassic emulator/engine. I don't know if the makers of ZeldaClassic noticed it and re-implemented from observation, or if they reversed engineered the ROM, or if there is a discussion about it somewhere (I haven't found one). But its definitely there.

What if its not? Check out a lot of the half-assed Zelda clones out there. Basically, none of them have it (and most emulate the SNES LoZ, which doesn't have this quality, but solved it by having Link's sword swing in an arc, which gives the same result without tweaking player movement). The LoZ clones will either have rigid tile movement (you press left and Link basically plays a walk animation to the next tile and stops, like a classic RPG overworld). Or, more commonly, Link has full pixel-resolution movement, with the problem that he "snags" on one-pixel boundaries of tiles if he's not lined up just so-so.

Some rambling, but hopefully some useful info in all that...

Yes, there are 2 different ways to do 2d movement. The entire world, including the ground and the player movement works through the use of 1 grid. When you press left, the player moves from the middle of the current tile, to the middle of the tile to the left.

This is very rigid, but presents very very easy implementation.

Option 2 has been mentioned, but not explained in detail. Option 2 is to have the world be on a grid of its own and the player/objects/monsters placed arbitrarily around the screen.

Many games, such as Diablo make use of bounding boxes for calculation of Sprite to Sprite collision.

Do some searching on google for sprite to sprite collisions, and you might get a better understanding.

Specifically if you want to see it in action, pick up a copy of Starcraft and look at their map editor.

You'll quickly notice that the terrain editor uses 2:1 Isometric tiles for the ground / environment, but the items and characters are not restricted to the grid. They use a form of bounding box collisions for the creatures, and the structures use pixel to pixel collision.

Get starcraft, load it, make a map. You'll understand option 2.