iDevGames

Introduction

Metrowerks’ CodeWarrior Learning Edition (CWLE) is a product targeted at beginner programmers and schools who wish to teach programming on the Macintosh. On the surface the CWLE 3 Integrated Development Environment (IDE) is similar to version two, which I reviewed back in 2000 for iDevGames. To that end, I recommend that you read the review of CWLE 2 since I will be taking a closer look at what separates CWLE version three from the other editions of CodeWarrior family in this review.

As with the previous version I reviewed, CWLE 3 includes not only many examples and tutorials, but also a video collection that explains all aspects of programming with the CodeWarrior IDE. To test those learning tools I enlisted the help of my girlfriend, who is not a programmer, in order to observe how a novice would approach the installation and use of CWLE.

Installation

As always, the installation of CWLE is very straightforward. You can choose either the Easy Install option, which will install all the necessary files for both C/C++ as well as Java development, or you can choose to install either the C/C++ or the Java development tools only. A full installation weighs in at about 677 MB, mostly taken up by examples and tutorials.

The Tools

As previously mentioned, since most of the tools were present in version two of CWLE, I won’t go too deeply into each one here; instead, I’ll provide a short overview of what tools are installed, what they look like, and how they work.

The Programming Tools

The center of CodeWarrior is the CodeWarrior IDE application. It encompasses the project management utility, the compiler, the linker, the debugger, and the source code editor.

The box includes a “Quick Reference” sheet for the IDE which illustrates the various interface elements with numerous screenshots, tells where they are located, and what they are for. This reference is well structured and covers all necessary parts and goes even a step farther to explain how to customize the IDE. Although a thoughtful feature, including the customizing section in the Quick Reference might not be the best approach considering the level of the intended market. It’s possible that this feature could lead to some hair pulling and some more work for system administrators within a classroom environment. Speaking of schools, if you need additional reference sheets, contact Metrowerks about obtaining more for each workstation—a must in my book. Finally, a Quick Start guide is included which shows how to set up a project in a few simple steps.

The Learning Tools

The great benefit of using CWLE is the excellent tutorial. It consists of a virtual textbook and several QuickTime movies that are started from within the textbook. The movies explain the various aspects of the CodeWarrior IDE as well as basic knowledge about what a project is. This textbook and the movies it contains enable a teacher to let the students work independently and still be sure that they are taught everything they need to know about the basics of programming with the CodeWarrior IDE.

In addition to the interactive tutorial, the Installer application will install several books in electronic form (both HTML and PDF versions) that cover programming in C/C++ or Java as well as books on PowerPlant and, of course, the user manual for the CodeWarrior IDE.

Returning to the classroom environment again, teachers will surely welcome the ability to easily create project templates from which the students then start their assignments. Simply place all the files needed for the homework project into a folder and move that folder into the Stationery folder in your CWLE folder. When you create a new project you can then choose the newly added template. Using this mechanism, teachers can prepare the whole semester in advance, and focus their attention on students who have questions regarding the task while the other students work independently.

The New Stuff

The most obvious change, apart from the interactive tutorial, points to CodeWarrior’s new support for the Cocoa API. However, you will still need Apple’s Interface Builder to edit the .nib files. This leads to the question, “Why use CodeWarrior to develop Cocoa applications when installation of Interface Builder is still required?” This question is even harder to answer when one considers the established integration between Apple’s Interface Builder and Project Builder. It remains to be seen if Metrowerks can create an interface designing tool that can rival Interface Builder, however, in their defense, perhaps focusing their efforts on the areas where they have shined in the past might be wiser.

CWLE 3 comes with lots of examples covering various kinds of applications. There are example projects for Cocoa as well as Carbon applications and there are even example projects for CLI (Command Line Interface) applications. The Cocoa examples show how to program toolbars or drawers, among other things.

Checking in on my girlfriend’s progress at this point, I found that she really liked CWLE 3 and made a little progress in her quest to learn how to program. No doubt due to the excellent tutorial, she now understands what projects are, and why it is a good thing to have them. She also mentioned that the interface was very clear and easy to understand—once again proving that Metrowerks is on target for the market to which they are selling. Her only criticism concerned the pace of certain sections of the tutorial, at times a bit too slow for her taste.

Conclusion

With Apple providing free tools in the form of Interface Builder and Project Builder, is there a market for CWLE 3? Indeed there is; Apple’s tools are free, but they won’t teach you how to program and are less suitable for cross-platform development. Schools and complete novices should seriously consider this product—an excellent launching pad for getting into the world of programming. CWLE 3, like the earlier version I reviewed, is easy to understand and includes abundant learning examples. In addition, my experience with Metrowerks has always been quite positive as they are a very forthcoming company if you have problems with their software. Intermediate-level programmers would also be wise to give a closer look to CWLE 3. The price is very competitive and provides enough power to write full blown applications in Java or C/C++.

One drawback is that, unlike with the Pro edition, you cannot fully optimize your code, and some features found in the Pro edition are missing in the Learning Edition. For any educational or hobbyist purposes, however, that should not be a problem. For anything CWLE can’t do, or if you wish to distribute your applications, the more expensive CodeWarrior Pro from Metrowerks should be used.

As I already mentioned, having to install and use Apple’s tools in order to develop Cocoa applications does not make CWLE the best solution for beginner programmers or students wishing to learn Cocoa. If Cocoa is the only framework being used, I personally would use Apple’s tools, not Metrowerks’, and get myself a good book on Cocoa like ‘Cocoa Programming on Mac OS X’ by Aaron Hillegass. However, programming Cocoa with CWLE is possible, and as a method of illustrating the way to program with Cocoa, or as a way to avoid learning two separate IDEs, it is definitely a useful solution.

If you want to write Macintosh applications or games but lack the knowledge, are coming from IDEs that are based on BASIC, or you’re on a budget, CWLE 3 is definitely for you. If you need a good and simple IDE for your school class then CWLE is the best choice as it doesn’t limit you to one language and it also offers you valuable assistance with its tutorials and examples. Experienced developers or those only interested in Mac OS X’s Cocoa framework, on the other hand, will be better off using the CodeWarrior Pro edition or Apple’s free developer’s tools.

• Rated 7
• Version: 3.0
• Category: Development Environment
• Developer: Metrowerks
• Url: www.metrowerks.com
• MSRP: $79 ($59 Academic)

codewarrior,le,3,metrowerks

written by ?

This is a short introduction to the STL (Standard Template Library), which you do need, you just didn’t know you did. It is intended to get you up to speed with STL, and learn enough to use it in your games. If you want to keep on discovering the STL, just Google for STL tutorials; there are a lot of them out there.

Every once in a while, we all need to keep track of lists of things. So, as beginner programmers, we declare static arrays and hope for the best. They are not the least bit flexible, though their size must be determined at compile-time, and they do not resize. So, after a while, we discover malloc, and after a bit of fiddling and crashing, we can finally make run-time sized arrays. We discover realloc, and we get resizeable arrays. All well, we can now start to manipulate our array, sort it, remove elements, insert elements in the middle and finally remove duplicates from it. Clearly, this isn’t much fun, but if we make a class out of it, we can make all those operations member variables. So, let’s say we make a MonsterList class, and teach it how to work with monsters. Now, we need to make one of these classes for WeaponList, CarList, and BirdList-and everything gets a little out of hand. But, this is only for sequential lists-say we would like a linked list or a map? Get out of here. Clearly, there’s bound to be a better way to do all this. Sure thing. Enter STL to make you scream.

The STL can be scary, no doubt about it. The headers are arcane, and it is based on templates, a concept that is not often used by non-advanced programmers. You’ll soon use a new way to write your for-loops (which was quite hard on me…) Still, not having to ever keep a numOfCars member variable around might compensate for that. (Not to mention STL’s string class.)

So, what’s the STL? Well, we’ll start out with a short explanation, and I’ll get back in depth later. In short, it is a collection of template classes for containers. (That is arrays, lists, maps and the like) STL stands for Standard Template Library, obviously. So, why templates? Well, a short explanation of templates might be useful. In short, it is a way to declare a class without making any assumptions about the type of its member variables. I will not go into templates here, all you need to know will unfold soon enough. (But I really recommend looking into templates, they can have a few nifty uses.)

In addition to merely being a collection of container classes, the STL also defines a wealth of operations to manipulate the containers. Among them are sort, copy, insert, copy_if, equal, max/@min@, search, and remove. (Check out the header for more!) One of the best things about the STL is that the containers are very alike, so that if you’ve learnt to use one, you can pretty much use all of them without too much thinking.

Let’s get to it, appetites hopefully whetted. An example:

@
#include <iostream>       // For cout
#include <vector>         // For the STL vector class
#include <algorithm>      // For sort et al.

using namespace std;            // All of the STL is in the std namespace

int main (void)
{
vector<int> numList;   // Declare a vector of int’s

numList.push_back (1);  // Add a few numbers to the end of the list
numList.push_back (4);
numList.push_back (3);
numList.push_back (9);
numList.push_back (-4);
// Now the list looks like this:
// 1, 4, 3, 9, -4

// numList.size() returns the vector’s length. (5, in this case.)
cout << “n The list has “ << numList.size() << “ elements.”;
cout << endl;   // New line

// Write out the elements of the list
for (int i = 0; i < numList.size(); i++)
cout << numList<i> << “, “;
// Let’s sort the list
sort (numList.begin(), numList.end());
// Write out the elements of the list again.
for (int i = 0; i < numList.size(); i++)
cout << numList<i> << “, “;
}
@

…and the play-by-play:

First, we need to include a few headers. Each of them are C++-style includes, without the “.h” suffix. There is one header for each container type, and one for the algorithms. (There are an assortment of others too, but they’re for really advanced uses.) The most common among the container types are vector and list, where vector is very similar to a regular array, and list is linked list. We include here. Then, we tell the compiler to use the std namespace. (Namespaces will not be covered here, though.) The vector<int> line is the first we’ll see of templates, so hang in here. It declares a vector, and tells it to use int as it’s type. Like so:

