#madmongers

See parts 1, 2, 3, and 4 to get caught up. When last our adventurers met we whipped up a bunch of tests so we could see that our code was working and that we could read our YAML spec file. You can see all that work in our git repository. 

See parts 1, 2, and 3 to get caught up. When we last left our heroes they had completed the spec for the adventure game, and started writing some basic pseudo plug-ins for things like using an item on an actor or a location. 

Between our last meet up and now, I’ve taken the spec and turned it into a series of Perl modules that you can now find in the git repo. I made the main Adventure module a Singleton so that all the elements of the game can be easily referenced without dealing with crazy crosslinks and ref counts, and passing variables to and fro until the cows come home. That module just acts as an index and all the actual functionality can be found in the various modules and roles. 

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. 

A couple weeks ago we had our first meeting for the Perl Adventure Series. Despite a terrible ice storm we still had 3 new people turn out in addition to our regular cast of characters. I hope we see them (and more) back. 

During the meetup we set up our Dist::Zilla config file, and a new GitHub repository for the adventure series. And we got started designing the mission data structure. 

We had a great time discussing all the implications of this design. There was a heated argument about including code snippets inside the config file in order to keep the game engine generic. However, I’m going to argue to the group that we should be putting these code snippets out into individual modules (or perhaps roles) and then just name those plugins in the config file. I hate the idea of code in a config file. It makes my skin crawl. 

Beyond the code in config debate, we figured out that we were going to use YAML as the storage structure for mission files. Not for live mission data, but just as the initialization data. I think the YAML is hard to read given the big blocks of text we need to include in it, but YAML is a lot lighter than XML, and not as strict as JSON, so the group decided it was best. 

We figured out our data structures for rooms, items, and other initialization data. We still have to figure out the data structures for the actions the player is allowed to take on any given item as well as in a room. I’m sure the robot that the player can control in the Space Mission will add a whole new mix of variables into the mix. 

Last month I offered a bold proposal to my Perl Mongers group (MadMongers): Let’s create a video game from scratch as a learning exercise!

At MadMongers we give a talk every month on some area of Perl technology. However, we almost never put those lessons into a practical hands-on form. Yet, we have members who are everything from “I have never used Perl.” to “I have used Perl every day for 20 years.” So my proposal was to build something relatively simple so that we could build it in roughly 12 two-hour sessions over the course of a year, but complicated enough to have real decisions we could make about its design. That way we could put to use skills like using git, creating a CPAN distribution, writing tests, using data storage mechanisms, parsing text, creating user interfaces, making web services, etc. 

When I was at Gamehole Con last year, Andy Looney (creator of Fluxx) introduced me to a series of games called Parsely Adventures by Jared Sorensen. If you have ever played old text-based adventure games like Zork, then Parsely adventures are basically that except where one person becomes the parser (the computer), and all the other players enter commands by saying verb noun combinations to move the adventure forward. Well, my idea here is to turn this back around on itself once more and turn one of the Parsley Adventures back into a computer game like Zork! 

I’m calling this the Adventure Series, and our first meetup is next week on Tuesday at 7pm (US Central). There we’ll be setting up the git repository, creating a Dist::Zilla config file, designing the initial mission data structure (most likely in YAML), and writing a few tests. If you can make it, you should join us. This should be a grand adventure in more ways than one.