well i got your point now, better than before :)
the way I implemented it, it will have no influence on the client or
bandwidth, if the client does not send "Look" events to the server. I
tested it with the original 0.48 client, where look is still
completely handled in client and as expected it doesn't make a
so what propose is: I commit the server changes, but I keep my client
changes local; that way I can make use of the feature and everyone
else doesn't have to :) In any case, if the textual description would
change on some circumstances (day and night time maybe, quests) it
might proove to be helpful, to have a way to get em from the server ;)
and we'll all be thinking about having the server sending text index
codes only to the client who would look them up in a database. and if
it's not in there, get em via http from the to be developed tomcat
Am 30.04.2006 um 04:00 schrieb Oslsachem:
> --- Jo Seiler <jo.seiler@...> wrote:
>> Textual representation is indeed complementary and
>> additional information. but what motivations are
>> there normally for
>> such additional information? I can see a few
>> categories for that:
>> - providing information for the player like giving
>> hints on what to
>> do with a certain object, maybe clues to quests,
> Are you talking here about common items or about
> unique quest items?
>> - creating atmosphere. gfx of a game are a short
>> time attraction. the
>> eyes tire way faster than the mind :)
> So here they are really used like a gfx complement or
>> - saving a lot of production time. you can have
>> content creators work
>> a lot more independently from gfx creators if they
>> don't have to wait
>> for the creation of a new gfx for a new subclass of
>> object they put
>> into the story. you take the things already
>> available and describe
>> what the gfx is not showing
> In any case I think a "No Gfx Available" default image
> is showed when the graphic isn't found and I'm not
> considering the act of giving an item with the same
> graphic another name as a (short) description of it.
> Again, the problem to solve as I understand it, is
> preventing the users from having to download a new
> version of the client.
>> Quests are defined server side, items are, creatures
> I think that the background problem here is separating
> logic from data, and the data that is strictly
> required by that logic (like stats) from the data that
> only adds atmosphere (graphics and textual
> descriptions) and that can't be logically processed.
>> And textual
>> information goes together with those.
> Textual information goes together with those just as
> gfx would go but it was decided that gfx were on the
> client side to reduce bandwidth usage I think.
>> Someone creates a new quest, let's say a beggar NPC.
>> You say "Hi" to
>> him but he only grunts. You wonder what you have to
>> do. Then you look
>> at him and notice he has no tongue.
>> You think for a
>> moment and
>> remember, another NPC told you about Orks doing that
>> to victims.
> First of all, maybe you're relying too much on the
> user's cunning ;D
> Well I agree that for now it can make sense to add
> that description server side if it is for a unique NPC
> in a quest but not moving all the common items
> "literary" descriptions to the server side.
> The point here is that the info that is known
> beforehand and isn't processed to get new info should
> be placed if possible on the client side, and indexed
> and referenced from there by the server like graphics
> Even quests dialogs content should be on the client
> side. That way you could simply translate the quests
> on the client side and the logic would work for any
>> So you'd add a description for the look action and
>> there you go. Why
>> install a new client for that?
> Not install but update the client automatically if
> possible. After all, you're adding whole new quest.
>> There's probably a few philosophies about the roles
>> of client and
>> server in multiplayer RPGs. To me, all the client
>> has to do is
>> visualize the world that the server delivers and to
>> record and return
>> the actions of the user.
> I think that's what it's called "the server doesn't
> trust the client": all the logic is processed on the
> server side and the logical data resides on the
> I think that visualizing doesn't only mean graphical
> descriptions but textual descriptions as well.
>> The thing client and server
>> have in common
>> is the language of the game world and data. The
>> client must
>> understand them to visualize correctly and also to
>> return valid actions.
> In any case what the client can really understand will
> be logical data but not raw data as graphics or
> textual descriptions.
>> From what I understand arianne/stendhal works now,
>> it's exactly this
> From what I understand the philosophy of the arianne
> server is reducing the bandwidth (Delta perception,
> UDP protocol) even if it is at the cost of more cpu
> usage on the server and client sides.
>> Anyway, the change is done and I can either commit
>> it or not :)
> I don't want to look harsh: I personally appreciate
> your effort. :)
> And I'm just giving my humble opinion as you suggested
> and nothing else (and maybe I'm wrong after all):
>> Any of you guys have any comments on it?
>> (and yes, would be nice, if gfx would be loaded from
>> dynamically, too. I'm thinking about adding an http
>> server thread for
>> resource requests or rather an rpc connector and a
>> servlet to access game resources - item & npc
>> descriptions, gfx,
>> maps, ...)
> That would be nice. I think the problem should be
> addressed with a system of updating not only graphics
> but text content too on the client side.
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> Using Tomcat but need to do more? Need to support web services,
> Get stuff done quickly with pre-integrated technology to make your
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Arianne-devel mailing list