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 P5 Milestone

Link back to Fall 2001 Milestone 5


I'm a little confused on what a AGDaemon is. First the requirements say "Add the ability to have objects that are not part of the world" and at the end of the paragraph it says "(AGDaemons are classified as 'objects' in the world.)" Are they part of the world or not? David Lott

Sorry, that is confusing. I just tried rewriting it – please let me know if it makes more sense now. Mark Guzdial

I was just wondering about something, because there isn't much code to test this with at this time.. but for the AGDaemon, I am having problems with the current code, namely because whenever you evaluate the given statements by Compiler evaluate: or valueWithArguments:, self is nil. So the only way I got it to work was adding a 'me' 'parameter' if you will and passing self in through that - is this acceptable, and if not, then could someone give me a hint as to what I could do instead?
I played with this when I first wrote this milestone, and I figured out a way to get self bound the way you want it, but I can't figure it out now. So I made the change you requested: :me is now provided. Mark Guzdial

Secondly, can we assume that the World has some way of knowing about the daemons - ie through an addDaemon: method in world or something of the like, because I really don't see any other way the world would know about the daemons :(

Thanks.
/dev/random
You're right – mea culpa. I've tweaked the example so that daemon's have names (so that they can be looked up) and daemons are added to the world. But we still don't want the users to be able to reference the daemons directly. Mark Guzdial

We've looked into changing the context of the block itself. Can you give us any hints? Help us, Guz, we're self absorbed! KAYRAD
Now why would one wish to do this? Mark Guzdial
Will a daemon have only one stepDo: defined or can the developer (workspace code) do something like the following?
myDaemon stepDo: [:player :world | world print: 'hi'].
myDaemon stepDo: [:player :world | world print: 'bye'].

Ooh! I like it! Your call if that should work. Sounds fine to me. Mark Guzdial

Also, along with the above question, how is the world going to know about the Daemon's and when should we keep up with them (initialize: new, etc...)? If we are going to execute the stepDo: every turn, it has to be known by the world somehow. The provided workspace code does not appear to take this into account.
Now fixed – sorry! Mark Guzdial

Thanks,

Jonathan D'Andries

bomb stepDo: [:player :world :me |

Am I missing something, or should the above be,
"bomb stepDo: [:player :me :world |"
I know this is a picky little detail, but order can drive me nuts.

Thanks,

Jonathan D'Andries
Sure – being consistent is good. Mark Guzdial
Storing the daemons in rooms does not seem right to me. You say they are stored as 'objects' in the World yet you add them to a room. Do only the daemons that are in the same room as the player 'step' at each turn or do they do something special? I was under the impression that ALL daemons 'step' after every turn. If this is correct, why not just add them to the world so you won't have to go through all of the rooms to get to all of the daemons?
Absolut Squeak
hmm looks like this was already asked by /dev/random - same confusion right, you use the naming of AGDaemons instead of adding to world so players won't have access Webb
You're right, Absolut Squeak. But I don't want to hose students who already have the room working, so here's what I just added to the Fall 2001 Milestone 5 page: You can add to the room or the world. (My suggestion: If a daemon is added to a room, add it to the room's world.) And yes, you do have to step daemon's every turn. Mark Guzdial
Here are some questions I have about daemons:

1: Should daemons be able to know about other rooms/objects? In the example given, it implis that daemons can only talk to themselves, the player, and the world but with no way to talk to, say, a troll to make it do something. This is fine by me, but I just want to be sure.
If you can get to the World, you can get to anything. Yes, daemons should be able to talk to other objects. Mark Guzdial

2: Can objects interact with daemons? It seems like they should, but I don't see any information on how this would happen. For example, in the bomb example, there should be a defuser (an AGObject) in a room that would have a rule 'defuse' or something like that. Then, the object would call bomb stopTicking. But, how is the object supposed to be initialized so that it knows where the bomb is. It seems like AGObject should have the method addDaemon:.
Sure, objects can interact with daemons. (world object: 'bomb') flag: 'fuse' value: 0 could be executed by any object that can reach the world to reset the fuse (without defusing it). Mark Guzdial

3: Could you show us how you would defuse the bomb. That is probably the easiest way to answer my questions.
(world object: 'bomb') destroy or (world object: 'bomb') stopTicking should both work. Mark Guzdial

I posted these on the newsgroups like 4 days ago and haven't gotten a response. Should I post all questions here and not there?

Thanks, John Hable
Sorry – I went to Webnet in Orlando on Wed. and got behind. Mark Guzdial


