When is it okay to be confusing?

I play a lot of DDR, and recently I got the old PS2 game “DDR Max.” It’s a little less polished than the newer games, but it does have a couple of very interesting bits at the end. If you get a high score, it lets you enter your name. But it doesn’t tell you how to enter your name. Letters just zoom up from the bottom of the screen, and you sort of have to work out what’s going on.

Actually, it’s just an extension of the normal game mechanics: if you stomp on the pads when the appropriate letter comes by, it’ll be added to your name in that position. The positionals are the same as the ones in the game, so the left pad is the first character, the up pad is the third, etc. The first time I got a high score, I couldn’t figure it out. I just sort of muddled through it and shrugged, and got a random string of letters for my name. Whatever, not important. But the second time I got a high score, I figured it out. It was so obvious! Yet I couldn’t see it the first time. I actually felt a little clever for figuring it out.

It’s a neat mechanic because it lets you do a little dance move to enter your name. Very cool. The question is: would it have been better, or worse, if it had given the user some instructions?

How likely would users be to read “enter your name” instructions, anyway? Plus, the actual mechanics would be very hard to explain. It’s unintuitive until suddenly you just “get it” and it’s completely obvious. So I suspect instructions´┐Żwould have made things clunkier, not easier.

The easter egg in the DDR Max credits is great, too. As the credits roll up the screen, you can step on the pads right when a name reaches the top. The name explodes, as if you’d stepped on a note. Just another cute continuation of the game mechanics. Instructions there would have been very detrimental.

So what’s the rule of thumb? Obviously, you can’t be confusing at the beginning of the game. But perhaps it’s okay to add mechanics that aren’t completely intuitive later in the game, as long as they’re very isolated, like the “enter your name” screen. (Or an optional mini-game, in the case of casual games.) Of course, it has to be fun enough to justify the confusion. DDR Max could have used a traditional “enter name” screen that was very intuitive… but it wouldn’t have been as much fun!

Note that I’m not standing up for the GUI’s in later DDR games. The GUIs for the “adventure mode” in DDR Extreme 2 and DDR Supernova are amazingly unintuitive, and they don’t have any “fun factor” to fall back on, either. They just suck. If you’re going to be unintuitive, it’s gotta be for a really good reason!

Why Game Code Sucks

I agree wholeheartedly with the comments on the previous blog post: game code seems to pick up most of its crap at the end of development (or what you suppose is the end). You start cutting corners because you think you’re done, or there isn’t much time, and soon enough your objects are pulling triple duty.

More than that, though, I think game code is just generally less reusable than code in other arenas. The problem you’re trying to solve with game code is “being fun,” and it seems rare that fun-ness comes together in the same way twice.

When your code is very unlikely to be reused, making it beautiful just isn’t worth it. Of course, if your code is buggy, then you lose sales. And if you can’t leverage your code to make sequels, you lose again. But aside from that, whatever. Game mechanics are so finicky and yet so simple that reusing your game objects isn’t a big win… you’re better off just hacking what you need now. Your next game will probably want all different details anyway.

There are some things that you’ll obviously want to use again: GUI widgets, configuration objects, maybe even your entire Top Ten List. But most of the actual game varies too much to be reused. So I don’t try.

So I propose a system that acknowledges that most of your game’s code is dead-end code, never to be reused in future projects. Its goal is just to be comprehensible and bug-free, not pretty.

Hit Points

I like to think of my code as having hit points. A beautiful code body with really elegant object structure has maybe 50 hit points, and as you start hacking things into the code, it starts to lose health. If it reaches 0, it’s unmaintainable and you lose. So you’ve got to periodically heal the program by refactoring code and documenting. However, if it’s still at 50 at the end, you lose, too, because you’ve probably overengineered things and wasted time.

The difference between this and traditional engineering is that I don’t recommend trying to make all your code perfect the first time through — I recommend quick hacking and then refactoring. When coding game features, you just can’t tell where something’s going to lead. The exploration factor is so high that you’re wasting time if you try to create perfect code the first time.

Embracing Prototyping

I think that at least half the cool ideas I had for Starcrossed got discarded. They sounded fun on paper, but they weren’t actually fun. And the other cool ideas changed dramatically from their original incarnation. If I’d spent a lot of time designing each feature instead of hacking it in real quick, I’d have wasted TONS of time. The only way to know how a feature is going to work is to see it in action, and tweak it for a while. Only then do I know how to code it the right way.

At that point, I step back and figure out if my quick-hack version is going to be reliable, or if I should rearchitect it to be cleaner. It depends on how much damage my quick hack caused. Sometimes I leave ‘em in there, if they’re fairly isolated and reasonably obvious.

I think a major time-waster among new programmers is ego: they know how to do things the right way, and they can’t give themselves permission to do it the fast way instead. Even for a prototype.

