The “Playing” Aspect of your Casual Game

This is not a post of game design, basic mechanics or dynamics. Nor aesthetics, story or characters. This “Playing aspect” is a set of structures and practices all casual games should have on nowadays markets, regardless if it is a hidden object, time management or chain popper.

Loading Times and Start Menu

The game must load fast before the start menu, and after clicking the “Start” button. If the game features comics or intro videos, a skip button must be available. The player shouldn’t spend more than 3 minutes between “Finish” installation button and getting into the game.

So many casual games are out there, so many clones are made in no-time… The competition is fierce. If the game takes too long to start, why bother? Why not giving up and getting a similar game on the same portal?

Of course, players will have more patience with your loading time if they had to download the game in the first place. They invested time, had to install it, so they will be willing to wait a bit. If your game is a Flash webgame, however, loading times must should be really really fast. I’d say 10 seconds top – provided you make an obvious loading bar with the percentage loaded very clearly stated.

Controlling

Casual players don’t expect to use anything but the mouse. They are not used to first-person shooters WASD control schema. They are not used to map spells on keys like F2, F3, etc. They will try to use the mouse, and they will use the left button.

Should we never use arrows keys? Arrows are OK – if you clearly explain them, with BIG art of arrow keys on the tutorial screen before the game begins, highlighting the explanation with particles around! J I’m kidding, but really, players skip tutorial screens in a blink. So during the half of a second they look to them, you should explain arrow controls.

Everything else should be controls aimed to help advanced/dedicated players – not the core control of the game. Like PopCap says, it is not that your controlling schema should dogmatically follow the “left button of mouse” mantra. It is just that, if game can’t be played like that, game design probably isn’t simple enough for the casual audience.

Tutorials

The player must be taught how to play the game. Don’t be afraid of tutorial screens, but always make an in-game tutorial on the first game stage (even if you are doing one-more-match-3). Teach the mechanic basics with in-game tutorials. If your gameplay is more complex, you could extend the mechanics in-game tutorial to the second stage, but don’t go much further. Too many in-game mechanics tutorial will give the impression the game just takes too long to “really begin” (as the Shopmania team found out).

Use in-game tutorials again when the player gets new powers/items/spells. Always provide a “Skip Tutorial” button, so returning players who start new games won’t have to go through it.

Saving

On casual audience, gameplay sessions are short (10-15 minutes) but frequent over the day (5-7 sessions). The game should:

1. Save the player progression automatically during gameplay, without locking the game.
2. Load save games fast when returning
3. Restore games in the very same point the player left. Everything must be exactly the same.

Would that mean that checkpoint systems do not work for casuals? It could work, but so many casual titles have implemented the save feature as stated above that your player will probably be expecting for them – and get frustrated if you don’t have it. Avoid taking unnecessary risks.

Also, casual players won’t comfortably manage multiple saved games, which is the reason save files are connected to simple and straightforward “player profiles”. If possible pick the Windows account login as the default user name the first time the player runs the game.

The “Install & Run” Aspect of your Casual Game

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.