Author: Scott

Here’s something I’d like to add to this site, once my Bard senior project is good and done: The Scottypedia.

What is the Scottypedia? Well, to explain it best, here’s a quote from me:

The Scottypedia is a MediaWiki encyclopedic website, in the style of Wikipedia, and editable only by me, Scott Jon Siegel. Rather than articles being objective, they will instead be entirely subjective, based solely on my opinion of various topics, such as games, music, television, technology, and family and friends.

There you have it. On a more intellectual level, the project would an undertaking in a personalized encyclopedia, a unique method of recording and presenting biographical information about me on the internet. On a less intellectual level, it’s a totally self-important, egotistical endeavor, which will likely never get off the ground due to (oh, I don’t know…) minor technical issues with getting MediaWiki to run on the server.

Has this been done before? Probably. Will I do it this time? Maybe. Either way, I’ll keep you posted. Back to sproj I go.

My review of Fluxx is up today at Joystiq, as part of my column. Fluxx is a fun party/family game, and I talk about it being a rules-focused game. But is it about rules?

Arguably, the central mechanic of Fluxx isn’t a player’s ability to twist the rules and set new goals, but instead the creation of clever pairs of Keeper cards. The vast majority of “Goal” cards are about the player who has both The Milk and Cookie keepers, or the player with both War and Death keepers. The augmenting of the rules certainly makes the play experience more interesting, but it’s the Keeper card mechanic that grounds the entire game, and Keepers are the only cards that aren’t about creating exceptions to the initial, simplistic starter rules.

Just something to chew on: what would a game that’s truly about rules look like? Maybe Nomic, or 1000 Blank White Cards. What other games could be made?

This desperately needs to be the topic of a GDC session. It doesn’t apply to most digital games, but it’s indispensable in analog game design, and a valuable communication skill in general.

The rules of a game are the most important aspect to convey to a player. In non-digital games, if the rules are not understood, the game can not be played.

It’s important to write rules that leave no stone unturned; a player shouldn’t be questioning what something means, or unsure of how to interpret something (unless, of course, the ambiguity is intended). At the same time, brevity is key, and no player wants to read a tome every time they play a new game. The writing — the designing — of the rules is as crucial to the play experience as the design of the game itself.

I’ve been writing a lot of rules lately, interspersed with some digital design docs that will probably go nowhere. Regardless, the intersection of the two has given me some new insight into the creative process. Here are a few tips for writing clear, cohesive rules.

1. Flavor first: If the game has a narrative tying the mechanics together, make that narrative clear immediately. The metaphors will be helpful in explaining and justifying the game’s logic and mechanics.
2. Get the boring stuff out of the way: List the materials needed for the game next, followed by any pre-game instructions for setting up. If it gets wordy or over-complicated, slim it down and add an illustration or two to help explain.
3. Begin with the end: The first rule you should give the players is the winning condition of the game. Tell them what their objective is. From a logical standpoint, all the other rules serve the winning condition, and will make more sense when described with regards to it. It also makes it easier for players to find when they forget how to win.
4. Go from general to specific: Think of it like newspaper journalism, or an inverted pyramid. After the objective, describe the broad, overarching rules before describing the instances and exceptions. If it’s Mille Bornes, explain placing mile cards before you explain the hazards and remedies, explain the hazards and remedies before you explain the safety cards, and explain the safety cards before you explain the coup fourré‘s. Another way of saying this would be to explain the things that happen most often in a game first, and the things least likely to happen in a game last.
5. Tell players what they can do, before telling them what they can’t: Somewhat related to the previous point, you should always explain the least constricting rules before explaining the most constricting. Rules explained earlier therefore become the primary rules, and the rules following are the instances and exceptions where the primary rules change or don’t apply.

In addition to these rules, remember to use short sentences with low-level vocabulary. When necessary, use illustrations (sometimes nothing beats a good drawing).

White space is also crucial. A page full of text looks intimidating. Use bullet points and short paragraphs to keep the reader/player from getting overwhelmed.

Finally, don’t be afraid to be friendly! Unless it’s entirely antithetical to the style of your game, use a light-hearted tone with your rules. I’m slowly learning that seriousness isn’t exactly a staple of this industry. When the purpose of a product is to be fun, then describing it should be fun as well.

I wanted my latest column for Off the Grid to be under 1,000 words, and I succeeded. Like, by a lot. At a hair under 400, it’s the shortest column I’ve written yet. There’s something to be said for brevity (I say this as I’m worrying about my senior project being too short).

