No subject

v2 and jx shouldn't be *too* hard.

>> - "Rebootworld" will start with current faces, but 4 pixels per
>>   cell and "tall faces".  So we can design better arches, especially
>>   buildings, without drawing anything.  That will kind of kill
>>   smoothing, I guess, but we'll see how it goes.  (I don't know if
>>   smoothing + tall faces has been though of yet...)
>
>   If I follow this right, it does mean that in many cases, the number o=
f
> objects would need to be increased considerable.
>
>   I gather that in the context above, a cell would be
> equivalent to a map space (otherwise, we don't get anything be
> subdividing it).

Right, cell =3D=3D=3D map space.  Not equivalent; the same thing :-)

> So while we now have each cell use 32x32 pixels, the basic idea
> is divide that cell in 64.

Em, no.

Ok.  A human is currently 1x1x1 cells (let's assume tall faces
are already supported), 32x32 pixels.

On rebootworld with the "small" faceset (which uses the same PNGs
as the current "standard" faceset), the same human will be 2x2x4
cells (meaning, for those not up-to-date with tall faces, it's
rendered as 2x4 cells, but occupies a 2x2 area on the ground),
and 16x32 pixels, so it would use (basically) the same image.

So yes, there would be more map positions to keep track of.  Not
really more objects in the sense of cf objects.  But yes more tails.

>   Such a major division is likely to have many impacts on map
> handling.  I think further investigation is needed.
>
>   Certainly subdividing is a good thing, and does make for a smoother
> interface/look.  I just think impact/way to do it needs some additional
> details.

Did I now explain it enough?

Yes, impact needs though.  Especially in things like speed, and
having all those tails around, and how many map cells the client
and the protocol can reasonably handle.

>   How big of a viewable areas do you envision the client to display?
>
>   For example, existing client supports up to 25x25, and I
> think the jxclient uses 25x19.  From quick calculations, it
> would seem that increase the detail by a factor of 3 will
> result in either less cells being viewable, or in almost all
> cases, the end user actually downscaling the images.

I disagree, I think larger images and less visible objects makes
for a better game.

OTOH, what I think of as the "ideal" range is between 9 and 15,
so yes, maybe increasing by 3 or 4 is too much.  Maybe only 2.

Another thing to consider is that maps built for tall objects
will look more "compact".  Like, the human character's image is
being scaled by 4, but the size of a corridor or chair it fits in
only goes up by 2.

(Or to rephrase that with the "small" tileset: the human image is
staying the same size, but the human object's map footprint is
going down by half.  So those 800 pixels in the client go a LONG
way, object-wise.)

Again, the fact that some people prefer a wider view with
crappier images is a reason I prefer to keep both "small" and
"enhanced" tilesets around.  But that's academic until such a
time as I have graphic artist volunteers :-) for now "small" is
all we'll have.

>> Technical
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>> Then of course, I found that people expect that clicking on a monster
>> will attack it.
>
>   This would be more useful for directional attacks - I
> shouldn't need to be perfectly lined up on a monster to shoot
> an arrow at it - if it is one space over, I should still be
> able to do so (and likewise, it to me)

Very good point.

>> True multi-scale
>> ----------------
>
>   One time in the past, someone toyed with the idea of there
> not being multiple scales - there is just one scale.  You don't
> enter buildings, but rather they are just there on the map.
>
>   That idea has some appeal to me, especially for towns - then
> everyone is logically on the same map (so you'd see other
> players about more, etc).  I don't know if that is something
> you considered, or how it would work out, but if you're going
> to do a completely new world...

I have considered it long, and FWIW it's still on the table as a
possibility, but I'm afraid it may cause "the bigworld fail"; as
in, going from home (or the inn) to the restaurant or the dungeon
you want to hit takes ages, assuming you can even find it, until
people get bored of the game and leave.

But it's up for discussion :-)

