Jump to content
Site Stability Read more... ×
  • Advertisement
Sign in to follow this  

2d first person basics?

This topic is 2947 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts


So yeah, as the title suggested: classic first person perspective (in the vein of games like Eye of the Beholder, Realms of Arkania 1, etc.). How are they made possible? I figured it would probably go something like print ceiling, print floor, work your way from back to front and check if there are any walls blocking the view, then insert interactive objects like chests and so forth. Is that close enough? Links to some educational material would be greatly appreciated.


Share this post

Link to post
Share on other sites
Eye of the Beholder could be done using just static images. Have images for each wall/floor/ceiling type when viewed from any 90 degree angle and combination of joining walls (there are not that many) and then just select the appropriate images for the five sides of the view cube.

If you want to take it a step further, many early 2.5D games used ray casting. This here tutorial gives a good introduction (I used it to implement a simple ray casting engine, many many years ago): Ray-Casting Tutorial For Game Development And Other Purposes.

Of course, using modern 3D hardware will wipe the floor with those old school software methods, and give you many more options smile.gif

Share this post

Link to post
Share on other sites
Yes, these games used the "painter's algorithm" which is just drawing from back to front. The order of cells (or walls) could be something like this (top down view):


Where the player is at '@' and looking towards "4". Of course, there are probably numerous other ways to set this up, depending on desired complexity, field of view, etc. For each of these cells (or for each wall of these cells) you will need to hand draw the wall images, which can get tedious (if you are not an artist). My advice is to use Photoshop, Gimp or Paint.NET to draw each wall on a separate layer as a simple polygon, so you can turn on/off various layers to be sure everything looks right. As I said, this can get tedious.

If you know something about 3D, it might be easier just to "fake" this pseudo 3D with real 3D, and have the GPU apply textures & lighting - just limit rotations to 90 degrees, etc. However, this has its own complications - you will need to build meshes for the dungeon, make sure they seamlessly fit together, and tweak the projection a bit so it looks right. It is certainly doable, however, since I implemented just such a thing in XNA as part of an exercise to learn XNA, and it wasn't hard (again, assuming programming experience and some knowledge of how 3D graphics works). The obvious advantage with using 3D is that certain effects can be added very easy - for example, you can limit turns to 90 degrees, but interpolate the camera so that it looks like the player is turning in full 3D. This is a nice effect, and is trivial to implement, but would be much more difficult in full 2D.

For the first method (2D), I don't know if you are going to find very many links - its old. For the second method, it will depend on what API you will be using.

Share this post

Link to post
Share on other sites
Out of curiosity, I pulled some of my older code for a pseduo-3d dungeon - I couldn't use 3D for this project, since it was being rendered completely with ASCII cells using a 2D "console" type library. Anyway, I ended up hand-coding up lists like this:

static int[,] pcUp =
{-2,-3}, // 0
{2,-3}, // 1
{-1,-3}, // 2
{1,-3}, // 3
{0,-3}, // 4
{-2,-2}, // 5
{2,-2}, // 6
{-1,-2}, // 7
{1,-2}, // 8
{0,-2}, // 9
{-1,-1}, // A
{1,-1}, // B
{0,-1}, // C
{-1,0}, // D
{1,0} // E

which stored all of the potentially visible cells for a facing direction in coordinates relative to the player (compare this with the top-view exhibit in my last post). Then I would use these lists to build an array of cells (in actual map coordinates) each time the player changed his position or orientation. Then it's simply a function of looping through each of these cells (in back-to-front order) and drawing them. I had to set up a separate series of coordinates for the destination coordinates of each wall so that they get drawn at the correct spot on the screen.

For features such as chests, doors (and the ubiquitous magic fountains, which every good dungeon needs), I had to have even more lists of static data. There were special corner cases that had to be handled, such as where to position doors - I cheated and set up the dungeon so that features were always visible only when directly facing the player (never off to the side). I also had to have hand written data for "depth" so that I could use that to dim the color for more distant objects, producing a cheap lighting effect. I never got around to drawing ceiling or floors - these would have taken even more hand-entered data. Most of this I worked out before hand on sheets of graph paper.

Note that even all of this is a simplification in that entire cells were considered either walls or clear. Some of these older games had each wall (north, east, south ,west) as separate components. If you went this route, you would have to come up with a way to store both cell and wall coordinates in the map data structure, and would probably have even more drawing/static data to set up.

Tedious indeed!

To compare, for the XNA version of all this, the hardest thing (for me) was figuring out how to get the texturing to look right. I wanted each floor cell (and wall) to alternate textures, so that when moving down a hallway, each position looked a bit different. This added to the illusion of movement. Again, this is something I eventually worked out on graph paper, although in hindsight it may have been much easier to just mirror each wall/floor texture in Gimp. In all, even considering I was basically learning 3D techniques and XNA at the same time, it seems like it was still easier to get something going using 3D than the previous case. And the best part is that changing the look of a dungeon is a simple case of swapping 1 wall texture and 1 floor texture. I would never have to open up a paint program again - but like I alluded to earlier I am horrible at art

p.s. Does anyone else feel like they have to do battle with the editor every time they paste code here? Hopefully I'm just doing something wrong, but I'm starting to dread entering code blocks...

Share this post

Link to post
Share on other sites
Thanks for the responses!

Use of 3d is out of question since the language isn't up for it. I guess I can simplify things a bit (since I'm horrible at art too :D) by reassuring that there will be corridors only (no open space like a 3x3 room) and limiting the variation in wall textures for starters. What may be feasible too is to create a wall cube (that is left wall - front wall - right wall attached together) and place& scale it according to its position instead of handling every wall instance separately but I will have to think about that.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!