Map Size Discussion [OLD]

[Dormouse]

--Split from Development forum by Halebop--

[No connection to Dundjinni?

Not coincidentally, this map size is exactly the same size as maps produced by the wonderful mapping application Dundjinni (see the Links & Resources page).

There may be no 'official' connection. But that says there is

It certainly seems connected to me. The map size is limited to the very limited DJ map size & exports from other progs have to be calculated to fit.

The current map size also does not make best advantage of widescreen monitors.

[Dormouse]

I havent looked. But crappy EULAs are enough to scare me away from anyone. Especially when potential money is involved. Though their EULA is toned down from the first draft IIRC.

At some stage, you might want to have a look at Dungeonforge.

It is still lacking features in comprison with Dundjinni, but is in rapid development. Maximum detail is currently limited to 128x128 pixels (DJ200x200), but the next version (due January) will have a maximum of 500x500. It can also produce maps in 61x61 - the BRPG size leaving no need for conversion.

It can produce maps up to 200x200 cells (DJ 32x40), and is fast and flexible. It can use a variety of the common image formats for its objects and tiles (png, bmp, tif, gif, jpg) including DJ user art.

It is free and there is no EULA.

It's been very usable since its first alpha, and is best regarded atm as being in fairly perpetual beta.

[Kepli]

Sounds good Dormouse, I think I'd like to look at the program myself.

But ... eh ... you still can't use Fluid art to make commercial maps. Using another program doesn't change that. You still depend on the user-art. What I mean is ... I still don't get the point about people hating DJ for the restrictions in the EULA. There are numerous good programs out there that will let you create great maps. The png-art you can use is the same for all of them to make commercial maps. You either use DJ or another program to do it ...

[heruca]

Once BRPG has had a chance to mature a bit, I'll bump up the maximum map size to whatever RAM will allow for the average user. A 200 x 200 cell map at 61 pixels per cell is 12,200 x 12,200 pixels (at 72 dpi, that's over 14 square feet of map!), and will take up a LOT of RAM! (anyone who feels like figuring out roughly how much RAM that would take is welcome to)

Another issue: Let's suppose I were to double the current map size. Would you be willing to wait four times longer for maps to load? If I were to quadruple the map size (to approach DungeonForge sizes), would you be willing to wait 16 times longer each time you swap in a new map? And don't forget, in an online game, these maps need to be transmitted to the other players.

The map size is limited to the very limited DJ map size & exports from other progs have to be calculated to fit.

1. The BRPG gameboard size is already larger than most plastic battlemats, so I wouldn't really call that "limited". Do people really use multiple battlemats in their face-to-face sessions to get a bigger playing area? You'd need a pretty big table to do that.

2. Even DJ maps need to be resized (to 61 pixels per square) to work in BRPG.

[Dormouse]

What I mean is ... I still don't get the point about people hating DJ for the restrictions in the EULA. There are numerous good programs out there that will let you create great maps. The png-art you can use is the same for all of them to make commercial maps. You either use DJ or another program to do it ...

I did notice a lot of people have objections to the Fluid EULA from the very first, and it did then get watered down. And if you do produce commercial art, you would not want inadvertently to use anything by Fluid & may be better never to have it at all.

I think that Dundjinni has a lot of very good features & that its user community has transformed the possibilities in RPG mapping.

What I don't like about it is that it often huffs and puffs and asks you to wait a while - I suspect this is due to the Java and possibly less than optimal coding. I doubt it's easily fixable.

Secondly, it is very rigid (map size, dpi, file system) and I often want to do things differently.

[Dormouse]

Once BRPG has had a chance to mature a bit, I'll bump up the maximum map size to whatever RAM will allow for the average user. A 200 x 200 cell map at 61 pixels per cell is 12,200 x 12,200 pixels (at 72 dpi, that's over 14 square feet of map!), and will take up a LOT of RAM! (anyone who feels like figuring out roughly how much RAM that would take is welcome to)

Another issue: Let's suppose I were to double the current map size. Would you be willing to wait four times longer for maps to load?

I think the essential issues are perception and flexibility.

Currently, I think BRPG will create the perception that it has been devised to fit DJ maps. This will attract DJ users, but may put off adherents of other mapping systems.

Secondly, the more flexible BRPG can be the more users it will attract. Some may want a very large map (I understand that CC2 has no limit, & the DF limit is meant to be so big that no-one would want to go beyond it); some may want a long narrow map of the same size; some may want lower dpi (a lot of DF users prefer to work in DC scale which is 20x20 pixels) and have bigger maps; others might want 200x200 pixels per cell (the projector users?), but they might all have a use for BRPG. Flexibility gives users to pick their own settings, it doesn't mean thay will all chose to max out on everything.

[Steel Rat]

Didn't want to turn this into a mapping program discussion, but CC is coming out with a raster graphics version that promises to allow one to make maps every bit as beautiful as DJ, probably moreso becuase I'm sure much less postwork will be required, and CC has infinitely better symbol and map control.

[Dormouse]

Didn't want to turn this into a mapping program discussion,

BRPG needs to take account of the mapping programs available unless Heruca wants to limit its market. If CC3 (?) takes off, what implications does that have for BRPG?

My basic suggestion to Heruca is that he make BRPG as flexible as possible so that it will be suitable for all the mapping programs including new ones coming out.

[Steel Rat]

Didn't want to turn this into a mapping program discussion,

BRPG needs to take account of the mapping programs available unless Heruca wants to limit its market. If CC3 (?) takes off, what implications does that have for BRPG?

My basic suggestion to Heruca is that he make BRPG as flexible as possible so that it will be suitable for all the mapping programs including new ones coming out.

I think, Dormouse, that you're contradicting yourself when you say BPRG needs to take account of the mapping programs, and then saying it needs to be as flexible as possible. I would say it needs to be ignorant of any mapping program and just let you import any supported graphics as long as RAM can handle it.

[Dormouse]

That depends on how much control you have of the grid. ATM the grid is set to 61x61 pixels with a map size maximum of 40x32 cells. You can import a graphic from anywhere but what matters is how it can be used in BRPG. The grid is critical because all the functionality is based on it.

[Steel Rat]

That depends on how much control you have of the grid. ATM the grid is set to 61x61 pixels with a map size maximum of 40x32 cells. You can import a graphic from anywhere but what matters is how it can be used in BRPG. The grid is critical because all the functionality is based on it.

I agree, which is why many people requested a customizable grid within BRPG. Since you can scale the tokens, if the grid is part of the map then you turn of snap to grid and scale the tokens as needed.

[Dormouse]

But the token movement is governed by the BRPG grid rather than token size, isn't it?

[Dormouse]

Didn't want to turn this into a mapping program discussion, but CC is coming out with a raster graphics version that promises to allow one to make maps every bit as beautiful as DJ, probably moreso becuase I'm sure much less postwork will be required, and CC has infinitely better symbol and map control.

Do you have any idea on when info on this is due out?

[Steel Rat]

But the token movement is governed by the BRPG grid rather than token size, isn't it?

Probably so, not sure.

[Steel Rat]

Do you have any idea on when info on this is due out?

No idea. A friend is beta testing for them and has shown me some output, that's about it. he says the interface is largely the same, just more options graphics-wise.

[heruca]

But the token movement is governed by the BRPG grid rather than token size, isn't it?

Yes, units are moved one cell at a time, regardless of the unit graphic´s size. At the moment, those cells are hard-coded as being 61 pixels wide. All base graphics, AoE overlays, halos, etc. are based on this size, so it isn´t likely to change very soon. However, the supported grid size (32 x 40) can easily be increased, and probably will be soon.

So in effect, ALL mapping apps are supported, as long as you resize your map to 61 pixels per cell. This must even be done with DJ maps.

I have no intention of limiting BRPG´s userbase to just DJ users, Dormouse, so you needn´t be so concerned. Give BRPG a little time to grow and develop.

[Gwindel]

One of my ideas for using BRPG for my rpg games was to scan and import the maps given in the scenarios (with a passage through photoshop to give them a more interesting look).
If the cells are 61X61, I can do it by resizing the map to have it that size. But as some of the maps have already a printed grid upon them I should have to turn the BRPG one to transparent.
The only kind of map that wouldn't work this way would be the isomorphic ones (skewed squares gridded). Maybe I can do it work with half moves. I'll try that one.
By the way, I am mostly using a powerbook, which means that I have no number pads and that I make all numbers by using shift+number; would it be possible to have the half move command other than the shift? Though it is not a critical problem.

[Gwindel]

I did made some tries with grids and maps and I would like to know if it would be possible to have two flavours of hex-grids?
From the hexgrids that are included in the beta versions and from the screenshots, it seems that the hex grain (the lines of hexes) are horizontal. Would it be possible to have also vertical hexes lines?
The reason is that it would be possible with the mouvements on that kind of map to use also isomorphic maps, because isomorphic square centers are placed in an hexagonal pattern.

[heruca]

Not in the initial release, I'm afraid. Perhaps not even until version 2 (which I'm hoping will also have the ability to handle offset square grids -- that's where every other row is "indented" by half a square, and looks sort of like a brick wall).

[heruca]

But I should also add that this capability may get developed for the initial release of "Battlegrounds: Wargame Edition", and if so, it may be a fairly simple matter to reuse that code and incorporate it into BRPG.

[Gwindel]

Indeed, it would be much more useful for the wargame edition. If people want to translate their favourite boardgame to Battlegrounds, they could need it.