iDevGames

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