Would anyone know if Baldur''s Gate uses a tile based engine? The Infinity Engine doesn''t look like any tile-based engine i''ve seen. It looks more like a pre-rendered map with sprites blitted all over it to represent buildings and other objects. In any case it looks quite good. If anyone could provide more information on the technical details of the engine it would be much appreciated. - iTCHY

I think it uses huge bitmaps for the background.
It''s not normal tile-engine

Yep it looks like it to me. There''s now way it could have been solely tiled judging by the amount of detail it shows.
Are there any inherent problems associated with this sort of engine. Apart from the obvious advantage of allowing the construction of detailed scenes I would assume that path finding would be easier using this engine (ie using masks to "paint" walkable regions) although the quality of the pathing will vary. The obvious disadvantage would most likely be the amount of work required to generate the scenes. Baldur''s Gate must have at least 150+ scenes and a lot of these scenes are several screens in size.

Well it came on 5 CDs so I guess the artwork was pretty heavy

I mailed Bioware and asked a couple of weeks back (it was about pathfinding then), and they answered that it''s a huge bitmap with a grid on top of it. This grid contains information on the terrain type, which is used for footstep sounds and pathfinding. I suppose they have a polygonal structure in addition to this which identifies doors, items etc.

So I guess the path finding would be handled similarly to a normal tile-based isometric game. The path finding was a little bit jerky as well although I don''t know the algorithm used. I had previously thought the path finding was handled by regions as in some adventure games.

I''m interested in finding out how the large bitmaps for each scene was constructed. I figured it would be possible to use tiles for repeated objects such as the ground and perhaps use smaller bitmaps for other objects like houses and trees. These object bitmaps could be blitted to repeat them as well. Although it appears that they were drawn as a large bitmap sliced into smaller quadrants.

Looks like I have more ideas for my little project then =)

-iTCHY

I''ve always thought that the biggest two problems with "huge bitmap" engines are:
1 - the size of the finished product (BIG!)
2 - Its difficult to make maps very dynamic. When relying upon pre-rendering, its hard to blow down walls and things!

The pathfinding algorithm they use is A* (check Amit''s game programming page for details).

Well, I''m under the impression that the background is really a single bitmap, no tiling, for ground or anything. As for construction, probably just modeled in a 3d modeler, rendered at a huge resolution and using a parallel projection. The major problem involved is the storage of the bitmap in memory.

BG is not very dynamic, I suppose the dynamic elements like doors and chests are handled so that a rectangular rendering of the second state of the item is pasted on the original background.

Anon''s idea of constructing a huge background at run time using tiling is rather interesting though.

How would you go about coding the bit that using a static background bitmap, to accomplish a 3d feel the characters themselves have to be drawn partially rasterized if they are supposed to be behind something? Destination color keying using a secondary bitmap stating that a background pixel is ''in front'' or ''behind''?

As far as I can tell from Baldur''s Gate screen shots (I''ve never played the game) it is nothing more than a King''s Quest graphic adventure with REALLY GOOD GRAPHICS. I would suspect the image is rendered in the following order:

1. Draw background layer / backdrop which is the scene.
2. Draw object layer, which are boxes, keys, rocks.
3. Draw player layer, which is the player and NPCs.
4. Draw wall layer / roof layer, which is anything that overlaps the user.

Using dirty rectangles, the frame rate of this kind of game would exceed isometric diamond tile games (fewer number of blits per frame).

As for path finding, they might use a 1 bit alpha channel and path find through that. The alpha channel would be all the areas the user can walk to, and all the areas he cannot. This can then be put through an A* algorith or something similiar.

The alternative might be a regioning scheme where the user clicks on certain regions of the screen and predetermined paths are then looked up (how do I get from point A to point B - I use Path AB) and executed. Some of the Sierra games were like this. The user thought they could go anywhere, but clicking on certain objects / locations would execute a predetermined path.