home | projects | about

Created by Spiffcode Inc.
Published by Handmark Inc.
Website: http://www.WarfareIncorporated.com

Warfare Incorporated runs on Palm and PocketPC based PDAs.

v1.0 released Sept 2003 (initial release!)
v1.1 released Mar 2004 (added level editor, ARM support, screen rotation)
v1.2 released May 2004 (added multiplayer)

About Warfare Incorporated

Early 2001 long time friend Darrin Massena and I hatched a plan to become partners and create a full-blown real time strategy game from the ground up for PDAs (both Palm and PocketPC). Together we created Spiffcode, Inc for this purpose. Although we are both experienced developers neither of us had the specific experience of creating an RTS game. We were convinced the genre would translate gracefully into the PDA space despite the small form factor and that it would leverage key strengths like the pen as the primary input mechanism, and we knew from the PDA game landscape that such a game, properly done, would create a splash and get visibility. All in all good vehicle to leverage the output of a small team such as ours.

We allocated a year of development time to complete this project however as it played out we let go of that date to prioritize creating a great game over a specfic schedule, which led to the 3 year number (actually v1.0 took 2.5 years from start to finish, and v1.1 & v1.2 another .5 years to finish).

We're both developers and worked on it full time during this period. We had a part time artist for the unit and firing animations for about a year and a half, and another artist for terrain and user interface art in spring / summer 2003. We had an additional programmer in spring and summer of 2003, and 3 testers in summer 2003 (1 in house, 2 out sourced). During summer 2003, we had 2 mission designers (our terrain & UI artist doubled as one of the mission designers). and briefly hired a sound effects engineer in 2002. We also had a business consultant to help negotiate the contract. So from 2001 to spring 2003 it was mostly Darrin and I, then it got more busy leading up to v1.0's release in September 2003. For v1.1 it we had 1 in house tester, and v1.2 we had 1 in house and 1 out sourced, and 4 part time mission designers. Interestingly for v1.0 we went through 2 terrain artists before settling on a 3rd one. The terrain art turned out to be quite an artistic and technical challenge due to the way the terrain is constructed.

Early on we made a big decision not to release WI ourselves and instead seek a publisher. We figured doing it ourselves meant forgoing retail exposure, as well as owning up to online sales and support. We had data from a previous project that showed a lot of potential from retail sales, so we were loathe to skip that. After a lot of back and forth work which literally took months we eventually forged a deal with Handmark, Inc.. We had the help of a consultant which was very valuable and next time I wouldn't hesitate to have this consultant handle the process from start to end.

Although development proceeded full time over the duration of the project, with various internally prioritized milestones, it really didn't hit "crunch time" until spring 2003. At this point we had a contract (or at least a verbal one at that point) that had a delivery date, and we needed to get the product done. From April till September 2003 it was a crunch. v1.1 and v1.2 were mini crunches in comparison. Completing this project and seeing it in the hands of users was a rewarding experience.

Making Warfare Incorporated

In 2001 most PDA games were not resource intensive - they were small, didn't tax the cpu, took a few months to create, offered a "light" game play experience. We wanted to change how gamers thought of PDA gaming by creating something different - a large scale, resource intensive game with rich content that brought elements of the PC gaming experience to the PDA. This meant deep game play, great story, great performance, digital audio, mission authoring, single and multi player game play (to name several).

One of the first concerns we had was whether the game we had in mind was possible. RTS games are notorious resource hogs (size and performance) and we were betting on pokey, small memory devices (low end 20mhz 68K's with 8MB of slow memory). We did a lot of tests estimating and measuring the feasibility. This took awhile. At some point it was clear that "yes we can" make the game if we pulled out all the stops by really focusing on size and performance (at first we including 2MB Palm V's as a supported device, but dropped that late in the game).

