Tales of the Rampant Coyote
Adventures in Indie Gaming!


(  RSS Feed! | Games! | Forums! )

Monday, January 02, 2006
 
The First Playable "Level"
I guess I'm learning and growing.

When I was at SingleTrac, I got really annoyed at milestones that always had an early "20% complete" milestone of a "First Fully Playable Level." The idea is that you have a fully-functional, more-or-less complete (to "Alpha" level, anyway) playable level of the game. And this was an EARLY milestone. My argument was that while that was fine for content, it sucked for programming. By the time you've gotten a single level "fully playable" (by my thinking, which was 100% complete playability), then your programming is about 80% DONE. Because every single level was going to use exactly the same logic.

Now that I'm pretty much managing myself & my limited team & stuff, I still have some disagreement over the wording and intent of that "First Playable Level" milestone, but I understand it a lot more now.

For one thing, I now more fully comprehend the old "80/20" rule --- 80% of the job takes 20% of the time. Which obviously means the remaining 20% takes the remaining 80%. So when the programming is "Almost Done" getting that first level truly up and running, you are really at the 20% mark after all. It's all those little DETAILS and polishing and handling transitions and exceptions that takes up the rest of the time. It provides you a working build that you can create integration tests with (so if it works today and doesn't work tomorrow, you limit the available window in which the breakage occurs --- better than checking in TONS of code for months only to find none of it works).

Content is a lot more straightforward. So depending upon the amount of reuse of content in later levels, the first level could really represent 20% of the content. So the metric kinda-sorta works.

But there's another big reason from a design standpoint. The big trick with any game is getting it beyond the "tech demo" stage and making it a truly working, playable game. Once you are there, you can see how well things are working, how they are balanced, whether the elements that sounded good on paper actually turned out to be fun on the screen, and you can get ideas for improving the game that might not occur to you when you are simply dealing with the "paper prototype" (the design document). A LOT of potential design revision can occur at that point, and the fleshing out of ideas that might not have been too solid previously.

From a management standpoint, the first playable level gives you some benchmarks. It can help expose tasks that were forgotten or ignored previously. It gives you a baseline on your game from which you can judge progress. It can help you evaluate a design and decide if its worth pursuing. It can allow you to start doing a "red-line analysis" of the game. You've now got a demo you can show people when you are trying to pitch your game (to focus groups, publishers, prospective team members, etc.).

In short, this is the point where it ceases to be a "cool idea for a game" and becomes a GAME. Probably not a very good one, but something from which you can constantly iterate and improve upon until it's a GREAT game.

I still take exception to any belief that the first playable level should be considered anything close to "final." But I'm now a firm believer in getting that first playable level up & running as soon as possible in a game. And while it might not fit perfectly in the "20% progress" mark, it's probably not too far from that. Maybe it's closer to 50% if you are constructing or learning a lot of new technology or design work (a bunch of "black triangle" work), maybe even less if you are doing a straightforward sequel.

Labels: ,



Did you enjoy this post? Feel free to share it: del.icio.us | Digg it | Furl | reddit | Yahoo MyWeb

Comments:
Coincidentally, we just released the public prototype test for Galaxy Rage, a game that takes place in a magical world where we look at our 2004 title, Inago Rage, and avoid making the same dumb mistakes twice. (We'll make new dumb mistakes, instead.) The question I'm struggling with now is: what on Earth do we do with this to get the right feedback?

The fact that I've been slaving over a hot design document and sizzling platters of code for months means that I can't even tell if there's a playable game in there. Naturally, then, we take what we have and show it around to fellow developers, as they're often eager to try it out. Ironically, however, it can be difficult to get good feedback from our own, because we're are so durned supportive of each other. We tend to see the positive aspects of an in-progress title and go, "This needs a few things, but you're on the right track." Sometimes what we really need to say is, "Look out for that train heading for you."

A colleague suggested conducting playtests at a local university (which has both a game development club and a game development major). This seems a step in the right direction.

But I get the sneaking suspicion that we're missing out on other avenues. What else does a fellow have to do to turn a prototype design into a winner?
 
There is something Maxis did that they called "Kleenex Testing." Unlike a handkerchief, with a Kleenex once you use it you just throw it away. That's pretty much how they handled their focus testing --- they'd use a bunch of testers ONCE for a focus group, get their feedback, and then they'd be "used up" (at least as focus groups).

That's maybe part of the trick - constantly getting "new eyes" on your game. What that means to me is that you DON'T ever do an "open" alpha (unless its just for marketing purposes), but you keep collecting a roster of names of people to show the game to at different points. That way you can keep getting a first impression.

One thing we did with Void War and Outpost Kaloki that really helped was to hold a LIVE testing event, rather than just distributing it over the Internet. Details of that one can be found at:
http://www.voidwar.com/testfest.html

Bribing people with free pizza and chips seems to help out a lot there. It's a lot easier to get feedback out of players while they are right there. You can watch over their shoulder, see how they are doing, take a note of where they are having troubles, etc. You can also personalize your questions, ask follow-up questions, and generally probe / grill them right there when they are just barely done playing. Potentially you could do the same thing at the Indie Game Conference in October.

One thing I've seen done is to have a questionairre built right into the game demo itself. Only works with people who have their internet connection up while playing the demo. But I imagine that would be a more successful way of soliciting feedback than just distributing a demo and hoping for emails to arrive. Alternately, just providing a link to a website with a form at the end of the demo could also help.

I'm still gonna be pushing my "Red Line Analysis" idea. It may not guarantee a masterpiece on the other end, but it at can at least help in making sure your demo has most of the things that suck removed from it.

Tell ya what. Wanna trade off on acting as Kleenex "Red-Line" Testers?
 
The Red Line concept strikes me as a great one, as it seems to allow biased reviewers (read: friendly developers who want to be upbeat and supportive) a way to give objective feedback.

I'll buy that for a dollar -- tell me where to sign!
 
Looks like your email is available via your blogger login, so I have you down.

You can contact me. I'm jayb, via rampantgames.com. Add me to your list!
 
Post a Comment

Links to this post:

Create a Link



<< Home

Powered by Blogger