• vector<int> — declares a vector of ints.
• vector<float> — declares a vector of floats
• vector<ChipMunk> — declares a vector of ChipMunks
• vector<ChipMunk *> — declares a vector of ChipMunk pointers.
• vector<vector<ChipMunk *>> — declares a vector that’ll cause you some headache.

No way to go wrong here, really. Just pass in whatever you want a list of.

Then, we call push_back to add a few numbers to the end of the array. (There are push_front and insert too, for the curious.)

The size() method is the reason you’ll never keep a numOf-variable around-it just returns the number of elements in your vector. We then use it to construct a simple for-loop to sift through all the numbers, and write them out. Note that the vector class uses <i> like any other array. (There is also a numList.at(i) to use, which performs bounds-checking. I really recommend using it for all of your development to be on the safe side-it catches more bugs than you might imagine. If you’re pressed for speed, change all your .at:s to <i> instead when you deploy your build.)

Then, we sort this vector. Unfortunately, this introduces a little thing called iterators, which we had to stumble on sooner or later. An iterator is basically a pointer to an element in your container. It behaves in the exact same way—that is, you can use *myIterator to dereference its data, and ++/—to move back and forth. Almost every algorithm in the STL uses iterators to do it’s work, so you’d better get familiar with them. For now, they’re just fancy pointers.

sort() wants two iterators, one to know where to start sorting and one to know where to stop. begin() returns an iterator to the first element of your vector, and end() returns an iterator to the element after the last of your vector. So, sort(intList.begin(), intList.end()) sorts the entire vector.

So, that’s the short example. Now, it isn’t often that we keep complex lists of ints around—we could use something that is more like the ChipMunk vector. And yes, we just do the following to juggle a ChipMunk list:

vector<ChipMunk *> chipList;
chipList.push_back (new ChipMunk("Stanley"));
cout << chipList.at(0)->health;

This works for everything but the algorithms. You can add, remove, count, and access them as usual. However, let’s take a look at sorting the ChipMunk list. How do you sort ChipMunks? By age, weight, size, or fur factor? This alone is a little problem (very solvable, though), but there’s a more subtle problem. Since the vector is filled with pointers to chipmunks, it would actually sort them the same way as it sorted the intList-numerically. This would mean that the poor ChipMunks would be sorted by their location in memory-not very attractive. The solution is unfortunately a rather complex one, and involves subtleties of both the STL and templates that I won’t go into detail here. Still, here’s how to do it:

template <>

struct std::greater
{
bool operator()(const Foo *leftVal, const Foo *rightVal) const
{
return leftVal->val < rightVal->val;
}
};

Just put that into your class header, and substitute Foo for your class, and val for the variable to sort by. (If you want to look it up, it’s a predicate template specialization) Then, sort using this call:


sort (fooList.begin(), fooList.end(), greater&lt;Foo *&gt;());<br />


So, why doesn’t everybody use the STL if it’s that good? Well, I believe there are two reasons. One, people are not used to working with templates, and are scared away by that. (I was for a number of years!) Two, it is seen as something of the application programming industry that isn’t up to par in performance to be used in games. Well, this is interesting, and I’ll look a little at it.

The speed of the STL is, from my own experience, as well as other articles on the subject, very good. (I certainly couldn’t do any better!) In fact, it is usually a question of executable size than executable speed. More, few games today are so performance-critical that they couldn’t muster the overhead from a few extra function calls per frame. Still, I certainly wouldn’t use an STL vector to manage the pixels of an offscreen buffer—just use it with a little care. Develop with the STL, and if you need the speed later on, just rip it out again. Chances are that you’ll forget it’s even there. The main reason to use the STL is it’s reliability, however. If you’ve ever spent more than a day to track down a bug that was caused by improper bounds checking, then you can count on using that day for optimization later on. I know the quality of my code has improved a lot since I became a zealot.

Let me give you an example: I’m currently developing a 2D side-scrolling platformer. Each level is divided into a number of cells, for visibility checking. Each cell holds a pointer vector to all the level entities (enemies, decorations, platforms, bullets) it can see. Multiple cells can see the same entity if it crosses a cell boundary. Now, this meant two things: depth sorting was broken, (since the cells were drawn out-of-order), and I had to draw a few things twice, as there was no way to tell which entity had already been drawn by another cell. I used the STL to combine all the entity lists from all visible cells into one master “visible list” (copy), depth-sorted (stable_sort) it, and removed all duplicates (unique) from it. Needless to say, this gave me quite a performance improvement, all in five STL calls. I would never have taken the time to crank out all that code and bug-fix it in the first place, so for the performance hit of sorting a few hundred (at max) elements in a list, I improved my frame rate by almost 50%. Now, should I notice that the STL calls take to much time, I could concentrate my efforts to optimize them, yes—but it would have been stupid of me to go for maximum performance from the start.

Thus, my recommendation is to use the STL, and just make everything work; then, profile your code and optimize where needed. Use the days you used to spend bugfixing and writing linked lists to get superior performance.

introduction,to,stl

written by Dair Grant

Introduction to Quesa

Quesa is a high-level 3D graphics API, designed to complement lower-level 3D drawing APIs such as OpenGL. It provides a powerful set of building blocks for constructing 3D worlds, giving applications access to features which are not normally found in lower-level APIs. Quesa is also a cross-platform library, and runs natively on Mac OS X, Windows, Mac OS 8/9, and Linux. The Mac port can be built with either CodeWarrior or Project Builder, and can generate Carbon, Cocoa, or Classic libraries.

quesa01.gif

Quesa Platforms

History

Before adopting OpenGL, Apple developed their own 3D graphics API. Known as “QuickDraw 3D” (QD3D), this was moderately successful on the Mac but never really gained widespread support with cross-platform developers. Although eventually shipped for Windows as part of QuickTime, it was primarily a Mac-focused technology.

At their 1999 WWDC developer conference Apple announced that they no longer planned to support QD3D on Mac OS X. This caused some discussion on the QD3D mailing list, and I decided to investigate the feasibility of re-implementing the QD3D API as a 3rd party library. This library would have to be developed without reference to or use of any Apple source code, but retain binary and source level compatibility with the original. Luckily the QD3D API provided a very clean design, and a prototype followed fairly readily.

This prototype formed the basis for the Quesa (pronounced “kes-ah”) project, and at WWDC 2000 Quesa was successfully built as a native Carbon library on Mac OS X DP4.

Quesa vs. OpenGL

A common misconception, which stems from Apple adopting OpenGL over QD3D for Mac OS X, is that Quesa is intended to be a competitor to OpenGL or Direct3D. The reality is that these APIs tackle different problems, and that Quesa is designed to complement APIs like OpenGL rather than replace them. While OpenGL focuses on improving rendering performance, Quesa is intended to improve developer productivity—to provide the services which many 3D applications need, but that drawing APIs such as OpenGL do not provide.

quesa03.gif

Architecture

The structure is as illustrated, with Quesa sitting between the application and OpenGL. Since Quesa calls down to OpenGL to perform rendering, applications can also side-step Quesa at any point and invoke OpenGL directly. This process is completely transparent to OpenGL, as it has no way of knowing if it is being invoked directly by the application or via Quesa on the application’s behalf.

This flexibility gives applications the best of both worlds: direct access to a low-level rendering API for advanced features, and a powerful high-level API to tackle tasks such as picking or iterating over the objects in the world.

Overview

Advantages

One of the main strengths of Quesa is that it provides a powerful set of building blocks for constructing a 3D world. These features are not found in APIs such as OpenGL or Direct3D, and each application must typically provide their own implementation to manage their data.

Another unusual advantage is that it insulates your code from the underlying rendering engine. This allows Quesa to provide non-interactive rendering capabilities, such as a pen-and-ink rendering style or even a ray-tracer. It also serves as future proofing, in case OpenGL itself is superseded on the Mac at some point.

quesa04.gif

MacDopplerPRO

Quesa has around 1,300 API calls, exposed as an object-orientated C API. Every Quesa object is opaque, reference counted, and derived from a common base type. The overall style is quite similar to Mac OS X’s Core Foundation API. Every function name follows a standard naming convention, that of Q3Type_Action. This system makes it very easy to “predict” new API calls—once you know that the data for a triangle can be fetched with Q3Triangle_GetData, the obvious (and correct) way to fetch the data for a NURB patch object would be through Q3NURBPatch_GetData.

Since the API is quite large, we will examine four features which Quesa provides that OpenGL does not (or provides only in a rudimentary form).

Geometries

Quesa provides 21 different geometry objects, from the simple (e.g. points, lines, or triangles) to the complex (e.g. spheres, torii, or NURBS). It also provides an efficient triangle mesh object (the TriMesh) which maps directly to OpenGL vertex arrays, and a flexible mesh object composed of an unlimited number of arbitrary polygons.

quesa05.gif

Chess

Quesa converts all geometries to TriMeshes for rendering, and uses an automatic caching system to rebuild these TriMeshes on the fly. This allows applications to work with high-level geometries such as spheres or cones, yet still have them converted to an efficient form when rendering. The geometry system was designed to be extensible, and will be prompted to a public API in the future. This will allow applications to register their own geometry types, and to work with them as if they were built-in geometry objects.

For example, an application could register a new “dumbbell” geometry, defining it as a pair of spheres and a cylinder. Once this definition had been introduced to Quesa, it would be fully integrated into the caching system and would be decomposed automatically to produce TriMeshes for rendering.

Math Library

As well as a rich set of basic 3D types (e.g. points, vectors, matrices, quaternions, or bounding volumes), Quesa also includes an extensive math library. OpenGL does not provide these data types, and expects applications to provide their own definitions.

Quesa’s math library provides both basic manipulations such as addition, scaling, or dot products, and more complex operations such as manipulating matrices or quaternions. There are also batch-processing APIs for transforming arrays of points or vectors, which will be optimized for vector engines such as AltiVec in the future.

Quesa also extends the QD3D math library with new APIs such as ray-box/sphere/plane intersection tests, and allows most of the trivial math functions to be declared as inlines. This means that operations such as vector normalization or dot products can be performed directly in application code, without the overhead of a call to an external library.

Groups

