links for 2009-04-09

links for 2009-04-07

  • "Dubstep doesn't need loyalty. It's not a fragile little creature that needs to be nurtured — at its centre, it's a big, ugly and increasingly popular monster that is gorging itself into immobility."

    "…firstly to critically and speculatively interrogate the deployment of sound systems, the deployment of vibrational force, in the affective modulation of populations. Secondly to examine the role that sonic intensity, a kind of art of war in the art of noise, has played in the theories of aesthetic innovation, from futurism to Afrofuturism."

Seeds for a Local Network

When moving to a new city, what’s your plan for meeting new people and engaging the local creative community? There are international networks like Pecha Kucha, Dr. Sketchy’s,the various BarCamps and other gatherings of interesting folk.

But if you dropped into a city and found none of those things or more likely, a small town where the critical mass just didn’t exist, what would you do? What kind of seeds do you use to grow a community where none was present?

There’s a fuzzy line between finding interesting people to talk to, colloborate with and drink and have good times with and the weird clinginess that comes from typical student/amateur groups. Achieving one and dodging the other seems to be a case of using the tried and tested invite and introduce method vs. broadcasting for participation.

(Brainbits is my new tag for loose thoughts I want to collect before they completely slip by me. ((edit: Was brainjuice, but I noticed Mr. Ellis using it, odds are good he’s prior on that particular turn of phrase.))

Things I missed at GDC

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…

Spreading the Brainjuice

AucklandNightHarbourAfter 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.

10 Tips for a Successful Wiki

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 soonGDC Poster, 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.

 

1.     Create a checklist for your documentation needs

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.

2.     Choose the Right Wiki

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.

3.     Invest in your wiki

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.

4.     Link to external files only when necessary

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.

5.     Create a Structure

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.

6.     Give each project its own namespace or 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.

7.     Make it Publishable

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.

8.     Train Users in Stages

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.

9. Use Tags and Search

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.

10. Implement RSS and other alert systems

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. 

Blotto Brace for GAMMA3D

GAMMA is an amazing event in Montreal which coincides with the Montreal International Game Summit. The Kokoromi collective (Cindy, Damien, Heather and Phil) put out a call for games tied to a theme to be played at a party on giant projection screens. Now in its third year the Kokoromi crew decided to run with 3D as their theme, so retro-future it’ll make your eyes water.

I’ve tried and failed to get a game completed the first two years, but this year was Win. Working with the insanely talented Antony Blackett (code) and Corie Geerders (art, and famous director of F*Dance) put together a weird game of support rather than destruction.

The goals were: playable and interesting with 3D anaglyphic glasses, playable at a party in under 5 minutes, uses an Xbox 360 controller for input.

So you control the game with the Left Analog Stick, it takes 3 minutes to win, and it has a strange zen quality which rewards not panicking. (Which was an unintended consequence of the control being very hard until you learn to release the stick to neutral for each movement. We may do a new version in the future with a different control scheme to see how that feels, but doing this thing in spare moments between other projects… we’ll see.)

So here it is, download Blotto Brace.

Requires a gamepad of some kind, playing it on a keyboard is damn near impossible (that will probably be the update we release) and 3D glasses are highly recommended. Run the fullscreen version only on 4:3 monitors, widescreen will make you cry.

The party kicks off right about now and it’s the first one I’ll be missing since flying from NZ would be prohibitively expensive. In my place I give you this game! Massive props to Ants and Corie for making this possible.