Adventure Series Part 3
See part 1 and part 2 to get caught up. In our part 2 meetup (last night), we changed things up a bit. I decided that tackling the space mission to start was going to be a bit much (too much content), so I switched us to Action Castle, the first adventure in the Parsely series. And built out a mission config file with notes from the adventure using the structures that we designed in our first meetup.
After explaining the reason for the change, the group agreed, and we continued on our merry way. As we continued to define our mission spec, we figured out an API for plugging code calls into the spec. For example, you could replace an exit like this:
exits:
North : catacombs
With a code call like this:
exits:
North :
code: PluginNameGoesHere
params:
destination: catacombs
foo: bar
We built some sample code for exits, actions, and turns. None of this is final or anything, just building some samples so we could work through the the thought exercise.
As we continue into part 3, we will be focusing on actors. Do we want to split them into characters and devices? For example, you can give and talk to a character, but you really wouldn’t do that with a device. So perhaps it is best to think of them as different things. Or, perhaps they are both actors, but they load different roles to give them those traits.
We also hope to start working on writing some tests at the next meetup. Speaking of the next meetup, you should join us. It’s on March 14th at 7pm. For part 2, despite it being Valentines Day, we had a group of 10 of us at the meetup. Not bad for a holiday.
[From my blog.]
My little part in the greater Perl world.
If I remember correctly from my MUSHing years, it's better to define callbacks for actions. You can talk to a device (a telephone, maybe), and you don't want to limit your imagination by implementation, right?
I know what callbacks are, but you can you provide me with an example of what I might want to do with them?
I'm not actually in charge of the design here. I'm leading my group through them making all the decisions. But that said, I'm always open to bringing them ideas to consider.
I don't remember the details anymore, but each object had something like
on_listenandon_enter, and it was possible to defineon_action, too, for object specific actions.on_enterwould typically contains the target room or object, but you could specify e.g. who's allowed to enter; inon_listenyou could attach phrases to replies or actions, etc.