One of the most powerful features in Quesa is the concept of groups. These come in several flavours, but are a type of Quesa object that can contain other Quesa objects. Given that a group object is itself a Quesa object, groups can contain other groups along with objects such as textures or geometries. This provides the basis for the hierarchical scene graph in Quesa, as an entire scene can be stored as a set of nested groups.

quesa06.gif

Setting Sun

Since groups can keep track of the bounding volume of their contents, this allows for automatic visibility culling. A group that contains 1,000 objects could test its cumulative bounds and cull every object within itself instantly if it found itself off-screen, rather than having to test each object individually.

Groups are also used to inherit state within the scene, allowing objects within a group to inherit their properties from their parent group (or from their parent group’s parent group, and so on up to the top level). For example, inserting a texture or a color into a group will affect any other objects placed in that group (including objects in sub-groups), and lets you chain together effects to be inherited through the scene.

Picking

OpenGL provides the ability to read back rendered values from the frame buffer. Picking can be implemented on top of this mechanism, one common method being to render each object with a unique color and to use the color under the mouse to identify the selected object.

Quesa provides a rich set of picking APIs, and allows objects to be selected in several ways. The most common is to query the scene under a window point, which will return the object(s) under the mouse. Picking can also be done over an area within the window (like a rubber-band selection in a 2D drawing application), or by firing an arbitrary 3D ray through the world.

The 3D ray form of picking is particularly powerful, as it allows simple collision detection simply by firing a ray from the front of an object and seeing what other objects in the world it hits.

Since Quesa picks mathematically rather than by rendering, it is able to return a great deal of information about the selection. This includes a sorted list of all the objects under the pick, and data such as the coordinates, normal, or UV of the intersection on those objects.

Future Goals

The primary goal of Quesa has always been to implement the existing QD3D API. This phase is now largely complete, and the next stage is to focus on performance improvements and new extensions. One obvious direction for extensions is to add features which were not feasible to add when QD3D used the RAVE rendering API, but which are now possible using OpenGL. This could include upcoming OpenGL extensions for more efficient geometry processing, or existing staples such as lens flare, light maps, bump mapping, or environment maps. Quesa uses Apple’s HeaderDoc system to generate API-level documentation, however we are in need of people able and willing to write general level docs. If you’d be interested in working on documentation, please sign up for the mailing list and let us know.

Learning More About Quesa

The primary source of information on Quesa is our web site, which can be found at http://www.quesa.org. Please sign up for the mailing list if you have any questions, and grab the latest source from the CVS server if you’d like to check it out. If you have any questions you’d like to ask me directly, feel free. The official Apple QD3D book is available online, which covers all of the main concepts in the API.

Useful Links

Quesa is the basis for the object-orientated 3D API in REAL Software’s REALbasic, and if you’re curious about 3D it’s a great environment for experimenting in. As well as being one of the developers working on Quesa, REAL’s Joe Strout maintains an RB3D FAQ, and has written several 3D articles for the RB Developer magazine.

There are a number of links to other 3D engines (several of which sit on top of OpenGL, as Quesa does) at the 3D Engines site. I would encourage you to check them out, and compare the feature sets of various APIs to what is available in Quesa.

introduction,to,quesa

Carlos Note: Does the headers for each section match our style-guide?

The I Team

A frequent complaint from indie developers is that indie team projects commonly fall apart without ever releasing a finished game. While it’s very difficult to complete a game as a lone wolf developer, some report that it’s even harder to form a multi-person team that can achieve this goal. Because it’s so rare for an individual to achieve sufficient talent in the areas of design, programming, art, music, and sound effects (not to mention marketing, selling, and business acumen), there’s an obvious incentive to assemble a team that covers most or all of these areas. Not only can a team tackle more ambitious projects than an individual, but there are projects you can complete with a team that are effectively impossible for an individual. But do the potential rewards of a team project outweigh the risks? Although team projects can lead to great rewards, they can also be perilous. When a lone wolf’s project fails, the damage is minimal. Often only one person is affected, and that person generally assumes full responsibility for the results anyway. Few outsiders will even take notice. You made a mistake… you only hurt yourself and hopefully learned from it… no harm, no foul. Sometimes a failed individual project is even considered a badge of honor, a sign that you endeavored to stretch beyond your previous limits. However, when a team project fails, many lives are affected. Fingers point in all directions. Angry posts from disgruntled team members start flooding message boards: The designer is an idiot, The whole art team is lazy, The programmer is incompetent, The project was just too ambitious.

The project dies a painful public death. Bitter ex-participants conclude that team projects are perhaps doomed from the start and opt never to make that mistake again.

Yet some team projects actually manage to succeed. The team synergizes well, completes a game in a reasonable amount of time, the game sells well, and the team continues to work together on future projects and lives happily ever after. Why? Did they just get lucky? Or do they know the magic formula that others don’t?

Here’s the good news: There are ways to increase the chance of success for a team project, and magic isn’t required. Most of what follows will probably resonate as common sense, but despite that label, the application of “common sense” principles in team-building remains all too uncommon. So let’s dive right in and learn how to build and maintain a great team….

To build a strong team, you must develop proficiency in the skill of team-building

No one seems to question that if you want to write solid code or create quality music, you need to develop proficiency in those areas. Yet how many developers dive into team-building with no real skill or experience in this area? Team-building is a skill like any other, and for a team project, this skill is more important than technical, artistic, and musical talent combined. Team-building is very challenging—it demands respectful consideration. If you do not know how to select team members, how to manage for results, how to resolve conflicts, and how to handle poor performance, you’d better learn these skills first before you assemble a team.

So how do you become proficient in team-building? The same way you become proficient in any other skill. Read books and articles, listen to audio programs, watch videos, interview successful teams with proven results, and attend classes and seminars. Successful team-building skills can be learned, and this takes time. Be patient. The information you need is out there, but you’ve got to absorb it before you can use it. You wouldn’t want a programmer on your team that couldn’t code a loop to count from 1 to 10 without referring to a book; similarly, it’s very risky to begin building a team until you’ve internalized the basic skills. It’s OK to build individual skills through trial and error, but if you use trial and error as your primary method of acquiring team skills, you’re going to negatively impact many people’s lives, damage your reputation, and probably make some enemies. Jumping into a team project to build your team skills is akin to fighting in a war to build combat skills. In both cases you’ll be lucky if you survive, and you may even bring your whole team down with you. So train yourself in basic team skills in private first. As the U.S. Navy SEALs like to say:

The more you sweat in training, the less you bleed in war.

As a minimum I recommend reading at least five books in this area before you begin to assemble a team. The specific books you read are not as important as your commitment to ongoing education. Keep absorbing new knowledge in this area even after the team is formed. If you already have a team, and it isn’t working out, then head for the bookstore and start learning right now. Take good notes and write out your own processes, such as for interviewing, resolving conflicts, rewarding excellence, and dismissing underperforming team members. Each time you apply these processes, you can further refine them.

How do you know when you’re ready to begin building a team? I would suggest the following rule of thumb: You’re ready when you can acknowledge that you would willingly join a team formed and managed by someone else who had your level of skill in that area. If you would think twice about joining such a team, you’re not ready to form your own. Identify what specific weaknesses would give you pause, and begin educating yourselves in those areas immediately. You live in the information age—take advantage of it.

People who’ve never managed a team before will probably consider this advice to be overly cautious. But those who’ve been burned by mismanaged team projects in the past are likely to appreciate it more.

Team first, project second

Many developers decide on a project they want to develop, work out a design doc, and then begin assembling a team to create it. This may seem like a good idea, but it’s backwards. The team must come first. You cannot realistically select a project until the team has first been assembled. It’s OK to have a general idea of the type of project you want to create, but until the team is assembled, you shouldn’t decide the details of the project. Why is this so? Let’s consider both alternatives (team first vs. project first) to understand the natural consequences….

Let’s first assume you opt for the common “project first, team second” approach. You get inspired by an idea, design a game in some depth, figure out what talent you’ll need to complete the project, and begin looking to build a team. You decide you’ll act as the designer/producer, and you determine you’ll need two programmers and one artist. You can license the music and sound effects for the game. The project is a simple 3D action game. You’re confident it will be a terrific game when it’s done, and the specs look achievable. You estimate that the game could probably be completed in 4-6 months.

Sounds like a reasonable plan, doesn’t it? And that’s the trap. Because it looks so reasonable on the surface, indies keep falling for this approach year after year. On a few occasions it actually works, but most of the time it fails utterly. Why?

What happens to the above project in reality? You search for months but can’t find a decent 3D programmer who’s willing to work for your terms. The best you can do is a 2D programmer who’s currently learning 3D programming. The artist you found can’t create decent textures to save his life, but he’s a great 2D animator who’s willing to “give it a shot.” The second programmer you manage to find lives overseas and barely speaks English, but he’s willing to work remotely. So you try your best to work with what you’ve got.

Things don’t go well. The two programmers experience frequent personality clashes. The artist isn’t able to create quality textures even after much practice. You get something running on the screen, but the technology is very buggy, and the game isn’t really fun. Team members don’t really buy into your original design and start trying to implement their own ideas, and you get upset that they aren’t reading the design doc carefully enough, so you try to assume more and more control, telling the artist exactly what to draw and giving the programmers ever more detailed to-do lists and schedules. But still everyone has a different conception of how the final game should look, and the lack of synergy causes the project to stall. Team members start doing the minimal work necessary just to make it look like they’re still contributing, but no one really expects the project to succeed. You discover that one of the team members is already contributing to another project, putting yours on the back burner. This downward spiral eventually leads to the cancellation of the project.

The erroneous assumption was that designing a good game is the key limiting factor in the success of the project. That may be true for individual projects, but it isn’t true for team projects. For a team project the limiting factor is securing the right team members. With the wrong team, you’ll end up spending most of your time worrying about control. With the right team, excessive control is unnecessary, and individual empowerment becomes the norm.

Another problem with the “project first, team second” approach is that it fails to leverage the team’s strengths. A game designed to exploit the specific talents you have available is a far better choice. Developers thrive when they work from their strengths. If you have an outstanding 2D artist, use him/her to create an outstanding 2D game instead of a lousy 3D game. Because the team is the limiting factor, the team must dictate the project.

