View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

KAYRAD P6 Design

P6 Design wishlist:

printing to individual characters, rooms (broadcast), and world.
Removal of anAGWorld player, replace with players to allow multiplayer symmetry
I say, kill off the players, only characters are needed. Jonathan Shaver
This follows with removing all the single player type interfaces we had to work around to use our design in M2-5.
A suitable replacement for the accept: sent: system. I need ideas, people.
See below. We could do everything using messages pulling all game action to the lowest level which would be our own Smalltalk style messaging system.Uploaded Image: sfithumb2.jpg
AGAction? Improvements to the parser? Make it?
Uploaded Image: sfithumb2.jpgWhat do you think about a context object of some sort? That way every object has a context and since every object parses, we can pass in context to the parser as an argument for parsing. Then the proper message can be sent to the proper object upon parsing.
Graham Coleman

Suitable embodiment for customizable messages. A message class?
Uploaded Image: sfithumb2.jpgMessaging is how Windows works, dude. Send message object with specific parameters which can be interpreted based on the type of message it is. Sounds like a good idea, but then you need to implement a message pump or something where objects poll for messages or where the message generates action on inception. What I'm talking about is deciding whether our system will be push or pull.

Push

meaning message is sent and action happens.

Pull

meaning action is sent and then it happens when the recieving object pulls it and processes it. Macintosh is push Windows is pull, and what will KAYRADAdventureGame be? AGAction sounds like a good message object or maybe AGMessage? Hmmm.
Messages when traversing room links?
Bidirectional attachment.
I don't like bidirectional. It eliminates the possibility for having one way traversal, like sliding down a chute that you can't climb back up Chutes and Ladders
Bidirectional attachment is just a macro to make things easier on for the game developer. 90% of all room transitions will probably be bidirectional. Graham
What does this mean? Uploaded Image: sfithumb2.jpg
Implementation of some examples of the passage obstacles we discussed earlier, closed doors etc.
Graham Coleman

Uploaded Image: sfithumb2.jpgUh, could we have those, uh... double guitars?


But seriously, we should decide once and for all if we're going to make this thing multiplayer or not. If we are then a completely different messaging system (in my mind a push messaging system) is needed and we need to work around that from the ground up. If not, then a messaging system isn't as important since everything is turn based and we can stick with what we have which is a really crappy pull based messaging system (you know, accept, sent, etc.) which we can improve to make everything more sensible.Uploaded Image: sfithumb2.jpg

I think that messaging should go and actions and interaction should come in. Objects can send requests to other objects and the character who you are can do the same thing. I think it would be very interesting to have a messaging system that can carry more than just indirection, but independent direction. What direction is up?
We need messaging. Things the player(s) are notified of are radically different than complex object interactions Graham

I say not multiplayer. It adds an immense level of complexity to what the writers of the game will have to do. Coordinating the multiple players and time driven events will be insane. Jonathan Shaver

I talked to Jonathan and thinks adding real time will be a hassle. So, here is what I would like to propose as a compromise:
We remove all the interfaces that assume single player, and provide alternatives. We keep the command based step time.
Here are the interfaces I have a problem with:
anAGWorld print: (this might survive, but it will do something different. it will message all objects in the world)
anAGWorld player: (I think this should be changed to players, or characters, if we choose to remove AGPlayer, as Jon suggested)
anAGObject verbHandler: (to be changed to verbHandler: actor:- already implemented and used. Likewise with indirectVerbHandler: actor:)
accept: and sent: must have suitable substitutes.
Graham Coleman

I would think that everything would have a general behavior, and that means that Objects would have a behavior model. Jonathan Shaver
I can see this happening. Graham Coleman

I have a radical redesign proposition. What about three and only two types of game things. One: There are objects. All other types of objects (world, player, character, daemon, etc.) are instances of an object. To make things simpler for the writer of the game we can provide prototypes such as world, character, player, etc. These prototypes can have properties preset, but the objects created can still be fully manipulated and changed. I think that we should also give the game writer the ability to create prototypes so that if we miss something, then the game writer can create a NEW PROTOTYPE. For instance, if Guz didn't say anything about daemons, the game writer can write daemon using the object prototypes. Two: There are requests. All objects send requests. Requests can have states like player and you can produce different types of requests, request prototypes. I propose two initial types of requests, mandatory and voluntary requests. Two objects in a barrel
I'm going hardcore with this, but here we go. Think of an object that isn't in your head. Daemon was a good one, but you've heard of it so I can't use it.
Okay, Graham wants me to write some code or something so here goes...


myCat := Cat new.
myRoom := Room new.
aBlock

Cat in the Hat|

I was thinking about maybe adding an enumeration for the worlds players, like world playersDo: block. makes it easier for someone to manage multiple players from the world. Graham Coleman

Link to this Page