For Ludum Dare 46, I created a very simple tamagotchi game called “Potted Plant Simulator” in Unity (you can find the code here). We kicked around this idea for “Keep it Alive” at the Knox Game Design online meetup, but it was more or less a joke.

However, brainstorming brought me back to the idea because I started wondering about how to procedurally generate a plant in Unity. I speculated that Unity’s hierarchy system (which localizes position, scale, and rotation to the parent node) would let you chain together branches, and I had to test that hypothesis. (Spoiler: hierarchy does not seem to be the best way to handle this.)

Yes, a single game merits an entire post, because there’s a pretty good chance that this game will be your event’s problematic fave.

I’ll be honest, I liked Cards Against Humanity. Liked, past tense. When it first came out, all the expressions of bigotry and cruelty and general horribleness felt like “punching up”–making fun of people who actually believe and say all that stuff for reals.

I now believe that’s a rationalization, or at least it was on my part.

This is a bit of a tangent on something I touched on in the “Scheduled Games” and “RPGs” posts.

Successfully running an RPG at a convention is an art form (one I haven’t mastered). It’s loud and everyone’s under tight time constraints. (Dire Bear Adventuring Co. did an excellent job running D&D at the last few Hamacon events, if you want a good example.)

Here’s a few quick rules I use when running games at cons:

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: