From ernest%WS5%BEPC2@SCS.SLAC.STANFORD.EDU Wed Nov 17 20:18:08 1993 Return-Path: Received: from SCS.SLAC.Stanford.EDU by pundit.cithep.caltech.edu (NX5.67d/NeXT-1.0) id AA00651; Wed, 17 Nov 93 20:12:41 -0800 Received: from DECNET-MAIL (MAIL$SERVER@BEPC2) by SCS.SLAC.STANFORD.EDU (PMDF V4.2-12 #4747) id <01H5FNLFWJDC8ZG4JM@SCS.SLAC.STANFORD.EDU>; Wed, 17 Nov 1993 20:12:29 PST Date: Wed, 17 Nov 1993 20:12:29 -0800 (PST) From: "Ernest N. Prabhakar" Subject: WarPath: Getting a Move on To: WAR@PUNDIT.cithep.caltech.edu Message-Id: <01H5FNLFY58I8ZG4JM@SCS.SLAC.STANFORD.EDU> X-Envelope-To: WAR@PUNDIT.CITHEP.CALTECH.EDU X-Vms-To: bepc2::scs::in%"war@pundit.cithep.caltech.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Status: R 19 November 1993, Ernest N. Prabhakar Is anybody there? I feel like I'm starting get into things again, but its hard to sustain without any feedback. Are you all forwarding me to /dev/null, or just nodding in tacit agreement and waiting until we get back to more meaty issues? Or do you feel I am being painfully pedantic and are too polite to tell me to get a life... Anyway, I believe I have a simple protocol for handling movement. It is almost painfully sparse, but I guess thats good for providing generality. We can always provide a sample class demonstrating its use, if we want something more specific and detailed. COMMENTS on REGIONS First, a few more thoughts on regions. I think it would work best if a region: isa WarSpace isa Topology [note that protocols CAN 'inherit' multiply] hasa Terrain hasa WarMap which I believe would be written as @protocol Region id map; id terrain; id terrainAt:Location; @end [Yes, I'm using pseudo-code for the arguments] Note that the use of 'terrainAt' would allow a single region to have multiple terrains, if it wished. R - TERRAIN Secondly, (since I'm in a spare mood), I'm beginning to think our 'default' Terrain should have no methods - it is sort of an 'abstract protocol' that specific protocols can inherit from, if that makes sense. Of course, as we explore further we might find methods to put there, so it seems a good investment to define it now. For example, @protocol Terrain2D float height; float heightAt:Location; float heightAt:(float)x :(floay)y; @end People could define protocols for various common terrain mechanisms to include as part of the distribution. You could even have a terrain which supported the WarSpace protocol [I'm starting to dislike that name...], to keep track of its own position. Another tricky issue of terrains is that edge effects (crossing into/out of) are almost - if not more - important than crossing within a terrain. There may need to be a separate abstraction for that, but I hope not. R - TOPOLOGY Finally, I should add that the Region hierarchy should work like the view heirarchy. That is, later subregions should be on 'top' of earlier ones, and hence 'hit' locations should be calculated from the bottom up. The reason for the this convention is to allow children to overlap. Also, it may be that 'peers' only need to conform to 'space' and 'map' protocols, rather than the full' region'. In fact, perhaps we should think of them as 'portals' [exits and entraces], which may or may not leed to another region. The only important methods, after all, are being able to a) decide if a piece goes there after leaving here, and b) transfer the piece there. In that case, 'region' would inherit from that 'portal' (gate? exit?) protocal. WARPATHS Anyway, onto movement. The first construct we want is a WarPath, which is basically an ordered WarSpace: @protocol WarPath -(Location) start:piece; -(Location) end:piece; -(Location) step:piece; -(Location) back:piece; //i.e., there is some sort of internal counter // which can be set to either end or moved back and forth // the location returned is the current one -(float) length:piece; - region; @end Note that all the movement takes a parameter "piece". Most of the time a 'nil' value should suffice, if the path is independant of who traverses it. But some pieces will certainly have different 'steps' than others. Note that this is considered purely a geomemtrical construct - tracing a line in space. While it may consult a piece to shape the line, in general there is no interaction. All the interactions with terrain and other pieces is handled by our next protocol. WarMove I hate to use the term 'Move', because we overload it so much in English, but I can't think of anything better. Trip is the closest I could come, but it doesn't sound nearly as nice. A WarMove hasa path (isa? naww), and handles the mechanics of moving pieces. In general there will be some sort of formal informal protocol it uses to query and modify pieces as they move. @protocol WarMove - path; - setPath:path; - check:piece; - move:piece; - checkMove:piece; @end The latter return nil if the move (or check) fails, probably returns the piece if succesful. The 'check' is used to verify that the piece can take the move (i.e., is it possible given the rules and state of the piece). 'checkMove' basically means move if check is legal. It is included because it can often be more efficient to do both at once. And that's really about it. I had lots of ideas about how to implement move, but then I realized that it is much simpler to let each game put in their own than try to find a general case. The point is that these protocols tell everyone OUTSIDE what they need to know, and the internal details are 'confidential' matter between a move and a piece. The main reason for splitting up a Move and Path is to allow 'standing orders'. That is, there can be a well defined Path that pieces are expected to take, and pieces can be applied to it sequentially. Conversely, you can know that a piece is allowed a Move, and experiment with different Paths until you find what is allowed. The important distinction, is that the callING piece has "control", whereas the callED piece has "information". You want to export as much control as possible, while keeping the information hidden. At least, that is my understanding of encapsulation. Of course, you know that when we say a piece has "a move", we often mean that it could fire, resupply, or do other things as well. And that perhaps we should expand our abstraction to cover that. However, that requires a much deeper understanding of what a piece is. Which will be the topic of our next discourse: "War and Pieces"...