quoth Mark Wedel as of Tue, 23 Dec 2008 21:55:33 -0800:
> Lalo Martins wrote:
> (various bits snipped here and there)
>> Gameplay
>> ========
>>
>> (use attacktypes more, add more attacktypes)
>
>   Like so many things done in crossfire, the discrete damage
> changes is something that was never followed up to fruition.
> (...)
>   I'd make a strong case that every 'attacktype' line get
> removed and replaced with appropriate discrete damage name.
> The complication here is that if we do use AND logic, automatic
> conversion isn't as easy (but for items with only 1 attacktype,
> still would be).

Since I'm proposing going manually through every single arch anyway for
other reasons, I don't think adding this to the task list would be a
problem.

Or here's a crazy one.  How about doing away with the
percentage-based resistances, and making resistances an absolute
value?  That would allow items to keep improving more or less
indefinitely, and would greatly help making higher-level
characters more powerful.  (Dragon logic would probably need
adjustments, I guess.)

To me it makes sense that someone with a super-duper Mostrai
armor takes no damage at all from an Orc's club but takes some
from a Holy Avenger or whatever.

>   The entire magic attacktype is also odd, because for lots of
> things it is used to denote a magical affect (thus magic
> resistant creatures take less damage). Maybe we just do away
> with that logic?

Yeah magic is different... have to think about that.

>   As far as new attacktypes - are you talking physical types,
> or other ones?

Both I guess.  I have a list somewhere that I compiled for a
different game... I wouldn't be able to use it directly

> For physical, the mix of slashing/blunt/piercing is popular.

Yes, I like that idea.  Maybe replace physical with these three new
types, reusing the physical code for blunt.

>> An important point that was raised in the list is that when you meet
>> something way above your level, it should hurt you badly but not kill
>> you instantly, so you can run away.  Of course if the monster is TOO
>> MUCH above your level (let's say 4x to keep consistent with the
>> definition of extra), then it's reasonable that you die without ever
>> knowing what hit you.
>
>   That's reasonable.  I'd make a strong case that in general,
> it should be difficult for characters to wander into places in
> which the enemy is 4x your level (low level dungeons are sort
> of an exception - if you're level 2, 4x is level 8 - not as
> unreasonable, as level 10 vs 40)

Agreed.  Again, since every map will be edited for the reboot, that's not
unreasonable to ask.

Although I'd argue there are cases where an exception is part of the
story.... look at my Valk temple for a good example :-) (the excessively
hard monster is used to mark "hey, this is the wrong way, and the
seemingly easy path is not the one Valkyrie approves of").

>   I think the slower combat has helped this out already -
> monsters generally do less damage per hit, so less likely one
> hit will take a character out, unless there is a real high
> level difference.

Yes, I think the slower combat made things a lot better in this aspect.

>> What I think the gameplay lacks most in 1.x is goals.  (...)
>
>   I agree that more goals are needed, and this can also help
> change the H&S focus - some goals may not be kill everything in
> a dungeon, but rather get some item, transport and item, etc.

Yes but that's not what I meant :-) I'm thinking higher level.  Why are
you doing that dungeon?  In Pupland, for every dungeon you finish, you're
presented with the next thing to do for one quest.  For every quest you
finish, you're given the next quest in the meta-quest.  So you have fun
and you know what's next.  Sometimes what's next is beyond your
abilities, but you know what you need to improve in order to continue, so
you go find a way to do that.  This way you have more fun and before you
know it, 40, 60 levels have gone by.

>> Generally I tend to go with Nicolas' idea of making the world truly
>> dynamic and persistent.
>
>   I'm not completely adverse to this idea, but I think it needs
> to be fleshed out more.  How do you deal with those
> goals/quests when the dungeon(s) related to them might have
> been cleared out.  How fast does stuff repopulate, etc.  As
> said before, my biggest concern is that the various maps are
> cleared out and haven't been repopulated.

True, and that's a decision to be made now before the rebootworld starts
being built, because it results in a radically different world.  It's a
wholly different game design.

Bear in mind also... with a persistent world, different servers
would "evolve" differently.  A fresh server would still have all
the initial quests and dungeons around.

There's a big question of how to integrate updates with this...
I guess I need to catch Nicolas online one of these days
(weekend?) and brainstorm, anyone else interested is invited.

>> Another important point: I want to make level progression a lot slower.
>> Not the actual gaining of levels, but what that means; how fast your
>> SP pool, HP pool, etc increase, things like wc (or whatever Nicolas
>> replaces it with); and also, make permanent stat increases a lot
>> harder, so that you only reach "perfection" typically at level 100 or
>> so.
>
>   I don't really see much problem with that.  Note that the
> balance work I've already done with melee combat presumes a
> certain level of WC, AC, and HP progression - if those are
> drastically altered, it may mean all that stuff has to be
> rebalanced (not that it can't be done, just want to raise that
> point)

Noted.  One more for the reboot arch to-do list :-)