Now let’s consider the second option: “team first, project second.” You may have a general idea about the type of project you’re looking to develop, but you keep your options open. You take the time to find the best team members you can. Since you have greater flexibility in choosing team members with this model (because you’ve kept your game design options open), you can pay more attention to interpersonal factors, selecting team members you expect will work well together. Once the team is assembled, together you work out a design that takes best advantage of the team’s strengths and compensates for their weaknesses.

For a project to succeed, you need every team member to be as committed to the project as possible. And developers are more likely to commit when they’ve contributed to the design and when the project gives them a chance to show off their strengths. Each team member knows their contribution will make a real difference, and they assume co-ownership of the project. So in this scenario you’re more likely to witness an upward spiral where enthusiasm and commitment remain strong throughout the project. Also, the team is more likely to want to work together again on future projects.

Selecting the right team members is the single most important factor in determining the success or failure of your project

You’ll see the statement above stressed in the strongest words possible in many top management books. Selecting the right team members is absolutely critical. If the wrong team members are selected, it’s possible that even the best manager in the world can’t salvage the situation and keep the original team intact. When a team is broken, an effective manager will frequently give some team members the axe and recruit new members to replace them.

Don’t blindly recruit the first interested person that comes along. Take your time to find and select the best team members you can, even if it takes months. The main limiting factor for your project will be your ability to attract and select the best team members you can find. If you can’t build a solid team, don’t begin the project.

Select team players, not individual superstars

For a team project to survive and thrive, you must select and recruit people who are team players, not individual superstars.

Consider the case of the 1980 Winter Olympics. Team USA created a huge upset in ice hockey by defeating the USSR team 4-3 and winning the gold, even though the USSR had previously blown away the USA 10-3 in the final exhibition match shortly before the Olympics. Team USA’s coach, Herb Brooks, said in an interview that he used a psychological test to reject self-centered superstars, and he selected only team players who would support each other.

Team players respect individual differences while at the same time committing to the achievement of a mutual goal. Team players are still highly ambitious, but their ambition is directed into the project or the company, not their own egos. Their ambition is for the team. They will rewrite any piece of code, redo any piece of artwork, recompose any piece of music, willingly and without complaint, for the good of the project—for the good of the team. Team players are like the cells in your body, working together to keep the host alive and healthy.

Because team players accept personal responsibility for the success of the project, you don’t need excessive control and management. Problems won’t be ignored—team members will root them out and fix them. Why? Because they’re personally responsible. They “own” the project.

Character trumps personality. Where personal honor is sacred, every individual assumes responsibility for the project. When honesty is paramount, suspicion and distrust cannot gain a foothold. And where mutual respect is high, petty personality differences simply don’t matter.

Your team must have a single individual in charge

Every team must ultimately have exactly one leader, and everyone on the team must know who that leader is with no ambiguity whatsoever. The leader sets the example that the other team members follow, and s/he must earn the respect of the team. When the team members no longer respect the team leader, the downward spiral begins. Respect cannot be coerced. It can only be earned.

How does a team leader earn respect? By embodying the virtue of and by putting the needs of the team first. The team leader is the quintessential team player. The team leader must strive to be honest, fair, and objective. If the team leader makes a promise, it must be kept. Whatever standards the team members are expected to live up to, the team leader must become the embodiment of those standards.

The team leader’s job is to give the team a victory on the first project, no matter what. Because this is an awesome responsibility, it must be coupled with a high degree of control. The team leader listens to all team members, but whenever a key project decision must be made, it’s the team leader’s job to make the final call. In a properly functioning team, team members rarely second-guess the leader. Once all the facts are on the table for a decision to be made, team players will generally come to the same conclusion regarding what’s best for the project and the team, even if it means more work or less freedom for them as individuals.

Software = Team

The quality of the software you create will be a direct reflection of the quality of the team you build. The state you want your team to achieve is called unit integrity. In this state all team members are working together to achieve a singular goal. Morale and productivity are high. When you have unit integrity, your project will converge towards a successful launch. Without unit integrity your product will diverge towards cancellation.

The team leader is directly accountable for maintaining unit integrity. If a team member isn’t pulling his/her weight, it’s the team leader’s job to straighten things out or to replace the underperforming team member. If morale is low, the team leader takes action to improve it. The success of the project will depend heavily on the team dynamics, and this cannot be left to chance.

A great way to build unit integrity is to do something together as a team outside the software project itself. If your team is local, try getting together for a pen-and-paper role-playing night once a week. If your team is scattered across the globe, find other activities you can do together, such as playing an online game together, especially a squad-based game where you can play together as a team. If the team members genuinely like and respect each other, it should be easy to find common activities. When teammates become friends, people look forward to the time they spend working together, and team morale soars.

Keep communication channels open

Maintaining a successful team requires an abundance of communication. Keep team members informed about the status of the project. Check in with team members frequently to see how work is progressing. Secrecy breeds resentment.

Build the project at least weekly, and make that build available to all team members. Let every team member know the status of the project. This not only prevents self-delusion about phantom progress, but it also boosts team morale as team members see the project improving week by week.

If your teammates aren’t local to each other, consider maintaining a private section of your web site where every team member can access project documents, including the design doc, schedule, task assignments, and project status updates.

Face-to-face communication is always superior to voice or email because the bulk of human communication is nonverbal. Don’t buffer yourself behind email when another method of communication would be more productive. Pick up the phone or meet with teammates face-to-face if possible.

Share the rewards

There are many ways to establish a compensation structure for your project. Ideally your team will function best if active team members share in the potential rewards, which means a percentage of royalties from sales. It’s critical that team members feel they are being fairly compensated and that their extra efforts will be rewarded. If you feel that a fair compensation structure is impossible, then simply don’t begin the project.

Aside from financial compensation, ensure that every team member receives credit within the game. Praise team members liberally, and be sincere and genuine in your praise. Don’t just assume that they know they’re doing a good job. Praising people is an easy way to boost morale. If possible, always praise individuals publicly—in front of the other team members. Be specific in your praise. Don’t just say, “Great job.” Instead say, “You did an outstanding job on those textures last week. The level of detail and lighting were superb. Excellent work! Your art is really helping this game shine.”

Put it in writing

Whatever agreements you make with your team members, you must commit them to writing. It’s often easy for people to agree verbally, but when everything is committed to writing, omissions and inconsistencies are more easily discovered. Try to predict all the various contingencies and decide how you’ll handle them. What will you do if a team member wants to leave the project prematurely? What’s the compensation structure? What duties will be performed by each team member? When will the royalty checks be sent out? Who owns the intellectual property? Can the musician sell the songs created for the project on his/her own CDs? There are no right or wrong answers to these questions. Every team will answer them differently. The only wrong choice is not to decide these things in advance and commit them to a signed contract.

Cut underperforming team members

During an anti-terrorist training exercise for a U.S. Navy SEAL team, a SEAL team member accidentally slipped, and his gun went off, shooting and killing one of his teammates. (SEALs train with live ammunition.) The team leader’s response? He immediately kicked that SEAL off the team for life, and in fact, out of the SEALs altogether. Why? Because from that point on, the others SEALs would never be able to fully trust that team member again, and trust is essential for unit integrity. Notice that intention wasn’t even a consideration here. It didn’t matter that the SEAL didn’t intend to kill his teammate. All that mattered was that he did, and this mistake killed team morale. From then on that particular team member would have always been a reminder of failure, which would have destroyed the rest of the team’s focus.

Despite this drastic example, in many ways software projects are similar. If a team member is underperforming, you must take immediate action to correct the situation. Explain what you expect of the team member in terms of performance, and put it all in writing. But if such correction doesn’t satisfactorily occur within a relatively short period of time (30 days is a good figure), this team member will quickly lose the trust of the other team members. And lack of trust kills unit integrity, acting like a cancer that may eventually spread to the whole team. In this situation you must cut the underperforming team member and replace him/her as quickly as possible. It doesn’t matter if this person intends to do better; all that matters is the actual performance. If you’ve selected only team players, there will be no grudges held in such a parting. The team player will recognize that the health of the team and the success of the project may require his/her departure.

A common mistake made by inexperienced team leaders is that they are too patient and forgiving of underperforming team members. While it may seem like a good idea on the surface to give people as many opportunities to change as possible, this generosity comes at great cost. Holding onto the under-performer for too long ends up punishing and sabotaging the entire team. Yes, it can be very tough to let someone go who very much wants to succeed, but it’s a necessary and unavoidable part of management. If you can’t stomach letting someone go, then you simply aren’t fit to lead a team, so don’t put yourself in this position.

Conclusion

This article only provides a small glimpse of the rules for building and managing a successful team. Team-building is a rich subject that can require a lifetime to master, and it is one of the most sought-after skills for CEOs. But despite all the risks and hard work, being a part of a team is an extremely rewarding experience, and most who’ve enjoyed it will tell you that it is indeed worth the effort. Hopefully the tips in this article can help you avoid some of the pitfalls and enjoy more of the rewards of team projects.

Bio

Steve Pavlina is President of the ASP and CEO of Dexterity Software, an on-line game publisher dedicated to releasing retail-quality games through shareware channels. You can find Steve interacting with Dweep addicts at his website, Dexterity.com

Copyright© 2003 by Steve Pavlina

working,with,teams

By now it should be no big surprise that I decided to make a computer game in the image of this beloved classic. I began in February of 2002 and ended in late May of 2003. Solace is the first game I’ve written that I did not publish myself (using online payment services such as Kagi). Indeed, this was my first experience interacting with a publisher. The road from independent game hobbyist to published independent hobbyist is not one well-paved or readily apparent, so I’d like to take a moment to reflect on my experiences traveling it.
h3. Finding That Special Someone
(Main Menu Screen) I should start off by stating that I am writing from the perspective of an independent game developer whose sole experience is with one publisher, namely Freeverse Software. In reality I don’t know how all publishers think—only how I think they do. Around the time I finished the design document for Solace, a coworker of mine was contacted about a Cocoa development project by Jason Whong (formerly of Ambrosia Software and Green Dragon, now an employee at Freeverse). Apparently, they had met in the past on a Bulletin Board service run by my coworker. Since my coworker was uninterested in Cocoa development at the time, he suggested to Jason that I meet with him instead. Although I had never met Jason before, I did know of his exploits in the Mac game development community (particularly the whole bug eating episode), so I let him know about myself and the new title I was beginning work on. After a short Thai lunch and a hand off of the Solace design document to Jason, the rest was history.

