Tex Pine - Game Production and Business Articles

After the “Download” aspect, let’s discuss the next step of the casual player: installing and running your game.

Installing

Convincing casual players to install anything is hard - they must reasonably trust on the site where they downloaded or on the friend who sent them the application. Above all, casual players hate installing things. Many fear viruses, spyware and trojans.

In fact, I suspect it’s one of the reasons Internet piracy hasn’t broke the casual industry: big portals are trustworthy, have privacy-compliance and virus-free seals, and some of them (Big Fish, Real Arcade) have their own trustworthy “client”, a sandbox to install and manage games.

That said, when casual players get to install something, they expect to get a “Next > Next > Next” wizard and it’s over. But how could one mess this up?

• If you are going to use Java or C#, and you require the player to install JRE or the .NET Framework to install the game;
• If you are going to use some fancy FX, and you require the player to install DirectX 9.0c or OpenGL 2.0 to make the game work;
• If you are going to build your own SDK, and you require the installation of any sort of run-time, DLL packs, media encoders, audio encoders, or anything but the game binary EXE itself;
• You released the game, but found a critical bug and require players to patch the game with an additional download.

Players won’t be happy to install other software than the game itself. They won’t update your game online. Anything besides a straightforward wizard is trouble. And they also NEVER get patches! Even a seamless auto-update function at the start of the game can be confusing.

Installation Scripts

When packaging the game on a setup file using tools like NSIS or Inno Setup the installation scripts should be very simple. The should be able to run with a simple file copy on the hard disk, without requiring any special procedures, registration or special code.

The reason is that when distributing through game portals, they will code their own installer scripts. Anything besides a simple file copy can be messed up. For developers, this is one of the key differences between core game and casual markets: you won’t code the installer.

Running the game

Pack every technology you need on the game binary executable or DLLs. Don’t require additional downloads / installations, and use what the OS provides you. It’s not about Windows XP SP2 or Windows Vista - It’s about the very first version of Windows XP, with no updates. Or maybe even the very first version of Windows 2000 without SPs. I don’t think developing for Windows 95/98/ME will make such a big difference (according to ArcadeTown data, something like 2-3% of the Windows market). But if you can use DirectX 7 like Fairway Solitaire and still get a great game, why not?

(By the way, first WinXP version features DirectX 8.1, and first Win 2k version features DirectX 7.)

Don’t forget Mac - aim for the lowest OS X version possible. On development use a Windows/Mac multi-platform technology. Linux is still ignored on casual, but might worth a try, if your technology gives this option, but you will have to look for alternative sites for distribution, since major portals don’t support Linux.

The golden rule

Leave all your risks on the gameplay.

Casual games are usually made by independent developers, and as independent, you will have few space on main distributors/publishers sites. When you get a good spot, you must sell it to the broadest range of consumers possible. Anything you can do to get your game running even on old machines will get you more $$.

Let the user decide if she doesn’t like your game for its design, and not for her inability to install or run it. Conversion rates are already low enough (1%). So leave all the risks on the game itself. Play safe on the technology of the project.

Go for rock-solid, multi-platform, “battle-proved”, plugin-free, old-tech compatible frameworks! Like these ones: PopCap Framework, the Playground SDK, BlitzMax and PTK.