RoboRally is Richard Garfield’s board game that he created after conceptualizing Magic: The Gathering, tried to sell to Wizards of the Coast before pitching Magic, but didn’t get published until a year after Magic got published. <-- [note to self: crappiest sentence I've ever written. I'll let it slide this time, but Never Again.] Confusing, I know.

It’s a really fun game experience, designed for up to eight people but still a blast with only two. RoboRally‘s biggest drawback is its sheer complexity, with dozens of pieces to lose and a complicated but crucial play order to each of the five “registers” in a turn. The complexity is all designed to give the game a more robotic feel, however, and in the end it pays off. Little touches like registers which “lock up” once a robot is sufficiently damaged give the entire game world a stronger sense of unity. And the randomness of drawing movement cards can make for some unusual turns; as I was playing last night, there was one turn where my robot was stuck spinning in circles, with my opponent repeatedly moving onto a conveyor built which kept pushing her right off again. Nothing was accomplished, but it was worth the laugh. Silly robots.

At $50, the game is a bit pricey for most (I managed to get it for 25 at Barnes and Noble), but given the replay value and multiplayer capabilities, it’s as worthwhile an investment as any video game worth the same.

I discovered the hard way that large-scale social games are more difficult to pull off than simple dice games or card games. I intended on debuting Vicious, my cruel and emotional game, at a reading of past contributors to Verse Noire. It didn’t go well. The following are reasons why:

1. The rules were too complicated: There were too many stipulations as to what players could and couldn’t do, and I managed to forget a few of the rules as I was explaining. Everyone got confused, including me.
2. There were too many materials to distribute: Every player needed a name-tag, several sheets of paper to write on, and a writing implement. These materials had to be passed out at the start of the game, which ate up time and gave the players that much more to get confused about.
3. The expected arrangement of the room wasn’t flexible enough: I wanted two teams of equal sizes sitting in circles, with the team-members facing each other. But this was a literary reading event; all the chairs were in rows, facing forward. I could either rearrange the entire layout of the room (taking more time), or I could try and fudge the gameplay based on the actual arrangement. The gameplay depended on the team members being equidistant to each other, and being able to read the name-tags. When I left the arrangement of chairs as it was, the game became virtually unplayable.
4. I didn’t think about time: This was a big one. The game was supposed to last around ten minutes. The rules, however, were far too complex to have the entire game play out in this amount of time. The game would have been much better suited to a longer time-frame.
5. I didn’t playtest: I should have, but it was difficult to gather enough people in order to try out the game (ten players was the absolute minimum designed for). This is no excuse, though. I should never have tried to publicly present a game that wasn’t thoroughly tested.
6. I choked in front of an audience: I got completely stuck when I realized things weren’t working right. Why? Because I didn’t plan out my presentation. I spent so long on the rules and the aesthetics of Vicious that I never bothered to write a script for introducing it. For some people, this might not be an issue, but I discovered that I really can’t ad-lib in a tight situation. Having even an index card with bulleted points would’ve helped immensely.

All-told, it was definitely a learning experience for me. Next time, I’ll have some ideas on how to build a proper social game, with less whining and excuses.

I’m conflating the Thursday and Friday of GDC because I’ve been doing this for what feels like forever.

What rocked:
Exploration: From Systems to Spaces to Self – Clint Hocking talked about notions of exploration, and how they pertain to game design. Not only was his talk exhaustively researched, but it was also incredibly well-constructed, funny, and invaluable to my work. The exploration and discovery of a system by a player is one of my favorite aspects of digital game design, and hearing Clint focus on it with such enthusiasm really made me feel confident in my approach. Clint even posted the slides and transcript from his talk! What a guy!

Writing Great Design Documents – It was the last session of the conference, but that didn’t stop Damion Schubert from giving a great talk to a FULL audience (they were actually turning people away at the door!). Possibly the most practical talk I attended all week, Damion emphasized the importance of design documents, and reminded all the designers who they were writing their docs for (hint: the coders), and to keep that in mind when deciding which details to include. And he posted his slides, too! How awesome’s that?

What was really great:
The Metagame: A Battle of Videogame Smarts – I already talked about this, but it was a great session with a lot of my favorite people in the industry.