Because I give myself permission to hack code, I can test ideas very quickly, even though I code in C++. I give myself two days’ coding time on an idea: by that point I can usually tell if it’s going to be exciting or not.

This is coding for fast results, not coding for reuse. It’s optimizing my time now, instead of gambling at optimizing my time later. My game code sucks, but it’s good enough: maintainable and bug-free.

Game Code Sucks!

It’s a dirty little secret in game development. The actual finished code of most games sucks. It’s barely maintainable, often riddled with special cases, and the code authors are often embarrassed to have their code seen in public.

I’ve been a senior engineer for over a decade, I’ve mentored new programmers, I’ve written long articles about how to write good code. But I have to admit that a lot of my game code is crap. And I’m willing to bet that by the end of your project, your code will be too. Why is that?

  • The goals of a game are too vague to properly plan around. You can’t use a “waterfall” development model with any reliability
  • The “agile” development method with a multi-discipline team tends to focus less on code cleanliness and more on making a fun game, which is an incredibly hard task all by itself
  • Traditional refactoring approaches don’t work well because the GUI requirements are extremely detailed and intricate
  • Your time constraints are manic and often impossibly short

I’ve heard all the arguments for how to fix this problem; everything from “be a better programmer” to “use more extreme programming” to “just plan things better.” But these don’t reflect the reality of the situation. The reality is this: if you show me a game that has really clean and maintainable code, I’ll show you some other game that beat them to market and quite possibly took some of their sales.

This isn’t unique to indie gamers, either. Except for a few cases (the engine code at Turbine is reasonably clean), the game code I’ve seen everywhere has basically sucked. Even when the developers use Scrum. Hell, especially when using Scrum methodologies, because game functionality seems to win out over code cleanliness in those situations. Sure, it shouldn’t, yadda yadda, but it does.

So we have to live in the real world where game code sucks. But our code has to be maintainable! We have to keep this code working for years after the game ships. We will quite possibly want to use the code for a sequel. It can’t be entirely throw-away code. Where do we draw the line, and how? I’ll offer my thoughts on that next time.

Any casual game devs need $20?

So I’ve done a couple of the “analyze your game for $20″ deals I mentioned earlier, and they’re a lot of fun. And I think they’re pretty useful, too — not that I had any amazing insights, but a new pair of eyeballs is always handy.

I wish I could analyze my own game this way, but I can’t. I’m too close to it. I’ve also subjected friends to alpha testing, and I’ve even done a full beta-test with hundreds of people. But after the beta, I made lots of changes, and now I have nobody left to give me first impressions!

If you’ve got a bit of time to spare, and you’re a game developer (or are an experienced casual game beta-tester who can give lots of feedback), and want to earn $20, drop me a line! :)

VS 2005′s Installer Creator Sucks

I have the nice fancy Visual Studio 2005 Professional, so when I wanted to make an installer, I figured it’d be trivial. I created a new Setup project, and then I figured out how to drag files into it and make registry keys, but then I got stuck. I couldn’t change even the most basic things like the Company Name! It always installed to “Default Company Name.” I knew there had to be a way to edit this, so I searched and searched. For hours! Now I will add this knowledge to my blog so that Google catches it and helps other lost souls.

The Company Name, etc., shows up in the Properties tabbed window. To view it, choose View->Other Windows->Properties Window from the menu. (It’s NOT the button along the top that says Properties, nor the menu option that says “Properties Manager”, nor the dialog that pops up when you right click an item and choose “Properties…”. Those are DIFFERENT properties in there. Brilliant.)

The secret is that you can’t just go to the Properties tab any old time. The Properties tab is context sensitive, so if you click on something in the User Interface window, the Properties tab shows properties for THAT window instead. The trick is to remember that the Properties tab only shows data for the last thing you clicked on.

So, to edit the basic setup properties:

  1. Go to the Solution Explorer tab and click on the base node of the project’s tree. (Such as “MyApp_Setup” or whatever you called it.)
  2. IMMEDIATELY click on the Properties tab (or use Alt+Enter to jump to it). Don’t click on anything else in the mean time!

Like so much of Visual Studio, it seems obvious once you’ve figured it out. But only after you’ve figured it out! Maybe if I wrote lots of Visual Basic apps this would have been trivial for me. But I don’t, and it wasn’t.

Having other troubles with VS 2005 Setup? If you want to do anything besides install some files, you’re going to need help from the Microsoft Knowledge Base. I needed to add a shortcut to the Start Menu to uninstall my program, and there’s no chance I’d have EVER figured out how to do this on my own. It involved creating a fake project and configuring the fake project’s files in weird ways. Good luck!

Instead of VS 2005… I gave up on VS2005′s setup process. It’s too inflexible and way too hard to figure out. Instead, I switched to Inno Setup. It’s free and very powerful. The “newbie” download bundle comes with an alternate front-end called ISTool. Make sure to get that! When you create a new project in ISTool, a wizard guides you through the steps of making an installer. I had a near-perfect installer in 5 minutes. I was incredibly impressed.

