[crossfire] House sizes

[Mark Wedel]

Yann Chachkoff wrote:

>> At some level, it has to be assumed that the outside scale isn't completely
>> uniform - a player isn't as high as the town walls, etc.  Instead, I think
>> we need to recognize that there are different scales about.
> 
> What annoys me with such scaling - for buildings, I'm not speaking of objects
> the size of a bottle or a sword - is that it prevents abstracting the visual
> representation of the game from its logical one. So, although generating a 3D
> view (or a 2D isometric one, or any other view than the top-down 2D view)
> from the data grid sent by the server would technically be not too hard,
> those scaling issues make the result rather ridiculous :). I'm also worried
> by the risk of wasted work: who can tell we wouldn't need to change scales
> again in the future ?

  I agree - we should only do this once.  From what I recall, your thought is 
that there should still be two scales, just that scale of the buildings should 
be larger than being proposed elsewhere?

  The scales of crossfire always get weird.  If relative to the player size, 
each square, either indoor or outdoor, is somewhere between 5 and 10' (a player 
takes up most of a space, etc).

  Lets presume that indoor is on the smaller size, and outdoor on the larger size.

  In that case, a building that is 40'x40' should be 4x4 spaces - probably not 
that unreasonable as I think about it (a 40x40 building is a good size building).

  Where things get complicated are the real big buildings - that castle that 
should 200'x200' now needs a 20x20 image - that is one big image for someone to 
draw.

  And at some level, you start to get the question - should there be such a 
large monolithic object, or should it be made up of multiple objects.  You 
almost start to get to the point of maybe there should just be 1 scale at some 
point.

  So other than me rambling a bit, I guess the point to some extent is that 
scale will never really match actual player size quite right - there will always 
have to be some level of 'this building image isn't really as big as it should be'.

> 
>> If we wanted to fix all the scales, we could probably do that, but would
>> probably be a major undertaking, (...) But that also starts to get into
>> another discussion - one which we could have, but something I think we'd
>> probably be looking at more for the 3.0 timeframe.
> 
> I tend to think that it is better to handle the whole scaling issue at once,
> instead of taking the transitional route - rescaling buildings alone would
> already mean a lot of work, both graphically and 'mapically'. Fixing all the
> scales later would probably mean fixing buildings again, and thus difficult
> work on the GFX would have been wasted (it isn't as if we had a lot of
> graphists... :)).

  True - we should only fix this once.  But we should also come up with a fix 
that can be reasonably done.  If I had infinite time & resources, I can think of 
lots of things I'd like to do.  But I don't, so I have to keep things more 
modest in many areas.

  However, a discussion on what should be the right approach is really the right 
thing to do, so I'm glad for this to continue.

  As I think about, I'm almost more fond of a single scale system - that is a 
huge amount of work, but fixes all the scale issues.


> I guess that we could proceed by not changing any of the current maps, but
> building a parallel set of renewed ones (maybe linked to the old ones in a
> way or another, so that they can be tested by players ?). So that could be a
> change not arbitrarily fixed for a given release, but something that could
> replace the old maps "once it is ready".

  Yes, but my experience is that parallel releases/development is hard to do - 
the process of keeping things up to date becomes a pain, unless it is done 
enough for people to use it, you don't get feedback, etc.  OTOH, SVN makes 
merging a lot easier than with CVS, so keeping branches up to date would be easier.

  One thing on my wishlist would be basic macro/preprocessing support in maps. 
Then you could have something like a 'map_config' file like:

#define SCORN_PASSWORD rope
#define BIG_MAP_SUPPORT

  And then in the map files, something like:

@say The gate password is SCORN_PASSWORD

and

#ifdef BIG_MAP_SUPPORT
slaying /my/big/map
hp 8
sp 14
#else
slaying /normal/map
hp 25
sp 4
#endif

  Type of things - then you'd have one mapset.

  If you extend this, you could have nested #includes, stuff like:

scorn_region:
#include "global_map_defs"
#define ...
#define ....

  And so on, where the defines could perhaps be local messages for the regions, etc.


> 
> 
> 
> _______________________________________________ crossfire mailing list 
> crossfire at metalforge.org 
> http://mailman.metalforge.org/mailman/listinfo/crossfire