My slides from NXNEi are woefully overdue for posting, but in the meantime I highly recommend the following:
I just had the privilege of speaking about game design and gamification at North by Northeast Interactive. While I want to clean up my slides to be useful to a new reader, I’ve collected a few links and resources either mentioned in my talk or directly relevant to the subject at hand. I’ll add more soon, but this should get you started!
The Ignite Welly folks have started posting speaker videos from the inaugural night at their on their Youtube channel. This is mine:
In 5 minutes I tried to cover 3 things that I think games often do well that could be of use to the (mostly) web and application focused audience:
This was 2 things too many. With such a short time frame I think the audience would have been much better served by focus on a single point in some depth. Hopefully this crash course overview at least got people thinking about some new areas they could research and apply to their own work.
A couple of weeks after I did this presentation I saw a few posts floating around and had others forwarded to me regarding applying “game design” to application and web design. The first one that really grabbed my attention was Why Is Every App A Game? The Badgeification Of The Internet and highlighted a problem that I don’t think I talked about enough during the presentation. The useful techniques that designers can look at from games are approaches to users, not applying game mechanics just because you can. Slapping a scoring system in the middle of your userbase is not going to make for a better experience or cause them to stick around longer!
This post, Top 5 Ways to Make Your Site More Fun, is a great example of looking past the intent of game design that I think is most relevant to other designers and instead reaching right for the raw tools we employ. We tend to consider games that have single use or isolated play mechanics that don’t fit into a larger context to be poor games, and that’s what you’d get if you just grabbed one of these ways to make your site more fun and applied it.
I think game design has a lot to share with other fields (and even more to learn!) but as with all things look very closely at how to apply the practices for the benefit of your users, not just the end results that we see in our own field.
Shatter came out July 23rd and everyone at Sidhe rejoiced.
We worked hard on this, Antony (programmer), Corie (artist), and Rory (programmer) in particular. Producer Alan kept track of our madness and helped with the design load. Jon provided his design “get it done damnit” know how. Dan and Daizong made nearly 400 levels which were then refined to the 80 found in the game. Module provided so much music and love, with Jos acting as intermediary and music producer, that it’s safe to say that it wouldn’t be Shatter without his audio genius. Mario kept our eye on quality the whole time and is responsible for the very popular friend’s next best score feature that has players chasing the leaderboards. I provided design support and a sounding board for Antony and Corie, beat the boss design into submission, and acted as their cheerleader whenever I had the chance. Many, many people at Sidhe touched Shatter at one time or another and they all helped make it great.
The love Shatter has been getting is astounding and I can’t believe how good it feels. Shatter is sitting at 87 on Metacritic today and players and reviewers really get it. It’s not a big game, it’s not terribly complicated, and it’s not out there to set the world on fire with cutting edge game design. Instead it’s a tight twist on an old classic and it will make you smile when you play.
A game given time to cook, iterate properly, not rushed and it turns out as well as you could hope. Who would have guessed?
I took a few photos at the launch party, the set is up on my flickr, but I like this one.
Today we can finally talk about a new project outside of the office! Shatter is a fantastic little game that a small crew at Sidhe has been cranking away on for a while. Not sure how much I can say about our development yet, but for now enjoy the shiny trailer.
A hard slap. A yelp. Frowns. Betrayal. Consternation. Confusion.
Laughter.
That’s what you get when you turn over the cards in SiSSYFiGHT 3000. Used as an exercise during the Game Design Workshop at GDC every year, SF3K is a simple card game which is very easy to learn and acts as a hell of an ice breaker. It’s also the perfect platform to teach rapid paper prototyping and in the right hands a great tool to explain the Mechanics Dynamics Aesthetics framework. Or you can just crib Marc’s slides wholesale. (What? There’s a reason they’ve evolved over 7 years of the workshop to a finely honed point. I’m not going to even try reinventing that wheel.)
The folks at Media Design School kindly invited me back to meet a new crop of students and to catch up with the Nightfall team I met a few months ago. Chatting with Steffan about what he had already covered with them it was obvious he’d gotten through the nuts and bolts of the industry stuff already so that was some of my previous material out the window. With two 4 hour windows to fill I turned to another project I’m poking at for day 1, and figured that the SF3K exercise would be an excellent day 2.
Over the course of a couple hours of lecturing and about the same again of Q&A I tried to distil down a bunch of lessons I’ve learned (mostly the hard way) from my time in the industry. There’s no such thing as a perfect design doc. Math will save your ass when balancing. Communicating to the player what they need to do is hard. Etc. Illustrated with examples from the games where those points got driven home, often repeatedly and with blunt force trauma.
Channeled Harvey for a bit as well, highlighting how lucky they were to be looking to games and pointing out that working in games means working with Very Clever People who are mostly a lot of fun to be around. Blew the Indie horn as well, regaling them with Derek Yu’s masterful writeup of Petri‘s completely mad 5 minute game stunt. Without video of said event I had to give it a very dramatic reading. Please tell me there’s video somewhere of Petri’s performance.
In the end no-one’s eyes glazed over and they had questions about all the usual stuff. Including, of course, working in Japan. That elicited my standard response: if you’ve got good Japanese language skills and don’t mind low pay it’d be a hell of an experience for a first job. Later one of the guys wandered over to ask more about it and I repeated the question.
“Well, I’ve been studying the language for 9 years and did the Level II JLPT.”
Oh cool, you’ll do fine then.
He does however need to learn the first rule of networking, if you get a card (like mine) and that person offers to provide you with contacts in a relevant area (like I did) then make sure you follow up.
The afternoon was given over to chatting with the Nightfall crew, who have come a really long way since I last saw them. They’ve got a ways to go, but might just make it. We discussed what their priorities were, and they had found themselves in the trap of every feature seeming to be equally important. The suggestion to focus on their first 10 minutes and prioritize from there got traction quickly and by the next day they had figured out a solid outline for that 10 minute experience.
Day 2 completely rocked my socks. The Game Design Workshop still stands out as one of the most useful and influential two days of my experience, and I wanted to share some of that with the students. After a brief arts and crafts interlude to cut up index cards and make game pieces they played SiSSYFigHT 3000 and I watched it work its magic. First round confusion, figuring out a new set of rules, a fresh game. Second round strategies begin to emerge. Social dynamics take hold again now that the rules are internalized and alliances are formed. Then broken. Laughter all around the room, truly is there any faster way to get to shared glee in large groups than a quick game?
After they had played two full games (I was curious to see how actions in a previous game would carry reputation over to the next. Turns out revenge is high on the list of SF3K priorities.) we broke to do a crash course in MDA theory. A little worried that I rushed it, but I wanted to get them back to the game quickly and figured that doing trumps listening.
With sticky notes in hand they wrote down all of the fiction and genres they could come up with in 90 seconds and then stuck them to the wall, looking for critical ideamass. Strange thoughts coagulated on the walls of the classroom, settling eventually to:
Hippo Lasers in Space got my attention. At first I worried that they’d paint themselves in a corner (what’re the emotional responses you’d try to evoke with that?!) but I held my tongue to see what happened. Plus they were just so darn excited about the concept. Especially when said like the old “Pigs in SPAAAAACE!”
They came back from a break and were given simple instructions: change the rules to create an experience which uses the mechanics of the game to support the chosen fiction. They also had a hard deadline with a clock ticking down in the background.
Watching the groups work was fascinating, I nudged here and there, encouraged them to Fail Faster, and pushed everyone until they were making quick rule changes and testing them out even more quickly. Everyone’s approach was different, one group got into heavy duty rule changes right off the bat and bogged down a bit, then came flying back out with a ton of iterations. The word Ninja was thrown around by various attendees as both a verb and a noun. Bad wiseguy accents cracked up another group.
I watched totally inexperienced students hammer at one of the hardest things in the biz: collaborative design. For the most part they had excellent back and forth, ideas were tossed in, evaluated, riffed on and tried. Rarely did people come to loggerheads, and when they did another member of the group would step in with “Well let’s try it!” You can’t argue with a prototype.
In the end, lots of awesome. The games they came up with were inventive, colourful and were just as instructive when they failed as when they succeeded. Everyone came away understanding the relationship between a designer’s use of mechanics and how those choices could reinforce, or sap, the fiction/meaning/understanding. Really wish I’d been on the ball enough to bring up the Bioshock narrative/little sister dilemma.
The class wrapped up with huge smiles all around. I think everyone was excited, energized, and actually hand a sense of what game design is like when you get into the nuts and bolts of systems design. It definitely had the same sort of buzz that I remembered from the Game Design Workshop.
A massive thank you to Marc LeBlanc for sharing the workshop materials which made this possible. I took the template and ran with it, changing very little except where necessary to fit the time and space constraints. It’s as inspiring to facilitate one of these workshops as it is to participate in one. Now, to run one back at the studio…
Derek Yu provides a genius write up of the Indie Game Maker Rant.
With roughly 1 minute remaining, Petri stands up and beats on the keyboard like the drummer on a Nordic slave ship. Even though we’re indoors, a warm breeze somehow makes its way into the room and unravels his ponytail, sending his flaxen hair waving as Wagner’s Flight of the Valkyries is pumped in through Moscone’s humble speakers.
It only gets better when you read the whole description of Petri’s 5 minutes of madness. The indies, as represted by Polytron/Infinite Ammo/rest of the TIGsource crew, keep making me consider diving headfirst into the path of that particular train. I wonder what Heather’s rant was about…
After speaking at the Media Design School in Auckland while I was up there for Semi-Permanent 08 they asked if I’d like to come back in the future. Well of course I would, I really enjoy speaking with students. Last week I returned to Auckland to spend two days with one of the game development classes who are entering the final part of their course.
With 3 weeks used up they’ve got the same again left in a pre-pro phase before moving on to 5 months to finish the whole thing. Like many student groups and first time mod makers they had a massively ambitious project planned which won’t fit in the time available.
So I spent two days talking about Scope.
They’ve actually got a wicked high concept for the game which could make for incredible FPS co-op play, but the number and variety of assets and systems that have to be built to support it are a bit out of control. The discussions revolved around the design choices they had made thus far and I looked for areas that I know will trip them up in the course of production. We talked about choices like dynamic physics vs. animated destruction, how to ensure silhoutte recognition in night time lighting conditions, and kept coming back to how to ruthlessly evaluate features and specs.
On the second afternoon I ran through the prioritization of Must Have, Should Have, Nice to Have and talked about the onion skin method of visualizing those categories. The group was highly receptive to the idea, and I foresee sticky notes of features and a clustering exercise in their future. The MDS students are a highly motivated bunch, can’t wait to play what they produce. They’re blogging their progress as well, so into Google Reader that goes.
Thanks to Steffan, Stephanie, Kyall, Darius and Brendan at MDS for organizing the trip and getting me in to spend time with some promising students. MDS has a blog as well and Stephanie snuck a couple of pictures and wrote it up.
In the interests of making this searchable and generally more accessible here is my GDC 2008 poster session, 10 Tips for a Successful Wiki, pulled out of PDF format into a regular post. I’ll address some of these points in an update soon
, suffice to say I’ve become an even bigger fan of wiki tools since last GDC. One wiki I’ve been pointing people to as a great (and free!) tool is Deki by Mindtouch. Have a look at their feature tour and play around in the sandbox, it’s an impressive piece of software.
Â
As with any tool, evaluate what it is about the existing system that leaves the team unsatisfied. What are the obvious areas for improvement of your documentation system? Generate a list of criteria that would create the perfect tool for editing, storing, accessing, and tracking the project’s documentation.
There are dozens of different wikis, from free open source models to commercial enterprise packages. Use your list of criteria to research the available options and evaluate each to see how it fits your team. Plan for the scope of the wiki, will your studio need to host tens of thousands of pages or hundreds of thousands? How many users will access it simultaneously? Will the server hosting it be local or remote? All of these factors will affect the speed at which users can work, and faster is always better. www.wikimatrix.org is an excellent comparison tool.
Nothing is perfect off the shelf and your wiki will be no different. Most wiki packages are designed to be customized and extended, so take advantage of that by investing in a few days of developer time to modify it to suit your needs. Re-evaluate wiki usage at regular intervals to gather feedback on the most common gripes and dedicate resources to adjusting the wiki accordingly. The few hours or days spent tweaking it will come back tenfold in time saved by users.
Many new wiki users will create a page and place only a link to .doc or .txt files stored in the source control system. Ensure that users are aware that text and image documentation is best stored on the wiki so that history is easily tracked. Linking to spreadsheets with complex formulae is unavoidable, so document the purpose of the file and any notes about it on a wiki page prior to linking to it.
While Wikipedia might look anarchic, it has a well defined structure that is moderated by thousands of volunteers. Your wiki will need its own structure, based on your needs identified in Tip 1. Make sure the first page users see presents them with the most pertinent info, based on their account. Wikis often support a variety of structures, including hierarchies, which are often easiest to follow for docs relating to a single project. Users build habits quickly; presenting them with a well defined structure right off the bat can create best practices organically. www.wikipatterns.com has been doing good work in this area.
When storing multiple projects’ (or departments’) documentation on the same wiki, use the namespace functionality to clearly delineate the area of each. Doing so will make searching easier and sorting among multiple projects far more effective. While most wikis support namespaces, some also have project areas which group relevant pages even more explicitly.
Depending on your project/publisher/studio model, it’s likely that you will have to publish documentation for external review. With a little planning a more traditional design document can be automatically generated from the wiki. Identify the pages which contain the information crucial to your audience and flag them with a template warning (“Page for external review!â€). Team members will know to keep those pages up to date and clear of rough notes. Use page transclusion to generate a single page containing all core design documentation and export it out to a PDF or similar format.
Start with a 5 minute tutorial on how to create an account, find a page, and edit a page. This will allow users to become familiar with using the wiki to find the information they want and help them to begin contributing. Â Introduce the Talk/Discussion pages (if your team has decided to use them) and then more advanced features as needed, like history and revisions. The barrier to entry on a wiki is remarkably low, and with just an account and basic editing features users can add to the project. Staged training makes it simple for users to grow into the various wiki features while contributing along the way.
A good structure makes it easy to find a page, but a large number of pages can still take time to sort through. Good search functionality saves enormous amounts of time, and tagging pages make them more flexible within your structure. A designer can tag a page with relevant terms, such as “designâ€, “systemâ€, and “combatâ€. Doing so allows a user to filter content by tag, helping them find the pages they are looking for more quickly.
Most wikis support RSS and other notifications for page updates that broadcast when changes are made. These alerts make it a snap for users to be informed when activity important to them happens. An e-mail alert assigned to the pages for publishing externally keeps the lead designer and producer abreast of any changes to information regularly broadcast outside of the team. Team members assigned to a particular level know when the level design is updated, programmers can track build note updates easily.Â