Behind the Screens: The Technology of Casual Game Development
The downloadable, casual game market is an exciting segment of the industry. Development cycles and budgets that are a fraction of those in the traditional PC and console spaces offer developers a lower-risk opportunity to bring their games to market. Developers don't need to contend with the bleeding edge of the latest console or video card technology; some of their bigger concerns are reaching a lower machine specification and trying to keep file size as small as possible.
In order to understand technology issues in casual game development more completely, we polled executives from some of the leading companies in the market.
Please note that the panelists answered the questions individually by email, without seeing any of the other responses.
Interviewee Bios:
Scott Bilas works at Oberon Media as Director of Product Development, where he manages a small but intense casual games studio in Seattle with about a million projects going on at once. In a past life as an engineer, he has worked on "big PC" games, edutainment, and even did time at a dot com. Shipped projects include the Oberon Multiplayer Platform, A Series of Unfortunate Events, BeTrapped!, Inspector Parker, Dungeon Siege, Gabriel Knight III, iCat Commerce Online, and Mighty Math Cosmic Geometry. Scott has been published in Game Developer magazine and Game Programming Gems I and II, and regularly gives talks at GDC.
David Fox is the director of game development at iWin, Inc., a leading developer, publisher and provider of innovative casual game communities. David has been a game designer and developer for over 12 years, with a focus on multiplayer casual games and storytelling. He is the author of several best-selling books about Internet technologies and culture, and his writing has appeared in publications such as Salon.com, Gamelan, and Developer.com. So far, iWin has released Jewel Quest and Mah Jong Quest, two of the top selling downloadable games in 2004. iWin has also just come out with the downloadable version of Family Feud.
Brad Edelman (Chief Technology Officer, PlayFirst) is responsible for setting company-wide technical strategy and driving the creation of its platform and products. Brad has spent the past 25 years participating in the evolution of interactive computer graphics and applications. In his previous position as Principal Engineer at Macromedia, Brad was a key architect of several of the company's flagship products. Brad is also the founder of Uccello Games, a successful game development studio and creator of "Triclops," a critically-acclaimed downloadable puzzle game. Brad holds eight patents and has five additional patents pending. As of this publication date, PlayFirst games include Diner Dash, Spellagories, Oasis, Subway Scramble and Chessmaster Challenge.
Brian Fiete (CTO, PopCap Games) founded PopCap Games in 2000 with John Vechey and Jason Kapalka. As the CTO, Brian oversees PopCap's technology including their open source Games Framework and he has developed a number of PopCap games including Bejeweled and Bejeweled 2. Before founding PopCap, Brian worked at Sierra's WON.net working on various networking technologies as well as creating the award-nominated game Wordox with Brian "Ace" Rothstein.
Brian Goble was already programming games for profit while earning a Bachelor's of Science degree in Computer Science at the University of Washington. After graduating in 1991, Brian worked as a senior software engineer at Edmark before co-founding Monolith Productions in 1994. In 2002, Brian left Monolith and co-founded HipSoft with Garrett Price and Bryan Bouwman to develop casual games for the downloadable games market. Current HipSoft titles include the popular word game "Flip Words", "Puzzle Express", "Trivia Machine" and "Digby's Donuts" which was the winner of the RealOne Arcade Game Developer Showdown in 2003. You can find more on HipSoft at www.hipsoft.com.
James Gwertzman is currently director of business development at PopCap Games, an independent game developer that has helped define the Casual Game industry with hit games such as Bejeweled and Zuma. Mr. Gwertzman joined PopCap Games recently when it acquired Sprout Games, the game studio he co-founded in 2003 and creator of hit games such as Feeding Frenzy and Pizza Frenzy. Prior to co-founding Sprout Games, Mr. Gwertzman was president and co-founder of Escape Factory, a console game developer. Before that he worked at Microsoft in a variety of roles, including director of online marketing for Microsoft Asia out of Tokyo. Mr. Gwertzman graduated from Harvard in 1995 with a degree in computer science.
James C. Smith is the lead game designer and lead programmer for several popular downloadable games including Big Kahuna Reef, Ricochet Xtreme (a.k.a. Rebound), Ricochet Lost Worlds, and Ricochet Recharged. His 10 years of game development experience began with a focus on programming retail PC CD-ROM games but the last few years have been focused on more causal downloadable games like Ricochet. James helped start Reflexive Entertainment in 1997 and has contributed to other Reflexive games including Swarm, and Wik & the Fable of Souls. He also helped launch the Reflexive Arcade web site which sells all of Reflexive's games as well as hundreds of games form other developers.
Kalle Wik is a Co-Founder and Chief Technical Officer (CTO) of Skunk Studios, a leading game development studio. The creative minds at Skunk Studios combine dynamic game design, art, and sounds to make games that everyone can play and enjoy. The Skunk Studios website is also a premiere destination for casual gamers looking for all the latest games. For more information on all the games Skunk Studios has to offer, visit www.skunkstudios.com.
How many people are typically involved in the development of a game at your studio and what is the composition of that team (artists, programmers, et cetera)? How many games are you typically working on concurrently?
Scott: This has varied wildly since the studio was founded, so we've working on anywhere from one to eight games at a time, usually with a few more baking in the oven awaiting resources. Our typical team varies depending on the size and type of the game. Sometimes we'll have five engineers and two artists on a project; sometimes we'll have one engineer do more than one game at once, with five or six artists all contributing. Each game has a producer and usually a dedicated designer. Audio work is contracted out. Other people are also on staff to do supporting roles, like systems engineering or infrastructure development, which are shared across all the games.
David: Typically, nothing is typical. Jewel Quest was designed and developed by one person who worked closely with a freelance artist and audio engineer. As the game become ready to launch, more system developers were brought on to expand and optimize the framework and a producer was brought in to tighten up the assets and user experience.
On the other end of the spectrum, our larger multiplayer games are a hybrid between web application and downloadable game. In addition to the game itself, we need to create community features such as a lobby, friend's list, etc. So the game could involve two or more game engineers and artists on the front integrating tightly with server/system developers and web developers on the back. Several producers help to orchestrate this, and tie in the art and audio.
Brad: Today's casual games are truly interdisciplinary efforts. Contributions come in many forms: art, music, sound-effects, programming, quality assurance, production, management, and that's just at a high level.
As a full-service publisher, PlayFirst produces a mix of internally and externally developed games, so the composition of the teams varies based on the situation. For developers, PlayFirst provides all the additional support an external game development team needs to transform their game into a successful product. In this situation, our contribution ranges from helping with business, legal, marketing and distribution services, to supplying core technology, quality assurance, focus testing and guidance. In essence, we round out an external development team by providing the expertise behind bringing their great ideas - and great games - to market.
And, unlike many publishers, PlayFirst is willing to look at concepts from a very early stage, even a one paragraph description. So, from this standpoint, PlayFirst is also a willing creative collaborator when the developer would like us to be.
For those titles that we develop in-house, our teams generally consist of the following: a programmer, a producer, an art director, staff artists and, as needed, contractors for audio and additional art production.
Combining the work of our internal and external development teams, PlayFirst has brought five titles to completion in six months, and we are working on five concurrently now. The first games were a learning process as we refined how to work with developers in true collaborative fashion. We have built the blueprint of what works and what doesn't, and now we are signing more developers and plan to ship many more great games.
Brian F.: Generally, PopCap games are built in three person teams: one programmer, one artist, and one producer. We want to maintain the agility and full-team project ownership present in small development groups, at least for the time it takes for the game's vision and mechanics to solidify. We have a very open development process at PopCap, however, so by the time a new game ships there will have been a number of contributions made by people not "officially" on the project. With production value and game complexity going up, we have chosen to expand the number of games concurrently in production rather than increasing the team size. At this point we have six games in full development and about another half dozen in various states of design or prototyping.
Brian G.: HipSoft is made up of myself (Brian Goble, programmer), Bryan Bouwman (programmer) and Garrett Price (artist). Garrett and I also handle the game design work while Bryan handles all of our server and networking systems.
Although we've considered attempting to develop two games in parallel, we've found that focusing on one game works well for us in terms of making the best game possible in a reasonable amount of time.
James G.:
A typical game for us involves anywhere from 3-8 people. At a minimum, we have a programmer/game designer, an artist, and a sound designer/music composer. A bigger project would have a dedicated level designer, multiple artists (typically a 2D illustrator and a 3D artist), and multiple programmers.
I should note that these are not full-time employees. Sprout Games has three full-time partners, all programmer/designers. We rely entirely on contractors for all other positions that we hire on a project-by-project basis. For a small company like us, this gives us the maximum flexibility and it allows us to keep projects at the prototype stage as long as necessary without the pressure of having full-time employees that we need to keep busy.
Whenever possible our contractors work in our office; we have found that it takes much more time and effort to get great results from contractors when they're not under the same roof .
We have found that we can have up to 2 games in full production at a time, depending on their scope, while also working on prototypes for a third.
James S.: Our development teams typically consist of eight people. Many people do multiple jobs, but if I had to assign labels, I would say we have four programmers, two visual artists, and two level designers. With the exception of localizations, we develop every aspect of the game in-house including all the roles mentioned above plus music, sound effects, writing, and QA. Obviously many people are doing more than just "programming" or whatever their title is.
We typically focus on one new game at time. But we do usually overlap the schedules a little bit. As one game is nearing completion, some people will transition over to the next game. It is usually good to have a programmer getting something up and running on the next game before all the contents creators are assigned to the project. We usually have an artist also start early on concepts for the next game before the last game is finished and before the full development crew is assigned to the new game.
We are finding that a game is never completely finished and it is difficult to say exactly how many games we are working on at any one moment in time. We are forever making new builds of older games for different languages, platforms or special API for rewards system or DRMs used by distributions parts. You could say we currently have 6 or 8 games in development if you counted things like Mac ports, web versions, localizations, add-on packs, an so on.
Kalle: Skunk Studios has anywhere from 2 - 4 games in production at any given point. Our production teams are usually comprised of a producer, programmer, artists, sound person and, in special cases, 3D animators/modelers.
What are the biggest technology challenges you face? File size? development time? Low target specs? Tools?
Scott: All of the above, and again it varies. Right now our biggest problem is tools and development time. In the past, we've run into file size and target specs issues, especially in the realm of performance (and I'm sure we will again in the future).
David: The biggest challenge is trying to pack high-quality features into a game that we are targeting to be a ten Megabyte download. This is especially difficult to do with art and audio, and we always have to make tough sacrifices. We spend lots of time coming up with clever ways to recycle and compress assets to avoid cheesiness and achieve slick-looking interface art, special effects, and a surrounding animated story.
It's also becoming tougher to keep our framework robust yet flexible enough to support many different styles of game-play. The framework started off as the structure behind slow puzzle-based games, so it takes a lot of work to get it suited up to handle more advanced arcade-style games.
Brad: Let me say this first: The biggest challenge in game development is creating fun. As CTO, I strive to make sure that technology does not get in the way of that primary goal.
In the casual games space, getting product teams to respect small download size targets is one of our biggest challenges. Game producers must constantly remind the team to monitor download size. I like to tell my team, "Programs get bigger one byte at a time." It's really easy to think that another "small" 8 KB image is "nothing," but these add up. Many experienced game developers are used to CD-ROM sized asset budgets, so ratcheting people back to 10 MB takes constant reminding - it's a mantra we repeat, "keep it small, keep it small."
Brian F.: I take a holistic approach to technology at PopCap - the biggest challenge is improving the efficiency of converting a vague game vision into a PopCap product. That is a very wide goal that has taken me all over the place, including developing unified games framework to reduce per-project basic technology challenges, building a project collaboration and communication tool to allow teams to work together more efficiently, and, my current project, an in-process scripted development environment designed to make PopCap game programming feel more fluid like an artist's tool rather than the standard coarse cycle of compile-run-stop-tweak.
Brian G.:
In 2004, we focused on download size and trying to keep all of our games around 5-7 megs. This forced us to create some new technology and tools for image compression, text rendering and image sharing.
In 2005, we're upgrading our core graphics systems to allow us to do more special effects and 3D rendering. However, our customers don't always have the newest hardware and many are not comfortable updating drivers when that becomes necessary. Our games need to run flawlessly from the first install or the user will just move on to another free game demo. For these reasons, enhancing our graphics without decreasing compatibility is one of the technology challenges we're currently working on.
James G.: At least for us, the greatest challenge to creating a successful game is game design, not technology. Someone once told me, "You can't engineer fun" and I think that's very true.
This may also be because all three founding partners at Sprout Games majored in computer science and have engineering backgrounds. As a result we find the engineering side of the business relatively straightforward and wherever possible we have applied technology to make the process of game designer easier.
For example, we have invested a fair amount of effort in making it easy to iterate quickly when designing a game. We have GUI tools for things like previewing particle systems or designing screen layouts, and our engine framework is very modular which makes it easy to quickly prototype a new game idea.
That said, there are certainly technology challenges in every project. The biggest one is generally performance. We have stayed away from hardware-acceleration in order to simplify our Q/A workload and to make sure that we can target the broadest possible set of customers. As a result, everything in our games are 100% software rendered, and even though we have some pretty heavily optimized graphics code, we must still work hard to realize our full artistic vision on low-end machines.
James S.: We feel we have a very good handle on the technology needed to make great looking games run well on low end systems and fit in relatively small downloads. The real challenge is just keeping the development time under control. It is very hard to not add every cool feature you think will make the game better. This is not really a technology issue but just a project management and game design challenge.
If I had to pick one technology issue we find challenging it would be building communities. The portal distribution system limits how developers can communicate with customers and build communities. We haven't adapted our community building process enough to fully compensate for the limitation placed on us by portals. We like to let our users create their own add-ons for the games and share them with each other. Only a very small percent of players uses the editor to make their own levels, but almost all users like the ability to get the free add-ons made by other players. Our current games have the editor in the game but all the community related portions are either web based or non-existent. Players have to go to the game's web site to download the free add-ons. To give more users access to this wonderful community we need to develop technology to bring the community into the game. At a minimum, it would be nice to be able to download add-ons from within the game. But it would be even better to stay in-game and have the ability to upload your creation, post review of add-ons, and access a community forum. Putting these features in-game would make them more accessible to some user and help resolve the problem of portals now allowing games to link to web sites. Many Ricochet players have no idea they can download thousands of free add-on levels because they purchased the game from a big portal who wouldn't allow us to include a link to the community web site in the game itself.
Kalle: The biggest technological challenge we face is delivering the most game and entertainment possible with the smallest filesize. Low target specs is a persistent challenge also, as we are constantly balancing the trade-offs between low target specs and high quality experiences for those with faster computers.
What programming language(s)/environment(s) do you use to develop your downloadable games and why?
Scott: We use Director, Flash, Visual C++, Visual C#, Perl, Jscript, Python, and whatever other languages are convenient do the job. Director was an easy way to get started, but lacks flexibility, has a bad scripting language, and is very buggy. Flash has a great object model and scripting language, and is flexible and quick to build games with, but has serious performance problems and a useless debugger. We continue to use Flash, though, because it is so quick to prototype with - I did a lecture at GDC 2005 on this subject. C++ is probably the worst language to write games in, but is very fast and flexible. The best solution is to steal the best traits from Flash and build a custom C++ engine with a powerful tool chain to support the content team. The rest of the languages I mentioned (C#, Perl, etc.) we use to build tools and infrastructure.
David: We use Microsoft Visual Studio 6.0 (C++) because it offers a mature, well-tested coding and debugging environment. This is important because we can get internal as well as external developers up and running very quickly. We've started to become very interested in working with talented independent developers and sharing our framework with them.
Our core engine is based upon the Simple DirectMedia Layer (SDL), which is a great open-source multimedia library.
Brad:
Again, as a publisher, PlayFirst works with external game developers, some who have loyalties to certain products (such as Macromedia Director) or only have certain skills (for example, they are Lingo scripters and not C++ programmers). Since creativity is paramount at PlayFirst, we are flexible and want to work with developers in a way that enables them to express their creativity most easily. That said, looking down the road at porting games to new platforms, we know that some approaches are more nimble than others, and we encourage developers to use our core game engine - which addresses many of these known challenges - when possible.
Our goal is to find the right set of tools for each game and each developer - we guide our development teams towards best practices that make the games easiest to port, localize and test, in order to maximize the opportunity and value of the IP.
Brian F.: We use Visual C++ with a custom framework built on top of DirectX for our downloadable games, and for our web games we use an ActiveX control with an API that's fairly similar to our downloadable games framework. We felt ActiveX gave us the most power and flexibility required to make our games feel the way they are meant to.
Brian G.: Bryan and I are still using Microsoft C++ v6.0 because we've used it for years and we're both very productive with it. However, we have the beta for the new version of VisualStudio--old habits die hard but we feel it's about time for us to think about upgrading.
James G.: We develop everything in C++. We take full advantage of object oriented techniques, C++ templates, and we also depend on the Standard Template Library quite a bit.
James S.: All of our downloadable games are developed in C++. We have a background in developing high tech retail CD-ROM games so C++ is what we are familiar with. We have a large framework (or library if you prefer) of code we have developed over the years. When we started making downloadable games it just made sense to leverage the code and experience we had.
Kalle: Until now, we've used Macromedia Director and Flash technologies for our downloadable and web games. We have also been evaluating other emerging programming languages and tools, such as the PopCap framework, Virtools, and GarageGames Torque engine.
To what extent do you plan for porting to other platforms (such as Mac) when architecting your games? What about localization?
Scott: Porting to other platforms is a solved problem. It's just a matter of deciding to spend the money to do it. Localization to other languages is an even easier problem to solve. In either case, there are simple rules we follow to minimize pain when porting, and it doesn't take much of our time to worry about these things.
David: It's always in the back of our minds. We chose SDL due to its cross-platform libraries (Windows, Mac, and many flavors of Linux). And as we build our games and identify new opportunities, we expand the features of our framework to support these demands on an ongoing basis. For example, we put all strings and art locations in master config files, so that they can easily be altered later on by non-technical folks. And we recently converted all the strings in our framework to wide strings so that it would be Unicode compliant for Korean and Japanese support. A major undertaking, but well worth it in the end. All future games can go Asian!
We're also looking into processes and libraries to more easily port our games to consoles such as the Xbox 360, handheld devices, and wireless devices.
Brad: At PlayFirst, we want to share our one-of-a-kind games with as many members of the casual game playing audience as possible. This is why porting to different platforms, such as the Mac (we shipped our first Mac title, Mac Diner Dash in June), and even down the road to mobile and new platforms like the Sony PSP, is important to us.
PlayFirst plans for localization and porting in all of our games. We promote best practices for both: we externalize string resources to make the localization process easier, and we use appropriate platform abstractions to port our games
Localization is critical for reaching key segments of the mass market. We've partnered with Boonty, a leading global distribution partner, to provide localization services for us. Soon you will find our titles breaking language barriers in the Chinese, French, German, Japanese, Korean and Spanish markets. And, of course we guide our developers around what themes work better in overseas. Everyone likes to have fun; therefore everyone should have access to the best playing experiences with PlayFirst games.
Brian F.: The PopCap Games Framework has already been ported to the Mac, so releasing new Mac games doesn't require that much additional work. That said, our site is still pretty PC-centric right now, but we're planning on releasing a number of new Mac games in the near future. Localization is a little trickier since we don't even support Unicode in the framework and we never do anything like centralize all a game's strings in a single location. While we will probably make some general localization-assisting framework enhancements in the future, we're still likely to develop game as if English were the only language in the world and then let the a third-party localization expert make them truly localizable - trying to do it during development is just too much of a burden that gets in the way of expressing the game's actual vision.
Brian G.:
We're currently supporting both the Mac and foreign language versions of our most popular games.
Getting our games onto the Mac has been relatively easy thanks to our partnership with Red Marble Games. We currently have 7 of our games available for the Mac. The only issue that comes up is the use of the right mouse button (for example, in Puzzle Express) since the Mac typically has only a single button.
Thanks to our image-compression and text-rendering systems, localization is relatively easy for us as well. Every text string (whether it's used for art or game-code) is stored in a single text file. Furthermore, the rendering parameters for any text string can be over-ridden to change the font attributes. For example, if a German text string is too long to fit in the space provided, the font size can be over-ridden to be a few points smaller to make it fit. Our text-rendering system also supports "double-byte" languages such as Korean and Japanese.
The true beauty of our system is that the localizers can localize, test and ship foreign language versions of our games without any recompilation necessary! We love it since there's very little for us to do…which let's us stay focused on our next game.
James G.: Our engine was designed to eventually be ported to other platforms, and in theory it's as easy as replacing our DirectX driver with a Macintosh driver. In practice our first Mac port was a little more difficult, but not much.
Localization was not something we thought about much at first, but now it is something we take pretty seriously. We use XML-based string tables for all text that gets displayed to the player, and we make sure that we don't hard-code anything into the game that might need to get changed during localization.
James S.: Our in-house game framework abstracts platform specific issues as much as possible. No game specific code ever makes OS calls directly. Out framework is mostly developed on Win32 but has been ported to Mac OS X, Linux, Xbox, and Xbox 360. Adapting the framework to other platforms is fairly simple and all of our games come along for the ride almost for free.
Many of our games have been translated to other languages. We always keep localization in mind when developing new games. Screen layouts are kept as dynamic as possible so that buttons can automatically adjust to longer or short text. Text is never baked into images. Any text that will be displayed always gets passed though a localization database at run time using a rather nonstandard approach. We don't require content developers to put all strings into one central text resource file or deal with text string IDs or keys. Instead, displayable text is allowed to be embedded into data files such as level layouts, power-up definition, or even source code. All displayable text is flagged as being localizable. We have a tool that can generate a single file with every displayable string. We send this generated file to a translation vendor who provides us with a localized version of the file. Our special runtime libraries replace the English strings with the localized string before the text is displayed.
Kalle: We publish our games simultaneously for PC and Mac - and (in most cases) for web.
Skunk Studios is committed to localizing its games into various languages, and we set up the asset frameworks with localization in mind during the development cycle.
What is your strategy for reusing code across multiple titles?
Scott: We reuse a lot of engine code across titles; that's a major priority for us. For game code, though, it really depends. Sometimes we copy-paste-adapt, sometimes we share code in common libraries, and sometimes we just chuck it and start with new code. It really depends on what the content engineers are most comfortable with on any given task. The most important thing is that we reuse concepts and patterns from previous games, so we're always building on previous experience. The actual code isn't that big of a deal in comparison.
David: We have one framework that provides all core animation and audio functions, based on a simple Script and Cast Member metaphor. We've tried to make the framework highly data driven, so that most of the sprites animation and behavior can be expressed in simple config files.
The framework also contains tons of "out of the box" stuff that every game needs such as pick a player dialogs, options dialog, rules dialog, pop-up help dialogs, and an in-game menu. This has definitely paid off… Getting the bones of a simple game up and running now can take a week, as opposed to months.
Brad: The strategy for this is simple: we have a core game library that is common across games.
Brian F.: The PopCap open source Games Framework (http://developer.popcap.com) does all the hard work. Outside that, programmers sometimes share bits of code through the tried-and-true technique of copy and paste.
Brian G.: In addition to our core game engine, we have a bunch of libraries that we use during the development of each game. When we begin a new project, we're starting with a proven game framework that we can use to rapidly prototype ideas and concepts. Our goal has to been to reuse as much code as possible and this has worked out well for us.
James G.: We have three different layers of code. We have our core engine, which all our games build on top of, and which provides core services such as rendering graphics, sound/music playback, and resource management. We also have a shared game library which sits on top of the engine, and which provides useful routines such as our user-interface code, user profiles, etc. Finally, we have game-specific code at the highest level.
As we write our games, we continuously think about whether game-specific code should be generalized and moved down into the shared game library.
James S.: Making games data driven helps a lot. We push as much of the game implementation as possible into the data. Level designers and game designers can add to or change many parts of the game through setting properties and writing simple scripts. The code becomes much more reusable when it has no specific knowledge of game specific objects such as specific type of power-ups or enemies.
We have a library of common code that is used on every game we make. This mostly handles low level stuff like reading image and sound files, drawing lines, blitting images, and abstracting OS specific things like output to the screen. But this common code also includes a robust system of object serialization, reflections, and a property editing. We also have a skinnable GUI system accessible to each game. These last two items combine make it easy to build a level editor for any game. Some games share higher level code in common such as management of game objects, scene graphs, AIs, and scripting. But other game use completely different system for this higher level code while still sharing the low level common code.
Kalle: We plan for maximum efficiency - whether that is to find ways to repurpose game engines we already have in existence - or whether it's in terms of re-using code across several games. One example of this approach is our worldwide high scores infrastructure - something that appears in all of our games. We maintain core libraries which can be quickly plopped into new games in development.
What target machine specifications to you develop for?
Scott: This varies depending on the game, and is something we often debate. Our minspec has been anywhere from a P3-500 with 64 megs of RAM and no 3D card to a P4-2GHz with a quarter gig and hardware T&L.
David: Currently, our lowest recommended machine is a Pentium 400 system with 32 MB RAM and a 16MB graphics card, with DirectX 7.0 support.
Brad: Since PlayFirst targets the mass market, our games are designed to be compatible with the most common PCs and Macs in use today. For the PC, our games generally require the following specifications:
Windows Version: 98, 2000, ME or XP
Processor: Pentium III 600 MHz minimum
RAM (MB): 128MB RAM (256 MB recommended for 2000/XP)
HARD DISK SPACE: 12 MB available disk space
PlayFirst games can be played on Macintosh computers running OS X 10.2 and above.
Brian F.: Our current target is for the game experience to still feel good on a P3 500MHZ 64MB system with DX6 and no hardware acceleration. To be fair, that goal isn't usually THAT hard to hit because we generally shy away from action games and we don't have plans for anything that would require 3D.
Brian G.: Our current minimum spec machine is a 500 Mhz with 64 Meg RAM. As we add more software-driven graphic effects, we may increase the min spec to give us a little more horsepower to work with.
James G.: Generally we shoot for reasonable performance at the lowest detail settings on a P3 700 machine running Windows 98.
James S.: We don't require any special video hardware, drivers or Direct X version. All the games we have made to date will work on any 32 bit version of Windows and run well on machines as slow as 500 MHz with as little as 64 MB of RAM. For future games, we are targeting a minimum of 733 MHz and 128 MB of RAM. We don't plan to require any 3D hardware acceleration any time soon.
Kalle: Windows 98, Windows ME, Windows 2000, Windows XP / 500 MHz / 128.0MB RAM / DirectX 7.0a
Mac OSX 128.0MB / 500Mhz
How do you optimize your games to provide users with high-end machines with the best possible experience, but still keep the game playable on lower-end machines?
Scott: This is easy with 3D games - just LOD the effects and models. With 2D games we add options to disable or reduce eye candy.
David: We try to scale our games with a "low detail" mode. Our framework auto-detects the processor speed and sets this mode accordingly, or it can be set by the player in the options dialog. In such a mode, we'll take out 24-bit transparency effects, nice shadows, rotation, scaling, full-screen fades, etc. The idea is to keep the game mechanic 100% playable and fun, but reduce some of the snazzier bells and whistles.
Brad: The reality is that the majority of the mass market does not have a high-end machine. We want everyone that plays our games to have the best possible experience. Our games are designed to offer compelling gameplay on our minimum system specs. High-end machines may offer faster load times and faster frame rates, but those would be the only noticeable differences.
Brian F.: Originally our framework only supported non-accelerated 2d drawing, but we added DX7 hardware-acceleration a couple years ago. A couple of our games, like Bejeweled 2, have supported multiple resolutions, but generally on non-accelerated machines we just lower particle counts, remove some rotations, and do nearest-pixel stretching instead of bilinear.
James G.: Up until recently, we haven't done anything special here. We simply designed our games to run okay on a low-end machine and didn't worry about it. On the latest crop of games (still in production), however, we are explicitly authoring detail levels so that players on higher-end machines will see more bells and whistles, but all users will still have a good experience.
James S.: Most of our games do a limited amount of feature enabling and disabling depending on the performance of the hardware. For example, if you play Ricochet Lost Worlds on a very slow computer it will disable some of the animations in the background. You still play the exact same game but some of the little touches are missing. But for the most part, we don't believe it takes a high-end machine to deliver a great gaming experience. The game is first and foremost about having fun, but the visuals are also important. All of our artwork is pre-rendered 3D which means that all the processor intensive number crunching has been done before the user ever runs the game. We don't have any trouble displaying beautiful 32bit color images on min-spec hardware at 60 frames per second. The high end systems end up with more cycles than they need, so we could theoretically be scaling to high end hardware better, but we feel the games look good enough as they are.
Kalle: We often test for a person's specs when we first initialize a game. During gameplay, we monitor the framerate. If it drops too low, we turn off advanced effects, modify physics settings, and otherwise adjust on the fly to the environment the game is running in.
How does your company approach QA testing? Do you have full-time, dedicated testers, work with a QA firm, or take some more informal approach? What sort of bug-reporting/tracking tools do you use?
Scott: We have full-time dedicated testers, and the size of that team depends on how many games we're doing at a time, or what the other departments in the office require. We also work with a few external QA firms. Again, this depends on the game and the need - for example, it doesn't make sense for us to set up a config lab, so that goes to a specialty testing company. For bug tracking tools, if we're working with a partner, we'll sometimes use their bugbase if they insist on it, but most of the time we use Jira by Atlassian. Jira is a great and affordable tool that we can easily bend to the multiple workflows we need to support across our different teams and offices.
David: We have a full QA team in-house to do the nitty-gritty testing, though we often send our games to outside testing companies during our beta period to ensure compatibility with a wide variety of platforms. We've been using Bugzilla for a while to keep track of open issues, and it does a fairly good job keeping everyone in the team on the same page.
Brad: Quality assurance is very important to us at PlayFirst. We want our games to not only meet but surpass our QA criteria. Each PlayFirst game is rigorously tested by our internal team of full-time QA engineers to ensure they meet the multiple unique demands of the casual gaming audience. Since these games are downloaded and do not come with instruction manuals, they need to be immediately fun, easy to learn, and endlessly playable. The key here is that we're targeting the mass market - that means everyone's PC, not just nice developer machines, need to be able to run our games. We've found that this is a common area where developers need our support.
In addition, as a publisher, we bring a lot of value with our QA capabilities, since most small independent developers do not have a compatibility lab, let alone a QA staff, beta program or a bug tracking system. This QA system helps shepherd all games through development and to the technical level that portal partners require. And, during beta, we also go beyond QA to get feedback from our portal partners on what they think of the gameplay and how the game could be tweaked for greater success. These are just a few more ways that developers can benefit from working with a publisher such as PlayFirst.
Brian F.: We have three great full-time QA testers in-house right now. All our games are based on a common framework, which greatly reduces things like compatibility bugs, and we put all our games through a beta program with hundreds of users before they go through formal PopCap QA. The QA process at the end of a product's development looks more like a final polishing stage than just "making sure the game works". To keep track of it all we use the custom-built communication and collaboration tool I mentioned before.
Brian G.: During development of a new game, our wives and mothers are playing the game constantly (since they are part of our core audience) so that we can fine-tune the gameplay and find bugs.
Once we reach Beta, we do an external beta test with testers that we've recruited through our newsletter. We typically get a few hundred testers to play the game and fill out a short survey.
After spending many years developing large AAA retail games and using fancy bug-tracking software, the QA process for these smaller games is, fortunately, much smoother and bugs haven't been a big problem for us.
James G.: We have never had a full-time QA person, although it's a luxury we would love to have. At first we had an ad-hoc approach, and it definitely came back to bite us. Our first big game, Feeding Frenzy, had a number of bugs which had to be patched. Subsequently we began publishing our games through GameHouse which has provided all QA for us. We use TestTracker internally to track bugs.
James S.: We usually do all testing in house. It starts early with usability testing. In these tests we recruit people who have never played our games to come into our office so we can watch them play the new game we are developing. As we watch them play we take notes about what was hard or confusing. Bug testing is also done in-house mostly be the development team. All our level editors and other tools are integrated into the game. One of the side effects of this is that the game gets a lot of testing. We track all bugs in Bugzilla. Near the end of a project we often hire a temporary employee or intern to do full time testing. At that stage in the project, most of the level designers and artists are also testing full time.
Kalle: During peak production cycles, we contract qualified QA engineers to test our games.
Do you rely on any third-party or custom development tools (i.e. source control)?
Scott: We use Perforce for our source control and Confluence for our wiki, and then a ton of other software dev tools on top of that to make it through the day (Photoshop, Paint Shop Pro, Beyond Compare, dBpowerAmp, Audacity, SQL Server, OneNote, Trillian, whatever gets the job done).
David: We use a bread-and-butter CVS repository. The biggest custom toolset we have has to do with builds. We've tried to create a turnkey method of "stamping" each of our games for various distributors (Yahoo, RealArcade, Shockwave, AOL Games, etc.), and including the proper logo or other requirements.
Brad: We use a variety of third-party tools in creating our games. Our development is done mostly in C++/Microsoft Visual Studio, though some of our developers use Macromedia Director. We use Perforce for version control, FogBugz for bug tracking, Installer WISE for installers, Adobe Photoshop, etc. It takes a big bag of tools to make these games.
We also have a variety of custom internal tools and SDKs. One of my key responsibilities as CTO has been to develop a game development platform unique to PlayFirst. This platform will streamline the development process and make revisions and later updates much faster. Ultimately, this will mean more top quality PlayFirst games in the hands of our customers.
We will be launching the new PlayFirst developer platform this summer, so be on the look out!
Brian F.: We use CVS. Pretty much everything else was built in-house.
Brian G.: We recently switched our source control from SourceSafe to "Vault" from SourceGear. So far, so good.
James G.: If a tool is available off the shelf that will help us speed up development, we'll use it. We use Perforce for source-control, TestTracker for bug tracking, and ImageMagick for batch image processing. We have been happy with GlowCode for helping us track down memory leaks. We also use third party libraries wherever we can, including things like loading JPG and PNG files, Ogg/Vorbis for sound/music playback, etc.
James S.: We use many standard development tools such as Source Safe, Visual Studio, and Bugzilla. We also several great libraries such as ZLib, Free Type, Anti Grain Geometry (AGG), and OGG Vorbis. We have custom tool for file packing, localization, level editing, and a custom art path. The artists do most of their work in 3D Studio Max but Photoshop is occasionally used for touchup.
Kalle: We have a web-based project management system, used to store assets and trade notes and ideas. We do not currently employ 3rd party source control tools, we simply archive builds daily on a file server.
What sort of community or multiplayer features have you included in your games? What more do you plan to do?
Scott: So far we've developed both single player-only and multiplayer-only games, but have not shipped a game with both experiences in one package.
David: Our company's roots are in multiplayer web games, so we're actually forging new paths here. Our first title, Family Feud Online Party, will basically be the first downloadable mass-market multiplayer game ever released (that's a mouthful!). The engine we're developing allows for seamlessly integrating a web application with our game application, so that a lot of the registration and community features players see will actually be dynamic HTML pages. The engine also includes a full player-matching lobby, in-game chat, whispering, buddy lists, and all the usual community goodies. We are able to borrow heavily from our existing online-game infrastructure to support the community features for download games.
For our single-player games, we are trying to roll out a more comprehensive high score system. We're also working on a "quick match" tournament system so that players can have the immediate gratification of being ranked against somebody with a similar skill level who recently played the same board/layout. All of our games also include a simple "tell a friend" e-mail invitation feature.
Brad: We don't currently have multiplayer functionality available in our games. But it is an area we are exploring as some of our key audiences, like families and kids, are very interested in playing games together online. Stay posted on all of our new game releases this fall by signing up on the PlayFirst site: www.playfirst.com.
Brian F.: We built a few multiplayer games in the early days of PopCap, and personally I think a couple of them are good. Now, I realize we were going about it the wrong way. We have some great new ideas, but they aren't quite ready for development yet.
Brian G.: All of our recent games have supported both online high scores as well as downloadable content. The high scores have proven to be very popular and the downloadable content system allows us to give our users additional content to keep the game fresh. For example, Trivia Machine can download new trivia questions and Puzzle Express can download new pictures.
In Jig Words, we expanded our networking systems to allow two more community features. Jig Words has a feature that allows you to add your own digital photos into the game, but we also created a server-based "Photo Sharing" feature that allows users to send packs of photos to their friends from within the game. This is a fun way to allow our users to spread Jig Words to their families and friends.
Jig Words also features a mode of play called "Letter Racing" which puts the player in competition against 3 other players that recently played online. Using recently recorded games for our multiplayer mode gave us several significant advantages:
Although this method of multiplayer worked well for the Letter Racing mode in Jig Words, we have plans for real-time multiplayer modes for some of our upcoming games.
James G.: So far we have not done anything along these lines other than shared high-score boards. The challenge is justifying the opportunity cost of investing in multiplayer features versus creating more single-player game-play. So far it hasn't really been clear to us that adding lots of multiplayer or community features would sell more copies of our games, although we do expect that to change and when it does we have lots of ideas for things we would like to do that we think will be a lot of fun.
James S.: Some of our downloadable games allow multiple simultaneous players on a single computer using Mouse Party™. Many of our retail CD-ROM games included networked multi-player modes but we have never put netplay indo a downloadable game. Much of the community in our games revolves around add-on content. Most of our downloadable games include a level editor. Anyone can make new levels and distribute them if they like. We provide a forum where people can share their creations or download one of the thousands of levels made by other players. Many fans check the forums daily for new levels to play.
Kalle: Worldwide high scores, tell-a-friend and challenge-a-friend.
If you have experience developing in other segments of the game industry, how does developing casual, downloadable games compare?
Scott: A lot of the people in this studio come from the hard core PC industry, so we're well versed in the differences. In comparison to "big" games, developing a casual game is a relatively low pressure, low budget, short timeline, small workload, and small team size experience. Something new and interesting is always coming along. The best games do also tend to rise to the top. Whereas big games tend to get a lot of sequels and licensed IP in the top 10, the top casual games are almost always original IP, and invariably fun games. There's also a lot of room for niche games that serve a specific market. The barrier to entry is very small compared to big games. It is also frustrating sometimes to be limited to a small downloadable game size, but on the other hand, it keeps the focus on creating fun gameplay, not 40 hours of $5 million content that most people don't make it through.
David: Some of our developers come from a more hard-core game development. While developing download games isn't nearly as much of a technical or logistical challenge as a big-budget PC or console product, there are always ways to push the envelope and roll in cutting-edge gameplay elements or special effects. We constantly play and learn from "bigger" games, and try to apply the best features to a more casual audience.
The budget and lifecycle of casual, downloadable games means that teams are small, milestones are many, chances of the product shipping are high, and energy and focus stays consistent from conception to hard launch. We also love the fact that our games are part of mass culture, not just "gamer" culture. It's great to make a game that everyone around us, from grandparents to tots, can enjoy.
Brad: I do not have background developing games in other industry segments.
Brian F.: I've never worked on a hard-core big budget game, so I can't speak from experience, but I'll list the important differences I see anyway: passion is more directly rewarded since we work in smaller teams where each member can actually make or break the game, we can afford to be experimental because we can afford to fail, and we are rewarded based on quality of the game experience rather than shelf space or pre-launch hype. That's pretty exciting stuff, I think.
Brian G.: The three of us at HipSoft came from many years in the AAA retail space as we co-founded Monolith Productions (along with three other guys) back in 1994. As you know, it's currently very difficult, time-consuming, and expensive to make a compelling (let along profitable!) game in the AAA retail space.
Developing casual, downloadable games, for us, has turned out to be much more fun as well as more profitable. It's refreshing to be able to show our games to our friends and family and actually have them not only identify with the game…but often get truly addicted to them. My mom played Flip Words every night for almost a year!
All of us at HipSoft have kids now and it's also very rewarding for us to be able to play our games with them since they're all non-violent.
Quite frankly, we love being a part of this market.
James G.: My co-founders and I all came out of the console game market, which frankly is a lousy business for the independent developer. Prior to starting Sprout Games, I had co-founded a game studio called Escape Factory. That studio went out of business back in 2003 when the project we were working on was cancelled by the publisher, and it was while we were figuring out what to do next that we stumbled into the casual game business - and have never looked back.
You can read all about that experience in a talk I gave at the GDC in 2004 titled, "What to do when it all goes to hell - lessons learned shutting down a game studio". You can find the slides at our website www.escapefactory.com.
Ironically, the casual game business is right now going through a lot of changes, and it's not clear to me that if we started Sprout Games from scratch right now we would be as successful as we have been. For one thing, there's a lot more competition than there was a few years ago. Even though the market is continuing to grow very quickly, it's starting to attract a lot of attention. The idea that making a best-selling casual game is a trivial exercise - just pick an arbitrary theme and clone Bejeweled - is a myth.
Personally I think that from a game-design perspective, making a best-selling casual game today is just as hard as making a best-selling console title - and perhaps harder because you don't have licenses to fall back on. What makes the casual game market fun is that the games are, at least for now, less expensive to make and so you can take more creative risks.
James S.: Before we switched our focus to downloadable games, Reflexive Entertainment worked on several retail CD-ROM games for many big publishers. Before that, most of us individually worked at other game development studios. I find the downloadable games segment of the industry to be much more relaxed, rewarding, and creative. The 18+++ month development cycles of retail games usually caused burn out. By the time the game was done I hated it. It's not like that with downloadable games. I still love to play every downloadable game I ever worked on. It is also so much more rewarding to have direct communication with the customers and instant feedback the day the game ships. The downloadable games space also allows for so much more creative control and experimentation. Publishers of retail games don't let the developer do much experimentation when there is a 5 million dollar budget at stake.
Kalle: Downloadable games is the most exciting segment of the game industry as far as we're concerned. Nowhere else in the game industry do you have the ability to design, build and ship a game every four to six months.
Fantastic answers, everyone. Thanks!