Quote Oddity

2 views
Skip to first unread message

amshahan

unread,
Apr 30, 2014, 10:26:54 PM4/30/14
to cs...@googlegroups.com
So one thing that has giving me issues is dealing with the way that the quotes have been implemented in dudefighter.txt.

(define checkpoint ('(Campfire)))

I've figured that this line sets the value of a checkpoint variable to 'Campfire', {'checkpoint' : 'Campfire'}. Although what this line ends up doing is returning a single list ['Campfire']. I'm not sure why these quotes are implemented this way, as in past labs and examples, the quote function was shown with a single variable or value. 

In this case, I end up having to parse out the value of the single item in the list and then use that value. That's working in some cases and not working in others, so I guess I'm wondering why this is implemented this way in order to figure out if there is a reason to it and then how I should go about using this ['Campfire'] list with a single value.

Any insight on this would be appreciated.
--Austin

Quinn Jones

unread,
Apr 30, 2014, 10:49:04 PM4/30/14
to cs...@googlegroups.com
Yeah, noticed that too, all of the weapons are done the same way returning a ['True'] or a ['False'].
Sadly, the only way to deal with it is say you assigned it into the variable foo would be to call foo[0] to get the string out.
This is a problem with the edges though since you might want to read in the fully specified names asis from the text so I might have 'Campfire' or ['Campfire'] in the same variable.  So you have to check it with isinstance(foo,list) first to see if it's already a string or if you need to rip the string out.

--Quinn Jones


--
You received this message because you are subscribed to the Google Groups "cs310" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cs310+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

dlu...@mix.wvu.edu

unread,
Apr 30, 2014, 10:44:11 PM4/30/14
to cs...@googlegroups.com
I’m pretty sure the checkpoint is supposed to be its own function, and when called, it will return you to the last node which set a checkpoint. For example, if you make it to campfire, you save its state, and then whenever you die or something like that, you go to the checker node. This node’s only exit is checkpoint, which should restore the state you were at during your most recent checkpoint definition.

Checkpoint should restore the environment in lispy, and anything that changed in your stagetext reader, and the edge of checker should be the checkpoint location, and you resume where you let off.
As to why it is in a list, I’m not sure, because ‘ (Campfire) should return the Token ‘Campfire’ which you can then search for the node to point to and set it as the edge of Checker, and then when you go to that edge it restores the Env and lets the player return.

If you don’t store the environment then the player might have items they should not and such at the last checkpoint, which really wouldn’t restore a checkpoint. It would just be a portal back to a point in the stagetext, which is only a portion of the problem.

You could possibly write checkpoint to handle both a string token and a list, as if it isn’t a string, it will then be the first element of the list.

Sent from Windows Mail

--

Quinn Jones

unread,
Apr 30, 2014, 11:33:11 PM4/30/14
to cs...@googlegroups.com

Actually it shouldn't save the environment as that in fact will break it, near the end of the text there are the nodes left and right in those you go to the left, get a key, and then use checkpoint to go back to the intersection and use the key on the door to the right.  If we restored the entire environment like you say then the key is "lost" and you can never open the door.  Look to the fact that the checkpoint is usually changed by define meaning it's a variable and what you really need is the ability to link the edges at run time.

--Quinn Jones
qjo...@mix.wvu.edu

dlu...@mix.wvu.edu

unread,
Apr 30, 2014, 11:39:24 PM4/30/14
to cs...@googlegroups.com
Looking at it now I suppose you’re right. I believe an earlier version of the assignment had a section that dealt with saving the environment. Technically though, if you die checker is the only edge, and then the environment should be restored to what it was at that point. Just imagine any video game you have played ever, if you die, you load the last saved state…
This can be achieved without breaking the stagetext if you restore the environment when checker is the only edge, or also, if you restore the environment not IN checker, but whenever checker is an option that you may go to.
The reason why this would work is that the key is an OnExit event, so even though the environment has been restored, you still have the key, as it is given to you upon leaving that node, not entering it where checker restores the env. Also, when you get back to LookAround, it defines the checkpoint again, so this will save your state WITH the key.
As far as whether or not it is a requirement though, it is not stated in the directions, so either it isn’t necessary for grading or it it’s only worth like half a point. To be honest, there are a lot of checkpoints. You would have to look and see if you can get to a checkpoint after reviving without visiting a crucial node. If this doesn’t occur then it is a pointless feature and a waste of time. If you CAN skip nodes after dying though it would break the continuity of the game, which would make it appear to be a requirement.
So more or less, it comes down to Menzies or Cheyenne to rule in on whether or not the environment should be restored when you die.

Sent from Windows Mail

Reply all
Reply to author
Forward
0 new messages