Licensed Music Woes

[I've finally returned to the computer desk, after a long, irritating move from San Diego to Orlando! Wow, a month with no posts...]

Like most small casual game developers, I used licensed music in Starcrossed. $50 a track is right in my price range. The better tracks usually aren’t quite loopable when you download them, so you have to go in and snip bits off of them to make it work, but it typically doesn’t take too long. I picked what I thought were some pretty good “soothing” tracks for Starcrossed. But licensed tracks aren’t really well understood by players. Here’s a forum post on one of the portals:

I played the trial and it was driving me NUTS because I KNEW I’d heard that music in some other game. I spent most of my free trial trying to figure out where I’d heard it before.. turns out its the same theme music used in Deep Sea Tycoon.

Deep Sea Tycoon also bought the same $50 music track. And probably a half-dozen other games I also didn’t play. Since players don’t understand how licensed music works, it comes across as … well, as shady. On the plus side, relatively few players will ever notice. On the down side, I’ve occasionally seen it brought up as a negative point in casual-game reviews. Reviewers don’t understand how licensed music works, either!

The only alternative is to get custom music, which is expensive and a gamble. You never know if the musician will be able to deliver quite the right vibe for you. But at least you avoid the “recycled music” vibe.

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.

Responsiveness, or the lack thereof

If you’ve installed the new “Windows Live Messenger,” have you noticed how terrible it is? It’s unresponsive. I often click on its icon in the tray and then wait and wait … sometimes I have to wait as long as five seconds before I get any indication that it noticed my clicks. In the meantime I’ve usually clicked like mad on the thing in case the first click didn’t work. It’s frustrating. I’m a long-time Microsoft IM user, and this lagginess has driven me away from the product. I’m looking into alternative IM clients like Trillian. And the only reason is that I hate having to wait to see if it’s working.

I feel the same way when playing a game. I hate it when nothing happens!

  • When the game starts, does it do nothing while it’s loading? Does it display a big black screen for five seconds, leaving me to wonder if the game blew up my monitor?
  • When I click a button in the game, does the button graphic change so that it actually looks like it’s been pressed? Or is it just a static unresponsive bitmap?
  • When changing the volume slider knob, does the game not play a sound to help me judge whether I’ve got the volume at the right spot?
  • Does the game not care that I have my mouse buttons reversed because I’m left handed? If so, it interprets my left clicks as right clicks, and right clicks don’t make buttons work. So what I get is this: click, click, click, “Hmm, it’s not working. Is it broken, or just laggy?” Either way, the game sure didn’t impress!

The number one rule of thumb when designing anything for the computer, be it games or anything else, is that it has to feel responsive! In fact, if your program is responsive at all times, we’ll assume it’s fast. The sad truth is that a program can be slow as hell behind the scenes, as long as it reacts swiftly to our input.

Defining Casual vs. Hardcore, pt 2: Time Consuming vs. Not

The other useful way to define casual vs. hardcore is by how long a game session is. A good rule of thumb is that a “casual game” can be played enjoyably in a 20 minute window or less.

So although I set out to define “casual” and “hardcore”, I’ve actually created four quadrants of game style:

Casual vs. Hardcore Categories

  • Challenging with Short Time Requirements: the most obvious example of this category is the old arcade game. Pac-Man, Galaga, Pole Position: these games require short amounts of time but are usually pretty challenging. (We often take for granted how hard these games were, back in the day.) Some games on casual portal sites fit this area, such as some Arkanoid clones. The Nintendo DS and Sony PSP also have a large number of games in this section.
  • Challenging with Long Time Requirements: many of the most popular console games fall into this category: God of War, Prince of Persia, Madden Football. These are games that have a long per-game session and are unabashedly difficult to play. They appeal to lots of people, but it should be no surprise that competitive males with lots of time on their hands tend to prefer these games.
  • Engaging with Short Time Requirement: this category contains most of the games on portal sites. Bejeweled, Diner Dash, Bonnie’s Bookstore. They are just difficult enough to be engaging without actively challenging the player’s abilities. They also have a brief time duration: you can finish a session in 15 minutes, usually.
  • Engaging with Long Time Requirement: a smaller number of casual games on portal sites fit this bill. A good example from the real world is a jigsaw puzzle. These are games that don’t actively challenge the player — they just require attentiveness. But they also require a long expenditure of time. One could argue that RPGs like Fate or Dungeon Runners also fit into this category, though then you have to quibble about “sessions”: you can play Dungeon Runners for 20 minutes, but in order to feel like you’ve actually accomplished something with your character (such as leveling up), you’ll need to invest an hour or two.

Why bother categorizing games this way? The reason is that you need to know who your target audience is so that you can make a game that appeals to them. Even big companies seem to miss this simple premise a lot of the time.

This grid is just one of many ways to categorize audiences, of course, and your mileage will vary, but even if you don’t use my categorization, please, use some categorization. :) Don’t just make a game you like and assume it’ll sell to everybody.

