[crossfire] Platform statement

[Mark Wedel]

Lalo Martins wrote:
> 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.

  Its an option.  Like most of the changes it is a pretty big one - there 
wouldn't be any clear/simple replace this value with that (a resist_fire 50 
doesn't directly correspond into fire_dam_reduction 5 - it really depends on 
lots of factors, like level of monster (or targetted level of item), etc.  In 
comparison, Ryo's proposed WC/AC change is a fairly straightforward change, and 
a simple WC X means new_wc Y through some formula could easily be done.

  I'd be a bit reluctant to start a task that basically requires a rebalance of 
all monsters/items.  It can certainly be done, but since we just finished one up 
(with the combat rebalance) and I hope soon to finish up spell rebalance (have 
the next 1.5 weeks off from work, so should get it done then), I'd like to see 
that get used more before revamping it.

  A more general question on the platform statement or just in general is how 
much of existing crossfire are we keeping?  In a sense, are we evolving 
crossfire or writing a new game?  This may just help define the scope of the 
project.


>> 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.

  I'd suggest just do 3 new keeps, and obsolete physical.  It makes it easier to 
see what stuff has been updated and hasn't been.  Also, I'd rather see 
dam_blunt, dam_piercing and dam_slashing vs just having 'dam' mean dam_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").

  But there are better ways to balance that now - give it lots of HP, so it may 
take a long time to kill, and at the same time, reduce the damage it does to a 
more reasonable level so most characters will survive a little time.

  I also think it would be reasonable in many such cases to put a weaker monster 
(say half as powerful, or maybe only 25% as powerful) before that one a ways - 
like 'this is your first test').  Really weak characters wouldn't be able to 
defeat that, but it probably won't kill them right away.  Characters that are 
meant to be able to kill that next monster probably wouldn't have much problem 
with this first one.  And characters that are able to defeat it, but find it 
challenging (have to use lots of magic, etc), are probably still tough enough 
not to get killed instantly by the main boss creature.


>>> 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.

  Yes - overall plot lines that have many parts can be nice also - it tends to 
give some focus.



>>   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...)

  I personally don't have a problem with certain things, like HP, being based on 
characters level/total exp.  I'm not sure how I'd feel with it going up by quests.

  One question would be how do you deal with death in these cases?  Is there 
still a penalty?

  Another problem is that I could see players picking the quests that only give 
these bonuses.  IMO, there should be some reward in just adventuring for 
adventuring sake - right now we have random dungeons, which can be useful places 
to pick up some experience.  If experience doesn't mean much, you now get folks 
doing quests constantly - maybe not a bad thing, but you have to make sure you 
have enough quests out there for people to do.

> 
>>> Loot and money
>>> --------------

>>   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)

  I believe the certain body parts are considered valuable, regardless if there 
is a use or not.  For example, legs and arms have little value, no matter what 
creature, where as someone noted, livers are a good source of money (as are 
brains IIRC), because they are consided valuable no matter what creature they 
come from.

  This is all calculcated internally if my memory serves.

> 
>> 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 was sort of thinking the opposite - a problem with money is because even 
right now, the values of items are huge from low level to high level.  One could 
say that ones level goes by a factor of 100.

  A normal longsword has a value of 45.  A darkblade has a value of 143000 
(3000+ times increase).  And that probably isn't even the most valuable weapons.

  Most games tend to collapse the price difference - maybe more like 100:1 from 
high to low.

  I realize darkblade is an exception, but you start getting into other high 
priced magic items you can find in a dungeon, adds up to a lot of money.  If you 
want to reduce amount of money in the game, reducing the value of items is 
probably the direction to go, not increase it.

> 
>> 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.

  But what happens if I have 200 food?  Is it still quoted in cleekins?  And at 
that point, I probably do have to know the value of it - do I have enough of the 
next currency up to pay for it (as I probably don't have 2000 cleekins or whatever).

  For that matter, even if I'm just buying 5 food, change may be needed from my 
next higher currency, so keeping things decimal makes things easier.

  I'd also suggest that names of currencies by intuitive.  I don't think anyone 
would know valuy of cleekins to aytbits, and if anything, I think crossfire 
should be easier to learn/play not harder.

  If more currencies really are needed, one could add iron pieces and copper 
pieces to current system.  That now gives 5 different levels of currencies 
(iron/copper/silver/gold/platinum), and I think most folks would recognize 
increase of those values fairly easily.

  If one did a 100:1 ratio between each of those (100 copper/iron, 100 silver to 
copper, etc), the platinum coin is worth 100,000,000.  Note that an amber coin 
is currently worth 500,000.  One could in fact lose the iron coins, and just do 
copper/silver/gold/platinum, and the platinum would be 1,000,000, which is still 
twice as much as the amber coin.

> 
>> 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.

  So I've played many other CRPG's, and they don't put money in the inventory, 
but instead represent it as coins (or such a type of currency) someplace. 
Likewise, when buying equipment, it is still quoted in gold or something.

  For such a system in crossfire, I'd so something like:
In the client, have the different coin icons near the inventory, and next to 
them, client displays amount of each those character has (but it does automatic 
consolidation to currencies).  In a sense, one can think about this in real life 
- if one asks you how much money you have, you say $97.  You don't say I have 4 
20's, and 10, and 5, a 1, and 4 quarters.

  The server just stores net worth of in the player object.  It treats this like 
any other attribute - player picks up money, that goes up, send update to client.

  The two trickier parts are this:
1) When describing value of an item, you don't want it to say 45,253.  You want 
it to say 4 gold, 52 silver, 53 copper.  So the server still has to have some 
idea of different ratios for descriptive purposes.
2) A mechanism is needed to drop coins (for altars, etc).  This could probably 
be done by using some special command and have a 'drop' type button next to the 
coin display.

