Something Completely Different: A Party Game that Feels Like a Party

A friend of my wife’s loves throwing parties–the bigger the better. Since these events frequently involve a mix of people who don’t have much in common beyond knowing the hostess, she uses a game as an icebreaker. Frequently that means Werewolf.

I understand why she chooses Werewolf. It’s capable of accommodating a large number of people, and it’s quick to learn. Furthermore, it creates a focus, something that everyone can get involved in and then talk about later.

However, while Werewolf is often characterized as a party game I think it has some issues when played at an actual party. Put simply, Werewolf stops the party. First everyone has to sit down and be quiet. Then people get to talk, but primarily to accuse each other of things. Finally somebody gets removed from the game, and they have to sit separately and hope the next person to be removed is interesting to talk to.

A better party game, I submit, keeps the party going. It has Werewolf’s positives–easy to learn, fun to chat about–but allows the event to continue around it.

Here’s a first swing at the concept:

Setup:

  1. Get lots of blocks. These can be anything that players can build with–wood blocks, Legos, folded-up 3×5 cards, etc.
  2. Write some goals for what the players should build on 3×5 cards. Feel free to make the goals wacky, but they should relate to the final structure the players build. “There are no rectangular pieces touching the table,” “there are three arches,” and “the structure is at least three feet high” are all good goals.
  3. Put the goals and the blocks on a table near the door. Make sure there’s enough room on the table for the players to build the structure–two or three feet square is plenty.

Play:

  1. Give each attendee one goal card when they arrive. This should be random, but feel free to keep some goals aside for specific guests (e.g., very easy goals for small children).
  2. Tell players this: “You can add one block at a time, or take away one block. You can do this as often as you want, but you can’t go twice in a row–someone else has to take a turn before you go again. If the structure meets your goal at the end of the party, you win!”
  3. Let people play as much or as little as they like! Take a photo when everyone’s left, and put it up on Facebook or email it around so that those who left early can see if they won.

I’m pretty sure that, with the right goals, this accomplishes what Werewolf does without requiring people to decide between following the rules and preventing their toddlers from overturning the dip bowl. If you get a chance to try it, let me know!

In the Lab: Working on an External Project

Last week a friend offered the chance to design a faction for a card game he’s working on. I leaped at the opportunity, and I’m currently hammering away at the design.

This isn’t my project and I don’t have express permission to discuss it just yet. If and when it’s ready for public consumption, though, I’ll let you know. My hope is that that’ll be soon–there’s a lot about the game that’s really neat, and I’m excited to talk about it!

I know this is a bit of a non-update, and I apologize for that. There’s a playtest opportunity coming up, which means I’m pouring time into my contribution to make sure it’s ready. I promise a meaty theoretical discussion for Wednesday. 🙂

In the Workshop

I’ve been in the workshop recently, prototyping something new. The project is in the very earliest stages and subject to enormous changes/complete scrapping, but I’m excited about it. Much of the fun of game design is the beginning, when you can imagine that an idea will work smoothly. 😉

(Mental note: “in the workshop” sounds much better than “at an old desk in the utility room.”)

This game’s concept is no more than two weeks old, which means that not only is it possible to prototype it, it’s high time to do so. Many if not most design problems cannot be solved just by envisioning how a game will play. Only putting the game on the table will tell you how it’s really going to work. As Yogi Berra put it, “[i]n theory there is no difference between theory and practice. In practice there is.”

Now, back to the workshop. I still need to finish up some cards . . . .

Something Completely Different: Context-Sensitive Fighting Game Controls

File this one under “projects for a 25th hour in the day” . . . .

Years ago I saw a really excellent post—I can’t remember whether it was on Shoryuken’s forums or elsewhere—regarding the challenges of learning fighting games. The poster argued that one of the major issues for new fighting game players is that the buttons aren’t labeled in a useful way; they have thematic names that don’t express what they should actually be used for. At the time it was difficult to resolve that in a satisfactory way, but it strikes me that this problem could definitely be addressed with current technology.

