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:
A few months back, I played around with (yet again) rebuilding a half-finished Metroidvania-style game I’ve played around with off and on over the years.
One of my goals in this experiment was to use base Unity functionality as much as possible, replacing 2D Toolkit and custom systems as much as possible. One of the prime candidates for such a rewrite was the menu system:
If it’s not immediately obvious, that’s essentially a vertical menu with items that have horizontal behaviors. When “Equipment” is selected, you can choose an item to use or equip on the horizontal axis. When a volume slider is selected, you can adjust the value with the horizontal axis.
Importantly, the game’s intended to be played with a gamepad, so I didn’t want the presence or absence of mouse or touch input to affect this behavior.
Unity UI navigation is pretty smart, and got me most of the way there. If you’ve focused on mouse/touch interface when building your UI, good news: if it’s a grid-ish format, it probably works the way you’d expect. That’s thanks to…
I’ve been readying my demos for the Knox Game Design booth at the Knoxville Gaming Convention, which includes setting up some new demo tablets. Having used a Kindle Fire for demos a before, I feel like it’s a fairly reliable setup for anyone who develops Android games, so I thought I’d share it.
The goal here is to have a device specifically for demos. I’d rather not put my personal tablet or phone, which is linked to my Google Play or Amazon Appstore accounts, up for public access.
I have an Intel Compute Stick (which runs $100-$200) that I can use to run full-fledged PC demos. It’s nice and flexible, but it means I have to carry around a TV for each demo station I want to run.
I like Kindle Fires as demo devices for a few reasons:
Remember that recent versions of Unity (e.g., within the last year or so) will not build to versions of Android before 4.1. If you’re buying a demo device that runs Android, make sure it can be officially upgraded to 4.1 or later, or you’ll need to rebuild your game in Unity 5. (Yes, there may be homebrew ROM upgrades available, but it may take some trial and error.)
For Kindle Fire, this means anything 2013 or later. If you want to be sure, there’s a list of versions and their corresponding devices on the Wikipedia page for Fire OS.
If you’ve bought a tablet, you know how this goes. Your first startup is a tour of all the basic questions like language and wifi access, usually culminating in the option to login.
The key point here is to skip registering an account. You should have the option to do this during the process (for some models, you may have to go back to the previous step to do so), and the tablet should still work if you do.
If you bought a Kindle off of Amazon, the device may come pre-registered. You should find an option in Settings > Account to de-register the device.
You don’t have to put your game on the Amazon Appstore to install it on your device; you can copy over the APK and install it from a file manager.
If you get a “parse error” when you open the APK, go back and compare the tablet’s Android version to the minimum Android API level you selected in Unity.
Once installed your icon will show up on the complete list of apps. (It won’t necessarily show up on Games or certain other sections, simply because those aren’t available unless you register your Amazon account.)
Physically mirroring your tablet to a TV is easy, but it requires some extra equipment you probably don’t have laying around.
The Kindle Fires I have use either SlimPort enabled USB (newer?) or micro-HDMI (older).
In the case of the USB, you can buy an adapter that will allow you to connect to both a HDMI cable (for mirroring) and a USB-B cable (for charging). This is the model I bought.
In the case of micro-HDMI, you’ll have a micro-HDMI port alongside your USB. (The HDMI port will be the wider of the two.) In this case, all you need is a micro-HDMI to HDMI cable.
While converting some old 2D Toolkit-based Unity code to plain vanilla Unity recently, I ran into a conundrum: Unity’s got great support for standard font formats, but still isn’t quite up to par with tk2d’s support for building fonts from spritesheets.
An example of a sprite font
It’s a minor issue–after all, it’s easier and more legible to drop in an existing font–but I wanted to keep the hand-drawn look.
So, I fell down the rabbit hole of cataloging the different options Unity provides for UI text (including TextMesh Pro, recently acquired by Unity and built in to 2018.1). While my knowledge of typography is pretty shallow (and it seems to be a rather complex topic), this should give you an idea of what’s out there and why you might want to use it.
Here are the slides and sample code from my presentation “LINQPad Cookbook” at CodeStock 2018. (Sample code should contain test data and all necessary DLLs.)
