Plan for Jay Barnson

Void War Update: Python is GOOD. Ease of play must be better...

The joy of SCRIPTS
Internal Test #2 of Void War went out this week. I had a nightmare of the time making sure the release had all the resources nicely bundled together. After finally making sure I had every sound, music file, model, and texture, and text file in the package AND updated to the latest version, I decided to create a Python script to save me some of this particular torture again. It took me far less time than actually bundling and verifying the package in the first place. Python just RAWKS. The new script maintains a "manifest" of the entire release, all files that go into it, and where to go to get the updated versions of the files. It will also use the manifest to build the whole package whenever I need it. It's a minor thing, but I'm in favor of reducing my headaches whenever possible. Especially the really time-consuming ones.

A multiplayer test
Immediately after sending this build out to the testers, I got into a multiplayer battle with one of them. With this build I added more power to the engines, making inertia an easier beast to tame. Combined with collision detection that can allow you to dive in and out and around the rings of space stations and other more complex models, and a more "loose" pick-up radius for gathering items (yes, we have items you can pick up in space), I felt like our whole "pseudo-newtonian physics" was really working. I don't know if my opponent, John, felt the same way. I pounded him pretty relentlessly. After we'd finished the testing session he announced, "I guess this proves that the game isn't just based on luck!"

That's MOSTLY a good thing, right? I mean, my overriding goal in Void War was to create a space combat game that didn't have the shallowness of gameplay in pure dogfighting like every other multiplayer space combat game I have ever played. So this is indicative of DEPTH, right? Depth is good, right?

Well, mayhap' it is, mayhap' it ain't.

A Tale of Two Siblings...
Ease o'Play and Depth o'Play are two brothers who are often seen at odds with each other, fighting as brothers often do. Some folks consider them opposites, believing Depth comes at the expense of Ease, and that Ease precludes depth. I prefer to think of them of two sides of the same difficulty curve.

To me, ease of play means that the player can very quickly arrive at the point where he feels competent at the game. The definitions of "very quickly" and "competent" are purposefully left vague, as they are subjective. Depth of play means that the player keeps learning of new things to do, and new ways to improve his game, even after a very long time. So if you envision a curve with player skill mapped to the vertical and time spent playing mapped to the horizontal, you'd see a curve that shoots nearly straight up right off the bat, then quickly levels out to a gradual but steady slope over time. That would be the ideal game. The greater the slope to the right of that competency level, the smaller the "window" in which players of differing skill levels can play competitively with each other. But if it's TOO gradual, players will grow bored with their slow progress (and lack of anything "new" to learn).

Okay - abstract theory part done. Time to get concrete. One of the best examples of this is the "fighting game," one of the most popular types of games in the last decade... mainly due to this very reason. Your CAT can paw the buttons and look good on the screen doing it. Your three year old can probably whup you by just mashing the "punch" button repeatedly. Anybody can get past the first level in most fighting games. THAT is ease of play - it just doesn't take anybody very long to get the hang of playing. Once you get past mashing buttons randomly while moving, you can learn timing, how to throw the right attack or defense at the right time. You can memorize dozens of "special moves" - and how to counter your opponent's specials. And how to counter counters. And even more insane levels of depth that I, in all honesty, never discovered. But I know people who did, and will talk about it for hours.

Applying the Lesson
So I was flying circles around John the other night, treating him like my own personal punching bag while exercising the multiplayer code. One thing I noticed was that when he finally got around to firing missile at me, they were going ballistic. rather than guiding in on me. Another tester, in single player, commented that the missiles were just going straight, and he was having a hard time hitting anything with them.

"Well, DUH!" is my first thought. "You need to lock a target first. Hit the 'T' key first before you fire." Sure... if you've played modern flight sims, or other space combat games, that should be obvious. But it's not to these guys. It's such a simple thing... I just need to draw more attention to the function in the documentation. Problem solved... I've appealed to past precident, and I can sleep better at night.

BUT... here's the thing: Is knowing better than to launch missiles without a lock REALLY a distinguisher of player skill? Should players be schooled by their betters repeatedly until one day they unlock the mystery that is the "target lock" button? Is this REALLY a mistake I want beginners to make? NO.

There was a round table I attended at my first GDC, back in 1994, where one of the guys from the "Panzer General" team gave some advice that I've never forgotten. When you make a game, he said, you have a problem in that you WANT to appeal to the hardcore guys, because they are your vocal minority and opinion leaders. But by the same token, if you ONLY appeal to them, you are creating a game that's only going to be enjoyed by a tiny subset of your players. The key, he said, is to make something that the hardcore players will gripe about, but grudgingly admit they had a blast playing. I think he referred to it as "conscientious quirkiness."

The control scheme should NEVER be one of the "challenges" for the player to overcome. Leave the challenges in-game, not on the keyboard. Wherever possible, try to not ever let the player look stupid. Let the experienced players figure out how to circumvent 'helpful' default behavior if they really don't want it... it's better than letting the newbies languish because they can't figure out how to make things work right.

So now I'm going to have the player automatically lock onto the "most likely" target if he tries to fire a missile without a missile lock. And do a smarter target selection when he manually chooses a lock, rather than just cycling through opponents in an arbitrary order. And then I'll need to round up a couple more newbies and see what they get confused about.