[crossfire] Platform statement

[Mark Wedel]

Lalo Martins wrote:

> quoth Mark Wedel as of Wed, 24 Dec 2008 16:37:08 -0800:
>>   I'd be a bit reluctant to start a task that basically requires a
>> rebalance of all monsters/items.
> 
> Actually, I think I'm over-reaching here.  All considerations of *how* to 
> deal with gameplay, especially game mechanics, are just IMHO and 
> suggestions.  I'll say what I think, reply on threads when asked, but in 
> the end, go with whatever the coders decide :-)
> 
> OTOH... I'd much rather rebalance all monsters/items now, while I'm 
> editing everything anyway, than later.

  I'd hope that things don't change so much that everything _has_ to be 
re-edited.  May be good to do so, etc, but there is a difference between that 
and something that must be done.

  From my past experience at rebalancing, a lot of rebalancing work also 
requires actual playtesting - that is the harder/more time consuming part. 
Pretty easy to change archetypes into values that seem balanced, but the 
question is are they really balanced, and that requires actual play testing.

  Could things get rebalanced again?  Sure.  But in a general form 'Can xyz be 
done?', the answer is almost always yes, but how much time/resources it takes to 
do it, is it worthwhile, etc, are all parts of an answer that need to be taken 
in consideration.

  My concern is that some of the changes being discussed are very large.  I'd 
rather have a more concise/limited set of directional changes that actually has 
a chance of getting done in a reasonable time fashion than a very large set of 
changes that may never get done.  We've done (or not done) that later case more 
than once.

> 
>>   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.
> 
> A little bit of each.  It's a rewrite, "Crossfire 2" so to speak,
> but not completely from scratch; you could say it's like Nicolas
> wants to do with the C++ server, starting from scratch and
> copy-pasting chunks of code.  I want to design the world from
> scratch but adapt or adopt maps, arches, images, etc.

  I'm not adverse to redoing the world - it has been redone once, so there is 
some proof it could get redone again.  But there is a pretty big gap of redoing 
the world vs redoing all archetypes/images/skills/spells/whatever.  See note 
above about something that can get done.  Start with the presumption you will 
need to do all the work yourself, as from past things I've done, that pretty 
much seems to be the case.


>>   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.
> 
> You'd still want exp, because that's what makes your skills go
> up.  I believe in the current system, either damage or wc is
> based on skill, right?  (Or both?)  For magic-users it's even
> more obvious...

  Yes, skills give spells and mana.  One could change it so that the highest 
skill you have determines hit points.  This has an interesting side benefit of 
it would be incentive for folks to focus on certain skills.

  As things are now, you could be good in many skills, and your HP still goes up 
at a nice rate, since it is based on overall level/exp.  If it was based on 
highest skill level, it means being good at a lot of different things wouldn't 
give you very good hit points.

> 
>>   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.
> 
> I think it's perfectly reasonable that a darkblade costs 3000x
> more than a normal sword, assuming you can buy it at all.
> 
> But a slightly better sword shouldn't cost 100x more.

  But if you could buy it, would anyone actually pay that much money for it?  If 
the answer is no, then it is overpriced.

  That IMO is the basic problem of the crossfire economy - it isn't really 
supply and demand.  Now to be fair, you can't really do a true supply and demand 
economy in a game world - you sort of have to let folks sell the stuff in 
stores.  But the basic failing is that there isn't gear to buy, or there may be 
gear but it is so expensive it isn't worth buying.


>>   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 disagree; I'd rather increase the value and reduce their
> number.  The problem, as you said, is finding one just lying in a
> dungeon; well, but I don't think you should.  Truly awesome items
> are the rewards of long quests, and you probably won't want to
> simply dump it on the sale store.

  Certainly depends on many factors.  If I can't use it (Am a 
race/class/follower), dumping it for huge sums of gold may very well be worth it.

  Reducing numbers it key - until that is done, hard to see how things play out. 
  But even now, you find various good items worth lots of money here and there. 
  How much should a +4 item be worth compared to a normal one.

  Most of the CRPGs I've played tend not to have such huge value differences - 
probably because in many cases they know that players will not spend those large 
amounts of money, so better to just not even given it out.

> 
>>>> 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.
>>   I'd also suggest that names of currencies by intuitive.  I
>> don't think anyone would know valuy of cleekins to aytbits...
> 
> Well... I strongly disagree.  But since this seems to be a matter
> of opinion, I don't know that anything can be done about it.
> 
> So I propose I do it my way, and we see how it looks, and in say,
> a year from now, we evaluate how much it sucks.  If it doesn't
> work or makes the game too hard, it's a simple matter to edit
> only the coin archetype files.
> 
> For one thing, I think it's clear to me from the last few emails
> that the whole way you use money in the game would be different;
> and at that point, I'd rather make the money more, <hmm, I know
> there's a word for what I'm thinking but it refuses to come to my
> mind... fitting the theme, mood-building, more part of the story
> than the game system>, rather than less.

  I don't know.  If I'm leaving the game to find out how much a cleekin is 
