For those casual-ites who have not experienced the core side, a bit of insight provides perspective on what to embrace and what to exclude. Where better to get info on the casual-core interface than from someone who has successfully navigated within both industries? Scott Bilas worked as the Lead Engineer on the core retail, PC/console games Gabriel Knight III (Sierra Online) and Dungeon Siege (Gas Powered Games). He currently works as Director of Development at Oberon Media in the casual online games space.
Everyone seems eager to define what “casual” is. How do you see it?
I used to think of "casual" as just "smaller scope, timeline, and budget.” While this can often be the case, I've since decided that it's too narrow and exclusive a definition. There are plenty of awesome hardcore games that serve niche audiences that are small, cheap, or quick to build (Geometry Wars, Crimsonland). There are also plenty of high-budget games running on expensive consoles that are definitely casual (Burnout 3, Guitar Hero). The cost/scope issue is more a function of desired depth of content.
Today, I think of casual as simply "games for everyone"—it's just an attitude. These are games that primarily focus on making game-play fun and approachable, not usually worrying about moddability, fancy graphics algorithms, inventory management, etc. Now, obviously all games are supposed to be focused on fun, but with hardcore games, it's easy for a developer to get distracted with expensive things that don't add much to the game-play. (I’ve been as guilty of this as anyone in hardcore development).
That being said, it's most convenient to think about casual games in broad terms. The line is blurring, though, as casual budgets go up and hardcore games become too nerdy to be profitable. This has been a big topic at hardcore game conferences lately. There will come a time, though—maybe in five years or so—when "casual games" will mean something totally different to us than it does today—or when it doesn't really have any meaning at all any more because we will all be making mass market games.
The Casual Space – Business-Driven
Brian Reynolds of Big Huge Games often speaks of the differences between a business-driven and a development-driven game company. What are the advantages of working at a business driven-company like Oberon Media (in the Casual Online space) as compared to a development-driven company like Sierra Online or Gas Powered Games (in the Core Retail space)?
I'm just a caveman developer, so I don't really know enough to comment much on this, especially when talking about advantages and comparing specific companies. But in general, from what I can see, the business-driven companies seem reliably to make the most money and the strongest partners and enemies. In contrast, the development-driven companies seem to bet on building a hit game—but most can’t do this very reliably. As a developer, I love making a game that's critically acclaimed and treated as something special, but I also really enjoy working with business development people who know what they are doing and are trying to get my game out in every possible way—every language, platform, channel, etc.
In thinking about the advantages and disadvantages of the places I've worked, I wouldn’t say that it comes down to whether the company was biz-driven or dev-driven. Instead, the key is the relationship between the game development team and the biz development team. And then we're talking about culture and personalities, not models. At least for me, what makes the most difference is the interface between both sides.
You mention the relationship between game development and biz development being very important. As the casual gaming market matures, do you foresee organizations like iWin, Reflexive, Oberon, Real and Mumbo Jumbo maintaining their ability to branch across the value chain? Can development and business really mix?
Oh absolutely. We're all already doing this, pushing out in every possible direction. If I saw a Cap’n Crunch’s Big Kahuna Berries cereal come out, I would not be surprised at all. As a developer, my instinct to loathe this kind of marketing stuff fights against my desire to see the stock gain value, for my IP to get out to more places, for mo' money.
For me, the best balance is to let the creative team run off and make great games while you have a different "live team" support group working to get the IP out there. So when someone signs a deal to get our games out in kiosks in the beef section at Safeway or whatever, and we have to put the Safeway logo and "#1 Chuck" on the main screen, the creative team doesn't pay an opportunity and morale cost. There's also the issue of these kinds of marketing deals diluting or tainting the brand (like a Diner Dash Playboy Edition might do) but that's for people smarter than me to worry about.
Casual Games Engineering
What books, websites, tools or other resources have you found helpful that you would recommend to someone interested in moving over to the casual industry?
Books
I originally learned C++ about 15 years ago on a now-ancient book called The C++ Primer Plus. Awesome book, and I swear I've seen it around on shelves lately so they must still be updating it, although it's probably totally different today (so buyer beware). I also got a lot out of Code Complete and Writing Solid Code (though that one's really dated now). The Effective C++ series is good stuff, though it gets too esoteric in places messing around with auto pointers and such, but overall it’s very good. And of course the various "gems" series, particularly Graphics Gems and (shameless plug) Game Programming Gems. Finally, you just can't get enough debug loving, so pick up anything online or offline by John "Bugslayer" Robbins, especially his Debugging Applications for .Net and Windows.
Lately, I haven't really been reading books for game industry or engineering topics. Blogs have taken over. Although I just happened to buy a set of books called Japan Underground and Deep Inside from Amazon Japan. Amazing pictures in those, very inspiring. Not very casual, but everybody should check those out.
Websites
I'm a big fan of Gamezebo and Jay Is Games through the Casual Game Blogs’ RSS aggregator. I find a ton of great new games through those that I wouldn't find on any of the big portals. I also like Kotaku, which, though primarily hardcore, is where all the cool kids go to get their game info. For tech people in Windows land, please read every article that Raymond Chen posts on his Old New Thing blog. Some others I read regularly: Jan Miksovsky, John Maeda, Mark Russinovich, Miguel de Icaza, Scott Miller, Joel Spolsky, Bruce Schneier.
Tools
Casual studios need to be more conscious of expenditures, so I'm usually on the lookout for cheap tools that do an equivalent job to the big tools. I'd recommend that people moving over to casual games reexamine the tools they grew up with and see if they can get away with something cheaper or free. Although you'll have to pry Visual Studio and Perforce from my cold dead hands.
Also, I'd look at alternate codecs, for example Ogg instead of MP3. While a big $10 million game won't even notice the $2k (or whatever it is) patent license fee, a casual game sure will. Ogg is more expensive on the CPU, but it's completely free to use, and great libraries like FMOD support it out of the box. In addition, the quality is much better, so you can pack your huge music tracks down even smaller. With Ogg, we've been able to get away with ~45kbps stereo for our music tracks without losing much quality. Consider JPEG2000 instead of JPEG, which has huge savings in space, though at a huge CPU penalty requiring a pre-decompression stage. Consider embedding Flash to play back video (Flash has a great video codec).
Finally, think about your use of 3D hardware. Many engines, including the one we use at my studio, are built on top of the 3D card. With this reliance, you're cutting out part of your audience that either doesn't have the right DirectX installed, or has bad drivers, or doesn't support pixel shaders, or whatever. I'd really recommend looking at SwiftShader from TransGaming to support this segment of the audience. Then you can have the best of both worlds—fancy 3D effects that scale back on older systems and perform well either way.
Organization is definitely something that would benefit the casual studio as much as a core game studio. How important is it for a casual studio to set up organizational tools such as source control, communication tools, time trackers, and info repositories?
I believe in heavily investing in tools and processes to support the development team, and I spent a considerable amount of time in the early days of the studio setting us up for success. This includes things like: a good bugbase (Jira) with proper workflow, strict standards for source tree layout and builds, compilers and SDKs checked into Perforce, an automated build system (FinalBuilder), heavy debug infrastructure in the games and engines, a good wiki (Confluence), a time tracker to assign costs to projects, email update services from different tools, a low-impedance content pipeline. . . . I took what I had done or learned at my previous companies (especially at Gas Powered Games) and applied what worked to the new studio. We continue to add new services often where there's a need, but generally things are pretty stable now, so we can focus mostly on continuously improving the engine and the content pipeline.
Do you think the energy put into your infrastructure has been well spent?
You bet. It's pretty often that I'll feel like we dodged a bullet, when something comes up that we weren't expecting but were already prepared for, and we didn't have to waste a lot of time dealing with it. As for day-to-day development, things are always getting better, but I'm very happy with the base we're building on—the investment has been paying off for some time now. Our ability to instantly scale the studio up to 30+ people when we were building the Vista games still gives me the warm fuzzies. We never would have been able to do that so effectively without the investments we had made in tools and process.
Tools for the Casual Software Engineer
There are a number of third-party solutions available for developing casual games such as Torque, the PopCap framework, and Macromedia Flash. Can you describe the experiences you've had working with these tools and share any recommendations you have for folks deciding which way to go?
Torque
We looked pretty closely at Torque 2D back when it was in beta, and it was impressive. I bet it's amazing today. One of the developers on my team did the evaluation and I remember him having a game up and running very quickly on it. The GarageGames guys are also really good about support. I'd recommend that everyone take a look at Torque 2D.
PopCap
We have no direct experience with this engine and haven't evaluated it, but I've heard good things about it. Given that it's free, though, I'd be concerned about maintenance and upgrades of the engine, as well as support.
Flash
I have a love/hate relationship with Flash. At Oberon we've shipped several games on Flash and I even wrote an article about it where I talked in detail about the issues involved in making Flash games (see: "What About Flash? Can We Really Make Games With It?" at scottbilas.blogspot.com). Since then, Flash 9 with Actionscript 3 has shipped, which changes the landscape a little—but in our research, not enough.
We've recently decided that for the type of games we want to make, Flash is too limiting—so we've switched completely to a C++ engine. Another limitation of Flash that has bitten us a couple times is its inability to run on other platforms without paying Adobe/Macromedia a giant licensing fee. Want your game on the Xbox? You're looking at a total rewrite with no reuse of code or architecture. We still use Flash for our new games, but only as an authoring tool, and not for playback. Our engine design is also partially inspired by the Flash object model—movies, layers, timelines, hierarchies, and such.
As for a recommendation, I'd still definitely look at Flash. If you want to make a graphically complex or CPU-intensive game, Flash may be the wrong choice, but no matter what, it's still worth evaluating. It's got a big, active community, and you can still make great games on it. I keep a copy under my pillow at night.
What is your take on developing multi-player functionality for casual titles? What resources or research do you suggest for someone just starting work on their multi-player technology?
This is an enormous subject, and much depends on what the "multiplayer functionality" is. Multiplayer is a broad spectrum—if you're simply doing connected games, or turn-based, it's a totally different story from true real-time or massively connected games. Even within real-time games, there's a big range—is it fully synchronized or is each client simulating its own? Are we peer to peer? Are we trying to host 1,000 games on one server? The game design itself is a key element in determining the cost of implementation and testing, and the research involved. It’s hard to give an answer on this, but I’m certain that connected gaming is coming in a big way to casual games, and we all need to be figuring out what that means.
I'd head over to the Torque forums and see what other people are running into. The GarageGames guys have also written a lot of great articles on networking, as have many other developers like Id, Valve, Lucas, Ensemble, Bungie—almost all of which can be found through Google. One thing is certain: adding connectivity to a game is a lot of work. Don't underestimate it, don't expect it can be bolted on later, and don't expect to get away with a short beta period. Connectivity and latency issues take a very long time to sort out, and you need real people to do it.
The Transition from Core to Casual
How does developing casual games compare to developing in the core space? Are you glad you chose to move into casual games?
I was surprised by how well my technical skills transferred over into casual games. We still solve a lot of interesting problems—they're just different, and they don't take three months to solve. It took me about a year to really figure out how to "scale down,” but I absolutely love the casual space and will never go back to hardcore games.
I say that for the usual reasons: small team sizes, simpler codebase, less pressure, etc. But another big reason I really dig casual games is the digital distribution, the try-before-you-buy method. Unlike retail, where you can sucker a bunch of people into buying a lousy game with a ton of promotion or a movie license, in digital downloadable the people who buy your game truly enjoy the game. Promote all you want to get the download velocity, but they won't convert if it isn't actually good. So the top ten games on a major casual games portal like Big Fish are really the top ten best games at that time for that portal’s audience. I love that. I also love how there's a lot of room for smaller developers to make a name and space for themselves. (This is nothing new, though. The old shareware model paved the way for this.)
How should an experienced core game developer be prepared to adapt in order to succeed in our industry? Is it only a matter of scale and attention span?
One of the biggest problems is actually understanding the audience. Hardcore developers make games for themselves ("I like that—let's put it in"), whereas casual developers make games for themselves and everybody else ("I like that, but let's make sure it works for my dad/sister/receptionist too"). This is a tough transition to make. It's very easy to start making assumptions about what the difficulty curve should be or how the tutorial should work, simply based on personal bias. But you've really got to get with your players and see what they do with the game. This is nothing new either: Valve has been beating the playtest drum since they published their "cabal process" years ago. Because we're digitally distributed, though, we can add analytics and find out for real what people are doing with our games.
For me, the toughest problems in adapting are: (a) stop being so nerdy; (b) love your audience, don't resent them; and (c) embrace frequent user-testing. It's easy to talk about but really hard to internalize.
One of the largest differences between a casual studio and a core studio is the scope of the products. Whereas a lead position in the core industry may put you in charge of a single title and all the resources that go with it, an analogous position in the casual space might put you in control of an entire portfolio. Is the skill-set of that project lead in the core space directly transferable to casual business?
I don't think that's necessarily true. On Gabriel Knight III at Sierra we had something like seven engineers with two leads. On Galapago at Oberon we had two engineers with one lead. At least in my experience, we've simply scaled everything down. I suppose where you'd normally have one person to manage each game's IP on big projects at a core studio, you would instead have one person to manage all your games' IP at a casual studio. But I don't have any personal experience with this. I have always managed development, and in development we don't really use the word "portfolio" very much outside of art.
Platform Independence
An advantage to being casual is flexibility and portability. Casual games are continually finding themselves on new platforms: mobile, Mac, console, handheld, PDA. Are alternative platforms a beneficial extension to the casual space?
Casual games work better for porting/adapting to other platforms for a few reasons. They usually have low system requirements, are top-down or 2D or otherwise flat. Though they may use 3D elements, they rarely have a rotating camera. They have a very simple interface—point and click, or click and drag—no hotkeys, and the right mouse button and wheel are almost never required for core game-play. All of these things make it a lot easier to build a good game experience on a set-top box, or a cell phone, or even a game kiosk in a pub. Most alternative platforms have slow processors, poor graphical capabilities, and a few digital buttons (no analog). Casual game designs also tend to “fit” better on these platforms—a Sudoku game is perfect for your iPod, whereas a first person shooter is going to be a lousy experience. As for whether alternative platforms are beneficial extensions: absolutely. We've all seen the success that GarageGames has gotten on Live Arcade. Top titles ported to mobile can make several times the revenue they make on the PC. Casual games can also perform well at retail (PC-CD). I think I saw Bejeweled lottery tickets somewhere—is that an alternative platform?
I think every casual game developer should be thinking about alternate platforms, but thinking carefully. Many of these platforms sound like a great idea but never really pan out. For example, the seat-back games they put on airplanes—are you sure you want to put time into porting your game to Linux or whatever screwy embedded OS those things run, even though nobody seems to buy game sessions from those things? On the other hand, I'm pretty stoked to see what new stuff comes out for the iPod, which is basically a high-end cell phone.
How do you feel about the recent announcement by Microsoft to offer XNA Express openly to allow development for Xbox 360?
I think it's cool. It's like Net Yaroze except way cheaper. It won't have any direct effect on casual games because you can't play these games without buying the kit (which most people won't do), but it should give rise to some great indie game concepts and demoscene stuff. I don't know how many times I've downloaded some cool looking demo from a site only to find it makes my machine lock up or runs so slowly I can't tell what the developers intended. With a solid, consistent platform, we're going to see some pretty awesome stuff—although what I'd really like to see is a Wii Express or DS Express.
Do you think the stance Nintendo has taken on giving games mass appeal will help casual games or the game industry in general?
The casual industry may get some ideas from Nintendo's games (how many DS games spawned from ideas pulled from Wario Touched?) but we're basically already there on mass appeal with our attitudes about making games. We may have a long way to go—only one or two out of a hundred who try our games actually buy them—but we're on the right path. It's the hardcore industry that has a long way to go on mass appeal. They typically look down on casual games, but most hardcore developers I know are huge DS fans, so I think Nintendo will be able to make some change in the hardcore space.
Developing for multiple platforms can quickly consume a lot of resources in a company. How should a casual game company go about building expertise on platforms outside of the traditional business model?
Each new platform is likely going to be an entirely different world with only a few things in common with your primary platform—new technology, new design challenges, new channels, new quality standards, new business model. A Nintendo DS is completely different technologically and API-wise from a PC. A set-top box with only a D-pad plus some buttons (in a crappy infrared remote) has little in common with a mouse and keyboard. If you sell on Live Arcade, you have to play by their rules—TCRs, getting in the content pipeline, making Microsoft happy with your game's quality and appeal. If you go to retail you must deal with the ESRB.
To build expertise on these platforms you're almost creating new business units to handle all of the unique concerns. It's a lot more than just getting a dev kit and learning the XDK, or worrying about supporting widescreen displays. I'd say the technical and design challenges, while 90% of the manpower, are only half the problem of moving into a new platform. The other half is the kind of thing you find a publishing partner like Oberon to deal with.
One special note: it's a good idea to plan for alternative platforms and languages as you're coding and designing your games. Avoid using libraries and frameworks that have draconian licensing schemes outside the PC world. If it's at all possible to have only one "action" button, it will be that much easier to work on a remote control. If you use 100% unicode internally for UI strings and have a TTF text rendering option, you can go to the Far East a lot more easily. If you have a mouse-based game design that can also use the arrow keys and space bar to play, then suddenly devices that don't have analog input are good options. In porting to another device a lot of reworking and redesign must always be done, but some decisions you make early on can really help reduce the cost of these things later.
Scott Bilas can be reached at scottbilas@gmail.com.
Interview by PopCap Games’ Ethan Clark, who focuses on PopCap’s alternative platforms including Xbox 360 Live Arcade . Before joining PopCap, Ethan was the project manager for Oberon Media’s externally published titles for Xbox Live Arcade and other platforms. Ethan can be reached at ethan.clark@casualconnect.org.