>> I don't know... strongly tempted to kill overall level entirely. What
>> is it really good for anyway?  I like the concept of item power, but
>> I'd replace it with something you get from quests.
>
>   Overall level isn't used for much.  Item power.  Hit points.
> That's about it I think.  Overall exp is still used to record
> your score.

Yeah that's what I was thinking.  It isn't used for much anymore,
so it's of arguable value.

>   For hit points, it could be done away with.  Why should one
> necessarily get a big blob of hit points every level, and
> nothing in between?  Historically, this has been because you
> got a random number of hit points per level.
>
>   But it would be simple enough to change it to some basis
> where you get 1 HP and these different points.  But see note
> above about impact of changing HP.

Or, again, possibly you gain HP on quests.  A long, arduous
journey to bathe in the Wellspring of Gaea...  I guess that would
make HP increases happen less often, but I'm fine with that, since
armor will probably be going up faster.

(Then of course each such increase needs to store a force so it
can't be used twice...)

>> Loot and money
>> --------------
>>
>>   Also selling flesh shouldn't give you that much money (I
>>   usually get my non-dragon characters started basically with
>>   selling livers).
>
>   I often thought that all flesh should basically have a timer
> (like the demon ichors) - they only are 'fresh' for so long,
> then become rotting, and then eventually disappear entirely.

Good point, that's entirely reasonable.

Heh, could even be creatures that *prefer* rotting flesh.

>   But most flesh should really be of very little value.  If it
> isn't used for some recipe, it really has no value beyond its
> food, so why would someone pay much money for it?

Well, the problem now is with the ones that *can* be used in
recipes... for balance reasons they end up having high values (or
maybe they have no value and the server calculates it automatically)

> My quick thoughts:
> Changing the name doesn't really change value.  If silver is replaced
> with bronze piece, and gold with copper, etc, that doesn't really do
> much to change actual wealth, all that really changes is what we call
> it.

True.  Changing the names is separate from gameplay; it's for
ambiance.  The gameplay leg of this section was, as I said on
Kevin's reply: putting more granularity in server values, and
re-thinking the value of things for balance and ambiance.

Like, IMO things like enchanted armor should cost in the gold
range.  Even *normal* swords/armor should be very expensive... in
the dozens of reggries (thousands of dollars) range I guess.

As a partially-related aside, I don't see orcs and goblins having
swords at all.  Clubs, spears, stoneaxes... hatchets maybe... are
more reasonable.

> I'd strongly suggest a decimal system be used (10:1 or 100:1 ratios).  I
> really don't want to have to be doing 64:1 multiplication to try and
> figure out values of different items.

Yes but that doesn't arise.  What happens is that things will go
in ranges... and we can even hardcode it that way.  So like, food
will always be quoted in cleekins (and if the merchant says
"three and a half", you do know half a cleekin is 4 aytbits);
clothing, weapons, armor, books, horses, etc always in reggries;
enchanted stuff, high-level books, etc, in the silver/gold
system; and houses, magical beasts, ships, and the like always in
plat only.

> I had suggested at one time that instead of actually having all those
> coins about (and extra code to deal with it), a characters money is just
> another attributed like hp or exp.

That's another possibility.  It detracts (IMO) from the feeling
of immersion, but it makes things simpler.

I guess it depends on how much the game would focus on
accumulating money.  I want to focus more on RP, build a
"believable" world, and for that I prefer coins.

> I'm also not fond of regional currencies.  While realistic, this tends
> to just become more of a bother to players to go in and exchange
> currency than actually adding much.  Now maybe you have some special
> quests (someone will only take regional currency or something), but have
> to keep in mind point is to have fun and not get bogged down in details
> of real world economics.

Again, depends on how much money is in focus.  If you want to go
to a different nation "trivially", just to complete a quest or
something,  I'd expect you to be able to do that without spending
any money.  But if you want to stick around, do the places'
quests, etc, then you'd want local money.

But that's something to think about only later.  For probably the
next year or more there will be only one nation on "rebootworld" :-)

>> Setting
>> =======
> < much about reboot removed>
>> I'll write something up the next few days.
>
>   Am interested in seeing that write up.  Do you envision doing
> all new maps them?  Including new world, new cities, etc?

Yes.  World and cities are all new.  Dungeons will be a mix of
new and ported, but porting requires some actual editing, not
just copying the file -- as per the cell size changes below, and
new features like tall faces, but more importantly, making sure
it fits the setting and the guidelines we agree on wrt gameplay.

>> Visual
>> ======
>>
>> - Facesets can have different pixel-per-cell sizes.  I think
>>   that's already the case, right?
>
>   Sort of.  While different facesets can have different sizes,
> I'm not sure if the clients actually use that information or
> not.

The server doesn't even care about the face pixel size, though,
right?  (Or even know...)

>From what I remember of client code, adding this intelligence to
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 of
> 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 === 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
>> =========
>
>> 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/


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

Reply via email to