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.

The “Download” Aspect of your Casual Game

Long time without posting… It’s time to hit the road again. 🙂 After the end of the Lex Venture project, it is time to review my past practices and try to get to (much) better game producing methodologies.

So, let’s start with the “Download” aspect of your game – it means everything related to the process of getting your game into the user machine. For the casual audience, it also means different issues for the two dominant distribution models available for indie developers: the Downloadable and the Online Models.

Downloadable Model

I would say, aim for 20 MB of download size. If you can’t, then for 25 MB. If it is needed, then 30 MB. More than that, either you gonna do an art-stuffed hidden objects game, or you are just taking risks. There is a point where the casual player just give up if download size is too large. Because there are so many games alike, they can pick what will arrive faster.

Sometimes, a different file format can save you a couple of MB on download size. We were using PNGs on the beginning but we switched to TGAs later on the pipeline. Even with a much larger file size on disk space – average 450kb on PNG against 4 MB on TGA – the compressed size after using LZMA algorithm on the setup package dropped to 400kb on PNG against 200kb on TGA.

Your SDK footprint on the game’s EXE should not be ignored also. For Lex Venture, we used the .NET Framework and it was a mistake – on the process of bundling the DLLs (to ensure execution even on systems without the framework installed), the footprint got to a whooping 7 MB! For the casual market, 7 MB could be a full game!

Also, consider that lighter versions of your game could be player on browsers –for example, the PopCap Framework browser plug-in or OSAkit technology. Both are ActiveX based and will allow you to distribute demo versions just like web games. When picking the technology and planning art, check if your basic assets and DLLs footprint won’t render web version impossible even with less art and levels!

Online Model

The future of PC (and Mac) casual games lies on Flash technology. More and more portals require Flash versions, and most of them will only publish Flash games (like Miniclip). As more the band broadens, Internet connection become ubiquitous, and the processing power increases to support fast software rendering, Flash will be increasingly dominant as a platform for PC games.

The “Download” issues on Flash games relates to streaming and browser cache. Flash has streaming capacities and you can implement in a way the player could start the first stage before the game assets are downloaded completely. But on the other hand, the user cache may expire before his next visit to the site, and the assets needed to start the game will have to be re-downloaded every time.

Casual Games Technology Hurdles for Newcomers

Before Lex Venture, my previous experience on game development was mostly on Flash/Shockwave small games and a 3D playable demo of a DirectX 9 game (which never came close to Alpha, but it was nice).

This article is aimed on developers of other game trends and markets (core 3D, indie, mobile, etc) who plan to give PC casual game genre a try on future projects, like we did. When you are going to develop quality casual games using hardware accelerated technologies, the following hurdles must be considered early on the project.

 

1. Integration with the OS

Many casual players talk on instant messengers, send e-mail, write on Facebook and things like that while playing the game. They ALT+TAB frequently, they use the windowed mode frequently, and everything must go smoothly when an IM window pops in. The present “Internet generation”, by the way, is much used to multi-tasking, so this behavior will only be more present in the future. Therefore:

• Players like windowed mode. Make sure it’s in your game options.
  
• The memory usage must be low, to avoid OS hangs when the user ALT+TAB from your game on a 256-RAM computer.
• If the user is on the windowed mode, the game must be completely paused – including music and particles – when someone poke the player on IMs, or when the download manager pops a message, etc. If the user is using full-screen it’s open to debate if the game should minimize or keep the game running and allow the “blip” sound of the IM warn the user.
• Unpausing must be also very straightforward, the user must simply click on the window.

2. Old computers / on-board video cards

Casual gamers don’t update the hardware often. In fact, since they also play while working, they will use terrible on-board video cards. Expect hardware compatible with old DirectX 7 or 8 – on some cases, not even that, and the game will need software-render. Remember that “Windows-ready” computers with on-board video-cards tend to not support OpenGL very well – some of them completely suck on OpenGL mode. So if you’re running under Windows, don’t risk: use DirectX or software render.

RAM limitation is also and important topic, especially if the on-board video card is using a piece of it through some shared video memory schema. Commonly, it will reserve 64 MB of RAM.

3. Save game / Load game

Save games on casual games works differently from core titles. The save game is associated with a player “account”, not with a save slot. More important, since casual game sessions are short (10-15 minutes) but frequently (more than 5 times a day), the user must be able to quickly quit and return later with the very same state he left. So, save games must be recorded every game turn or every couple of minutes without hanging the gameplay.

 

4. Loading screens

Load screens should present smooth animations that indicate the amount already loaded – like filling bars and walking characters. It helps to keep players waiting. However, to successfully implement smooth animations during loading times (which, you know, hangs a lot!), we will spell the magical word: “multithread”.

