Implementing a simple persistent web game server

[AeonOfTime]

Hi everyone,

I have a concept for a pretty simple web game, and am currently
considering my options regarding the storage of the game state.
Ideally, I would like to have a custom server running that keeps the
most accessed data in memory, and which all clients connect to.
Nothing new there, but I am wondering as to what protocol to use for
the client server communication. Go for one of the available XML-
based standards, or use something custom that will generate less
overhead but be more cryptic (and possibly difficult to maintain in
the long run)?

My current plan is to use PEAR's Net_Server (1) and extend that with
the functionality I need.

Thanks in advance for any input you may have.


--
1. http://pear.php.net/package/Net_Server

[Sjoerd]

Re: Implementing a simple persistent web game server

On Aug 8, 3:19 pm, AeonOfTime <s.mordz...@gma il.comwrote:

I am wondering as to what protocol to use for
the client server communication.

What kind of data are you sending? How much?

[AeonOfTime]

Re: Implementing a simple persistent web game server

On Aug 8, 3:52 pm, Sjoerd <sjoer...@gmail .comwrote:

On Aug 8, 3:19 pm, AeonOfTime <s.mordz...@gma il.comwrote:
>

I am wondering as to what protocol to use for
the client server communication.

>
What kind of data are you sending? How much?

It's an RPG-style game, so it's character stats and actions to
undertake - mostly numbers there, so not much data at all. Where there
will be more data is in querying item descriptions, but I think that
will be a separate daemon as the main server only keeps track of stats
and what items you have.

[Captain Paralytic]

Re: Implementing a simple persistent web game server

On 8 Aug, 15:06, AeonOfTime <s.mordz...@gma il.comwrote:

On Aug 8, 3:52 pm, Sjoerd <sjoer...@gmail .comwrote:
>

On Aug 8, 3:19 pm, AeonOfTime <s.mordz...@gma il.comwrote:

>

I am wondering as to what protocol to use for
the client server communication.

>

What kind of data are you sending? How much?

>
It's an RPG-style game, so it's character stats

That should be "its character sets".

[AeonOfTime]

Re: Implementing a simple persistent web game server

On Aug 8, 4:53 pm, Captain Paralytic <paul_laut...@y ahoo.comwrote:

>

It's an RPG-style game, so it's character stats

>
That should be "its character sets".

Sorry for being cryptic, I suppose that should have read "It is an RPG-
style game, so the data consists of character statistics and commands
for actions to undertake".

For my defense I have to add that I am french, and that accounts for
some occasional glitches :)

[Jerry Stuckle]

Re: Implementing a simple persistent web game server

AeonOfTime wrote:

Hi everyone,
>
I have a concept for a pretty simple web game, and am currently
considering my options regarding the storage of the game state.
Ideally, I would like to have a custom server running that keeps the
most accessed data in memory, and which all clients connect to.
Nothing new there, but I am wondering as to what protocol to use for
the client server communication. Go for one of the available XML-
based standards, or use something custom that will generate less
overhead but be more cryptic (and possibly difficult to maintain in
the long run)?
>
My current plan is to use PEAR's Net_Server (1) and extend that with
the functionality I need.
>
Thanks in advance for any input you may have.
>
>
--
1. http://pear.php.net/package/Net_Server
>

Most OS's and databases already cache the most recently used data in memory.

If you're going to use PHP on the server, you're probably going to be
using html, xml, etc. over HTTP It really doesn't make that much
difference which it is, because you'll be using a browser on the other
end. There are other ways to do it - but they will be much harder to
implement from the client end (where most people will NOT have PHP).
Also, please remember that HTTP is a stateless protocol - strictly
request from the client/response from the server and that's all.

Alternatively, you could use something like Java where you have more
flexibility and can run applets or java applications on the client end
(many people do have java, but not all).

The actual format of the data is meaningless at this point. You need to
first determine what you need for the game as far as communications, and
concentrate on that. That will help you determine what protocol you
need to use. And once you have the protocol, you can do about whatever
you want with the data.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[Sjoerd]

Re: Implementing a simple persistent web game server

On Aug 9, 2:30 am, Jerry Stuckle <jstuck...@attg lobal.netwrote:

The actual format of the data is meaningless at this point.

I agree. You should first use any protocol which is easy to work with
and is simple to use. That will no doubt give problems with
performance and/or flexibility. When you see these problems, you know
better what your program demands of the protocol and you can pick a
better one.

This means that you will be changing the protocol somewhere in the
development of your game. This means that you need to have an
abstraction layer, which handles the communication and has an
interface which is unaware of the underlying protocol.

[AeonOfTime]

Re: Implementing a simple persistent web game server

On Aug 9, 2:30 am, Jerry Stuckle <jstuck...@attg lobal.netwrote:

>
Most OS's and databases already cache the most recently used data in memory.
>
If you're going to use PHP on the server, you're probably going to be
using html, xml, etc. over HTTP  It really doesn't make that much
difference which it is, because you'll be using a browser on the other
end.  There are other ways to do it - but they will be much harder to
implement from the client end (where most people will NOT have PHP).
Also, please remember that HTTP is a stateless protocol - strictly
request from the client/response from the server and that's all.
>
Alternatively, you could use something like Java where you have more
flexibility and can run applets or java applications on the client end
(many people do have java, but not all).
>
The actual format of the data is meaningless at this point.  You need to
first determine what you need for the game as far as communications, and
concentrate on that.  That will help you determine what protocol you
need to use.  And once you have the protocol, you can do about whatever
you want with the data.

Agreed on all of the above. I still had a misconception about the
client/server architecture I would have to use. I was thinking in
terms of games that have a real client that runs on the player's
computer and communicates with the server. In my case, the client will
be a PHP script on my end with a local server script I will use to
access the data via HTTP to (hopefully) allow for semi-real time event
game events.

The initial question about the protocol was also motivated by the fact
that I plan on making the game code public at some point, and using an
established standard for the game/server communication would enable
developers faster access to it. There will be constaints in
performance though, so in the end I may have to go for something
proprietary anyway.

Thanks for the input!

[AeonOfTime]

Re: Implementing a simple persistent web game server

On Aug 9, 8:33 pm, Sjoerd <sjoer...@gmail .comwrote:

On Aug 9, 2:30 am, Jerry Stuckle <jstuck...@attg lobal.netwrote:
>

The actual format of the data is meaningless at this point.

>
I agree. You should first use any protocol which is easy to work with
and is simple to use. That will no doubt give problems with
performance and/or flexibility. When you see these problems, you know
better what your program demands of the protocol and you can pick a
better one.
>
This means that you will be changing the protocol somewhere in the
development of your game. This means that you need to have an
abstraction layer, which handles the communication and has an
interface which is unaware of the underlying protocol.

You are right. I was planning on building the server, and on the
client side have a class that handles all the communication with an
easy to understand API to access or send the required data. Then I can
change the underlying protocol if I need to without modifying anything
in the code on the client.