The concern goes like this: most fighting game characters have attacks that serve defined tactical purposes. By and large they will have a long-range strike that controls the opponent’s movement; a quick and unpredictable attack that probes for weaknesses in the opponent’s defenses; a slow but powerful smash that’s meant as the last move in combos. One of the major hurdles for players who are new to the genre is recognizing that the moves available have these specific uses.

Part of what raises that hurdle so high is that the various attack buttons aren’t labeled “control,” “probe for weakness,” and “smash.” They’re “medium kick,” “light kick,” and “heavy punch,” which sound thematic but don’t do anything to explain how they ought to be used. New players thus find themselves without the information necessary to make decisions about which attack to throw out, and are obliged either to button-mash or to figure it out on their own. Either way, it’s a substantial barrier to clear before they can start to get full value out of the game.

Moreover, the knowledge a new player gains from one character isn’t transferable to another. Millia controls with kick and probes for weaknesses with crouching kick; Ky controls with slash and probes for weaknesses with kick. Picking a new character means starting from about 50%; the new player (hopefully) knows that different moves have different applications, but has to figure out which move is for which use all over again.

When controllers just had whatever markings they had, and the labels needed to be appropriate for all characters, this was a very difficult problem to solve. However, today we can do context-sensitive controls. Imagine something like this:

The controller is a tablet or smartphone. Instead of being labeled light, medium, and heavy kick, buttons have descriptive labels appropriate to the character. Not only is there a button marked “control opponent’s movement,” it’s the correct button for that character. New players immediately see that each attack is for a specific purpose.

What’s more, the buttons change. If the opponent jumps, attacks that aren’t useful in that situation have their buttons greyed out—the attack will still work, but it’s clear that that’s a bad button to press right now. Attacks that are useful will stay their normal color and will get new labels, like “anti-air.” In single player mode, the game can be paused so that players can look down at the controller and find out what might be useful to do.

Fighting games are, I feel, one of the hardest genres to get into—but also one of the most rewarding. Context-sensitive control labeling would make it a lot easier to access both what a specific character can do and how new players should think about their moves generally. And it’s so doable now . . . if there’s time . . . .

Maharajadhiraja: Further Thinking

I couldn’t resist spending some time working further on a game based around the concept of the maharajadhiraja, the ruler who doesn’t want to destroy other rulers but rather to preserve them so that they can acknowledge his or her greatness. The more I think about the idea, the more it seems like it leads in neat directions.

First, I still like what it does with player elimination. Everyone wants to secure their own power, but the leader has to stop short of fully removing rivals from the game. Complete safety is thus unachievable, which helps keep the game interesting as it goes along.

Second, I’ve started to be very interested in how the design might naturally control snowballing—the situation where players get more powerful as they advance toward victory, so that they enter a positive feedback loop where winning gives them power and the power causes them to win even faster. (The name comes from a snowball rolling downhill, picking up snow so that it speeds up and picks up even more snow.) Most games with the potential for snowballing rely on mechanical barriers that limit how much power the players can acquire at different points in the game. By contrast, this game could have players limiting their own snowballing, stopping their feedback loops in order to keep their opponents in the game. That’s unusual, and I feel that it would be fascinating in play.

My ideas so far have been minimalist, with some dice for each player as the only components. The intent was that simple mechanics would put focus on the key dynamic of getting some—but not too much—power at the opponents’ expense. Unfortunately, nothing’s worked yet; having few mechanics means there aren’t many levers to pull when something doesn’t play out as intended.

So, an interesting idea, but one that’s not quite there yet. I’ll have some free time this weekend to plug away at it a little more.

Thief in the Night: Annotated Edition

I feel badly for the little decisions in game design, the ones that edge a game from OK to good, or from good to great. Usually they don’t warrant a blog post or designer diary entry in and of themselves, but they have a significant impact on the final product. There needs to be a format where we can bring these small-but-important design choices to light.

