[crossfire] Platform statement

[Mark Wedel]

Lalo Martins wrote:
> quoth Mark Wedel as of Fri, 26 Dec 2008 21:40:25 -0800:
>>   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.
> 
> I still don't agree with this... but in a way, I think we're both right 
> on different aspects.
> 
> Maybe the right solution is to call the coins something other than gold 
> and silver, and still keep them in your inventory, BUT also keep a total 
> account as you suggested, display that directly in the client, and work 
> with that for most sales.
> 
> In fact -- and this is coding, not content, so read it as a low-priority 
> suggestion rather than a plan -- I think it would be best if buying and 
> selling had a separate user interface.

  I do tend to agree on that buying/selling - I think I mentioned that in 
another e-mail.  But this is more an interface refinement than a content change 
(that said, one can relate to another).  As I said in my other message, the idea 
of getting a list of all items in the shop you can scroll through, see the 
price, and click on it to buy would make shopping easier.  But it also changes 
the way shops can be done - now you don't need a bunch of spaces to spread stuff 
out - it can all be held in one space (or even inventory of the shop type object).

  For selling, I've often thought that an inventory window for the client could 
be useful - the current listing in the client is a pretty basic listing.  Bring 
up a new window (I'm thinking on how it would be done in the gtk2 client - java 
client would be different) - that inventory window would contain detail 
information for all objects - name, weight, where it goes on the body, and value 
(not probably 2 values are needed - what player thinks it is worth, and what 
shop is willing to pay).  The later case would only show up if in a shop, and 
player could click on something to sell that item.  I'd also have this window be 
able to set up different favorite lists for the client (instead of the entire 
locked/unlocked thing, should be able to set things up like 'this is list 1, 
list 2, etc'  But that is really programming/client, not content again.  That 
said, it is beyond just client, because server would have to communicate these 
values to the client also (but that isn't hard to do).


>>>>> (discussion on tall faces)
> 
> I'll leave that one for the coders, although I need a decision before I 
> start actually making arches and maps.

  Once all decided, probably good to figure out priorities/what order the work 
will be done in.  That lets better planning be done - is the answer needed in 2 
months or 12 months for example.

  Now from my thinking, going one way or the other shouldn't be too hard - its a 
matter of adding/removing the more links in the archetypes and merging images.

> 
> However, I'll repeat what I said before: I believe tall faces are already 
> implemented, at least partially, and that would make that, by definition, 
> a simpler solution than any alternative :-)  (If I'm wrong, then ok... 
> but either way it's not up to me.  I'll just make arches and maps using 
> any system the coding people tell me to.)

  I believe it is true that tall faces will work right now without any real changes.

  However, if you divide what is currently a 1 part object into a 4 part object, 
there are different ramifications.  Number of objects.  Effectively reduced 
viewable area.  Another one I also thought of is it changes balance with respect 
to damage and area of effect spells (a creature (including player) takes damage 
for each part of the creature in the spell IIRC.  So if a player is now a 4 part 
creature, I believe it would now take 4 times as much damage from a fireball). 
None of these are insurmountable, but can extend the scope of the project.  It 
just something one has to be aware of and plan accordingly.


>>   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?
> 
> He would not move faster, that's why I wanted movement to slow down
> proportionally.  Or then again he could move *a little* faster but not
> too much; so if zoom out is 10x and you move the same "apparent"
> speed, then you're really moving 10x faster, and I think that's
> unfair.  But maybe you could move 2x faster (5x slower apparently), on
> the excuse that you're paying less attention to your surroundings.
> Combine that with a transport (horse) that moves 3x faster, and you're
> moving 6x faster.
> 
> Monsters is a good point, I suppose at some point there should be
> objects (ground?) that force a zoom out.

  One has to be careful how all this is done.  There is not any way (other than 
honesty) to know what the client is showing the player.

  So for example, the client could tell the server I'm zoomed out, and thus I 
move faster, but in fact the client is showing me a zoomed in interface.  So I 
get the advantage of moving faster, but still at the higher zoom level.

  Now with different images, maybe it doesn't make a difference - in zoom out 
mode, as you say, maybe we don't transmit certain bits of information to the 
client.  How all that gets controlled is perhaps trickier (I guess you could add 
a flag to all objects to denote what zoom levels it is visible at.  But from 
what you describe, you are also adding something to denote preferred faces at 
different zoom levels).

> 
> But this is getting too deep, and it involves both coding and
> content.  So here's what I propose: let's postpone this whole aspect.
> I'll start the content on the assumption that there is a single scale
> (hugeworld as you say), and if we decide that's unplayable, we think
> about how to do zooming and how many levels and what the UI will be.
> Even if we end up doing it exactly as I envisioned it, we'll all be
> able to fine-tune it better by having actual content to test against.

  Hugeworld was just one thought.  You could still keep the multiple scales as 
now, but not allow zooming either (basically things act as they do now).

  One thing I like about lots of games is that they do provide some form of 
world map (zoomed way out) the the player, that gets filled in as play goes on.

  In a sense, player starts with something like 
http://dooler.woosworld.net/cf_map/, althought maybe some level of blurring gets 
applied so you can't distinguish the roads and towns.

  As you play, it fills in details.  For example, if we presume you start in 
Scorn, it would generate a label for Scorn and put it on the map.  When we 
finally get to Navar City, it labels it.  Maybe even some number of dungeons or 
other landmarks.  And of course, it shows you where you are on that map.

  this is a bit different than you are talking about, as you are just talking 
about zooming in/out information player already knows - in this model, even a 
starting player would have a world map, just nothing filled out on it.

  I always liked such games because it helped give a feeling of what the world 
is.  And if you see an areas without any notations on it, may be an indication 
you haven't been there (or there is nothing there either)

> 
> best,
>                                                Lalo Martins