One Idea for Large Maps

[docplutonium]

Hey Hey...

I don't want to set your development time back or anything, but I was just re-reading your reply to my post about any ETA on the Beta release of this product and you mentioned about having issues with the sharing of large maps.

One thing you might want to check out is how Battle Grounds added the functionality of sharing maps from a URL rather then from the GM's Computer.

It's great on Bandwidth because you can send an URL to the player's clients as to where to get the map from rather then choke up the GM's Bandwidth. AND with the url sent out, each player can download the map at the same time from the url address.

This would be awesome from my standpoint where I have a web site and the space to place these files.

Anyways, just a thought and maybe you already have this, I don't know. But if you didn't, and it does not take a years worth of coding time, maybe you might want to look into this as a possible solution to your large map sharing issues.

Thanks
Doc

[John Lammers]

Thanks for the suggestion. I'll put some thought into the issue of website hosted maps, etc. I've actually been thinking about that--but as a way to allow between-session retrieval of resources. My issue with large maps is not with the transfer but with vision/line-of-sight calculation on a large map. That is, the performance of the dreaded "Goblin Behind a Tree in an Otherwise Open Field at High Noon" scenario. That's an issue because EpicTable's vision is done with masking--which makes it handle math-unfriendly surfaces like caverns beautifully, but results in a lot of needless calculation when you have a large, open environment. I need to hybridize the vision logic.

Thanks for the suggestion, though. Most of the EpicTable resources are retrieved from the host on an as-needed basis, but I'd planned on allowing you to package up resources for pre-game download. Using a URL for a referenced resource is sort of a blending of those approaches. It's worth some thought.

[Omnidon]

For me, large maps are a must. I've been nagging heruca about that throughout BRPG's development as well. ;-).

While EpicTable's ability to have multiple maps open at once will certainly reduce the need for large map support, it will not always be a satisfactory substitute. There are times when you just literally need to see the "big picture". A world map, for instance. You just can't get a good grasp of the relative distances if the map is shrunken down or viewed one piece at a time.

Keep in mind that not every map needs to use FoW, so the ability to use huge maps really should be available, even if FoW needs to be disabled when using them.

As you implied, there are also ways to cut down on the needless LoS calculations on large maps (namely, by detecting the large open areas and excluding them from the finer calculations).

As a temporary measure, you could also set a maximum view distance for LoS, so that it won't run LoS calculations beyond a certain distance from the point of view, while still supporting large maps. Obviously, simply improving the LoS algorithm would be better though.

[John Lammers]

What is a "large map"? I remember reading a post (here or on another forum) about maps representing a couple square miles and still zooming in to tactical map view. Is that the kind of "large" we're talking about?

When I talk about "large maps", I normally mean something around 3000x3000 pixels. You can do a whole level of a cavern complex or dungeon or an outdoor scene and things still look pretty nice when you zoom in. But if you're using a grid that's, say, 50 pixels per square, that's only 300x300 feet. That goes a surprisingly long way indoors or around a camp, but it's not the square mile map I've read about. A square mile, at 50 pixels per 5-foot square would be 52800x52800! Assuming 4-byte pixels, and assuming my math is correct, that's over 10GB. Now, if we're talking about textures and not images, the game changes, and the problem reduces to managing FoW rather than cripplingly large images.

What I've been thinking about is an overland map and separate encounter maps. And then, transitioning from the overland map to an encounter map with a mouse click would be cool--essentially, inter-map navigation. In fact, someone else has suggested that for staircases, etc., between levels of an indoor/underground map.

Wargamers/miniature gamers, though, might want that huge battlefield map. I see EpicTable as more aimed at RPGs than wargames, but I have to revisit FoW anyway, and when I do, I'll keep the battlefield map in mind.

[heruca]

I'm a proponent of using area scale maps to show the big picture, and switching to separate encounter-scale maps as needed.

While part of me thinks it would be neat to be able to zoom into a city map to see encounter-level detail, a bigger part of me shudders at the thought of having to map out the entire city at that level of detail. That would entail months or perhaps even years of work to do properly. GMs have more than enough work to do as it is without bogging themselves down with work that would for the most part go unused (unless your players are in the habit of visiting every single shop and residence in a city). For an MMO, that sort of work is warranted. For a homebrew RPG campaign, it's not.

[John Lammers]

I completely agree with you, heruca.
Anyone think it's suspicious that VT developers are united on this front?
VT implementation issues aside, heruca's right--the amount of work on a GM's part to map even one city at that level of detail is staggering.

[John Lammers]

This thread got me thinking about map scale, the sweet spot for VTs, and issues that arise when you step outside that space. I turned my very long-winded reply into a blog post.

[Omnidon]

I'm not one of those people who thinks you should be able to zoom in from the world map to see the entire city. :P

However, I could easily exceed 3000x3000 pixels. My personal feeling is that the program should not be hard-coded to prevent you from using larger maps.

BRPG's grid features work up to 4000x4000, but it at least lets you continue adding map tiles beyond that if you don't need snap-to-grid and such.

[John Lammers]

Point taken. And I agree with you--hard-coded limits aren't desirable. Practical limits probably are. For instance, I think it would be undesirable if EpicTable let you send (erroneously or not) a 20 GB image to the players during game time. I know this isn't what you're talking about, but I'm using it as an illustration that there is a practical limit. Certainly, it's not 3000x3000, but all players' machines will hit a limit at some point, and software that doesn't acknowledge that is obnoxious. (Take, for instance, text editors that will let you try to open a multi-GB binary file, knowing full well that they're not designed to handle that and that you've likely made a mistake in trying.)

Okay, so having said all that, I spent a good bit of time sketching out ways to handle monstrously large maps. Essentially, the practical limits described above apply to images, not necessarily to maps. That is, loading a huge image into memory is going to be a problem at some point on any machine, but having a huge map composed of smaller images would be okay. I'd just have to be careful to free up memory from parts of the map you're not actively viewing.

So, oddly, having defended the need for practical limits, I'm acknowledging that you can stretch what's "practical" by thinking of the problem differently.

Let me ask you this: for your huge maps, are these really huge images or are they maps backed by textures? Handling an infinite map backed by a texture is not especially difficult. Handling an arbitrarily large map backed by an arbitrarily large image requires trickery. And by the way, I agree with you that this trickery is warranted--you've already sold me--I'm just thinking about timing now.

[Brennen Reece]

Is there some way for ET to split larger images into smaller images which are handled separately as they are needed?

For instance, I upload a 2000x2000 map, but we are only looking at a 500x500 piece of it. ET creates four 500x pieces and only loads them into memory (or transfers them over a connection) as they are needed.

I make the disclaimer that I know nothing of coding (scripting, maybe) and this is well beyond my bailiwick.