Back to General and Gameplay Programming

Pseudo 3D And Eye Of The Beholder Or Bard's Tale

General and Gameplay Programming Programming

Started by Rob0Tix August 05, 2016 02:55 AM

18 comments, last by Anri 7 years, 8 months ago

13,307

August 07, 2016 02:05 AM

I was using C++. Yes the document is confusing, just stick the the part where the author builds the pseudo-3D view. How he slice the images and fit them together to achieve reusability.

While I agree with the comments that "i[background=#fafbfc]n this day and age, keeping it simple involves using modern hardware, api and engine capabilities", if you just want a simple dungeon crawler, many 3D Engines will overwhelm you with their unnecessary overhead and some 2D libraries such as SFML are quite modern and straightforward to use.[/background]

Drawing a view like this essentially requires 2 tasks: determining what to draw and where to draw it. The old methods (as detailed in that document linked earlier) perform the transformations by hand, using obtuse and kludgy rules, in order to determine where on the screen to draw a particular sprite. I've written such systems before, a long time ago. It was confusing, filled with weird edge cases and hacks, and the result was inflexible. The other way to do it is to feed some geometry and a view transformation matrix to a 3D API, and let the hardware perform the translation according to well-understood and well-defined math. It's far simpler that way. I read the document, and even taking into account the fact the author is clearly not a native English speaker, the algorithm outlined is the very definition of obtuse. I would be hard-pressed to recommend such a method to anyone at all. Although breaking the ice with 3D engines can take a bit of a learning curve, it has the advantages of: far better performance than the outlined technique, with a potentially far greater field of view; more flexibility in camera positioning; more flexibility in wall shape, structure and placement without compounding the complexity of the rendering loop (ie, curved walls, half walls, animated walls, etc.); fewer constraints on the view (ie, can look up, down, etc...), again without compounding the complexity of the rendering loop; 3 dimensional movement and level layout; and so on. The benefits of using a full 3D API are myriad; I am at a loss to think of a single benefit stemming from faking it.

If it is a question of style, you can still use the cartoony, hand-drawn sprite style. It's just that using a modern API VASTLY simplifies the math involved in drawing the view.

Accidental Noise Library
The Adventures of Goblinson Crusoe
Terrain Editor

Rob0Tix

105

Author

August 07, 2016 08:16 PM

ok, If I take the 3D route. Other than the math or api specific learning, is there an example out there for this? Any programming language.

Alberth

10,209

August 08, 2016 05:25 AM

You mean, are there more programs written using OpenGL? Yep, the Internet is full with them.

Rob0Tix

105

Author

August 08, 2016 10:30 AM

No, I mean for creating a simplified project like Eye of the Beholder, using modern 3D, compared to a full 3D application. Is there an example for something like this, such as a tutorial?

I went about 20 pages into the articles here, but there is not much related to this type of game.

Alberth

10,209

August 08, 2016 11:33 AM

I am not so sure Eye of the Beholder counts as simplified project, but you may of course disagree with me on that one :)

Assuming that "full 3D application" means that you can rotate the camera in any angle, rather than just 4 orientations, I would say: not much difference.

All your map code is fully 3D. Rooms have a 3D size, game objects, player, and monsters all walk and talk in 3D. Of course all the player and the monsters can (and probably do) walk in 0/90/180/270 degrees along the axes, which simplifies the math somewhat. They can also walk fixed distances, and you can have rooms and corridors with a size that is multiples of that fixed distance (which makes it look like you work on a grid).

The GPU (OpenGL) converts the 3D world to a "flat" screen display, so you don't have to do that.

I don't expect there to be a tutorial for it. It's just generic OpenGL rendering, except you limit camera orientation to 0/90/180/270 degrees in your game, same as the player directions. There is nothing more to it.

I went about 20 pages into the articles here, but there is not much related to this type of game.

