Re: client server part 1

To: crossfire@ifi.uio.no
Subject: Re: client server part 1
From: korg@rdt.monash.edu.au (Cameron Blackwood)
Date: Fri, 14 Oct 1994 14:09:30 +0000
In-Reply-To: Remember Oct 13, 20:42 when you rambled....
Reply-To: c.blackwood@rdt.monash.edu.au

I am at home with a horrid cold at the moment, so you may have to
suffer through some ravings.


Comments on protocol document:
------------------------------

I should state from the start that I am doing this from the view of game
fairness not ease to impliment or efficency in the protocol. I would
like to impliment NPCs as client processes to allow more smarts with
less impact on the server. :-)


Because people are too lazy to read the whole thing, here are some of
my main points:
  * change <locx> <locy> to <locx,locy> and allow ranges.
  * free ITEM command more, to allow
    ITEM 1 arch wooden_floor -2-2,-4-5 or floor from (-2,-4) to (2,5)
    MAP -5--2,0-4 slimy_pond_water
    in one command
  * make client more 'I am the universe' in its view (no global info).



Detailed destruction:
---------------------
  | >GENERALITIES

  | >Each packet consists out of one line of text terminated by a newline
  | >(0x0a) character.  Line lengths of up to 4096 characters (including the
I like the text idea.

  | I see no real problems in this area of the protocol.  However, see
  | notes on startup (below) about extensions.
I see a few in that for my liking, I would rather the client was
unable/unaware of its 'universe'. In that it did not have to give the
server (x,y) values, but rather relative movements.


  | STARTUP
  | =======
  | C->S: PROTOCOL (revision) This is the revision number that the client
ok. Why a number? Why not something like
PROTOCOL client 4.3 +pixmaps -sound +super3Doomlikegraphics protocol3.4

  | C->S: SEND_IMAGE_NAMES
  | S->C: I_IMAGE (image) (image) ... - the I_ stands for initialization stage.
Maybe do this on a per map level? I guess once at the start is fine.
How about:
C->S: SEND_IMAGE_NAMES <map>
<map>= "current", "all"

  | C->S: SEND_ARCH_NAMES
  | S->C: I_ARCH (archname) (archname) ... - this sends all the archetype
same.

  | >C->S:LOGIN <client-version> <name> <password>
<client-version> may be related to <revision> in the protocol
command. I see little need for both.

put <name> and <password> first so <client-version>, if used, can be
multiple strings.





very optional stuff:
--------------------
  | C->S: STACKING (depth)
No. Dont like it. I would rather that the server kulled what the
client could see if it was required, to all equally. I see the
protocol argment for transmitting the minimum and if a client isnt
going to use the extra objects, then why send them.


C->S: VIEWRANGE (distance)
C->S: HEARRANGE (distance)

I like the idea that the clients only relate things locally to
themselfs. So they dont store or use x,y coords, but rather treat
everything as centered around themselfs, like 0,0 follows them around.

The above 2 commands set the range that the server need worry about.




  | >VALID COMMANDS FROM THE SERVER TO THE CLIENT
  | >============================================
  | >MAP <locx1> <locy1> <image1> <locx2> <locy2> <image2> ...
how about
MAP <locx1> <locy1> <image1> [<image1a>...] <locx2> <locx2> <image2>...

where images cant start with numbers so one can distinguish the
end of a list of images from the next (x,y). Because we have the
possibilty of ranges, we can go:
MAP -5--2,0-4 wall

This needs to be totally retransmitted each move or you must require
that the client and server keep a history of vision. This is fine for
the client, but not nice for the server. Dunno solution.

  | Note that all (locx,locy) pairs are map relative, not center relative (in
I would prefer that the server did the conversion to abolute. It
stops the client cheating.


  | >UNMAP <locx1> <locy1> <locx2> <locy2> ...
Not needed it you require retransmission of all images. I guess its
not too hard to support storage of images in the server, its just not
what I expect the server to need to do.


  | ITEM <length_flags> <tag> <locx> <locy> <arch_name> <flags> <weight>
  | 	<name>
I suggest we replace <locx> <locy> with <locx,locy> (and forbid other
things of this format). Also loc[xy] may be a range such as 4-12 or
4--3.

IN becomes <0,0,item#> or maybe a length_flags field.

Thinking about it, I would rather one item per like in the format:
ITEM <tag> <fields> [<fields>...]

where a tag of 0 means dont bother storing this object.

where <fields> is something like (for example):
  weight  44
  arch sword
  state  gas
  color  pink
  rads 4000
  magic "earth air fire beer"
  eyes	12
  music "my name is prince"
  material paper
  faces north
which may be used or ignoreed as the client sees fit. 

This opens the possibility to do the following:
ITEM 1 arch wooden_floor 1-4,2--3
or item wooden floor from X=1 to 4 and Y=2 to -3. This would make
mapping quicker.

  | The number of objects is not sent - that will be contained in the name.
Hmmm.

  | I also want to be able to use a local archetypes file if possible.  Not
I like this idea. Coool.

  | >VIEW <number>
  | >After this command the client considers the item with the tag <number>
  | >to be the viewpoint item and will always try to center the map around
  | >it.  This is typically the item which is the player object.
Whats the use of this? So my client can move onto a map and then view
it from all locations. COol, who needs magic mapping?

Hold on this is a server to client command?!? I dont see a use for
this. Maybe looking through portals or something? Once again, a
server function. 

Ahh so players are objects? Hmm dont like that abstraction. I would
rather that the client gets a 'i am the center of the universe' view.

  | MOVE - same as the client command that is sent to the server.
ok.


  | C->S: MOVE 123 44 45
I would rather have a relative move function. SO the client goes
move 0 -1   for north
move 0 -5   for north 5 squares, the server will truncate this if its
            too far, or maybe set it as a 5 turn goal.

  |  IF anyone has good ideas on how to handle this area, I would
  | be interested.
cool then. :-)


  | S->C: MAP 40 50 wall 41 50 wall 42 50 wall ...
  | S->C: UNMAP 40 40 41 40 ...
one way.

  | and new object that appear are sent:
  | S->C: ITEM 642 45 50 1 orcimage Orc chieftain
  | Orc wants to attack player, so it moves towards him:
  | S->C: ITEM 642 45 49
  | S->C: ITEM 642 45 48
cool enough.


  | >TEXT text
  | >PLAY <sound>
fair enough.

  | >STAT <stat> <current> [<maximum>]
STAT <stat> <current> <maximum>


  | >REQUEST <name> <type>
  | >TRANSMIT <name> <type> <length>

  | The server will send the data as fast as it gets request.  Thus, the
  | client should only request a little at a time, otherwise the socket
  | buffer might overflow (if on a slow connection), and the server
  | will then terminate the connection.  By default, the size of the
  | socket buffer is set to 32K - this is pretty big.
Select returns if a write will block. 

  | >ERROR <type> <...>



  | VALID COMMANDS FROM THE CLIENT TO THE SERVER
  | ============================================
  | >LOGIN <client-version> <name> <password>
  | 

  | MOVE <number> <from_x> <from_y> <to_x> <to_y>
  | >APPLY <number>

  | Location of the object should probably be sent, as in the MOVE command
  | above.
Not if the client dont know the global position.

  | >INVOKE <spell> <locx> <locy>
  | FIRE <flags> <fire_type>
how about:
ATTACK <x,y> <attacktype>
ATTACK 0,-1 fireball
ATTACK 0,-5 4434	being the users sword, the -5 will be trincated to -1
			by the server.
ATTACK 0,-1 teeth

  | >SAY <...>
  | >REPLY [YES|NO]
  | COMMAND (command):  This is a simple extension.  Various servers may
how about:
INPUT <question_type> [ <text> ]
OUTPUT <type> <data>

INPUT yes_no The sage picks his nose. Want to buy some paper?
INPUT string 485754 * 347324 equals
INPUT user_list
user_list may generate a series of OUTPUT replies, such as.

OUTPUT admin_info korg rgg dwagon root root NPC

OUTPUT string The policeman walks up to you "Do you feel lucky punk?",
OUTPUT string he says.

  | Only optional commands should use the COMMAND name.  A required command
  | should be part of the protocol.
Maybe internal info like mapinfo and users should be kept in a faked
item type (say a book or scroll that one can send read requests to)


--
`Rev Dr' cameron.blackwood@rdt.monash.edu.au,    << skeptic, virtual goth >>
  +61 3 905 3403/809 1523      >> BSD Unix, C/C++, genetics, vi, ATM, HW  <<
  Monash University of Oz.    << Clemens & McGoohan: cool minds & great TV >> 
______ GCS d? p--- c++++ l u++ e++ m+ s/+ n- h f+? g+ w+++ t++ r++ y+ ______
"You're wasted here.. You should be back in the 3rd world killing communists."
"This is the 3rd world and you're sturing up the natives. We have our
own interests here on this island, quite apart from the airbases there's the
golf courses."            -Jerry Grogan and Darius Jedburgh. Edge of Darkness.
Prev by Date: More improve weapon thoughts.
Next by Date: Re: client server part 2
Prev by thread: More improve weapon thoughts.
Next by thread: Re: client server part 1
Index(es):
- Date
- Thread