Game maps similar to Eye of the Beholder?

[dxfoo]

I didn't know Eye of the Beholder would be considered research after all these years. But I'm curious how they designed the maps. It might help for a near future project.

Is this how it's normally done as in writing a text file with the map? For example:
W = Wall
S = Skeleton
P = Player
- = Direction facing
G = Gold chest

And how would you know the unique characteristics between one skeleton and the other if the skeleton on the upper-left is most important to set higher hit points?

No telling if this will show up correctly, but I hope you get the idea.

WWWWWWWWWWWWWWWW
W S                                           W
WWWW   W             WWW       W
W       W   W             W    W      W
W-P	W	W G W	 W
W       W	W S	W S           W
WWWWWWWWWWWWWWWW

[Mario F.]

Eye of the Beholder didn't use that system for level design. That model (slightly more complicated models than that, but essentially what you describe) have been used in very early game programming back in the 80s, and later for text-based games on the PCs all the way down to MUDs.

Map:
EOB used raytracing for its art. So the level design reflected this choice. It was still essentially a matrix that defined the game map, so you could argue it still used something similar to that. However this matrix was rather different. It was a matrix of blocks, and each block described North, South, East and West faces. 4 bytes were needed to describe a block, each face taking up 1 byte and consisting by nothing more than a pointer to a more complex C structure that does the whole describing of the face (wall type, moss, carved letters, buttons, etc).

But each block described on 1/64th of the wall. Each wall section took 8x8 blocks to be fully rendered.

This was the initial state of the game. Doors opened and closed, objects were picked, buttons pushed and monsters walked around. So, at each game tick, the world would update itself and a changes were made to the in-memory matrix to reflect these events.

Monsters:
Monsters were not differentiated inside the same family. So all skeletons were exactly the same. If there was the need to create a special/different skeleton, a new monster was created.

Rendering scope:
For purposes of the game engine, all it cared about was the player viewport. The way the level was rendered on the screen was simple. A buffer describing the player viewport was updated as the player moved around. This buffer was a simple C structure. Not much more than an array of pointers to those blocks in the map the player could see. While the game engine did update monsters movement on that level, the rendering was just concerned with that buffered viewport. Then it just raytraced everything described in that viewport.

[VirtualAce]

The first DOOM used a matrix like that to do ray-casting through the grid. To speed it up they used known constants to break the x and y raycast into two tangental ray casts. They did this b/c at the time sin() and cos() were extremely slow. Main limitation of this type of engine is it does not support 6 DOF and when looking up/down the 2D raycast falls apart. This is why most games like this did not allow the player to look straight up/down and limited the degree to which one could look up or down. Dark Forces expanded on this idea and used sectors of line segment descriptors for their walls. Essentially Ax + By + Cz = Ax + By + Cz. Using that you can find where two lines intersect and they used this along with sectors to determine the visible walls and what needed to be rendered. In both games if a baddy was present in the area it was rendered using billboards. Novalogic expanded this idea into voxel rendering and was the only company I know of to actually create a 6 DOF voxel engine. I have no idea how they did it. Games that used this engine and it's variations were: Delta Force 1, 2; Comanche 1,2,3; some early Black Hawk Down titles; Armored Fist 1,2,3. Novalogic was able to seamlessly combine voxel terrain with 3D meshes. Some of their games suffered from mesh creep in that their position was not always constant with the world which made them appear to creep ever so slowly.

[dxfoo]

Interesting. Are there any books or tutorials that teach this in depth? Aka map designing or similar.

[VirtualAce]

There used to be a tutorial at Peroxide games about how to do the DOOM ray-casting but I'm not sure it's still there. This team was working on the next Ultima and it had a well-known publisher but the project was canned later. The filename for the tutorial was pxdtut7.zip.

[Mario F.]

I also can't, for the life of me, find where I once read about EOB methods. It's somewhere on the net. That i'm sure. give it a go and you may find it before I do.

[Mario F.]

Don't you hate it when I spend time searching for something on google without any success, only to then find it with the most obvious of queries. The query you should have remembered before any other? Yeah.

Here it is: http://eob.wikispaces.com/Tools, from Google "eye of the beholder source code"

It's very interesting reading. You obviously don't have access to the actual source code. But every meaningful structure is defined in C terms and the whole process is explained. Should give plenty of ideas to devise your own pseudo 3D engine, along with the link I provided on my initial post.