I presented at an international tech conference this week, speaking about game design and, specifically, the Lua programming language (which you might know if you ever tried your hand at modding World of Warcraft or Garry's Mod, and a dozen other games and software titles).
To mix things up a little, however, I opened the talk with an exercise in analogue game design. I did this because all too often we sit down to "make a game" with everything sorted: we've picked the setting, the heroes, the villain, the programming language or the tabletop media, maybe even the artwork. The one thing we sometimes forget are the mechanics: the part of the game that makes it a game and not just a fun short story.
And so I gave my audience, before I started the talk, a blank card. I told each person to jot down a number between 1 and 10, and also to write down a win condition, keeping in mind that other members of the audience would play their cards before or after them, and therefore may override their rule.
I wrote a number and a rule down, as well, folded my card, and placed it on the podium.
I gave them the duration of the presentation to come up with their number and win condition. The talk went well, and if you're the sort of person who's curious about developing games for the tabletop or for video games, then you should go buy the book because it's full of useful information on both.
At the end, we played the game we'd all invented. First, there was the question of how the game was played, which I answered by demonstrating this important principle: even tabletop design can benefit from computing power. Using Lua, I quickly wrote a sequence randomizer: a simple application to take each number on a die (die type is provided by the user at execution time) and present the numbers back to me in a random order. Obviously, the same task could be done with actual dice but dice are truly random, and sometimes you have to wait for true randomness to present itself. I needed each number on a d10 in a random order, and I didn't have time to wait for 27 or 53 or whatever number of rolls it would have taken for true randomness to hit every number. Lua provided simulated randomness (because computers aren't actually ever random, being constructed by humans). If you're curious, here's the Lua code:
#!/usr/bin/lua
-- seed
math.randomseed(os.time())
-- shuffle a table
function shuffle(tbl)
for i = #tbl, 2, -1 do
local j = math.random(i)
tbl[i], tbl[j] = tbl[j], tbl[i]
end
return tbl
end
-- get range from args and put into tbl
local lo = arg[1]
local hi = arg[2]
local tbl = {}
for i=lo, hi, 1 do
tbl[i] = i
end
array = shuffle(tbl)
for k,v in ipairs(array) do
print(v)
end
A game (of sorts) ensued, proving my point that game design could happen spontaneously and without much prior planning, as long as a few key elements were present: choice and chance. Choice provides free agency to players to create their own kind of fun. And chance provides a random engine for something automated or scripted to challenge those with the free agency, who must either embrace what chance gives them or fight against it.
Did I create new Mixed Signals customers? I don't know. I invited people to a game of Petition later in the conference, and by mentioning the site and what we're doing here. But more importantly, I hope I got people thinking about gaming, and how gaming provides incentive in both fun and in work, and that everyone's goal is not always the same. I think game theory is an under-valued skill, and I hope that my talk provided some insight for attendees.
Most importantly, I hope I demonstrated that even when you strip the technology and structure away from the process of making games, creating a game is as easy writing random ideas on some scrap paper, assigning structure, and then playing. It's easy, it's at worst an interesting experiment and at best an educational and fun experience. If you've never tried spontaneous game design, try it today, and let me know how it went in the comments.
Photo by Rand Ompersson Creative Commons cc0.