Game Design

Pat Wendorf beholder@bespin.dhs.org
Tue, 28 Sep 1999 11:18:29 -0400


Now that I can post to the list, I might as well post some of my
thoughts:

1)
The server could be prototypes in a HLL until we reach a concencus that
it's purpose is absolutely defined. i.e..  Why not make this Data
Exchange layer in something like Python which it's easy to modify the
major things quickly, then we can move to programming it in C++.  With
this in mind, I'll make the Server and Client data layers in Python
(unless someone wishes the client to be done in Visual Basic, either way
I'm not touching C++ to do something that's going to change on a daily
basis :)

2)
I'm still worried that our scripting language is too complicated.  I
finally took a look at the web page  and the current AHLL design
encompasses many features that may not be necessary.  We are rendering
information to a "semi-dumb" client.  In other words when a character is
walking around on a screen, I imagine the server would send the tile map
(upon changing to the current screen), and then all other supplemental
information like other players on the screen, and what they are doing or
where they are moving to.  The client uses these numbers the server
sends across to show the proper graphics for each tile, and each
character, and also information like ambient sounds and music could be
sent across also... So in essence the only primitive is the "Room" and
all scripting will center around this object. This is getting confusing
so I'll show an example.

In this example character "Bob" is walking from World 1, Area 1, Room
X1, Room Y1 -> World 1, Area 1, Room X2, Room Y1.  In other words he's
walking one screen/room to the right. The server will send everything
except what's in <>.

<server response to change screen>
<static information>
Location: W1, A1, RX1, RY1 <this is the physical location within the
game world, it shows up in the title bar of the client>
Room Name: Dark Haven Square <this is the room name and shows up in the
title bar of the application>
Tile Map: 1,3,5,7,5,3,5,7,9,4,3,-3,4,3,4,3,4,2,3,4, <etc.  This is a
numeric representation of the room tile map>
Music: Forest Song #2 <music for this room, I'm thinking it might be
better to assign music to areas rather than rooms?>
Ambient Sound: Wind <ambient sound>

<dynamic information on load>
Character "Bob": 1,5 <this is the first character rendered, ie. the
player ;) NOTE: location is given in X,Y>
Character "Sue": 1,9 <this is another character on the screen>
Mobile "Rabbit #2": 7, 3 <this is a mobile that is inhabiting this room>

<events that happen while character is on screen>
Character "Sue": 2,9 <"Sue" moved on screen>
Character "John": 23, 1 <New character has appeard on screen>
Talk "Sue": "Where the hell am I" <"Sue" broadcasts message to all
characters on screen, aka. talking out loud>
Weather Change: Cloudy <screen gets darker because of clouds, mabye
cloud effect shows up>


In other words, the server just keeps sending status messages, and the
client (which has to be programmed to interperet these specific
messages), will render the scene accordingly.  So the scripting language
would be something like this:

<developer prompt>
World(1).Area(1).Music = "Forest Song #1" <changing song for world>
World(1).Area(1).Room(1,7).Map(1,9) = -3 <changing part of map>

In essence we can control any portion of the game this way, and we still
have the essence of the goal of the project, which is a cool online MUD
type game where many characters can interact, and the game designers can
change every aspect of the game while online.

But I must leave for school now, I'll finish this later.

--
-------------------------
Pat Wendorf
beholder@unios.dhs.org
ICQ: 1503733
-------------------------

Success is as dangerous as failure, hope as hollow as fear.