One of my main goals for Hamacon analog gaming was running events. This is typical when you’re talking about CCGs (tournaments) or RPGs (one-shot adventures), but I wanted to extend this to board games. Specifically, I wanted to introduce games that were fun or interesting, weren’t necessarily popular (i.e., you wouldn’t find on Tabletop or similar shows), and weren’t necessarily easy to learn (i.e., not Cards Against Humanity or Love Letter).
I updated one section of my “Hamacon Analog Gaming Bible” after every event: a list of people who had run something or otherwise provided content to the event. (This is the primary reason I’m writing a blog series instead of just making that document public in Google Docs.)
I am not a people person. I can handle all manner of technical details (like scheduling, teaching games, planning procedures, etc.) but as soon as I have to send an email or make a phone call I get antsy. Rest assured, I didn’t keep this contact list so I could send out an email blast as soon as I started planning.
The main purpose of your contacts list is to remember key details. Who are they? What did they do? How do you successfully get in touch with them?
If you’re running a free play board game library, you’ll need to have some sort of check-out system. It doesn’t have to be complicated–and it’s better if it’s not–but there’s a surprising amount of refinement you have to do to get it right.
My process uses two index card boxes labeled “checked out” and “checked in.” (If you haven’t read the “toolkit” post in this series, it will be helpful to cross-reference.) When someone checks out a game:
The next section of my “Hamacon Analog Gaming Bible” is a setup and teardown checklist. There’s nothing revolutionary here, but it’s helpful to remember a few things that will make your life easier down the road.
Over my years running Hamacon, I built up a Google Doc I called the “Hamacon Analog Gaming Bible.” These first few posts will be an adaptation of that. The first section is my packing checklist, so let’s start there:
Five years ago, I was offered the chance to run analog gaming for Hamacon, a small anime con run by some of my friends in Huntsville. My only qualifications were (1) I had played tabletop games at cons before, (2) I own a lot of board games, and (3) I was willing to drive a car full of those games 3 hours away.
It was a great experience, mainly because Hamacon had a dedicated, knowledgeable community running it, and that community had the freedom to do some interesting creative things.
In my case, I wanted to build an analog gaming room for people like me: somewhat socially awkward, and interested in trying heavier or offbeat games I might not be able to experience elsewhere. I didn’t necessarily achieve that. Even if I had, that’s a very narrow focus which isn’t necessarily serving other attendees wants.
While I’ll likely be on a con staff somewhere in the future, I’m not currently, so I don’t feel like I’m revealing con secrets by adapting my con checklist (and other lessons learned) into a blog series. Hopefully, someone can benefit from some things I learned–or at least avoid some things that I failed at.
I’ll also mention that MTAC and Momocon were major inspirations for the way I ran Hamacon analog gaming. Which is to say: if you like tabletop games, they’re cons you might want to check out.
Posts in this series:
I mentioned in my intro to RPG Maker scripting post (and in the panel that’s based on it) that you can use source control systems like Mercurial or Git with RPG Maker VX Ace, allowing you to take periodic snapshots of your work.
(First, you’ll want to read a tutorial about how your chosen source control system works, such as hginit.com for Mercurial. This post will make a lot more sense once you do.)
What I neglected to mention is there’s two big, easy-to-forget gotchas with this setup.
My last post was basically an info dump on what I’d learned about RPG Maker Ruby scripting during Ludum Dare 37. From the comments I got on it, I realized “info dump” is not an exaggeration–it’s literally a bunch of abstract, raw information without any examples, and so it’s confusing if you haven’t messed with it before.
So, let’s walk through how we’d think through a very simple change.
Ludum Dare 37 was the first time I’d really, truly built a finished product in RPG Maker rather than tinkering, and I learned a lot. Given that RPG Maker scripting doesn’t seem to be a well-known topic among more casual users, it seems like a good idea to try to summarize a lot of what I picked up.
This is a follow-up to my last post, Building a Procedurally Generated Platformer, which (not being a disciplined blogger) I’d sort of forgotten about until a comment about an off-hand remark I’d made about another blog post popped up in my RSS feed. Then (again, not being a disciplined blogger), I forgot about that half-finished post until I started thinking about writing a new post and checked my WordPress admin.
In the last post, we discussed one way you could randomly generate a two-dimensional array of values representing ground, platform, and trap tiles. For example, it might look like this:
The trick, of course, is to convert each of these chunks into actual Unity objects, and to do so in a way that performs well.
Because we’ll be adding new chunks as needed, we want to make sure we don’t freeze play due to adding large chunks that are costly to instantiate. Because we want to restart the level quickly (without reloading the scene), we want to minimize the cost of creating new game objects.
