I just haven’t been working on casual games recently. I’ve gone back to developing MMOs (as a contract consultant and engineer), and so my wife and I made a new blog on that topic. It’s at http://www.eldergame.com if you’re interested.
Some people have gotten stuck near the end of Starcrossed, when it starts to get pretty hard. If you find yourself getting stuck on a level, try these cheaty cheat codes!
Refill Energy Refill: while playing, just type “moonpower” (without the quotes). You won’t see any feedback until you type the whole thing — then you’ll see your energy bar instantly refill!
Instantly Win Level: while playing, just type “starpower” (without the quotes). Type it correctly and you’ll instantly win the current level and go on to the next!
Just a warning though: using either of these codes will reset your score to zero! So if you’re going for a high score, you can’t use these codes.
[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.
As Jesper Juul (his company made High Seas) mentioned to me in an email recently, match-3 puzzle games seem to be getting harder. He’s right… they really are. In fact, the newest match-3 puzzle games are really tough! In earlier posts, I had suggested that the DS game Puzzle Quest was too difficult to be a casual game. But maybe I’m wrong. The newest match-3 games rival Puzzle Quest in difficulty.
I still think that, in general, casual audiences want to be engaged by a game, rather than outright aggressively challenged by the game. They don’t think it’s fun to retry a boss stage over and over until they get it right. But what was once engaging is becoming boring. What was once a perfectly-balanced match-3 game three years ago is too easy now. I think the hide-and-seek item hunt game genre is undergoing the same thing: the newest entries in the genre are significantly harder than the earliest ones. That genre is solidifying, too, and it’s much younger than the match-3 genre.
This is a tricky problem, because it means it’s harder than ever to know how hard to make a game. Starcrossed isn’t a match-3 game at all. But it’s played on a similar board. Do any of the player’s match-3 skills come into play in Starcrossed? Probably some match-3 skills, yes, but not all of them. So … yeah. I guess I should make it kinda-sorta hard, then? What do I use to measure?
The only real way to tell how hard to make it is to get members of your target audience to play your game and give you feedback. If you’re making a match-3 game, your audience is match-3 enthusiasts, so you’ll have to find some and get them to test your game.
At this point, you might be shouting, “Just stop making games in the same genres!” There’s some merit to this: if you make a game that’s significantly different from the common portal games, you can assume that the audience doesn’t have any skills in your game, and it’s a bit easier to balance. You can err on the side of easy.
But as I found with Starcrossed, even a game with significantly different mechanics has some crossover skill. Let’s face it: casual gamers are starting to get real gaming skills, and those skills will carry over into almost any kind of game they play. The audience is solidifying. They’re getting better, and casual games are getting harder as a result.
I’m extremely happy to announce that you can now download Starcrossed from iWin games!
Starcrossed is a unique new puzzle game with a celestial theme. Help Ione rescue her sisters and restore the heavens! Although it looks at first like just another match-piece game, it’s actually quite a bit different.
Once you’ve gotten the hang of the game, be sure to check out the Challenge Grid. This is (IMO) where the game is at its best: each Challenge has a different rule set and objective, and there’s TONS of neat challenges to discover. The constantly-changing gameplay really satisfies my ADHD impulses.
Should your game have a Credits screen? Of the games I have handy, more than 50% have a credit screen. Yet some of the biggest names, such as Luxor 2, don’t. Instead, their credits are only in the readme.html file that comes with the game.
What’s the advantage of having credits in-game? It’s unlikely that people are going to be impressed by a list of names… and the people who ARE impressed by a list of names are the sort of people who read readme files anyway!
I removed the credits screen from Starcrossed, partially because it seemed unnecessary, and partially because it wasn’t very polished — and I didn’t want to spend a lot of time making it look cool. There are credits in the readme file, and that’s enough for me.
Am I missing something here? Is there a point to in-game credits aside from the vanity effect? I know in the brick-and-mortar games world, people really like having their names in the game’s documentation… getting your name in-game is cool too, but not as important. Presumably this is because the sorts of people who care (such as Moby Games) use the credits from the booklet, not the in-game credits. But even that is just vanity; it means nothing.
Especially in the casual games market, where brand names are irrelevant, let alone developer names, I think credits screens are an unnecessary detail. Unless your credits screen is awesome to behold, don’t bother.
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!
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.
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.
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.
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.
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!