relative to a silver piece (going to the docs, using a calculator, whatever), 
I'd think that also ruins the mood quite a bit.

  I find most games that make up new terms for money or other game aspects 
instead of using already well known words just annoying, and not really in any 
way more immersive than those that do use the standard words.  After all, 
everything else in the game is in English (or local language of your choice), 
and to just take out certain terms almost seems more noticable than not.



>>> 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.
> 
> Sorry, I don't follow.

  I didn't really mean to go into a code design on it, but briefly:
In crossfire/maps, there are really 3 types of objects:
1) Immutable objects - these never change and have no interaction with the 
players.  Walls and floors are the main objects in this case.  These are also 
typically the most common objects on the maps.
2) Objects with speed.  Spells, monsters, players.  These objects go off and do 
things, whether controlled by AI on the server of by a player.  In some cases, 
the AI could be very simple (damage things on this space, propogate to next spce 
in case of spells).  These may be the least common objects on a map.
3) Items - swords, chests, levers, etc.  Things the player may interact with in 
some way, are not immutable, but on their own, they will never do anything.

  Now under the changes you propose, a player, which is currently 1 object, 
would likely become 4 objects.  a 2x2 monster (4 objects now) would become 16. 
Granted, there are cases here where changes in footprint may not mean that 
actual number of objects, but useful as an example.

  Rather than use all those more pieces, the object itself could denote its 
size.  Exactly how that is done is an implementation detail, but could be done 
as a radius, which probably makes the most sense.  So instead of that 4x4 
monster using 16 objects, it uses one and notes it has a 2 radius.

  Now instead of the global list of objects like we have now, the objects are 
stored for each map (this is also useful in threading).

  To continue with the example, when the player tries to move to some space near 
that big monster, it gets the P_ALIVE flag on that space just as it does right 
now.  But instead of traversing the objects on that space to find the monster, 
it just traverses that linked list of monsters to find out what monster is 
occupying that space.

  This may be more efficient than adding in all those additional heads/tails - 
at some sense, with such a logic, you don't even need that support anymore.

> 
>>> 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.
> 
> Again, I believe this work has already been done at least partially.

  I believe the client would handle that change without problem.

  However, such a change in images effectively reduces the amount visible in a 
25x25 space.  Under what you describe, the same number of pixels would now need 
to be drawn in a 50x50 map grid, since each space is effectively divided in 2 in 
both the x and y axis.

  The max supported coordinates in the protocol is 25x25 IIRC.  So under the 
changes, this means player would now have the equivalent viewing area of 12x12 
(client would still get 25x25 spaces, but each now conveys less information).

  As you noted in another messsage, your idea of amount of spaces viewable was 
lower - if 12x12 matches, no problem.  But if you are looking for something 
equivalent of 15x15, then that would require protocol changes.


>>   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.
> 
> It's not a time sink, it's a, hmm, progressive multi-level menu.
> 
> For a metaphor, try to find something on Google Maps without
> changing the zoom level.
> 
> The idea is that I want to make a "dense" (as opposed to sparse)
> world; not add 1000 miles of nothing in one direction and then a
> city.  So let's say you go out of Scorn to find that dungeon in
> the forest, or a village.  There will be a lot of interesting
> things around.  There's also a chance that many (most?) of those
> aren't interesting to *you*, so you'd rather not have to think
> about them too much.  So you zoom out to the big picture; Ah, all
> right, there's a forest here, there's a village there.  You go to
> the forest, then zoom back in to find the grotto... or go to the
> village and zoom back in to find the house you want.

  That part is simple enough to understand.  But how the player gets from scorn 
village is now the question - is the player effectively just playing on the 
zoomed out map?  What about monsters, etc?  And does he move faster?

  Clearly, zooming out is useful for finding things.  But what I'm not sure is 
how that interacts in the game.  Is it purely just a mechanism to help one find 
their bearings (I'm in the wilderness someplace, I zoom out, and now I can see 
where Scorn is relative to me).  That helps me travel back to Scorn, but if I'm 
still moving at a slow pace, then I probably go back into 'normal' zoom level - 
once I know I have to travel southeast, being zoomed out probably doesn't do me 
much good.  Now I may zoom out now and again to get my bearings, but I don't see 
myself playing the game in a zoomed out mode.

> 
> That's not realistic.  Realistic would be forcing you to wander
> around, maybe follow the road, maybe consult a map, and hope for
> the best.  But IMO having a "zoom out" would improve gameplay.

  One could do it right now.  But the issue is filling in those additional 
spaces.  It's not that useful if I zoom out and everything appears at 25% of old 
size, and all that is drawn in the middle 25% of my screen, with the rest being 
black because there is no information for those spaces.

  What's perhaps confusing to me is you're talking different zoom scales, which 
is really just something the client can do, and different scales in the game 
world itself, and how those interact is what I'm not sure of