Below is my attempt at creating that format: an annotated version of Thief in the Night’s rules. It includes some behind-the-scenes discussion of how the game came to be and thoughts on why specific rules are the way they are. Here’s hoping you find it enjoyable and informative.

Thief in the Night – 2-20-15 (Annotated)

Thief In the Night

After a few weeks of Unity work, I started to feel like I hadn’t flexed my game design muscles in a while. So I set myself a two-hour deadline to come up with a game.

Here’s the result: Thief in the Night. It’s a simple game for two players that you can set up with stuff lying around. This isn’t a polished product; make any changes you think are good, and let me know what you think!

Lines of Questioning: Update

First and foremost, Jake Thornton is back to posting at Quirkworthy! If you haven’t taken a look at Mr. Thornton’s blog yet, I would urge you to give it a try. It’s a mix of theory posts informed by his decades of experience and behind-the-scenes discussion of his games, all of it fascinating.

With regard to what I’m working on: an excellent Unity meetup led me to a whole new way to build Lines of Questioning’s PC version, one that largely frees rules enforcement from relying on Unity’s physics system. This will put an end to some unpredictable, difficult-to-replicate bugs that arose from fractional irregularities that could crop up in tile positioning.

Figuring out this new approach reminded me of the importance of bouncing one’s ideas off of others. I was dead set on how I was doing things, and was spending a lot of time ironing out my method’s flaws. Talking with the rest of the meetup group got me out of a mindset where I had to bash through the walls in front of me, and showed me that I could sidestep them entirely.

Of course, the first thing that happened was that I ran into an entirely new wall. 😉 That’s all right, though; fresh challenges are always interesting. Time to open a new scene . . . .

Project Updates

Lines of Questioning’s PC implementation is coming along well. This week’s work has been split between getting the GUI in place and finalizing the basics of rules enforcement: checking whether tiles connect appropriately to their respective lines, making sure they aren’t stacking atop other tiles of the same type, etc. Of course, nailing down the basics of rules enforcement means that the really complicated parts are yet to come. 😉

In other news, I’ve made a bit of progress on Over the Next Dune’s new look, and have continued trying things out in the Flying Drone Toolkit. There’s nothing to report yet on those fronts, but they’re not forgotten.

I expect to spend at least some time next week building more physical prototypes of Lines of Questioning; devoting lots of time to coding has slowed playtesting considerably, so I’d like to get some more copies in circulation in hopes of speeding things back up. Boardgamegeek’s print-and-play competitions are also in full swing, and I’d like to put something forward for at least one of them. Always, always I need that 25th hour . . . .

Something Completely Different: Ideas for Games Involving Drones?

When I run into a roadblock while coding Lines of Questioning, I sometimes mess around with other tools and ideas as a way to clear my mind. Recently that’s meant experimenting with the Flying Drone Toolkit. (Full disclosure: I know the Toolkit’s creator.) It’s basically a pre-programmed setup for implementing VTOL drones in 3D games.

To date I’ve just been poking around and learning about the Toolkit’s features. That’s fine so far as it goes, but there’s a natural temptation during that sort of exploration to focus on what the Toolkit does easily rather than on what it can do with some effort. I need a project to really test its–and my–boundaries.

In searching for ideas I’ve tried to draw inspiration from the way the drones fly. They don’t act like jet planes; rather, they move like helicopters. What else flies that way, and what interesting things to they do?

– A news helicopter that has to fly around getting good footage.

– A guardian angel that has to protect someone without being seen doing it.

– Superman, being Superman.

– Vehicles moving in zero gravity, that have to pick out precise orbits or land on broken extraterrestrial terrain.

– Vehicles that move like they were in zero gravity–martian landers, repulsorlift speeders in Star Wars, the U.S.S. Voyager when it lands–carrying people to and from adventures, often through hostile terrain.

I like some of these ideas (let’s be honest, I basically like any idea involving Superman), but I feel like I’ve only scratched the surface. If you could make any game involving something that flies like a VTOL drone, what would you do?