Actual human beings don’t fit neatly into any one category; many gamers tend to slide between two or even three of these. But when they’re in the mood to play a game, it’ll be a game from a certain quadrant. If I want to play some God of War, then playing Diner Dash instead isn’t gonna cut it.

One other thing: a good game hits ONE or at most TWO of these groups. Don’t try to make a game that appeals to all four quadrants at once; we’ve yet to see anybody make anything successful that way.

Asset Tracking: a better way?

In my last entry I commented on how I’d lost track of one of my sound effects during development — I didn’t know where it came from. I decided to create a paper trail of everything I buy from now on; this will be a last-ditch mechanism to help me track stuff down by following my own footsteps and seeing what I bought and from where.

But it’s not really good enough, as you pointed out (yay, commentators). Is there a better way? Well, the .WAV file format has space to store strings in it, so it should be possible to stick useful information into the .WAV files themselves. Then even if they get changed a bit, I could figure out where they came from. I think the .OGG, .PNG, and .JPG formats have that option, too, so I could use it to track all my assets.

The problem is that I don’t have a program to easily edit that data. If anybody knows of a simple GUI app that can do that, I’d be happy to try it out during my next game development and see how it goes. I can’t find one, though…

(It’s tempting to get sidetracked and write my own little editor for it, but I really shouldn’t let myself get sidetracked any more than is strictly necessary…)

Asset Tracking, or, “Where’d This Sound Come From?”

As Starcrossed undergoes the final polish and QA phase, I made sure all the game’s licenses were in order. One trouble: during development, I bought many sound effects from places like Sound Rangers and only ended up using half of them. I have an “assets” spreadsheet that lists all of the sounds I used and where I got them from. But one of Starcrossed’s sound effects wasn’t on the list.

I searched everywhere trying to find where this sound came from. But it was renamed from its original filename, and I’d obviously mucked with it — I’d reduced the file size, and I’d also probably tweaked the sound in ACID Studio. But where was the original file? I have no idea. There’s no trail for it.

My big fear was that it was a temporary sound that I’d grabbed from somewhere on the web, and forgotten to replace with a licensed sound effect. That didn’t seem too likely, but it might be the case… after all, I had no idea where the sound came from! So I had to make a last-minute replacement. And the replacement sound effect wasn’t quite right, so I had to muck with it a while to get it to sound okay. Wasted time, wasted money.

Moral: don’t be stupid. Err, I mean, keep a strict track of all your assets! For my next project, I’m going to print out the invoice email for every sound I buy, and stick those emails into a file folder. That way even if my asset spreadsheet goes awry, there’ll be a paper trail to try to figure out where things went wrong.

Avoid 14 hour QA sessions

This weekend held a pair of grueling 14 hour QA sessions for our upcoming game. I have contract work through the end of the month (ill-timed, but monetarily important) so it’s been very difficult keeping up with QA work to get the game out the door. A few take-aways:

  1. Remember to take lots of scheduled breaks during 14-hour playing sessions or your arm will twist up like a pretzel. Sandra and I were both in considerable pain this weekend. When it hurts to move the mouse, video games seem a lot less fun.
  2. When taking a break, get away from the computer! Otherwise you’re not helping the over-mousing situation. I recommend a session of Puzzle Quest on the DS. It uses different hand muscles.
  3. We use an internal wiki to check things off the QA list, to make notes, and to record bugs. This works pretty well for small teams. By all means, you must have a QA check list.
  4. You need multiple QA sessions in order to get a real handle on game balance. Each time we played, our skill levels with the game would be different. I’m better at the game in the mornings than in the afternoons, too. Take notes about each session and average them!
  5. Remember that after 100+ hours of playing your game, you are the world’s greatest player of your game. Balance accordingly! Err on the side of being too easy, even though that is an incredibly hard thing for many game developers to do. “It has to have some challenge, or what’s the point of having spent all this time on it?” Two answers to that:
    1. Casual game players don’t want nearly as much challenge as other types of gamers. “Casual” should be a tip-off there. You still need challenge, but you need a more relaxed pace of difficulty-ramping.
    2. By the time you’re play-balancing the game, you no longer have ANY idea what level of difficulty is appropriate. Err on the side of easy, and then get other people to test it to make sure it’s not too hard.

I’ll post the QA list up later, too. That might help people who are trying to figure out what a QA list should look like.

“Click To Skip This Movie”

I’m slowly slogging through the beta feedback and making changes to my upcoming casual game. One of the comments made the think. Somebody complained that they wished the story scenes were skippable. But the story scenes are skippable… you just have to click the cursor anywhere on the screen, or press the escape key on the keyboard.

So this player wanted to skip the movie, but didn’t think to click the mouse. They expected instructions on how to skip the movie. I’m not sure how people became trained that movies are un-skippable by default, but they apparently have.

Since I have no way of knowing how many users are in this boat, I don’t know whether I need to add a “Click to Skip” sentence somewhere on the screen. I’d rather not, since it looks stupid. Next time I do a beta, I’ll add logging to see if people can figure out how to skip the movies.