Hi. Maybe the subject isn't descriptive enough, i had little space =). I'de like to know how many diferent dificulty levels for crossing a tile you guys think would be enough for a game. You know, a sand tile would take more time to cross then a road one, a swamp tile would take more time to cross then the sand one, and so on. Guessing a number here, would 256 be enough? Thanks.

My guess is that 256 will be more than plenty. In fact, it may even make the game seem too complicated. People like simple. If they know that there are about only four or five different movement speeds, they'll probably be happier. Of course, you could use the higher detail to smoothly transition from one basic type to another, I suppose. Like moving from plains to sand would be moving from difficulty 64 to difficulty 96, and tiles in between could have values of 72, 80, and 88, for example.

That smooth transition idea sounds great. =)

Much of it depends upon the level of detail available to you. If a unit usually only moves about a speed of "10" in the best of conditions, then having 256 levels below that is rediculous. Also, you get into the realm of lower ROI... if there is little or no perceivable difference between the speeds, there is not a lot of reason to include that level of granularity. For example, we are used to driving our cars at 65 in the best of conditions, 55 on urban highways, 45 on major city streets, 35 on side streets, 20 in school zones and 10 in parking lots. Anything more detailed than that is really starting to lose clarity and therefore becomes extra levels of detail for very little recognizable effect on gameplay.

My off-the-cuff suggestion is to use 8 or 16... anything more is probably overkill.

Just to clear something up...

This is just for a library so i want to know how many are enough for any game, i'm not actually going to implement them, i'm not going to implement anything. =)

I just want to know how much margin of manuverability i should leave for developers who happen to use it.

But hey! Thanks a lot for the input, i was actually thinking of supporting up to 65536 levels, i guess i won't now. =)

If its a library, I'd say you have two choices:

1) Flexibility

I'd support costs from 0 to 1, which can then be mapped on what ever integral values you want

2) Size

In this situation, I'd say you should support "n bits" values... so costs could be stored on 1 bit or, 4 bits for 0 to 15, etc... this way you could handle it by having a "costs array" indexed by the node's ID or something...

I won't get into much more details cause they're mainly implementation details... but I'd say you should handle both. Not all projects have huge memory constrains (esp. PC games :P), and for those working on consoles, if its a target audience you plan to please, I'd say implement also size optimizations.

If you still want to be able to tweak your costs, while only having say, 2 bits of data for each node (say, 0 = road, 1 = grass, 2 = mud, 3 = mountains), make these to be indexes to an array of real costs. This way you can assign costs of 64, 72, 88, 1024 to each of these terrain types.

I hope this helps, and I also hope I didn't read your post too fast and skipped details :)

Cheers

Eric

xEricx: Hmmm, using a 0-1 range and then mapping to integral sounds like a really intuitive way to handle the levels, i never thought of that. I'll have to think about it.