Multithread is not easy! Even when implemented only for these loading times. By the way, don’t multithread on casual games for anything else – dual core PCs are still not as widespread as the casual market requires. An exception would be if you are aiming for XBOX Live Arcade or other present-gen console network.

 

5. Mini-games variety

On the present standards of casual games, you should think on adding variety to gameplay – mini-games, bonus levels and special levels with different mechanics. You have to foresee the possibility of switching the gameplay mechanics between stages. Don’t overlook this analysis – it will really add to development time and force you reworking many codes if you later decide to integrate mini-games on the project without planning for it since the beginning. In our case, implementing the Boss Battle of Lex Venture later added roughly 2 months to the schedule.

 

6. Switch fullscreen/windowed

On a number of 3D games, you have to restart the game if you want to make the fullscreen/windowed transition. game developers already know why – the game needs to destroy the fullscreened 3D video device and create a new windowed one, hence re-creating every mesh, texture, scene nodes, particles of your game state. Hence some core games tell the player to restart the game so changes can “be applied” and the whole thing will be re-created naturally on the next load.

Asking the core player to restart his 3D game is acceptable on some cases – asking the casual player to do the same is not. Either your engine support switching, or you will have to program an engine wrapper and make the game on top of it, to facilitate the switch fullscreen/windowed feature.

 

7. 3D technology and 2D graphics

I like 3D graphics! But casual players don’t care if the graphic is either 3D or 2D. Graphics just have to give the game the proper look, make it unique and allow the game to run on casual players’ machines. That’s the tricky part, because they could be using a crappy video card and have DirectX 9 fancy graphics slowly emulated on software – or, more commonly, not even rendered!

Put as much 2D graphics as you can, even if on 3D billboards. Use 3D meshes for specific objects which will provide that unique feel on the game – but always keep poly count under control. Those old days of obsessively counting polygons are back. 🙂 On Lex Venture we used 3D for letters and board platforms, which were cubic and rectangular forms with very few polys.

Also, take a look on my previous article on fancy and lightweight 2D graphics.

 

8. Security Wrappers and Setup Packs

That is a must on a market dominated by the downloadable try-before-buy model. The technology – engine or framework – you chose must be completely compatible with the main DRM solutions for casual games. True there are many proprietary DRMs you won’t have access to test your technology, like PlayFirst’s, Big Fish’s and Mumbo Jumbo’s. But others like Softwrap, Trymedia and Game Shield are available for use after signing up.

Also, wrapping things and creating setup packs takes time. Specially if you are trying to use the most advanced security functions, which might demand changes on your code. If you don’t have a publisher to do it for you, reserve yourself at least two weeks on that, not counting the approval time of the DRM provider if it’s necessary (like with Trymedia).

Techniques for Fancy and Lightweight 2D Graphics

So you are going to use lots of 2D graphics on your next game project, targeting lower-end machines. It’s a casual-oriented game project, or maybe just a 2D indie game that should run on the most number of PCs possible (which is a smart move). You need:

• Beauty
• Performance
• Fast download

Hardware-accelerated and software-rendered 2D graphics can be both fancy and lightweight. Even if your hardware-acceleration is an old one, like DirectX 7 or 8. You can make lots of effects (“Beauty”), use few video memory (“Performance”) and consume less disk space on the game final size (“Fast download”).

The three main techniques you use to accomplish that are:

1. Tilemaps;
2. Real-time draw deformations;
3. Particles.

Tilemaps

Tilemaps will allow you to have a large amount of 2D sprites on a single 512×512 or 1024×1024 texture. Perhaps even all the graphics you need for the game! :). You load a small amount of tilemapped textures on your video memory and “mount” game graphics drawing pieces of it in the screen. Check this basic tutorial.

Some tools, like Torque Game Builder, generate tilemaps by slicing a texture on a matrix of equally squared tiles, mainly for frame-by-frame animations. But tilemaps can be more powerful. With a custom tool, you can optimize every single pixel of a texture for a different game assets, not space-wasters equally-sized squares! Consider, for example, what Bookworm Adventures did:

http://www.igda.org/casual/quarterly/2_2/index.php?id=2

With a very small set of textures, hundreds of different monsters could be generated with “pieces” of those textures! The outcome was a very small-sized game download (20 MB), but with lots of aggregated values and a tag price of 29 bucks at the time of its launch.

For Lex Venture, we used tilemaps for user interface and in-game sprites taking advantage of every possible available pixel. Loading times got faster than previous projects that used one texture file for each sprite, and disk space and memory usage got smaller.

Real-time draw deformation

On hardware-accelerated 2D drawings, engines render sprites by creating a 2-triangle, 4-vertexes primitive rectangle mesh textured with the sprite image, right into the frame buffer. Think it like a 3D plane right in front of the camera (actually, thats exactly how Blitz Basic do it).

