I'm not quite sure what you're getting at here. It almost sounds like you're suggesting pre-drawing the view from any given turf facing any direction at two different distances, which means for a 20x20 dungeon 10 levels deep (fairly small dungeon) you'd have to draw 32000 bitmaps by hand. Now, this system has the advantage of allowing you to draw whatever you'd like, but I'd be a bit leery of having to hand-draw 32 bitmaps of that size, let alone 32000.

Now, if you mean to generate the view dynamically based on the user's surroundings a la any classic dungeon crawl, that's a bit more sane... but you've missed quite a bit of the problem. Suppose you've got this setup:

# #
# #
#P#
###
###

A player is at P and facing south. The tile in front of them is a wall, so under your system (if I understand it correctly, and I don't) you'd draw two diminishing walls off to either side of the view screen, right? Two tiles in front of them (BEHIND the first wall) is also a wall, so you draw a wall in the center of the view screen, at a distance. The end result is that the player sees a dead end (which is good)... with quite a bit of space between them and the wall (which might not be quite what you wanted).

Now suppose you have this situation instead:

# #
# ###
#P
#####
#####

Again, there's a player at P, and they're facing south. This means that the only two tiles it will look at are the tile in front of the player, and the tile behind that... both of which are walls. We already covered this above, and so the player gets the exact same view as they did in the above scenario: a dead end, with some distance to cover.



Long story short: You need a LOT more than two views for any given possible "side" of an object. Crude ASCII diagram for a system with a view range of two:

\                /
_\______________/_
 |\            /|
 | \          / |
 |  \        /  |
_|___\______/___|_
 |   |      |   |
 |   |      |   |
 |   |      |   |
_|___|______|___|_
 |   /      \   |
 |  /        \  |
 | /          \ |
_|/____________\|_
 /              \
/                \

Even with this fairly narrow representation, you end up with 12 separate views per "side", 14 if you were to add representation for walls one step forward and two steps off to the side (picture the two side walls in the middle, sloping towards the camera). If you crop this view down so that you can only see the immediately-in-front picture and objects in the positions directly obstructed by it, you'd still have 4 separate views and it would be very, very annoying to get anywhere with such a view. Either way, that's only for a relatively short view range; if you wanted to see 3 or 4 squares in front of yourself, you have to set up even more views for each object.

That said, it's still very doable (I say so because I've done it). Never done any tests on how well it runs over a network. There are two possible approaches to displaying objects themselves: you could either give each client a set grid of screen objects which would change to display the appropriate bitmap for the spot they cover on-screen, or you could have each possible object view use its own set of screen objects and do all the displaying by adding and removing to client.screen. Not sure if the former method has any advantages; I've only tried it with the latter, and it's still a relatively slow operation if you're using a large viewscreen (there's a visible delay of a frame or two when major changes are made in the view between steps), although this could be used to make some nifty transition effects (not that you couldn't just slow it down if it was too fast). Now, the real problem comes when you get to representing movable objects such as other players; I'd definitely advise against making an action-oriented game of any sort with a system like this, even if you had a cramped little viewscreen that could be updated quickly.

Ter13 wrote:

okay, like a solid object would have a var that declares it solid, and have seperateable graphics, like if you want a 1 aquare ahead, A-type view of a long stone corridor, and beyond that is another stone corridor, you would have two types of that turf, a big, up fron one with a hole in the center for a B-type turf, and then a small one, to go in that hole, so you wouldn't have to draw 320000+ plus tiles, just have to give the turf four variables, like Northimage, southimage, and so-on, each displaying that image if the user faces north or south, or whatever... but in reality only having 50-100 images... still a lot, but hey, It's a big concept...

You seem to be implying using prerendered images for every view in the game, in which case breaking it down into near and far views seems a bit pointless--since you couldn't draw any of these views at all without prior knowledge of the map, I don't see too much advantage in breaking them down in such an arbitrary fashion. You gain the advantage of less work to change a view, if you don't change any of the surroundings. Unless you want to role-play someone with very severe tunnel vision, you're going to have to take into account a LOT more than the turf a player is on and the surrounding turfs, especially since it also sounds like you're suggesting using a turf-by-turf grid rather than having each turf be a hollow grid cell with independant walls. You might as well break it down into each separate view of any object within the player's field of vision, which comes out to a LOT more than two views. The advantage of using prerendered images is only that you can freely represent whatever you want in any view, thus allowing you to go into a lot more detail and get much cooler effects without making an already bulky engine (under BYOND, anyway, or at least from what I've been able to piece together--I imagine you might be able to get it reasonably speedy if you were good enouh and worked at it a bit) heavier and slower... in which case, yes, you ARE drawing thousands and thousands of views for anything but a very small map area.

Bumparoo, ok, leftely was right, way hard, way fun... but i'll try to find a better way to do this without huge download sizes, i got a basic map going, 5X5 squares, and one monster in the entire thing, my cleanup procs aren't working yet, but i'm good.....



ANY COMMENTS ON THE BYOND FIRST PERSON FUTURE?????? JOIN IN!