There is probably loads related, but here we rarely talk about games as a whole. Much more often we discuss some detail problem without ever discussing game type. Most of these problems are generic, they can happen in almost any game. For example, if you have a problem with a vertex shader, extremely likely that problem has nothing to do with your type of game, there is just something wrong in the shader details that needs to be fixed.

Another example, if you use fixed distances in your game world, you can store things in a grid. Any problem there then falls in the class of "problems with maps using grid storage", without ever listing what games or game types that would be exactly (since it's not of interest for solving the grid storage problem).

smr

2,468

August 08, 2016 02:19 PM

I did a little toy project a while back that mimicked the aesthetics of these classic pseudo 3D FPS RPGs. The originals had created static images for all of the walls and doors at their various positions. I used OpenGL and rendered things as you'd expect with the API using 3D.

The difficulty in recreating the experience of these old games is that, as they were only pseudo 3D, the perspective and FOVs don't exactly conform to the physical reality that our 3D hardware was designed to model.

For example, one challenge I had was the fact that the camera position needs to actually be some distance behind the point where your character is standing, otherwise your field of view will not actually intersect with anything in that room besides the back wall (it's too close). You'll actually be viewing the next room. Adjusting the FOV to be much wider and placing the camera on the wall behind where the character was to be standing helped, but this made rotation a little wonky. Rotating the player didn't actually just reorient him. I had to both reorient and move the camera to the other wall. So, if you could imagine a circle that enclosed each room, the camera is always on the perimeter of the circle pointing in at the center. Rotating the camera actually moved it along the perimeter into one of the four cardinal directions pointing inwards. It wasn't perfect but it looked OK.

Rob0Tix

105

Author

August 09, 2016 03:05 AM

ok, I got my work cut out for me. Since my last post and your recommendations, I had another chat going back in a visual basic forum. Though, I won't want to use vb, it's still helpful to try some simple techniques out. I did my first from scratch matrix manipulation. I just rotated a single point at origin 90 degrees. It's really lot's of fun. I look at math tutorials on khanacademy.org. I previously created a vector class with some basic vector arithmetic. After all the comments, I think I will have to go full speed on 3D stuff.

Kylotan

10,510

August 09, 2016 09:20 AM

You might consider trying to use Unity for this. I made a start on a similar game and it was very quick to drop a bunch of cubes into the world which represent the houses or solid wall areas.

FFA702

163

August 13, 2016 10:04 PM

You could always try raycasting, it's fun and easy to understand. Took me about 3 days to implement the framework in C# for a multiplayer RPG i'm still working on. Gives that cool retro look and you only need high school math to understand the inner working, so it's very flexible and workable.

Anri

1,043

August 14, 2016 11:17 PM

For the more traditional approach, look directly at the game world data you will have to work with - a tile map.

1) You can only view in the usual four directions, North, South, East and West.

2) You will only view a certain amount of tiles deep in the direction you are viewing - say three or four to keep things simple.

3) You will have a drawing order - starting with the furthest tiles, and then "painting" towards the view's tile.

4) A serious issue will be considering the edges of the tile map - this will likely be less tiles than your "viewing distance" allowence....

...I'd recommend graph paper and working it out for yourself. Put yourself in the computer's position and take note of what is actually drawn in each example you produce, and what is not; what patterns can you identify? You will find, in the end, this kind of engine to be a "simple beauty", as you will only need the ability to draw a bitmapped image to the screen, and the means by which to create a tile map. However, it will require some investigation skills on your half, so patience will be required. Of course, one can use a game-creator application which is a valid method by all accounts, but this way will be personally rewarding as you develop your problem solving skills.

Best of luck!

Languages; C, Java. Platforms: Android, Oculus Go, ZX Spectrum, Megadrive.

Website: Mega-Gen Garage

Pseudo 3D And Eye Of The Beholder Or Bard's Tale

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Pseudo 3D And Eye Of The Beholder Or Bard's Tale

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines