Question on Token Size

[icedcrow]

I've noticed the portraits are 63x63 and tokens are 32x32 on the files that come with the software.

I've seen where tokens are being created here that are 100x100 or so...

Do you scale the tokens down or are your battle maps laid out where they are that big that a square is 100x100?

How big are you making your portraits?

[Kalan]

I've noticed the portraits are 63x63 and tokens are 32x32 on the files that come with the software.

I've seen where tokens are being created here that are 100x100 or so...

Do you scale the tokens down or are your battle maps laid out where they are that big that a square is 100x100?

How big are you making your portraits?

Well normally portrait size remains consistent - usually in the 63x63 range. Tokens (and by extension battlemaps) tend to vary a little bit from user to user depending on how much detail/transfer speed they are going for.

The "generally accepted standard" for token/battlemap size though in my experience tends to be in the 50px x 50px range for tokens, whilst battlemaps use 1"=50px type scale. This seems to give the best balance between detail and speed.

Of course maps which are not used for combat can usually be larger or smaller than that (same with shared images).

Not really sure if that answers your question or not - but those tend to be what I notice as being the "standards" :)

[icedcrow]

It gives me something to go off of yes. Xorne stated he uses 100px and when I saw the size of a 100px, I realized the maps would not show a lot at that size.

[Xorn]

Note that I use 50 px/sq maps. :) I just like the bigger tokens so that when I'm zoomed in on a smaller area of the battlemap, they look sharp still.

[icedcrow]

How does that work though? If the squares are 50px/sq and you are running 100 px tokens, don't they take up more than one square?

[Kalan]

How does that work though? If the squares are 50px/sq and you are running 100 px tokens, don't they take up more than one square?

They do until you use a function in the program called "token scaling". Basically once you place the token on the map, you zoom the map in until the token fits into a square. Then you right click on the token, and select "lock to scale" or some such.

Really works slick :)

[icedcrow]

That's awesome! So make a 100x100 token... put it on the map where the map square would then be 100x100, and then just zoom it down?

Nice.

[ShadeRaven]

Yes, that's how it works, Ice.

I started with making 50x50 (for medium) token to fit my base grid scale of 50 pixels. However, a lot of the tokens I was creating from online images really started to lose their detail when I reduced them to so small a scale. I found that by creating 100x100 base tokens, I kept a significant amount of graphic quality.

As mentioned before, once you place a token down on the map, you zoom in until the 100x100 token fits in tightly with your 50 pixel scale grid, then activate "token scaling". Then you can zoom out to a normal view and the tokens resize themselves to fit the view.

What makes this awesome is that each-and-every token you place thereafter automatically resizes to fit the current scale. It's a wonderful feature. And then when people want to zoom for a close-up on some part of battle, the details are there and the tokens look good.

Drawback, I assume, is that you are increasing the size of your token files by a factor of 4 by making them 100x100 in comparison to 50x50.

[icedcrow]

That's ok, if you are using png files, the size difference should be relatively painless.

[Griogre]

Be careful on that logic - FG apparently transfers images in uncompressed format. So it's not the file's size on disk that matters for transfers: it's the uncompressed file size. Obviously, this size *is* directly affected by area in pixels and color bit depth. FG seems to timeout rapidly on token transfers, I don't really think the designers really envisioned some of the large full color tokens some people used being passed around.

[Xorn]

/agree Griogre

I like the look of my tokens, but if they were 50x50 they would transfer a LOT better.

Why did I settle on 100x100?

Because I made 928 of them. If I decide I would rather use 50x50 down the road I can run a batch process shrink them to 50% and they'll come out fine. But if I made them 50x50 to begin with, then I don't have the option to increase their size without them being blurry and pixelated.

[ShadeRaven]

I haven't gone over 200x200, although I can imagine needing 300x or 400x eventually, if creatures of that magnitude are ever introduced.

Are the Gargantuan sized tokens of that pixel size giong to be a problem?

[Griogre]

Orcus is gargantuan. Large monsters are fairly common. Many of the high level monters are big. You really do want to play around and determine monster scale before you do alot of work. For example if you did go with 200x200 for medium monsters Orcus would be 800x800 which is bigger than the entire default map size displayed. Even at 100x100 for mediums he's still taking up more than a quarter of the map desplayed at a 100x100 grid with no zooming. This is why 50x50 mediums are more common than larger sizes. You want to be able to have most fights on the map without having to shift the view around all the time.

In forth ed in particular the players move around more and you want to show as much area as possible for the fight while at the same time having a token that doesn't look like mud.

[ShadeRaven]

I use 50x50 gridding for medium. I really didn't like how much detail was lost on token creation, though, when I set the tokens to 50x50 base, so I bumped it up to 100x100 pixels. However, they are set to fit to grid so they won't be any larger for the fact.

I just want to make sure that the token file size won't be a problem when it comes to running game sessions.

At this point, I think it's likely that I will only keep active those tokens that are potentially used in the current host file. I don't plan on having 1000 tokens always available. Hopefully, that will help with the load.