We understand the given code completely. My problem is with how the daemons are stored. The example given adds it to room. Is add: another method that we have to write for room or should this have been "houseworld add: bomb"? If it is correct, then why are daemons stored in rooms and not the world directly because, logically to me, they are not part of a room and have no business being in a room?
Thanks
Absolut Squeak
See above...Mark Guzdial

Should you only be able to talk to a character if it is in the same room? I'm assuming so, because it makes no sense to perform an action on a player in a different room.
John Hable

Makes sense to me, John. Mark Guzdial

just a short question, I am assuming that leon should be added to a room right? cause he wasnt...

MotherSqueakers
Yes, but he wasn't because that's not a complete demo. Again, I'm giving you only a bit of the demo here and I expect you to fill in the gaps. Mark Guzdial



When the daemon ticks, should it tick at the beginning of the turn, the end of the turn, or does it matter? I'm assuming at the end. This would make a difference if you were trying to defuse the bomb on the last tick.

John Hable
Since the tick occurs BETWEEN turns, I guess you're asking if it should happen before the processing of input or after? I would think after. Mark Guzdial



Help! Somehow I opened a new inner world in Squeak, and I can't get it away. The entire window is covered in a grey square, and there is no way to close this "inner world." I can't do anything and I've lost my work! How do I close the inner world?



In the example for AGDaemon where it says:
kitchen add: bomb.
Should it be:
kitchen contain: bomb. ?
Everything from Nothing
nay, we still don't want the users to be able to reference the daemons directlyMark Guzdial, check out above discussion - Webb

If the player walked into a room that contained a bomb would that show up when we print out the description of that room? Also can a player defuse the bomb by typing "defuse bomb" or does it need to be just some random action we define in our workspace code to call the stopticking method of the bomb?
Tim Hardcastle

No, the Bomb is a Daemon which is not viewable from the Player. Mark Guzdial

So if we are to understand this, what you are saying is that the player can't perform any of the operations on an AGDaemon that he can on an object such as look, take, use, put etc right?

MotherSqueakers
Yes, that's correct. Instead, you could have a real object that gets manipulated which impacts the Daemon behind the scenes. Mark Guzdial

Ok so whay type of events would tell the bomb to "startTicking" or "stopTicking". Are these just going to be defined in the workspace code by stepDo: aBlockOfCodeHere , and executed after every player turn? And I am confused as to how a player is to defuse the bomb when it is not allowed to interact with it or even know it exists.

Tim Hardcastle
Imagine having an object that the Player CAN see (maybe a "fuse"), which when you do some verb (maybe "extinguish fuse"), sends the messsage (world object: 'bomb') stopTicking. Does this make sense? Mark Guzdial

Assuming that you perform startTicking when you perform initialize:, when else would you use startTicking? Possibly relighting the fuse to the bomb or something? (I'm not seeing the full purpose of startTicking, is it just there since stopTicking is?) Thanks.
Team Rocket (Rod Drews)

Just a question. I've noticed something funny about the bomb blowing up the world. This prints a message to the screen before it kills the world. Why does it print a message? Calling 'world quit' destroys the GUI and you never see the message. Am I missing something? Jared Parsons
My Gui is not completely destroyed when world quit is called. It only tells the inputMorph to delete itself. The display morph stays there until the user closes the window. Errol Summerlin

at the end of P4 you gave us this workspace code
box := AGObject named: 'box'.
box description: 'A Big Box'.
box longDescription: 'A Big Box that you can put things in (hint, hint).'.
box makeContainer.

gadget := AGObject named: 'gadget'.
gadget description: 'Some generic gadget.'.

gadget in: box.
kitchen contain: box.
then you expect this to work

take knife
put knife into box

This does not follow the format of the table declaration. I think you need

box when:[:player :me :world | me sent: 'knife'] do: [:player :me :world | player drop: (world object: 'knife'). (world object: 'knife') in: me.].

There is no way around this line being necessary for that command to execute properly and still have the rest of the when: do: blocks in table execute properly.

Why couldn't we just design the syntax for our workspace code ourselves? We are only allowed to design the trivial parts of our program and that upsets me. Getting the crummy workspace code to work correctly is the hardest part about writing anything in this class.
Errol Summerlin
oh boy, I didn't notice that extra code for box/gadget — I was doing exactly what you were saying, but then again it hasn't been working right for most AGWorld's I've been using... I kinda agree with you but I think contain: was left like this to be consistent with its previous use for AGRooms containing objects. For now (until I hear overwhelming reason) I'll try both (but probably most TAs will be grading without the when:do:) - I definitely see the inherent frustratioin though— Webb
so now I am seeing that the when:do: was ruining the tests. much easier now! Webb


Links to this Page