Re[2]: [cplp-dev] Re: What's next

[Petras K. <mox...@de...>]

Friday, October 11, 2002, 10:03:46 PM, Andrew Brosnan rašė:

> The world map would be an object? (and things in it?) I guess that makes
> good sense. I'm going to have to get my OO programming book out. (I just
> got Damian Conways book...guess I'd better get to it)

Well, as far as I can remember, James [Mastros] suggested the idea of
a object oriented approach and I think it makes sense. If anyone has
arguments against, we would all like to hear them before making the
final decision ;)

>> We also have a client/server structure.
> Are we talking about writing our own http client or using a browser?

I think we are talking about a browser interface for the first version
(XML-RPC would enable us to add more interfaces later on). So here is
how I envision the client/server thing:

A server is an application that is sitting on some port and accepting
XML-RPC queries (which is just some XML over HTTP)

A client is a CGI application that connects to the server, does what
it needs to do, formats a HTML result and sends it to browser.

So the scheme would look like:

/------\  XML-RPC  /----------\  HTTP  /-------\
|Server| <-------  |CGI Client| <----  |Browser|
\------/  -------> \----------/  ----> \-------/

> what would the map be based on? coordinates?

I guess so. It might be inefficient to store the map in a two
dimensional array in some cases, but would that be a problem for us?

>> b)  generating the character (in theory it could be generated by the
>> client, but I think it is easier to leave it for the server),
> yes, also generating it on the server would give us more control to
> update & change things without *necessarily* requiring users to upgrade
> or even know about it, wouldn't it?

Yes, I agree with that.

> hmmm...just wondering out loud...how will we keep session stuff
> straight. I mean, if the server generates a map and characters, sends
> them to the client, and then the client wants to do *something*, (which
> may eventually alter the character or map), obviously client and server
> need to be in sync. Any thoughts on managing sessions? Is this what you
> were thinking?

There is no concern about keeping sessions during CGI applications,
because we can use HTTP cookies (if that is what you meant).
So once the initial handshake is made, a special token (so called
unique session ID) is generated and is shared between client and
server. So server can know which client is playing who and what map it
is using and so on. Obviously this session ID has to be passed to
every XML-RPC request, so that the server can track users.

>> b)  somehow display this data on screen (ASCII art like nethack?),
> I am clueless here..sorry. I'm happy to research it though.

Displaying a map in the browser is not a difficult thing to do. The
map will presumably have tiles, so displaying them in ASCII or in a
set of images would be simple IMHO.

>> In terms of Perl, map and character could be instances of object
>> classes "map" and "character" respectively. Keeping objects separate
>> would probably help us when we will want to expand or add another game
>> theme.
> Yes, although I'm sure that using inheritance (base->derived classes)
> will make sense for many things, especially for things in the 'world'.
> (I'd better get to that book:-)

I am looking forward to this, because I also wanted to learn more OO
Perl ;)

-- 
Sėkmės,
 Petras Kudaras                            mailto:mox...@de...