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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

I just happened to remember seeing a couple of modules on CPAN the other =
day that might actually be of use to us for this. The modules in question=
 are Games::Maze and Games::Object. IMO, we might want to take a look at =
these.

Tom

----- Original Message -----
From: Andrew Brosnan
Sent: Friday, October 11, 2002 4:07 PM
To: Petras Kudaras
Cc: cpl...@li...; cplproject-develop=
er...@li...
Subject: Re: [cplp-dev] Re: What's next

On 10/11/02 at 10:01 AM, mox...@de... (Petras Kudaras) wrote:

> Here I am going to present my view of the first stages of the game.
> Feel free to express your opinion and comment on this.
> =20
> The goal is to make a charactermove in the world and interact with
> walls. So there are a couple of objects that we must pay attention to:
> =20
> a)  a character,
> b)  a world map, which consists of:
>     1) walls;
>     2) empty space.

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)

> =20
> We also have a client/server structure. =20

Are we talking about writing our own http client or using a browser?

> In my opinion, the server has the following duties:
> =20
> a)  generating the map (or reading it from somewhere),

what would the map be based on? coordinates?

> 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?

> c)  transmitting the map information and character information to the
> client via some protocol,
> d)  waiting for the client to give instructions (which at this stage
> would only be "move north/south/east/west")
> e)  process the instructions from the client and respond witha status
> message (either "successful" or "not successful -- bumped into a
> wall")

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?
> =20
> The client has these things to do:
> a)  handshake with a server, get a map and character data,
> b)  somehow display this data on screen (ASCII art like nethack?),

I am clueless here..sorry. I'm happy to research it though.

> c)  take instructions from the player and send them to the server,
> d)  update map information internally and redraw the map (if the move
> was successful, if not -- display a message why it was not successful)
> =20
> The communication between client/server could be over XML-RPC.
> =20
> 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:-)

> =20
> This is my view of the game and I would like you to present yours.

I'm going to work on this some more. Good discussion.

Andrew

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
cplproject-developers mailing list
cpl...@li...
https://lists.sourceforge.net/lists/listinfo/cplproject-developersGet mor=
e from the Web.  FREE MSN Explorer download : http://explorer.msn.com