The point of the story here is that if you have an “in” (i.e. you know someone already in the correct position to give you a hand along), then the road is much easier. However, simply knowing someone doesn’t guarantee getting published. Having a good public track record is crucial! Being able to approach a publisher with “This is what I’ve done already, this is what I’m doing next,” is important. The longer and more successful your virtual sum is, the greater the chance a small to medium size publisher will take you on. This is one reason why the uDevGames Contest is such an excellent venue for independent game developers. You get to create a game, on which the iDevGames community will readily provide feedback, allowing you to make that game even better. Then if you’re lucky you may win, allowing you to say something like “Winner of the Best Polish Category.” But even if you don’t, it is one more public example of your work that a publisher can use to get to know you. If you enter the next four uDevGames Contests, that’s four publicly released titles backing up your claim that your next title should be published.

When dealing with small publishing houses, you need to keep in mind that while their resources may be vast, they are also limited. By necessity, they must be very picky about who they decide to publish and who they need to turn away. Naturally then, you want to make your proposal to them seem as simple on their part as possible. When you think you’re ready to approach someone like Freeverse or Ambrosia, keep in mind these three magic words: “Return On Investment” (ROI). Then, instead of thinking about the return you will get on your investment, think about what the publisher’s will be. Simply stated, you have a much better chance at getting published if you can show them a product which is 95 percent done, noting that you have another three percent to complete and they’ll be responsible for only two percent. This way you take the majority of the investment upon yourself (which in my case was simply 17 months of my time), and they look at it from the approach of “Well, even if we don’t sell bushels of them, we’ll still make money.” Granted, if your game’s quality is below what they’d consider you probably won’t get published, but then again they’ll be more likely to give you advice so that when your game is up to snuff, they’ll be ready for you.

It will also pay off if you do some research into the various publishing houses before you approach them. In the end, what you will want is a publisher who fits well with you, as well as your game fitting well with the publisher. Although I was lucky enough to meet Jason in person, there are several other reasons why I felt comfortable publishing Solace with Freeverse. Firstly, I looked at their reputation in the Mac game community, which is one of making fun and whimsical games: a company who can make a simple game of Solitaire great by throwing in a series of jokes and a barrel of monkeys (literally). I admire this about them, that is, their willingness to stray from the norm and go off on a path all their own. In contrast, my games tend to be very utilitarian (some might say bland) in nature. I can create visually appealing titles with in-depth gameplay, but I’ve yet to make one in which the player busts out laughing! In the end I felt that some of the Freeverse “spirit” was what I really needed.

I also examined the genre of games Freeverse produces and the nature of the audience they cater to. Freeverse is known for their selection of card and board games, with the occasional RPG and shooter thrown in, and their core audience enjoy the roll of the dice and the turn of the card. Solace strove to be a board game in your computer, so it would fit nicely into their current selection of games.
h3. What Went Right
h4. (Game Map Screen) Building upon past experience
Solace is sixth game that I’ve created and released publicly, and is the third game to reuse the same core engine code. This means that I was able to get Solace up and running in a relatively short amount of time. It also meant that I had a strong base which was relatively bug free to build upon, allowing me to spend most of my time actually creating Solace and not working on how to develop a fullscreen OpenGL display. Taking the time to create a solid foundation that is modular enough to carry between projects is incredibly important, and will pay off well in the end!
h4. Entering the uDevGames 2002 Contest
I entered the uDevGames 2002 Contest with a relatively simple arcade game called The Belt. This helped in several ways. Since The Belt utilized the same engine code Solace does it meant that the code would get another round of public testing before Solace was released. Also, I was already exchanging emails with Jason (and in turn Ian Lynch Smith) about Solace when I decided to enter the contest. What this meant is that I not only got another notch on my belt with The Belt, but it also impressed them that I could halt one project and create another well-polished game in under three months! Of course, winning the uDevGames Contest was also handy, since I put the prizes I won (namely BBEdit and Carrara Studio 2) to use in creating Solace.
h4. Expanding my graphical talents
I spent a large amount of time over the past two years focusing exclusively on making better graphics. Going back and looking at the artwork in Vortex Next Generation and comparing it to the artwork in Solace is sufficient testament to the amount of effort I put into bettering myself in this particular area. I spent my time getting acquainted with the various 3D renderers, as well as expanding my knowledge of Photoshop. I’m continuing this today by studying and learning the (lost?) art of “pixel art,” with the hope that my next game will have a more “retro” feel to it.
h4. A great publisher
I cannot express fully the availability and openness Freeverse Software showed me. From the beginning they were both courteous and prompt. I’ve attempted to contact several publishers in the past, and my best experience was waiting approximately two weeks for a response to my email. Granted I’m sure said publishers were busy, but would you want to tie yourself to a publisher with whom you’ve had a bad first impression? I think not.

In contrast, I not only received replies from Freeverse promptly, but even before an official contract was signed they gave a large portion of their time to me. From providing feedback to the latest build, to suggesting areas in which they could improve upon the quality of the game (i.e. the wonderful voice-overs Colin provided), to allowing me to spend nearly four months from the time they first sent me a contract until I finally decided to sign it. They were open and understanding about the difficulties a hobbyist game developer with a full-time job has. In the end, my experience with them was nothing like the horror stories you read about on the web and in Game Developer Magazine; it was more like working with a close friend.
h4. An understanding wife
Finally, no married game developer can write a postmortem without thanking his or her spouse. This particular game was incredibly stressful due to the fact that it was being published. This is the first time I’ve really experienced the two-month crunch time before release—you can image what it must have been like for her! We are both working full time jobs and I was spending more than four hours a day at home programming. I could just say she’s been incredibly patient, but in reality her patience has reached goddess-like levels. Without her, I would never be able to have half of what I have today.
h3. What Went Wrong
h4. (Battleboard Screen) Lack of personal playtesting
Solace is made in the image of Axis & Allies, which is a large and complex game. In turn, playing a complete game of Solace also takes a couple of hours. Having this kind of overhead means that I spent almost no time actually playing my game, since one can spend their time either playing what they create or actually making their creation! Hence, there were several update and beta versions I released that had bugs which could have been caught had more effort been put into play testing a complete game. In the end, however, your hands are tied. There are only so many hours in a day, and I’d rather spend them adding new features and fixing bugs. Thankfully I had a great complement of beta testers as well as the guys at Freeverse to play test for me.
h4. Entering the uDevGames 2002 Contest
Yes, even though there were many benefits to entering the uDevGames Contest, one cannot discount the fact that it added nearly four months to the development time of Solace. Even so, it was worth it in the end.
h4. Massive hardware failure
It happens to everyone eventually, mine just happened to occur in February of 2003. My Lombard PowerBook G3 now reports an error where there is something wrong with the processor cache, and running it for any length of time is an uncertain procedure. I had planned to wait until the G5 processor was released before purchasing a new PowerMac, but the sad reality is I had to purchase early. Here’s hoping that Solace does extremely well so that I can purchase one in the future (that is, after my wife and I purchase a house).
h3. Conclusion
The creation of Solace is one of the major milestones in my life. I always told myself that one day I’d write a game that was published, printed, and put on store shelves. Having a great development experience and a wonderful publishing company were added benefits that made that milestone something I’m eager to attempt again.

I’d also like to say that Solace is the first project in which I’ve had the pleasure of working with both a musician and an artist, and in the end the experience was again a joy and not the hassle many game developers make it out to be. My gratitude goes out to Steve and Andrew for jobs well done!

So, what’s next? I’ve got a few ideas for uDevGames 2003, and now that Solace is complete and the beginning of the contest right around the corner, who knows? Perhaps I’ll be adding another notch to my virtual belt here soon!

Solace Credits

* Developer: Feline Games
* Genre: Turn-based Strategy/War
* Site: homepage.mac.com/felinegames
* Team size: 1
* Released date: June 20, 2003
* Project length: 17 months
Development hardware: PowerMac G4 (“Wind Tunnel”) 
* Critical applications: Carrara Studio 2.0, CodeWarrior, Adobe Photoshop

Download

* Demo

solace,feline,games

Overview

Since the early days of the PowerPC, CodeWarrior Pro has always been the most powerful Integrated Development Environment (IDE) for serious Mac game programming. It compiles programs written in C, C++, Objective-C (Cocoa), and Java, and can compile for Mac OS, Windows, Linux, Palm, and most game consoles. Unlike the PC world, the Macintosh has very little competition in the professional-level compiler market; the only other mainstream choices include Apple’s Mac OS X-only Project Builder and several BASIC compilers, such as FutureBasic and REALbasic.

Over the years, CodeWarrior has outperformed other Mac development systems, while offering more flexibility and features, as well as optimized code—important issues for professional development. However, at $400 ($300 upgrade from CodeWarrior 7), CodeWarrior 8 now faces competition from Apple’s freely distributed development tools. In addition to the price factor, the current version of CodeWarrior has some issues with compiling under Mac OS X. New and more powerful versions of REALbasic and FutureBasic are also applying pressure to CodeWarrior’s position as the tool of choice for Macintosh developers.

What You Get

Inside the CodeWarrior Pro 8 box you will find two CDs labeled ‘Tools’ and ‘Reference’, as well as two small packets, ‘Quick Start’ and ‘Quick Reference.’ The ‘Tools’ CD includes the compiler and all necessary libraries; an easy install of the Mac compiler and libraries requires about 300MB of disk space. The ‘Reference’ CD includes sample code and tutorials. Although the printed documentation is rather sparse, the ‘Reference’ CD, which includes online documentation, and the free online classes at CodeWarriorU (codewarrioru.com) more than make up for it. Also, nearly all the tutorials and samples at Apple’s site and at nehe.gamedev.net (for those interested in learning to use OpenGL) come with CodeWarrior project files, which can be easily compiled with CodeWarrior Pro 8.

Standard Features

