Tex Pine - Game Production and Business Articles

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).