Draw deformation is the ability to modify sprite draw by manipulating this primitive mesh. With a good tool-set, you shall be able to change colors of vertexes, deform, scale and rotate the sprite.

For example: you have a white butterfly sprite. Before rendering you could modify the color of the vertexes of the primitive mesh to green, purple or anything else. You will then be able to draw the butterfly with a different color on the white tones using conventional vertex-color technique. Now draw the same sprite many times and you have lots of colorful butterflies in your game with just one single image file!

Deformations on scale, rotation and overall alpha transparency are quite good for GUI transitions. Almost all casual games today use them, and so should you. Pick tools and engines that allow you the vastest range of real-time draw deformations.

Scale + alpha transition

For software-rendered graphics, draw deformations are more limited. For example, you can’t scale with bilinear filters without making the graphics look badly crispy. So plan ahead what the game will and will not be able to do considering the software-render technology you picked.

Dynamic applied alpha masks

Dynamic applied alpha (transparency) masks is a technique to make 2D graphics even lighter on disk space, extensively used by PopCap Framework. You use web-image formats without alpha – JPG and GIF – for your game graphics. For each image that requires alpha, there is an equivalent gray-scale image with the alpha mask needed. The engine loads the GIF or JPG image, and then modify the texture on the video memory applying an alpha channel based on the gray-scale information.

The sum of those two files is smaller and loads faster on software rendering than an image with the same content on a format with native alpha, like PNG. Works best for GIF images. (Note: you should study the differences between GIF and JPG to pick a format that fits into your game graphic style)

Particles

Particles are a important part of any game, but key ingredient to for casual / light 2D titles. You only need a handful of 16×16 textures to create amazing effects on screen! Don’t you dare not considering the particle system on your decision of the which framework to use!

You need a powerful particle system. It would be better if it could draw 2D particles, where particles will be drawn as regular sprites. Most 3D engines features however only features particles using 3D elements like PointSprite, Billboards and Meshes. They are beautiful, but they are also, well, 3D elements! They will consume more CPU with culling / render ordering calculations, and are not as precise for a 2D-based game.

For casual games, aimed on lower-end machines, I advise you to try engines that supports 2D particles. Specially if you are going to support software rendering. If they ain’t available go with PointSprite particles, which are 3D but optimized for 2D drawing at the DirectX device. Billboard and Mesh particles are heavy on rendering if the user don’t have a good video card.

If you can only choose between Billboard and Mesh, go with Billboard. But maybe you picked the wrong framework/engine!

As the last advice, don’t you get too heavy with particles! Low-end machines suffer if you push too hard. Emitters should not emit more than 20-40 particles at a time. I would say 50 on a very particular case, but try to keep the particle count under control . Remember that each particle is still something to be drawn.

PC OS for 2008 and beyond

For the casual game developers, I think it is insightful to have a look on these articles:

Why choosing XP over Vista? and 2008: Linux’s year on desktop 

They state two trends on the PC OS market for 2008 and beyond:

1. The faster spreading Vista distribution is Home Premium Edition, not Ultimate nor Home Basic. For game developers, the main difference between Basic and Premium editions I believe to be the Aero interface and the XBOX integration on Windows Media Center;
2. Linux computers are coming for good with the spreading of cheap laptops. The main impact will be on 2009, but we should think on preparing our games to have Linux versions (and use Linux-friendly frameworks);

Digital TV Games Hurdles

The public Digital TV system is being implemented on Brazil, and people are talking much about DTV games here. I believe it is an incredible opportunity for game developers, but there are hurdles that they must know beforehand:

Render

It is not possible to make real-time 3D games right away, because digital TVs only display what it receives from the transmitter. It won’t render in real-time anything more complex than 2D HTML-like menus. Think of it as a web browser with a very good dedicated channel for video broadcasting, and that’s about it. It will take time to have embedded video cards for real-time rendering on set-top boxes and TVs. The way to overcome this limitation is to use just pre-rendered 2D graphics, but see the next topic.

Video memory and CPU limitations

Game developing for DTV receivers (set-top boxes) are like developing for those old video-game consoles and mobile platforms. When it comes to hardware power they are very low and challenging, specially on cheap and popular set-top boxes. CPU speed won’t be higher than 300 MHz (at the very best case),  and video memory is of course very specialized for the TV broadcasting, not aimed for real-time applications. Game developers should have three or four popular models and test on it all the time, to make sure the games run smoothly.

Input

User input isn’t good. The remote control has to be used as a joystick, and they definitely are not designed for such a function. Some remote controls might have a technology similar to the light pistols of the consoles, recognizing where the user is pointing to, but they are rare and expensive. Response times of remote controls also doesn’t help at all. Game developers should aim for very simple input, and consider  “turn-based” games so that response times aren’t critical.