adonthell-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Adonthell-devel] Item spec


From: Alexandre Courbot
Subject: Re: [Adonthell-devel] Item spec
Date: Wed, 15 Jan 2003 08:42:47 +0100

> > But does it use our python layer? If so, well that's not serious
> > anyway, as I didn't think about the editors when saying that. I'm
> > mainly talking about the game - moreover maybe what I said was
> > wrong!
> 
> Not the editor but the engine. As the dialogues are python files, it
> seemed only natural to handle them with py_object. And I guess
> dialogues belong on client side, don't they?

I *think* (otherwise said: for what it's worth ;)) the dialogs should be
run on the server side, and the text and answers should be sent by the
communication layer. Otherwise it might be too easy to cheat - you just
need to analyze the dialog, and then you could twiddle it. One can say
that you can also analyze the dialog and answer what you should answer,
so here is another reason: because the dialogs can change the game state
or run some stuff, which belong obviously on the server side. So
dialogs, as all game elements, belong to the server side.

> > Good question. If py_object makes the conversion, we'll lose the
> > different types. Or maybe we can write one method per data type,
> > just as Python does for its conversions.
> 
> Hm ... but how would py_object know of what type an attribute is. It
> would have to try all available types, I fear. Only the reciever knows
> the type.

That's why the receiver should call the appropriate method
(py_object::getattr_asint(string &) for instance).

> Of course, py_object could have methods like get_int, get_string, etc.
> At least the most basic types could be covered that way. If somebody
> wants to return something unusual he can use plain get and convert
> stuff himself.

Exactly.

Alex.
-- 
http://www.gnurou.org





reply via email to

[Prev in Thread] Current Thread [Next in Thread]