Recent versions of CodeWarrior have offered powerful code optimization. CodeWarrior allows you to choose the level of optimization you want, and whether it aims for small code size or fast execution speed. While it may seem that maximum optimization would be the logical choice, it can take an hour or two to compile at highest optimization compared to a few seconds at lowest. The project manager makes it very easy to organize source files and libraries, and to set up different build targets if necessary (such as building Mac OS and Windows versions in the same project). CodeWarrior Pro 8 also includes a useful debugger; you can mark certain lines of code at which it will pause and open the debugger window to step through each line, and see what each variable contains at any time.

CodeWarrior also includes Rapid Application Development (RAD) tools, including PowerPlant, a framework used to quickly set up interfaces with windows, menus, buttons and other elements which you can design yourself.

New Features

In CodeWarrior Pro 8 there is a RAD tool for Java programs, which should prove useful for even Java game developers. There is support for Cocoa and Interface Builder, which would eliminate the only real advantage Project Builder had over CodeWarrior Pro 7, if not for an annoying bug that I will go into later. There is also a new feature called ‘Code Completion’, where CodeWarrior automatically guesses what word you are trying to type and can fill it in for you, i.e. if you type “@player.lo@” it will list any variables you might have in that class that begin with “@lo@”, such as “@player.location@” or “@player.lowerbody@.” This is useful if you ever have trouble recalling variable names, or have exceptionally long ones. Unfortunately it means CodeWarrior will occasionally pause for a second or two to update its list of variable names, which can get irritating during large projects. Thankfully, Code Completion is off by default.

Also new in this version is a ‘Class Browser’ that can list all your classes and let you look through all their variables and member functions, which is useful if you have long source files or many classes, but it would be much more useful if it just showed the classes you use; as it is now, it seems to show all the classes you use and all the ones in any libraries you include.

Problems

Unfortunately there are still some bugs and annoying ‘features.’ Compiling and building under Mac OS X works, but in my experience it was not possible to actually run the build from within CodeWarrior; it would just load endlessly. Due to this bug, it is not possible to use the CodeWarrior debugger under Mac OS X. Fortunately this is not a problem for me because I do all development using Carbon and Mac OS 9, and the builds run perfectly under Mac OS X. However, this is a fatal flaw for any Cocoa developers in my opinion.

A minor irritation for my workflow concerned the IDE feature that opens all of the windows which were active when CodeWarrior was last used. Although this feature may be time saving for developers working on a single project, it is somewhat of an irritation for developers like me who work on multiple projects at a time.

Conclusion

For those who have yet to purchase CodeWarrior, or have been using older versions, CodeWarrior 8 is a mature and solid development tool for games and applications. It shines as a cross-platform alternative to Apple’s free Mac OS X developer’s tools and for Carbon development. Mac OS X developers face a harder decision when we factor in the price difference between Apple’s tools and CodeWarrior, and the issues with compiling under Mac OS X with CodeWarrior 8. Metrowerks does offer a possible solution in the form of CodeWarrior Mac OS X Edition—a less expensive subset of the Pro edition, with a Mac OS X-only compiler and no Java support. Metrowerks has a chart outlining the differences between the two editions on their Web site.

Overall, CodeWarrior Pro v8 was perfect for my OpenGL Carbon game development, but the only useful new feature in version 8 for my needs was Code Completion, which is helpful but not really worth the $300 upgrade price.

• Rated 8
• Version: 8
• Category: Development Environment
• Developer: Metrowerks
• Url: www.metrowerks.com
• MSRP: $ 599.00 ($299.00 upgrade)
• Mac OS X Requirements: Mac OS X v10.1.3, PowerPC G3 or greater, 128 MB RAM, 350 MB HD

codewarrior,pro,8,metrowerks

Community Editorial

A recent article in the Bangkok Post commenced with:

My advice, if you are a developer and someone asks you to do something on the Mac, is to pretend not to hear them.

Unfortunately, someone who is not familiar with Cocoa or the Mac OS X development environment might read that and derive an understanding that the Mac is in some way an inferior development platform. Though the purpose of the original article is not clear (Is it a review? An editorial?), this editorial is a point-by-point rebuttal, written by visitors to iDevGames’ forum, aimed to clear any damage done to the image of Mac development.

Learning a New Environment Takes Time

In the first two paragraphs, the author admits to being new not only to development on the Mac platform, but to the Mac platform itself. I must ask: If he is as inexperienced with Mac programming as he says he is, why did he accept this assignment? An unfamiliar operating system, an unfamiliar programming language, an unfamiliar framework/API, an unfamiliar development environment, and yet an expectation that everything will look and act just the way another environment does? This is an unreasonable expectation. Differences in two environments are not flaws. It takes time to learn anything as sophisticated as the Macintosh operating system and the Macintosh development tools, and it shouldn’t be expected to be the same as a different product. Unwillingness to admit not knowing how to use it and take the time to learn it ends-not surprisingly-in confusion and unproductive work. Let me emphasize that switching platforms and entering a new professional development environment are not for amateurs.

As far as his problem with the Mac having but one button on its mouse, it is irrelevant. It’s a difference in the platform user experience, not the development tools. A two-button mouse can be used, probably the same one plugged into the original author’s PC right now. The Mac does not require a second mouse button, and for most users it is unnecessary. Those who desire one are free to use one.

The Tools

The author then continues to explain that while installation of Apple’s tools is a snap, obtaining them is not. Being over a 300MB download, this is true for many users, but there’s not much Apple can do about it. However, the development tools come on a CD with the latest release of Mac OS X; also, high speed connections to the Internet and CD burning hardware are commonplace today, so getting hold of the tools should not be difficult for most people—especially developers.

Apple’s developer tools are also free of charge, far more affordable than the Windows tools mentioned in the article. If Project Builder and Interface Builder are not desirable, there are other environments available for the Mac like CodeWarrior, JBuilder, and REALBasic, to name a few.

The author continues:

The latest C development interface is called Cocoa.

This is simply wrong. Cocoa is not “the latest C development environment,” it is based on Objective-C, which is a different language with some very large differences from C. This is clearly explained in the introductory developer documentation, which includes a complete book on Objective-C.

Both the description of using “a typical development environment“ and Apple’s development environment are so horribly oversimplified that it’s difficult to criticize them. The best rebuttal I can think of is that the underlying differences between the environments are much greater than what the IDE looks like, and that the author could not leverage his experience with other tools as much as he would have liked. I seriously doubt he can build an interface in VB that works right on the first try (so add the build/test/edit/rebuild cycle onto that explanation as well) any more than I could sit down in front of Visual Studio, type in some Objective-C, build the equivalent of a nib file, and get a properly working application in a few minutes.

The author continues:

In a nutshell, so far this is the worst development environment I have ever had to use. The most unfortunate part of the Cocoa environment is that the higher-level pieces appear to be separate from the underlying bits, and the links between them are arcane and poorly documented.

The initial statement of this paragraph is quite unprofessional. The remainder reflects a flawed understanding of object-oriented design and, again, the incorrect assumption that Cocoa behaves exactly like other tools he has used just because it performs the same function.

Documentation and help

His complaints of incomplete documentation are valid; this is the largest and most persistent annoyance Apple developers have to put up with. However, one wonders if he is aware of the tightly-knit developer support community, from mailing lists run by Apple to sites like this one, where help is easy to find (assuming you don’t introduce yourself by declaring “this is the worst development environment I have ever had to use“). The article does mention that the author has sent emails to the Mac community and is awaiting a response. Perhaps before writing this article, he should have admitted that his confusion is his own fault, not Apple’s, and waited for replies to come in from those emails.

Conclusion

My advice, if you are a developer and someone asks you to do something on the Mac, is to take the time to look over the tool set and API, familiarize yourself with the basic concepts and how they differ from the rest of your experience, have an open mind about how to solve seemingly familiar problems, and generally behave like any competent programmer encountering an unexplored field of knowledge.

This editorial was written by the combined efforts of the following iDevGames community members: Mark Levin, sealfin, James David Ramsey, kjurtyl, and edited by Chris Burkhardt.

If you are interested in learning about Cocoa, iDevGames recommends the book ‘Cocoa Programming for Mac OS X’ by Aaron Hillegass.

rebuttal,to,bangkok,post

This text is an introduction to the world of Mac OS X software development. While it’s primarily aimed at UNIX developers wanting to develop for Mac OS X, the book does not require any previous programming knowledge and should be suitable for anyone interested in software development on Mac OS X.

Contents

The book is divided into the following chapters:

• Welcome to Mac OS X
• Navigating and using Mac OS X
• Project Builder and Interface Builder
• Development Tools
• Objective-C and the Cocoa development frameworks
• Cocoa programming
• AppleScript programming
• Mac OS X and beyond

For a full table of contents, please visit the book’s page at Manning’s website. ‘Programming Mac OS X’ is divided into three parts. The first covers the Mac OS X architecture and usage, with topics ranging from help systems and the Finder to process management and user accounts. These chapters are filled with small useful pieces of information for any new Mac OS X user.

The next part introduces the Mac OS X developer tools, starting with ProjectBuilder and InterfaceBuilder, and moving on to tools like AppleScript Studio, gprof, leaks, and MallocDebug. All the Apple developer tools are, however briefly, covered in this chapter.

The third and final portion of the book covers practical Mac OS X programming. It starts with a discussion of the Cocoa infrastructure and the various languages available for Cocoa developers. Chapter 6 then continues with a tutorial on Objective-C using Cocoa. In the tutorial O’Malley describes the process of creating a Cocoa application working as a GUI front end to the UNIX utility wget. The tutorial goes though all the necessary steps in the development process, but the learning curve is pretty steep and not all the source code is listed. The former might be somewhat of a problem for readers with no previous C programming knowledge. While there is no CD accompanying this book, all the source code examples are available as a free download from Manning’s website. Chapter 7 is dedicated to Apple’s scripting language AppleScript, with various small examples and guides. Both standard and Cocoa-based AppleScript are covered alongside the fundamentals of the language.

The book ends with Chapter 8: “Mac OS X and beyond”, which discusses more advanced Project Builder features such as inline scripting and how to use different compilers. The chapter finishes with an example of how to use Perl with Objective-C and Cocoa.

