That moment when your auto-scaling, self-healing servers and continuously integrated and continuously deployed codebase all start working together seamlessly and flawlessly.
If none of that made any sense to you, then just understand this:
muhahahahah! *rubs hands together while laughing maniacally*
[From my blog.]
]]>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.
]]>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.]
]]>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.
If this sounds like a fun exercise, and you live within driving distance of Madison, WI, then I encourage you to join us at our next meetup on February 14th (assuming your significant other will allow you to leave the house).
[From my blog.]
]]>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.
Over the course of the series we hope to make a real working game with both a command-line and fully visual web interface. The group will be workshopping a Perl 5 version of it live at each MadMongers meeting. In addition, one of our members will be attempting to simultaneously write the whole thing in Perl 6. All of our code will be open source and published on GitHub, and hopefully also CPAN.
[From my blog.]
]]>I have an idea for a year-long series of presentations for MadMongers. Come listen and share your thoughts.
[From my blog.]
]]>My current project is https://tabletop.events and I've already begun preliminary work on the next.
]]>Almost 7 years ago I started working on building my second video game ever, a project that would be known as The Lacuna Expanse. Almost 6 years ago, I launched it and over the next year I evolved it as much as I could, before having to return to my other businesses. Luckily, you, the amazing community behind Lacuna Expanse picked up my mantle after I open sourced the game and continued to evolve it and make it your own. It has existed under the community’s leadership for 4 years and you have done a remarkable job.
Unfortunately, for the past 1.5 years, the game has been losing money on some months, and breaking even on others. The community has big plans to reboot it, but that has not yet come to fruition. As a business we cannot sustain the loss indefinitely, and as such have decided it’s best to make a graceful exit on our 6th anniversary.
The Lacuna Expanse will go offline as of October 1, 2016.
We are keeping Lacuna alive for thes next couple of months so that you can spend down any remaining essentia, and also so that you can gain a little closure as you complete your empires and say farewell to the friendships you’ve formed through the game over the years.
All is not lost however. All of the code for The Lacuna Expanse will remain open source, and I’m sure some people will choose to create their own local servers. In addition, several of the volunteers that have been working on The Lacuna Expanse over the past few years are continuing to make progress on a reboot of TLE under a new name. Once complete, it will have a host of new features. The name of the new game is Keno Antigen, visit the site and subscribe to be notified when it goes live.
Thank you to our community. Lacuna would have been nothing without you. We are forever thankful for your support and patronage.
JT, Kevin, John, Jamie, Tavis, and Graham
The Owners of Lacuna Expanse Corp
[From my blog.]
]]>[From my blog.]
]]>