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

Questions on Fall2001 P3 Milestone

Go ahead, ask away, on Fall 2001 Milestone 3.


Can we change the existing architecture of our design from p2 in order to make p4 and p5 more logical? We will probably need more abstractions than what was originally programmed in p2.

Absolut Squeak
Absolutely! That's what we expect! Re-designing as you learn things is a good sign! Mark Guzdial

Can we assume that object's names will only be one word long? If we don't assume this it makes it very ambiguous when matching the indirect object rules. Squeaky Clean Squeakers
Nope. "ugly troll" and "big troll" are both valid object names. Mark Guzdial
And those would be two different objects/characters. Correct?
Absolut Squeak
Yup! Mark Guzdial

Our question concerns the doVerb message sent to AGObject. Does this method accept a set of static commands (such as look, take, die, etc) OR are these custom commands that the developer can set up? If they are static, what is the complete list of static commands that this should support?
The static commands are the ones listed in P2 and the new ones added in P3, e.g., "put" with indirect objects, "take", "look", "go", etc. Using doVerb:, you should be able to reference static or newly defined verbs (e.g., via the verbHandler method from P2). Mark Guzdial

In our P2 design, our AGObjects did not know how to look, take, etc. Most of that logic we put in our AGWorld class. Does this mean we need to move that funcationality over to the AGObject class? It looks like you are requiring our objects to be able to look, but in real life objects do not know how to look. We hope you can clarify why the object requirements are designed this way. Gark Muzdial and Associates
These aren't real life objects: They're AGObjects, "Adventure Game Objects". In adventure games, all objects do support being looked at. It is the AGObject's responsibility – they're the only ones that know their own description. The World is not responsible for how objects look. Yes, I strongly recommend that you move your functionality from the AGWorld to the AGObject. I expect that you'll lose points for that design on P2. Mark Guzdial

Concerning P4 requirements: is the HTTP web interface supposed to be accessible via a standard web browser?
Gark Muzdial and Associates
Yes – on Questions on Fall2001 P3 Milestone, we decided Netscape 4 would be our baseline. Mark Guzdial

Concerning p5: You have created an AGDaemon called bomb in the first example. Then you add a flag called 'fuse' with the value 0. In the next line, however, you access a variable named fuse. This does not seem to make sense. Do you mean to say something like: self flag: 'fuse' value: ((self flag: 'fuse') + 1) to increment the fuse's value by one?
Gark Muzdial and Associates
Absolutely – thanks! I've fixed it. Mark Guzdial


Layering in M4:

We have a table.
Make the table a surface.
Put a chocolate cake on the table.
Make the cake a surface.
Put trick candles on the cake.

(i) If the troll eats the table, does the cake and the candle fall to the ground with the candles still on top of the cake? Or is it assumed that the troll ate the table and everything on it?
Hmm, guess that's up to you to define. "Eat" isn't a required verb. The physics is up to you. Mark Guzdial

(ii) Now make cake a container.
Put a hot girl in the cake.

If the troll eats the cake, does he eat the hot girl, too? Or does the trick girl jump out of the cake and onto the table holding the flaming hot candles between her teeth? If not, what happens to the candles... because that's what everyone's really interested in.

Git yo' Squeak on!
The Troll isn't a Container. Right now, Characters can't be Containers, so the Troll can't contain anything. I'm not particular about that. I'm mostly interested in how you handle the fact that most things won't be on an explicit surface, but some will, and descriptions and object structure must reflect this. Mark Guzdial


We have some questions about whether 'processEvents', and 'currentRoom' are to be used by the player as commands, or they are functions that are part of the internal workings of the program. If so, what are 'processEvents' all about?.
MotherSqueakers
No, they are internal methods. AGRoom must understand 'processEvents', e.g., 'kitchen processEvents.'. Mark Guzdial

Will future iterations of this design up to P5 be expected to run specification code line by line, or shall we design the interfaces too?

Graham Coleman
I'm a little confused by the question, but I'll try a few answers and you let me know if I got it :-). Yes, P5 should be able to execute P2 or P4 example code. P6 and P7 can be any kind of method interface you want. P4 and P5 should have user interfaces that work both in Morphic and via the Web. P6 and P7 user interfaces only need to work in Morphic, with both the original Telnet-like interface and Wonderland extensions. Mark Guzdial