Four appendices are included, in this order: “Getting and installing development tools,” “UNIX and Mac OS X command mappings,” “The precursor of Mac OS X: Mac OS” and “A brief history of UNIX”. The titles should be quite self-explanatory of the contents. Like the rest of the book, the appendices contain a lot of useful information and are definitely worthwhile reading.

Final Thoughts

‘Programming Mac OS X’ is written for developers with a UNIX background in mind and therefore concentrates hard on subjects such as command-line tools and scripting. The fact that the book does cover these topics make me believe that it would also be useful for a lot of beginner Mac OS X developers interested in the underlying UNIX core of Mac OS X.

Readers new to Mac OS X development will certainly find a lot of interesting information in this book, which is well written, up to date, and doesn’t have the mistakes and errors common in most computer literature. O’Malley has a light writing style that makes the book fun to read and easy to follow. If you are new to Mac OS X development, it’s definitely money well spent.

Developers already familiar with the Mac OS X developer tools and Cocoa should think twice before buying this book, as the primary objective of the text is to introduce you to the Mac OS X environment and then get you started with Cocoa. The chapter on Cocoa/Objective-C programming, while very good, is nothing more than a warm-up tutorial to get you started with Interface Builder and the Cocoa framework. For those of you just interested in learning Cocoa, I would recommend getting a full-fledged Cocoa book such as ‘Cocoa Programming for Mac OS X’ by Aaron Hillegass, or ‘O’Reillys Learning Cocoa with Objective-C, 2nd’.

Related Books:

• ‘Step into Xcode : Mac OS X Development’ by Fritz Anderson
• ‘Beginning Xcode’ by James Bucanek
• ‘Advanced Mac OS X Programming’ by Mark Dalrymple, Aaron Hillegass

programming,macosx,omalley

by Casey Gatti

Carlos Note: Change links to Textile markup format. needs a bit more proofing maybe?

Overview

Everyone these days seems to be thinking in 3D, when 2D animation can still play an important role, and games with 2D, especially cartoony looking games, are still loved by users. I know many of you are thinking, “2D? that is so 1980’s!”, but here’s why you need to learn good 2D animation techniques and my article will help you to achieve them.

Technical aspects of hand drawn animation

2danim01.gif

Hand drawn animation requires the artist to employ a system for keeping all the drawings in proportion and correctly registered. Maintaining proportions is based on the natural skill of the artist, however keeping the drawings correctly registered is a matter of using the Acme, Oxberry, or Standard 3-Hole peg bar system.

Basic equipment needed for drawing

I’d recommend purchasing the Standard 3-Hole peg bar system. Just think of 3-hole punched paper on top of a peg bar. To visually look at, or even perhaps order one, please visit LIGHTFOOT LTD. (http://www.lightfootltd.com/indexa.html) They cost only $4 per peg bar and you’ll probably need two ? one for the light table, and the other for the web-cam testing system.

Go to any office supply store, purchase the cheapest 500 page ream of paper ($5) and a 3-hole puncher ($25). Do not purchase pre-punched paper. This paper has factory made holes which are too big for the peg bars (your paper will slide around way too much).

Portable light tables run between $50-$90. Just tape the peg bar on top of the light table as shown in the photo.

2danim02.jpg

For more information on the general tools and materials needed for animation, please refer to the book title “The Animator’s Workbook.” It is an excellent resource for anyone pursuing animation.

Theory of character animation

Characters, primarily in video games, operate in looped animations. In the Playstation game “Oddworld”, the user has many different character movements for Abe to perform: standard walk, run, sneak, run-jump, jump, etc. The principles for these character animations stem from the study of an individual’s movement. Sometimes the best ways of understanding motion is through video recording a movement and viewing it frame by frame. Don’t be afraid to act out these movements. It is ideal to use a camcorder for the studying of movement in game animation because both camcorders and many video games operate on a 30fps time base. The artist can then choose to rotoscope the movement (trace over the real-life images) or draw the frames by hand and add distinct characteristics to the movement. To learn more about character animation and the amount of frames normally associated with a cycled animation (eg. walking, sneaking, running, etc.) please refer to “Character Animation” by Preston Blair. Please remember that this technique can be applied to 3D animation as well. Many 3D programs support importing QuickTime or AVI files within the background of a certain view. Since we can’t all afford $10,000+ motion capture systems, filming a character moving and then using the joints and bones as reference in a 3D program would be great.

The electronic tools needed for testing

So, you’ve drawn up 10 pictures which show a character running. Now it is time to test the animation. Before I go over the hardware and software to purchase, I want to mention my system specs: iMac 500MHz DV, 20GB, 768MB RAM, Mac OS 10.1.5, 1024×768 resolution. I would recommend the following tools based on their quality and modest costs:

• iBot by Orange Micro — Web-cam captures very high-quality 640×480 imagery with outstanding screen refresh rates of 30fps. (Firewire model — $90)
• BTV / BTV Pro by Ben Software — Application for capturing video content from most web cams. Works great with iBot. The basic version has the main tools that you’ll need for $20. But if you’re interested in stop-motion animation, motion detection capture, and some other movie editing features, consider the $40 pro version.
• ioexpert Driver by IOXperts — Provides the driver for practically all firewire cameras. This was bundled at a discounted rate of $10 if a user purchases an iBot, but I’m not sure if this discount is still valid. (Regular price — $20)
• QuickTime Player Pro by Apple — Any multimedia content creator should already have this purchased. It is needed for importing an Image Sequence ($29)

2danim03.jpg

Final cost should be around $150-$170 for all of these components and you’ll have a darn good animation testing system.(Just so you know, other non-computer based animation testing systems cost between $3,500-$5,000. It’s pretty ridiculous.)

Rigging the camera and lighting

The last thing you’ll need to do is rig the camera so it can face down and shoot the drawings. The camera needs to be securely connected to the crane-type of system. It can not wobble during shooting footage. You’ll also need a decent desk lamp or drafting table light to properly illuminate the “live area” which the camera will be shooting. Most video capture software has the capabilities to adjust brightness, sharpness, and contrast, but I suggest to try to create the correct lighting without configuring it through software. (I’ve sometimes run into software glitches when I try to adjust the lighting from within different video capture software.)

Testing and capturing the animation

These instructions assume that you’ll be using the same software as me. However, the principals provided within these steps should be applicable to other tools. Make sure the iBot is plugged-in and start-up the BTV software. It is best to capture animation tests at 320×240. (Capturing frames above that size takes more disk space and could possibly not show accurate frame rate when playing video back on a slower hard disk.) You need to set the preferences to save the screen captures to a specific directory/folder. You want them to be in PICT format and the program to automatically append a sequential numbering system to each file.

2danim04.mov Artist checking the movement

Step-by-step

• After you capture each file, quit out of the program.
• Now it’s time to use QuickTime Player Pro ($29) to import an Image Sequence. This cuts out the need to have an image compositing program such as Adobe Premiere or Apple’s Final Cut.
• Open QuickTime, select File and choose Open Image Sequence.
• Navigate to within the folder and select the image numbered 001.
• QuickTime will now prompt you with an option to import the files based on frames per second. Since video games mainly run at refresh rates of 30fps, it is best to import your animated characters at 10fps, or 15fps. (Note: If you have a 10 drawing run cycle, have the frames imported at 15fps. If the motion is too fast, then import them at 10fps.) To achieve the smoothest character animation, it is best that the characters play back at 15fps with your desired motion.
• Save the QuickTime movie. Choose “Save normally (allowing dependencies)” This saves a lot of hard disk space. Set the movie to Loop and hit play. If you wish to share the QuickTime movie with another person, follow these steps: Select File and choose Export…, select Movie to QuickTime Movie from the pull-down menu, click the “Options…” button, and then click on Video “Settings” and choose your preferred codec. I’d suggest Cinepak. Make sure the frame rate matches the frame rate of what you imported the frames in as. Finally, choose “Limit data rate to 90k per sec.”)

2danim05.mov Finished animation test

There you go!

It’s best not to use a scanner for general animation testing. The motion is what’s being tested, not the fine line quality of the drawing. Web cams quickly take a snap shot in 1-2 seconds, automatically append a sequential numbering system to the file and are immediately ready for the next picture. Scanners take a minimum 20-30 seconds per picture. Scanners are only useful for capturing the final cleaned-up/fine line drawing.

Final clean-up of animation

The clean-up process is when the animator cleans up the drawing by applying a fine line marker trace of the original animated drawing. Hopefully you already have a scanner at your disposal.

• Fine line each drawing
• Set the scanner to scan the drawings as “line art”. This will allow only the dark, fine line to be picked up. Line art = bitmap format.) Tape the peg bar onto the scanner and scan each drawing.
• Use Photoshop, Gimp or any other low-cost image editing tool (Sprite Editor) to color in the drawings.

I hope this sheds some light on the tools and processes of traditional hand drawn animation. When I have a little more open time, I’ll expand this article to include techniques and processes for coloring the characters in vector and raster-based applications.

low,cost,2d,animation,techniques

chrispruett01.gif

Vicarious Visions develops games for a wide array of game consoles and operating systems, and some of these games are developed for several systems simultaneously. How are the development teams organized?

It really depends on the game. Usually, we are able to share sound and graphics assets across platforms. The company’s development teams are sort of divided into two sides: the console/PC side and the GBA side. Since I work on the GBA side, I am not intimately familiar with the goings-on on the console side, but I believe that a single team is usually responsible for all versions of a game.

Whiteout and Tony Hawk’s Pro Skater were both made for several different platforms. How were people and development managed for these projects?

In the case of Tony Hawk, the Windows and PSX/PS2 versions were created by other developers. The original Tony Hawk games on the PlayStation were made by Neversoft. Vicarious Visions developed the GameBoy Advance versions of the game: Tony Hawk’s Pro Skater Advance 2, 3, and 4. I was not on the development team for any of these games, but I believe that Neversoft provided us with some game assets via Activision, the publisher. Whiteout is a game that we built from scratch. The game supports PS2, XBox and Windows. My understanding is that the same team was responsible for all three versions and there is no GBA version of the game.

When a title is ported to the GBA, are graphics and sounds usually re-used or converted, or due to some limitation are new game assets required?