Size and performance remained major ongoing concerns throughout development. Size was always a guessing process, since the content comes in towards the end of the project. Even so it was easier for us to estimate the eventual size than to rationalize how much that eventual size mattered to an end user. As our game grew we spent a lot of time rationalizing the game's use of memory. The craziness of the problem was reflected in high end devices shipping with 64MB or more, and we were spending a lot of time thinking about a few hundred K more WI size. It really does matter to users, especially those with 8MB Palm devices. In the end we prioritized making a great game as priority 1, and using reasonable amounts of memory as priority 2. We figured creating a great game would tend to justify the memory use. That said we did invest in data and audio compression to save size.

RTS games are cpu intensive and have a lot of activity going on in real-time. Terrain graphics, unit movement & firing animations, fog, state machine maintenance, path finding, multi-channel digital audio, user input, multiplayer communications, and a frame rate (to name a few!) We targeted two "low-end" devices for good performance: the Palm IIIc, a 20mhz 68K based 160x160 device with many wait state video ram (slow), and the Clie 615c, a 33mhz 68K based 320x320 device (4x the pixels of most Palms of that time with a cpu that wasn't 4x faster). We employed many different optimizations to run well on these devices. Almost the entire graphics and audio pipelines are in assembly language. All sprites are "compiled" at runtime into 68K, cached, and executed to draw. Significant process optimizations were also needed, such as minimal "dirty tile" redraw and minimal state machine execution techniques.

Our code/debug cycle was on Windows as much as possible. It has very good tools (Visual Studio). This critical decision saved time and made this game possible; it also made it possible to port to other platforms quite easily. We made an abstraction layer that separates the game from the device specific OS primitives, and wherever we could we put logic on the game side so it wouldn't need to be handled in the OS abstraction layer. Our abstraction layer for Win32 and PocketPC is small. It is bigger on Palm, for 2 major reasons - first, there are many device differences in the Palm models that WI runs on. This requires much more code to abstract those differences (display, graphics, and audio are a few). Second, the 68K side required much assembly language to get decent performance (with C equivalents for Win32, PocketPC, and ARM based Palms).

Initially we had in mind a Palm only game for the devices that existed at that time - lo-res (160x160) grayscale and color devices. It wasn't until much later that we decided to target hi-res Palm device resolutions and PocketPC resolutions. It was a big decision. All of the unit graphics and animations are hand drawn. Unit graphics suitable for 160x160 are not suitable for a 320x320 screen and would need hand-drawn equivalents. Similarly, WI uses a number of hand-drawn fonts that are separately authored. In all WI shipped with 3 sets of graphics, all separately authored (for low, medium, and high resolution devices). Supporting 3 different graphics sizes also required switching to a virtual coordinate system within the game simulation. By the time we shipped hi-res devices were commonplace and having this flexibility really payed off.

For a game like WI, the Palm platform is a challenging very diverse development target. We spent at least 1/3rd of the project time just handling these issues. WI's support of this diversity requires specific handling of many of the individual cases. Slow 68K cpus required huge amounts of assembly and elaborate in-game optimizations, architecture limitations required elaborate memory management and data retrieval techniques, various audio hardware required 4 different audio "drivers" and much debugging, various PIN (pen input area) hiding apis (4 at last count) behaved differently requiring special handling, various hi-res apis (Sony's old HR apis and Palms newer double density apis) required special handling, different screen output techniques were required for performance on different devices (Clie used MQGX.prc, OS 3 & 4 Palms use direct screen output, OS 5 and above use Palm OS apis, Zodiac required special Tapwave api for speed), differing bluetooth implementations between Clie and Palm devices required special handling, OS 5 devices required ARM native binaries + 68K callbacks for OS apis... there are many more cases like this. PocketPC devices on the otherhand are almost clones of each other, have architectures that are more traditional (like PCs) and required almost nothing "special" over Win32.

WI is a content heavy game with many content data types, some of which are quite complex. They all required specialized tools to manage and create. Early on we made a decision to write all tools using C# and the .NET framework. This ended up being a huge time savings over straight C++ and enabled us to make richer tools. Some of the tools needed: audio & data compressors, animation editor & compiler, sprite, bitmap, and font compilers, form editor, pdb compiler, sound effects editor & compiler, profile viewer, terrain compiler, palette creation tools, full blown mission editor.

To be continued...
last modified September 06, 2004, at 09:14 AM