We'll try to clarify our previous question:

(i) We have a table (it's a surface). On top of the table, we put a cake (cake is also a surface). On top of the cake, we put a candle. So far so good.

Say the table is somehow destroyed (bomb, termites, whatever). Does that mean that ONLY the table is destroyed, and the cake maintains it's layered integrity; or does it mean that the table and everything layered on top of that surface is also destroyed?
I would think that you would retain the layered integrity of the cake. Mark Guzdial

(ii) We have a box (it's a container) with cookies in it. Say the box is somehow destroyed. Does that imply that ONLY the box destroyed; or are the box and the cookies in it are destoyed, too?

Git yo' Squeak on!
I would think that the cookies would go, too. Mark Guzdial


We have an object (that is a surface) that is on another surface that is on another surface: like candles on a cake on a box on a table. Will the object be asked where it fits into the layer heirarchy, or will we only need to tell the user this when he looks at a room ( "You see: candles on a cake on a box on a table. ").
I think the latter is okay – just local knowledge is fine. Mark Guzdial

If the former holds, how much should the BOX be able to tell if asked, based on the following layer heirarchy:

i i i (non-surface)
CAKE.CAKE.CAKE (surface)
BOX.BOX.BOX.BOX.BOX (surface)
TABLE.TABLE.TABLE.TABLE (surface)

Git yo' Squeak on!
Box should know what surface it's on, and what's on it. Box should know its contents. Table doesn't need to know that there is a Cake on the Box. Mark Guzdial

Daemons are defined as objects that are not part of the world. However, is a daemon supposed to have the attributes of a regular AGObject, such as containing other objects, being a surface, and being takeable? We weren't sure if "object" in the description was in the general sense or in the sense of AGObject.

Git yo' Squeak on!
General sense. Daemons might manipulate an object, but they are not objects in the AGWorld. Mark Guzdial
Right now my group has AGPlayer understand how to perform actions such as look: , go:, take: . But according to the Milestone 4 description we are to add a doVerb: method to each object. I dont see how it is an objects responsibility to know how to look at itself... yes it needs to know its description, but shouldnt all the actions be done by the player?
NO FOOD OR BEVERAGE ALLOWED BEYOND THIS POINT
I answered this above, but wrt AGWorld. The object is the only thing that can figure out what impact the verb has on it – not the Player, not the World. Mark Guzdial

Our group was thinking that it would probably be better design to have AGObject and AGCharacter subclassed, such as takable/nontakable objects, etc. We don't see how this is possible with the current implementation of the game, since when you create a knife you say 'knife := AGObject named: 'knife' ' and then after the object is created tell it that it is takable or not takable. Is there a way to turn an AGObject into an instance of one of its subclasses after it has been created?
Gark Muzdial and Associates
I completely agree! Fix that in P6. In P3, P4, and P5, live with this design. Mark Guzdial

General sense. Daemons might manipulate an object, but they are not objects in the AGWorld Mark Guzdial

so does this mean that the bomb has no physical manifestation? how can the player defuse the bomb if he can not see it? the bomb is the daemon right? I am terribly confused by this.
can an object be both a container and a surface?
I.E. can you have a box that has a sandwich on top of it and an ugly troll inside it waiting to ambush you when you try to take the sandwich?

N'Squeak
ok..so prism is down and I can't e-mail my group, but I am wondering if CRC cards should care about inheritance? We have an AbstractObject class that deals with the stuff rooms, characters, and objects have in common, do I need to include the things it takes care of on the object, character, and room crc cards? or can I put somewhere that the character is an abstratobject? is one of its responsibilities be an abstractObject?
Errol Summerlin
For UML Class Diagrams and Descriptions, do we also have to turn in descriptions of classes and their methods like last time?
Kevin Steely
CRC cards don't care about inheritance. An OOD description includes class and method descriptions. There could be an AGObject bomb that talks to the fuse. Mark Guzdial




Links to this Page