Again, it depends on the game. Usually, we can use a lot of graphics and sound assets from other games. I worked on both of the Crash Bandicoot GBA games that Vicarious Visions has done, and in those cases we were provided with some sound and art assets from the original PSX titles. Occasionally, converting a graphic or sound to a format suitable for GBA will not be possible with acceptable quality, and in those cases we mostly recreate the asset from scratch. That’s not to say that our artists’ main job is conversion, though. We can usually grab bits and pieces from a console game, but we create the majority of a game’s art from scratch. For example, I was the lead programmer on Frogger Advance: The Great Quest, which was tied in with a PS2 title by Konami. We were given 3D models of the characters from the PS2 game, but we created all the animation for those models on our own. We were also able to use some of their textures in tiles for our levels, but otherwise all of the art in the game was created by our art team.

chrispruett03.jpg

Courtesy of Nintendo Japan

Which development systems and tools do you use for your GBA programming?

We use the official Nintendo hardware mentioned above. The Nintendo dev kit consists of a grey box connected via SCSI to your computer, a compiler and debugging software, some development libraries, and a debug-enabled GBA that connects to the grey box. The compiler is a derivative of GCC 2.95, I believe, and binaries produced with it can be downloaded via the debugging software onto the grey box. You can then run your game on the test GBA. All of this software is Windows-only. Of course, GCC will run fine under Mac OS X and Linux, but the debugger software and grey box drivers make development on any platform other than Windows a challenge.

What languages do you use to develop for the GBA?

Though Nintendo only officially supports C (and Assembly, of course), we use C++ for almost everything. We write a few very time-critical functions in 32-bit ARM Assembly (the processor also supports a separate 16-bit instruction set), but I’d guess that 98% of the code in a typical side scroller project is pure C++.

There are a lot of free GBA development environments, tools and emulators. Do you ever use these at Vicarious Visions, and what’s your impression of those you have used?

Some of the coders at Vicarious Visions experimented with the freely available GCC 3 releases, but their tests showed that GCC 3 code generation doesn’t seem to be as good as 2.95. The main problem with freely available tools is that they are usually buggy, and (unless the source is also released) don’t give us enough control over the output. We want to be able to organize our data in the most efficient way possible, and our methods are usually pretty different than those chosen by the authors of free development tools. Instead, we write our own tools, which are usually much more specialized for our particular needs.

Every GBA has a known and fixed hardware configuration. Is this an advantage or disadvantage compared to the ever changing Mac and PC hardware platforms?

It’s an incredible advantage. Writing on a platform with frozen specs is great; if it works on your machine, you know it will work on everybody else’s. Furthermore, the GBA is a game machine, and the hardware supports many game-centric features (hardware sprites, character based VRAM, transparency, rotation, scaling, etc). Also, the fixed hardware places a nice limit on the technical requirements our game must meet. If you are developing a PC game, for example, that will be out in two years, you want your graphics engine to take advantage of video card features that will be available when the game is released. The catch here, of course, is that you may be developing technology before such cards are even available, or before consumer machines are fast enough to run your game. On the GBA, we are not under pressure to meet the requirements of future hardware, since the hardware isn’t going to change. While we still need to push the technological envelope to stay competitive, we can immediately test the viability of new innovations. This is great, because it allows us to focus on game design instead of technology, which is what is really important. It also means that if we come up with some incredible hack, we don’t have to worry about it breaking under new versions of software or hardware in the future.

chrispruett04.gif

Bakudanjin

Over the years, Nintendo has released upgraded versions of its GameBoy, for example “Color” and “Advanced.” Does Vicarious Visions maintain a collection of libraries and other code to ease development for each GameBoy generation?

Though I wasn’t at Vicarious Visions when the GameBoy Color development was going on, my understanding is that we had some technology that was shared between projects. However, all of our tech was written from scratch when we started working on the GBA (at least, to my knowledge). The GBC stuff was all in Z80 Assembly, and our GBA projects are all C++, so translating the code didn’t really make any sense. Now that we’ve done a number of GBA titles (about 10 released, at last count), we’ve been able to build up a collection of useful code. We try to keep all our code very modular (which is why we use C++) and can often mix and match modules to create new functionality for each game. We also try to spend a significant portion of our time refactoring our classes and keeping modules clean, so that they can be easily used in all sorts of projects. Each game creates new tech as well, which is usually fed back into the common code collection. A good example of this is Crash Bandicoot 2: N-Tranced. In addition to a side scrolling game mode, Crash 2 also features an isometric mode with 3D character sprites, called Atlasphere. I was the lead programmer on that project, and my main responsibilities were the side-scrolling portions of the game. Eric Carazi, another GBA programmer who had experience with our 3D isometric engine codebase, was responsible for creating the Atlasphere game mode. Eric and I worked independently for the most part, merging our code together at regular intervals. We were able to work in very different code environments without much difficulty, which I think is a testament to the effort we put into keeping our modules atomic.

Given the GBA’s hardware limitations, it was quite clever creating an isometric 3D view for the Tony Hawk games. Although you weren’t part of the development team, could you share anything about its development?

The development team created a lightning fast 3D engine, a complete physics model, and the means to run all of this in an isometric scrolling world. My understanding is that the game was the result of many hours of blood and sweat on the part of the development team, but the results were so fantastic that the effort was worth it. The core focus throughout development was making sure the game played just like its PSX counterpart, even though we didn’t have the luxury of fully 3D worlds.

In my research for this interview, I learned that there is a very active GBA hobbyist scene of developers. Do you see any opportunities for an independent GBA developer to break into the GBA market as is sometimes the case with Mac/PC lone-wolf developers?

This is a very difficult question to answer. I guess the short answer is no, I don’t think that hobbyist games are likely to be picked up by a publisher and sold on the market. There are several reasons for this:

• Time pressures — Hobby development takes a long time. At Vicarious Visions, we usually have four to eight people working full time on a game for six months, and even then time pressures can be difficult. Creating an entire game from scratch, without the support of the hardware vendor, in your free time, and without proper hardware documentation is a huge challenge.
• Licenses — The games that sell best are ones with well known licenses. Just take a look at the most popular GBA titles: Pokemon, Yu-Gi-Oh!, Mario, Zelda, Metroid, Spongebob, etc. Games without a license are a big risk, and a lot of units have to be sold for the publisher to make a profit.
• Cost of entry — Nintendo development licenses—you need one, but they are hard to get. If you can build a good enough game or demo to get publisher support, you might as well start your own development company.
• Quality — Producing a competitive-quality GBA title is harder than it sounds, and publishers always want the cream of the crop. If you are capable of producing such work on your own time, you might consider becoming a full-time developer.

Of course, there are great reasons to develop games on your own time:

• You’ll learn what it takes to make a game.
• You’ll produce work and gain experience that will be extraordinarily valuable if you ever decide to apply to work at a game development company.
• You’ll learn (out of necessity) how to write efficient code. (Push yourself. Make your game run on a 200MHz 604e. Don’t require hardware acceleration. You can do it.)

chrispruett05.gif

Nonetheless, if you are really interested in developing GBA games, my advice is to apply to an existing company. Make a killer Mac/PC demo and include it with your resume. Manufacturing costs alone are expensive enough to require significant sales for the publisher to make a profit, so few publishers are willing to take risks on unproven developers.

As with PlayStation and other game consoles, there’s a formal procedure to be followed to become an ‘official’ GBA developer. How does this work?

In order to become an official GBA developer you must apply to Nintendo to receive a development license. Once you have a development license, you can buy official Nintendo development hardware. A company called SN Systems also makes dev kits, but you still need to be licensed by Nintendo if you want to publish your game. Though I am not involved in any of the business aspects of Vicarious Visions, I believe that this process is very difficult. Once your game is complete, you must send it to Nintendo for stress testing before it can be manufactured. This process, called “lot check,” involves testing every aspect of your game for bugs or non-compliance to standards. For example, Nintendo requires that the buttons on the GBA be referred to using a very specific vocabulary, and if your game does not follow this standard it will not pass lot check. This process is to make sure that all games meet a certain level of quality. Nintendo isn’t generally looking at the design of your game; they are trying to make sure it will never crash under any circumstances.

In the event that I had a hit Mac game, and decided to port it to the GBA, what would be the best route to take?

Assuming you’ve obtained a Nintendo development license, you must first have Nintendo approve your game via the lot check process described above. If you are going to act as your own publisher, you’ll need to pay Nintendo for the cartridges, as they control all manufacturing. After that, I’m not really sure what happens; Nintendo probably also has to approve the box art and other materials. It’s a pretty complicated process, designed to make sure that Nintendo gets a chance to approve all titles for its hardware before they hit the market.

Let’s talk about your employer, Vicarious Visions. So far, only one title from them has appeared on the Mac: Terminus, which was made available for three platforms. Which technologies were used to develop it?

chrispruett06.gif

Courtesy of Vicarious Visions

Terminus was Vicarious Visions’ first big project. It was completed in 2000, long before I arrived, so I don’t really know the details of its development.

How were the sales results for Terminus, both generally and for the Mac specifically?

The game was released on Mac, PC, and Linux, and won the first annual Independent Games Festival award. Also, all three versions shipped in the same box, so it isn’t possible to track Mac-only sales. I’ve heard, though, that a significant number of Mac users picked the title up.

How does Vicarious Visions go about creating a new title? Is there any “game concept think tank” producing ideas?

All the designers meet weekly in groups to discuss gameplay ideas and directions for new projects, and we often have small brainstorming sessions (open to everyone) about how a particular license or idea might be converted into a game. By the time a publisher is on board, the general form of the game has already been decided. The general form might be something like, “It’s a colorful side-scroller with puzzles based on the TV cartoon. The main character’s signature move, a super-charged jump, will be an integral part of the play experience.” The designer takes this information and produces a design document, which details how most of the game mechanics will work. Supplementary documents about level design goals or significant technologies may also be produced. Once the team gets into the full swing of the project, the designer’s job is to create content and make sure that the design document is up to date. If it turns out the original idea for the super-charged jump isn’t going to work as planned, this flaw must be identified and corrected as early in the development of the game as possible.

chris,pruett,vicarious,visions