> 
>> 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" :-)

  IMO, the main focus of playing crossfire is to have fun, not necessarily for 
it to be realistic.

  Does needing to go in and exchange currency add to the fun factor?  Probably 
not.  I'm not saying everything has to be fun, but we should probably try to 
look at these things and see how do they improve gameplay.

  As a side note, right now crossfire server doesn't have any concept of 
foreign/different types of currency.

> 
>>> 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.

  I suspect automatic conversion for cell size changes could be done, but review 
for guidelines clearly has to be something done manually.

> 
>>> 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...)

  Correct.

> 
> From what I remember of client code, adding this intelligence to
> v2 and jx shouldn't be *too* hard.

  No, it shouldn't be that hard.


>> 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.
> 

  I think I follow, but just to make sure I'm clear.

  In this case, the human uses 4 cells on the map (2x2), and obscures 4 more 
cells (its tallness in this context).

  The main think we're looking to gain here is finer placement/movement of items 
(with each cell being smaller, movement steps are also smaller)

> 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.

  I wonder if there may be better ways to deal with this.  In any case, we're 
not really going on design here, but general goals.  But my quick thinking is 
that it could be more efficient not to use all those head/tail archetypes and 
instead have some form of footprint in the archetype.  When some action happens, 
look for nearby archetypes and check that footprint.


> 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.
> 

  I thought one of Ryo's goals was to remain protocol compatible.  This change 
sort of seems to go away from that.


>>> 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)
> 

  Yeah, I don't know how that would really work out.  I'd say that the 
extra/unused stuff in town should get removed, so the only things in towns are 
things you'd use (temples, taverns, shops, etc).

  I recently thought of redoing shops some.  Currently, there are the shop 
listing signs which lets you see what is in the shop.  It would be even more 
convenient for that to be interactive - this is what's in the shop, this is how 
much it costs, and you click here, and its yours type of thing.  In such a 
model, shops don't need to be very big anymore.

  I personally have no idea how a hugeworld thing would work out.  It does help 
with the different scale problem (you don't have one anymore).  And for small 
villages or taverns along the road, probably improves immersion, doesn't remove 
it.  Most of the CRPGs I've played have pretty much had a single scale - even if 
there were indoors, they would be same scale as outside.

>>> 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.

  One thing partially corrected with the combat rebalance was movement speed - 
it was generally moderated so slow characters wouldn't move as slow, as fast 
ones not as fast.

  But lots of games don't penalize players for carry lots of loot.  So could be 
fair that speed is really just based an armor being worn, and not on how much 
crap is being carried.

> 
> 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.

  That is reasonable in my mind.

> 
> 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.

  To me, that is the big thing currently lacking - the outdoor world is static 
and safe.  There should be danger here and there.

  That said, with current map scale, travel from scorn to navar city doesn't 
take very long.  To make it take any significant amount of time would mean 
slowing the characters down so much that it becomes painful (oh - I moved a 
space. Maybe in another second, I'll move another).  IMO, the fix for that isn't 
to slow down movement, but to increase number of spaces between those two 
places.  Make it 5000 spaces - now it really will take some amount of time.

  That said, point of the game is to have fun, not be totally realistic.

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

  Completely reasonsble.

>>> 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.

  I guess it depends on how the outdoors is done.  If outdoors is really just a 
time sink to get from town to a dungeon (or other town), then maybe a different 
interface is needed.

  But I'd make an argument that if that is all that outside is, then that needs 
to be rethought.  Wasting my time getting from point A to point B in a game 
isn't fun - it has to add something, be interesting, whatever.  In fact, of the 
CRPGs I've played, they don't really have this problem - if you've been to a 
place before, you can get back instantly.

> 
>>> 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.

  As long as it is easy to find those entrances, I don't really have much of a 
problem on this.  But if I have to spend a bunch of time hunting for it, that 
once again doesn't become very interesting.

> 
> - 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...)

  But it seems this zoom of the client still has some relation to movement - so 
how do you handle that?  In a sense, are you just adding multiple levels of maps?

  I'm just not really clear what we're zooming in on here or what that really 
gets us.

>