Small Changes, Big Results: Redefining a PC Franchise for Nintendo Wii – Probably the hardest choice I made during the conference, as this talk was held at the same time as Goichi Suda’s “Punk’s Not Dead,” Chaim Gingold’s “SPORE’s Magic Crayons,” and the “Pitch your Game Idea” session. Nevertheless, Robin Hunicke‘s breakdown of how to properly adapt a franchise for a new console was fantastic. Robin all but ignores the Wii Remote as she discusses how best to fit a familiar franchise to a new console and a new market, keeping a keen eye on the smallest details while never losing sight of the big picture.
Sadly, no slides from Robin. :(

The Game Design Challenge: The Needle and Thread Interface – I’ve wanted to go to one of Eric‘s game design challenges for years, and was happy to finally make it to one. It would’ve been worth it for Alexey Pajitnov alone, but Harvey Smith and David Jaffe both gave great presentations as well.

What was so-so:
GameBoss: Simplified Online Game Creator – I caught an early-morning session on GameBrix, a collaborative online platform for designing and developing small digital games. Unfortunately, the company didn’t seem sure of the target demographic for the program; its relative simplicity was certainly accessible by any age, but the bright colors and cute games developed seemed skewed toward a pre-teen age group. Still, I’d be grateful for any program that allowed me to build simple games or prototypes, and the open-platform, flash-based approach of GameBrix was a definite sell for me. I’m looking forward to trying out the closed beta whenever they get around to it.

Reflections of Zelda – Eiji Aonuma’s talk on the development of the last several Zelda games didn’t really wow me. I was expecting more details of the design process, rather than developmental issues like whether players like the “toon-shaded” look. He also seemed to be contradicting himself, blaming the poor reception of Wind Waker on its cutesy style, yet then creating Phantom Hourglass which shares the same look. He also asserted that Four Swords Adventures did poorly because it was too difficult to understand, and yet is now integrating a multiplayer mode of Phantom Hourglass so disconnected from traditional Zelda gameplay that I couldn’t for the life of me figure out what to do. Still, Aonuma’s slides were cute, and his presentation was very clean.

What disappointed me:
The Nintendo Keynote: A Creative Vision – Yes, it’s true. Miyamoto’s keynote was nothing special, at least in my opinion. I understand that the man couldn’t reveal anything new, but he could’ve at least talked more about his creative process, and maybe revealed some non-stock-threatening insights into his design process and his experiences at Nintendo over the years. Instead, he talked about gaging successful gameplay on whether or not his wife likes it, and about how he tried for years to implement some form of Mii’s into Nintendo products.

On top of that, his presentation was sloppy. All the slides were loaded onto a Wii’s photo channel, but the system wasn’t meant for that kind of presentation. Miyamoto had to constantly resize images to make them fit on the projector, and the flashing cameras from the crowd caused his Wii remote cursor to go crazy (he actually had to hold a finger over the remote sensor while talking). Contrast this with Phil Harrison’s presentation, which was loaded into the photo gallery of a PS3. He simply walked around the stage with a sixaxis, depressing one of the shoulder buttons to advance the slides. Every slide fit perfectly, and there was practically no way of knowing it was being run off a PS3 (except for the controller in Phil’s hand). He even had the PS3 review the “photos” at the end of his presentation, going into a unique autoplay mode with each slide falling onto a table as a polaroid. It just looked great.

And that was GDC. Back to game design, I promise.

I wanted to take an opportunity on Joystiq to talk about the IGDA student scholarship experience, and chose my column to be the vehicle. Apparently it’s long and “rambling,” so I included some advice for future applicants at the end of the feature. You know, as a reward for enduring.

To be fair, I need to cut back on my word counts. It’s not even verbose; it’s just full of things. Joystiq’s clearly not the venue for lengthy columns, and I need to keep that in mind from now on.

Harvey Pekar doesn’t draw, he just writes. That’s why he needed Robert Crumb, Alison Bechdel, Chester Brown, David Collier, Gary Dumm, Frank Stack, Drew Friedman, Dean Haspiel, Val Mayerik, Josh Neufeld, Brian Bram, Spain Rodriguez, Joe Sacco, Jim Woodring, Joe Zabel, Ed Piskor, and many others to illustrate American Splendor. It’s collaboration, and I’m in love with the idea of it.

I’m a designer. I don’t code. I don’t have the head for the numbers, for the logic of it. Collaboration with a wide array of technically-oriented individuals would be a unique way of surmounting this problem, reaching out to programmers with design documents in hand, offering to work closely with them on the development of something really great (or so I’d hope). I’d be a serial collaborator – now there’s something to put on my business card!

But would serial collaborations be fruitful in game development? Could the styles of the coders be seen in the final products? Would the games I designed with various programmers all feel different?

More importantly, would anyone even agree to do it?