Software Engineering 3156

3-Oct-01

#8: Specification

Phil Gross

2

Administrivia

About asymmetric groups http://groups.yahoo.com Homework submission General questions to webboard

3

More Stuff?

Heartbeats?– Ping and Pong messages

Better logon mechanism?– Confirm password

Compressed map format? Need your feedback

4

Extensions

Find other interested groups, if necessary Talk to us Go for it Example: floating-point location instead of tile

5

Specification Details

We incorporated your suggestions More details More iterations needed – give us feedback

6

Requirements Doc

Partially revised Requirements-style 30,000-foot-view Use

Cases

7

Changes to Schema

Call it version 0.9 Fewer messages

– Delta has object-change info

Instances can have different image URLs Talking vs. attacking We have some sample messages More…

8

All Objects…

Have a unique ID Have a default URL where the image

representation can be found Client can cache images, or request all from

server on startup

9

All Components…

Talk to LDAP– Java JNDI interface; We’ll be giving you code

Talk XML– I gave you sample JDOM code

Talk over the network– We showed you basic networking code

Will be multithreaded– We’ll be talking about that at design time

10

The GameEvent Element

A message between components AIs and clients request moves Server evaluates them and sends deltas out to

all connected clients/AIs

11

Move And Chat

Movement requests– Checked for validity and timing, and either granted

or rejected

Start/EndChat– Enter conversation mode

Send/ReceivedText– Exchange chat messages

12

Attacks And Change

Attacked– Gives result of an assault

Gone:– ReplaceObject

Bot with a corpse, closed chest with open chest, etc.

– ChangeStats Flip a status bit, give health, hp, xp, gold, etc.

– StatusMessage Get a message from the server

13

Game Entry/Exit

Enter/Quit game– Client requests

KickGame– Server boots you

ExplicitSave– Client requests that current actor state be sent to

repository

14

Editor

Get data from Editor mode of client to server SendObject, LoadMap

– Plus confirmations

15

Data Transfer

MapData– The absolute info

GetAllInstances– Responds with AllInstances– All Items, Actors, and Bots

MapDelta– Changes since last delta– Deltas have a sequence number for detection of dropped

events

16

Exceptions

ExMoveForbidden, ExNoConversation, ExKicked, ExNoPermession, ExUnknown

17

GameMap Element

Contains all the information necessary to describe a game map, including graphics for the client and simple scripts for the AI

Basic entities:– Tiles– Objects– Bots– Actors (user players)

18

Map Element Parts

Metadata – basic info on map {tile | item | bot}set

– For tile and item, unique ID plus URL to graphic– For bot, initial state plus scripts

More on scripts later

{tile | item | bot | actor}instances– An instance of a class at a particular location on the

board and with its own instance data– Item instances have behaviors

19

Actors

Bots are an extension of this Have hp, xp, name, speed attribute And a status word

– 32 bit value– Each bit represents some accomplishment in the game– Interactions with objects and bots can set bits– Setting bit 31 ends game– Covers both inventory and plot progression

20

Bots

Have a state, and sometimes a target, plus possibly a master

State: current activity, e.g. attacking, fleeing, wandering, conversing, assisting

– State says what to do, but it’s up to the AI to actually do it

Target: for certain states, e.g. attacking Master: If assisting, this is the character to assist

21

Bot Scripts

For a given state, describe what to do if someone is seen, conversed with, or interacted with

Filter: check any of my and their instance variables

Result: if filter passed, these effects happen OtherFilter applied to all other “visible” entities,

plus target

22

Examples

Partial More coming Give us your requests/questions

23

Service Discovery

DNS– SRV records– SIP

X.500 / LDAP Jini Berkeley SDS SLP Wireless

24

Service Discovery

DNS– New: SRV records

X.500 / LDAP Jini SIP Berkeley SDS SLP Wireless

25

DNS: Domain Name Service

Primary purpose: “discover” machines– “Address record”: for example,

www.cs.columbia.edu = 128.59.16.149– Equivalent to an address book

Secondary purpose: advertise mail servers– “Mail server”, or MX record: cs.columbia.edu’s mail

is primarily handled by ober.cs.columbia.edu

26

DNS (II)

More recent: user-definable services, using SRV records– Domain controllers– Telephony servers– Generally done on a domain basis: “here’s the

service provider for domain X” Tools for DNS

– nslookup– host– numerous API’s (resolver built into Java sockets)

27

Others (I)

SIP: Session Initiation Protocol: Invented Here!– http://www.cs.columbia.edu/~hgs/sip– Basic idea: how to find someone to communicate

with– Primarily for telephony applications (Caller-ID, Call-

Forwarding, etc.)

Jini: distributed object-level service discovery– Appliance-aware services: embedded Java

28

Others (II)

Berkeley SDS: current research– Improve security and scalability of service discovery

mechanisms

SLP (Service Location Protocol)– IETF attempt, generalized SIP, less successful

NIS (Network Information Service)– Primarily user authentication, but can generalize– “Mirror” /etc files

29

Challenges for service discovery

Running out of IP addresses on which to host these services– IPv6

Lack of a standardized mechanism– Each service discovery mechanism has its own

target applications

Mobile services– Wireless technology: “find” the service physically

30

LDAP: Lightweight Directory Access Protocol

One popular solution to general discovery requirements

Very generalized white-pages mechanism– User-definable “schemas”– Common applications are network nodes and users

Based on DAP, X.500 Extremely popular

– ldap.columbia.edu: try it out…

31

LDAP (II)

We will be using LDAP for several purposes– Discovering server and AI programs on the network– Keeping track of basic user authentication and

information

LDAP server already set up on softe.cs.columbia.edu– Code examples will be covered in next week’s

recitation– Don’t need the code for specification document

32

LDAP Map 1: Servers

Mapref Title IP Port:int ExtensionList ServerType:char (0=Game, 1=AI) All can read, only servers can write (at startup)

33

LDAP Map 2: Actors

ActorRef (userID) ImageURL HP:int XP:int Gold:int Encrypted password Only game server can read/write

34

LDAP Map 3: Actor → World

ActorRef WorldRef LocationX:int LocationY:int Status:long WorldInstance:long

– Timestamp from when server was started Read/Write by server at player entrance/exit