[Jihgfed Pumpkinhead]

[Oops, this should have been in the new technical forum. Sorry.]

Call me unimaginative or inexperienced if you like, but I've never really thought about doing an RPG without a tile-based map.

But I was working on my map editor, and kept bumping into memory constraints. Sure, I haven't optimized at all, but I also haven't included nearly all the objects I want to have in my map. Currently, I take the image I want, and split it up into a bunch of tiles, load those tiles in, etc. So instead, I was thinking I could just draw the image straight to the screen. This will make it easier (I think) to start loading images on the fly, if I need to; also, the amount of compression you can do on a large image puts to shame the amount you can do on a tile.

So, since I imagine the graphical style of the game will mostly be large objects on single colour background (example), I was thinking the map file could just consist of a list of object ids and locations, rather than a complete list identifying every location on the map.

Then, to draw the map to the screen, you just search it for all the objects which are in, or extend into, whatever the screen area is. You'd have to cap object size at some arbitrary number to keep the search from getting out of hand.

The search seems to lend itself to some "two-dimensional tree" sort of search, a concept so deeply insane I can't even begin to envision it. I suppose I could keep two trees, one for x and one for y co-ordinates, and look for inter-sections, but that seems sort of kludgey.

So that's what I'm thinking. I imagine collision detection becomes a real pain for non-square objects, but I guess I could compose such objects out of smaller square ones. This is also really only worthwhile (I think) for maps with a very prevalent default terrain.

Anyway, I'm sure stuff like this has been done (unless it's a really bad idea, which is possible), I just don't know where to look for information on it. I just came up with it, so I'm not too attached to it, and so please feel free, encourage even, to bash it about however you like. Better you point out the problems to me now than I figure them out after having been working on it for weeks.

Thanks a lot.

[Ninkazu]

This should help:
http://www.qbasicnews.com/articles.php?id=6

[ThousandKnives]

I've contemplated a similiar idea. I was once considering using a combination of tile and non-tile data actually. Tile data for the "field" (grass, dirt, paths, water, etc) and the "overlay" data (trees, rocks, cliffs, etc) would simply be a position-independent linked-list of objects.

Which is pretty much what I already do for (what I call) "map objects" (interactive/moving things), this would simply extend that method to "dumb" map objects.

The only performance issue I can see is when you have a large-sized map with a lot of objects present on it, you will have to sort through a rather long list of objects to determine which ones are on-screen and which ones arent. You may even need to fumble through the list multiple times if you are going to "layer" the objects (There may be a way around that though).

I mean, you arent likely to have hundreds of villagers on a map, but you are much more likely to have hundreds (or even thousands) of trees/bushes/plants/rocks.

Just my thoughts on it. I think it could definately work though.

[Mobius]

what would be good also is to go even farther and add Red Alert/Starcraft style map editing so you can have both single tiles and "blocks" to create maps
_________________
It is best not to meddel in the affairs of dragons for you are crunchy and taste good with a varity of condoments.

[DeveloperX]

[Nephilim]

Well, I think the idea is certainly feasible if you organize it correctly, and it certainly seems like this sort of engine would be better suited to what you are envisioning, which goes a long, long way towards justifying spending time investigating it.

I suspect that you will get a lot of development advantage if you can narrow down your requirements in certain particular ways from being arbitrarily sized and placed images.

For instance, having a maximal size for a graphic would allow you to make a very quick cull of objects outside the visible extents based on an x or y sorting because you could compute the range of elements to consider. For instance, if objects can get no larger than 100x100, then you only have to check items whose registration point is between the left x minus 50 and the right x plus 50. (Of course, depending on the number of tiles you have, it might be faster to just skip directly to the rect intersection test for each tile.)

Another good way to define a dividing line of when to break something up into multiple tiles would be a requirement that the boundary definition for the tile would be a convex region, and then store that convex region to the tile. That way, when you draw your screen, you automatically generate a list of convex regions which define whatever boundaries you need to check against.

Let us know what you discover in your investigations - I'd be interested to hear your experiences.

[DrunkenCoder]

did I hear anyone say quadtree?
no?
google it...
_________________
If there's life after death there is no death, if there's no death we never live. | ENTP

[BigManJones]

Yep, I was going to suggest that using some typically 3d oriented algos squished down to 2d would be worth looking into. Although I don't have experience with quadtrees myself they will allow you to divide your scene up into visible/nonvisible bits. Also, using line intersection test for collision detection would be neat (again, I've never done it.)

If your going to be using pathfinding, have irregular shapes and maps will make using the A* algorithm very difficult.

[The Anarchist]

DeveloperX: You know, thats pretty much what I thought when I spent a little time thinking about how FF7 worked (I do this to almost all my games, which now I come to think of it is pretty sad). The scrolling on the visible layer only corresponds to how things are moving in the virtual layer, and wether or not you've crashed into a virtual line. Although, having said that FF7 had some parts where instead of straight forward, scrolling up and down, the character would be 'walking into the distance', in which case the method might not work in the same way.
_________________
Some may know me as MidnightDreamer... time for a namechange.
blackgc.f2g.net

[DeveloperX]

[mandrake@rpgdx]

[twinsen]

Well wasn't the whole reason tilemaps were used was because of memory restrictions back in the old days. Nowadays computers and video cards are fast enough and have enough memory to do away with tiles- why should we have to put up with boring repeditive graphics anymore? I agree- death to tilemaps. Oh well, thats my two cents- feel free to abuse me if you feel strongly otherwise :)
_________________
Lovely girls & great prices always available at CLUB 859, 859 Glenhunly Road, Caulfield, Open 10am till late 7 days. +61-3-9523-8555. (Sorry, it was in front of me in the newspaper, I just had to use it as a signature!)

[Ninkazu]

I feel strongly otherwise, because I can't do graphics as impeccable as Baldur's Gate! :P

[twinsen]

[DrV]

hehe... $0.02... nothing certain but death and taxes.

But I think tile-based maps are good, for a few reasons:

1. The graphics don't take up a huge amount of space (tilesets can be relatively small)

2. Collision detection and the like are easier to program

3. It's not really that hard to write a p*p scroller... ;)

but like you said, it's kind of a matter of opinion.
_________________
Don't ask no stupid questions and I won't send you away.
If you want to talk fishing, well, I guess that'll be okay.