(Like everything else... I'm running for content leader, not dictator)

>> This is really two different features on the server side:
>>
>> - All movement is slowed down proportional to the "scale"
>>   attribute of the map.  (If you think moving 10x slower on the city
>>   than indoors is annoying, bear in mind you'll probably move a little
>>   faster indoors, and outdoors you'll have transports, which I want to
>>   use more heavily.)
>
>   This doesn't appeal to me much, and probably not much to
>  other people.  I remember when we went from smallworld to
>  bigworld, some people complained about how long it took to get
>  from one town to another (which is still just a minute or two
>  if you know where you're going)

This is to me a matter of fairness; walking across town shouldn't
take as long as across the room.  But this is a game, so the
proportion doesn't need to be realistic; walking outdoors should
be a *little* slower, not necessarily a lot.

OTOH, I do *want* to make walking to another city annoyingly
slow.  Why?  Because you just shouldn't do that.  Yes, walk to
the town nearby, but then expect that to take a while.

But to go to a different kingdom, you'll want a horse at least.
You'll probably want to camp along the way.  And there may be
goblins.  Or bandits.  Or goblin bandits.  Or bandit zombie
pirate goblin cultists.

Or you take a ship, or the dragon, and get there faster and with
no stress.  But it costs money.

Or you're ridiculously high level and you teleport there, or fly
on your pegasus or pet dragon, or... you get the picture :-)

Again, there will be only one kingdom for at least a year.

>> - Objects can have different faces depending on the "scale"
>>   attribute.  I suppose if there isn't a match a default could be used=
.
>>    Those faces can have different (cell) sizes.
>>
>>   That doesn't mean you'd look 10x smaller outdoors, but a little
>>   smaller.  Then I'd go for making the "enhanced" tiles 16 pixels
>>   rather than 12.
>
>   Is it worth it to have different faces, or just have the client do
> rescaling?
>
>   My concern here is that making up lots of images is a big resource
> sink.  I've seen it through 2 times (from XBM to XPM, and then
> from 24x24 to 32x32 image size).  In both of of those cases, an
> automatic conversion is done as the first pass, but
> cleanup/colorization is needed to make them proper.

I prefer to have the *possibility* of different faces and
mass-resize stuff with bash+gimp (or bash+imagemagick) than lay
an edict that it will be done by the client :-)

Also, most objects (and I mean almost every single object in the
game) will only ever appear on one scale level.  Only living
things appear on all two (or three)... maybe a few other objects,
but I can't think of any right now.

(Yes, there is the question of equipment dropped outdoors.  I
guess I'd just build one single image representing "stuff", and
you have to actually look at it so know what it is.  And maybe if
it's too small, you just simply lose it.)

>   From what I've seen above, I see a lot of 'new images'
> needed.  I'm not sure how much work gros has done - maybe there
> isn't a lot left to do.  But at some point, I start wondering
> if instead of having folks work on 3 or 4 new different image
> sets if that effort wouldn't be better focused elsewhere (like
> having those folks make maps).

I'm trying to plan things so that as few new images as possible
are needed, and those that are can be made from the existing
default set.

>> The rationale here is that we're trying to make both movement and
>> window size work for what are two almost entirely different games;
>> dungeon exploring is one thing and requires one UI, walking around the
>> city or road or forest is something else.
>
>   I don't know - I personally don't really have much problem
> with 2 different games/scales.  Maybe that is just me.  The UI
> needs are perhaps more different based on the action - selling
> items needs a different interface than when I'm adventuring.

Let's think in terms of non-game software development.  Doing a
dungeon, or walking in your house, or interacting in the tavern,
working on the workshop, etc, is a "task" UI; you're actually
doing something, and the UI needs to support you optimally at
that.  Walking around outdoors is really a "menu" UI; what you're
there for is to select a place to go, to select a task to do.  So
presenting more choices, in a way that's reasonable, accessible
and "rememberable", is the optimal thing to do.

And I guess that, really, is the whole motivation for the
multi-scale idea.

But after this conversation I'm more and more tempted to make it
a zoom button on the client.

>> We could even go back to Smallworld ways and use 3 scales rather than
>> two, I'll put that up for discussion.
>
>   The problem I had with smallworld is that it was just too
> small - it started to get to the point that with the number of
> dungeons, there was one almost every 5 spaces - it just didn't
> feel that good.

I get that.  But that's what "scale visibility" is for.  So those
dungeons would simply not be visible on scale level 3 (travel).
How you actually get to the dungeon depends...

- If doing per-map scale attribute: then you'll walk around in
  scale 3, until you find an entrance to a "forest" map, which is
  scale 2, and in this forest there may be one or more dungeons.

- Or if doing client zoom button... then scale 3 will simply help
  you find the forest more easily, at which point you zoom to 2
  in order to find the actual dungeon.  (Cool side effect: there
  could be some abandoned treasure just lying around, which you
  only find if you zoom in to 1 in unexpected places...)

best,
                                               Lalo Martins
--
      So many of our dreams at first seem impossible,
       then they seem improbable, and then, when we
       summon the will, they soon become inevitable.
                           -----
                  http://lalomartins.info/
GNU: never give up freedom              http://www.gnu.org/