The only down side is that Inno Setup doesn’t create .MSI files, but for casual game installers, that’s not an issue.

Analyze your game for $20

You may have noticed that I don’t put up a lot of Game Analyses. I love to analyze games, but the write-ups take a few hours of time, and I always feel like I should be working on something that pays the bills instead. I still play lots of casual games, but I only jot down a few notes on each one, and never write up a web page for them.

But I do love doing the write-ups. So I was thinking, what if instead of making write-ups of published games, I wrote up analyses of almost-finished games, just for the author? So here’s my pitch: if you have a mostly-finished casual game and would like a second opinion on it, I’d be happy to provide one. I’ll play your game for an hour or so, write up all my notes (three or four pages worth), and send them back to you — all for $20.

This will include:

  • a mini-QA session (I’ll try to crash your game),
  • checking for common oversights (for instance, do you support lefty mouse button swap?),
  • notes on the intuitiveness of your control scheme
  • notes on your game’s presentation.

I’m not a super expert, but I do have years of experience as a professional game developer crafting user interfaces, which means my comments will at least be somewhat relevant. Think of me as a very attentive beta tester who will give you copious notes on my experience.

The results will be sent privately to you, unless you’d like them added to the Game Analyses section of my website, which I’d be happy to do too.

Anyway, drop me a line if you’d like to try it. I’ll do the first one for $10, as a Getting Started offer :) There are crazier schemes on the internet, right?

The quality of an endorsement

I love Pac Man Championship Edition on the XBox 360. It’s an amazingly crafted game with tons of polish and perfect level design. You should buy it.

But wait, should you listen to my endorsement? The fact is, I’m really, really good at Pac Man CE. My score puts me in the top 150 overall, and the top 10 weekly. Naturally, I play a lot more than I should — hours a day. I’m completely addicted.

So does my being good at the game make my endorsement less valuable? Well, if we take it to the logical extreme, let’s suppose that I was the #1 Pac Man CE player, and I told you, “You should play this game, I’m the world’s best at it!” Yes, of course you would find that endorsement a lot less valuable than an endorsement from a friend who is only so-so at it, but who loves it anyway.

But professional game reviewers tend to be really good at games — very often to the detriment of their review. No review I saw mentioned that God of War 2 had tough bosses even on normal mode. That’s because the reviewers didn’t find them tough at all.

But it’s not like I endorse every game I like, even if I’m good at it. I like SOE’s Everquest 2 a lot, but I won’t recommend it to people because SOE has made too many rookie game-balance mistakes — I have no faith in their ability to maintain the game. (And trust me, I know rookie MMO game balance mistakes. I made all of them when I rebalanced Asheron’s Call 2. And, like the SOE game balancers now, I didn’t even realize many of them were mistakes until years after the fact.) But even though I only endorse a game I truly want you to play, my idea of “you” the audience is naturally tempered by my own abilities.

In the end I much prefer demos, but I can’t afford to play all the demos that exist out there — I need to use reviews to narrow my search. Hmm, if only Rottentomatoes.com did casual games!

“Sculpted” content versus “freeform” content

Another useful way to categorize game designs is by their approach to content. Some types of games (such as adventure games) are completely “sculpted” by the designer: every bit of the content has been planned out beforehand. The traditional match-3 game, on the other hand, is “freeform” — a large portion of the gameplay comes from randomness. That doesn’t mean the designer didn’t work hard on the balance — they likely spent a long time making sure the randomness felt fun — but in general it’s still a lot easier than making sculpted content.

As casual games get ever more elaborate, we’re seeing sculpting become a requirement rather than a choice. These days, even match-3 games have pretty significant “sculpted” aspects: it’s not unusual to have unique board layouts for each and every level of the game. You might call this “mini-sculpting” because that the designer still relies heavily on randomness, but they limit the randomness to ensure a fun and constantly-changing experience.

What are the advantages of sculpted content?

  • The pace is exactly as the designer wants it
  • The designer can create obstacles for the player to overcome; these are often much more fun than just playing randomly-generated levels
  • If the game has story, it can be tied intricately into the sculpted gameplay.

But what about the disadvantages?

  • Even the longest sculpted game is shorter than an infinitely-long random game. The user has less content.
  • A game that’s unfettered by tight sculpting can adjust its difficulty upwards or downwards to better match the user’s ability. (Sculpted games can do that, too, but of course that means you have to sculpt an easy mode and a hard mode and so on.)
  • If the user gets stuck, they are stuck forever. They can’t try again and hope that the board is different.

More and more games are going the sculpted route, or else combining sculpting with some randomness, even though this shortens the game. Not really surprising. Sculpted content feels more “polished”, and polish is much more important to a casual game than play duration!