iDevGames

A Look Back at Macintosh 3D Software

Back in the days of Mac OS 8.5/9, my 3D application of choice was Strata Studio, the 3D program that gave us Myst. Looking for extra features and stability, I evaluated the state of 3D software for game asset creation. The games industry was heavily into the early versions of Max at that time, and programs such as Cinema 4D and NewTek’s LightWave appealed to me because of their Amiga roots. Maya was yet to appear in the industry as a mainstream application for developing 3D game art, yet when it did appear, it was a pretty massive impact with a lot of studios switching over. I settled on Maxon’s Cinema 4D and have been using the program for several years now. Most recently, for Strange Flavour’s iPhone games Flick Fishing and SlotZ Racer.
Read the rest of this entry »

Tools

blackshades03.gif

I programmed mostly in CodeWarrior; part of it in version seven, and part in the copy of version eight. I am testing in order to write a review for iDevGames. I used Meshwork to create the buildings, player models, and one of the handguns. David Drew used Cinema 4D to model all the other weapons. The main menu music was done with the help of John Graham, and the rest of the music I composed with SoundEffects, SoundApp, and the Digidesign Pro Tools Trial, using sound loops created by Carlos Camacho.

What Went Right

Using Skeletal Animation

Basing my character models on skeletons meant I could easily make characters react believably to impacts — from bullets to gun butts upside the head — to blend animations together. My animation editor, based entirely on inverse kinematics and constraints, allowed me to make fluid and complicated animations within a couple of minutes (like the disarm animation).

blackshades04.gif

Actually Finishing the Game

While Black Shades is still rough around the edges, it somewhat resembles a finished game. Unlike my last entry, GLFighters, I now have a main menu, high scores, a config file, and some background music. This leads to a lot of bittersweet comments from friends along the lines of “Wow, it looks almost like a real game!”

Not Making my Own Sounds

In GLFighters I made my own sounds with a built-in microphone, which did not result in high-quality sounds. In Black Shades, I found sounds from free sites all over the internet and modified them with SoundEffects to make them more interesting. I now use OpenAL for hardware acceleration and 3D sound.

The Graphics Style

Using models with no textures made for a unique look, and also cut down development time for the models that I made by at least 90%. It also allows Black Shades to run at an acceptable framerate on low-end Macs. It would be very difficult to make a game with detailed graphics able to run such a huge city at playable speeds.

What Went Wrong

blackshades05.gif

Lack of Help or Options

I clearly did not learn my lesson from last year’s contest that most people do not bother reading a ReadMe file. Although Black Shades’ gameplay is much more self-explanatory, it would have helped to have a tutorial level or something that explained how to aim with the iron sights, disarm people, tackle people, etc.

Not Supporting Mac OS X

It seems that by now almost all gamers are using Mac OS X, so many are not able to try Black Shades at all. Others have to play under classic emulation, which has many problems and could lead to negative votes in the contest. I actually tried to Carbonize Black Shades, but it was much harder than it seemed due to differences in things like file loading, mouse control, and timing.

Variable Difficulty Levels

Some people are much better at this type of game than others, and the current setting is very difficult. The last level of the game is almost impossible, which most likely frustrated some otherwise skilled players who then gave it bad ratings. Halfway through the voting period I had to significantly reduce the difficulty of several levels.

Conclusion

blackshades06.gif

This contest was a good exercise in having a deadline and actually finishing a game; generally I work on a game for a long time and gradually lose steam until I am just not interested any more. Then, I start a new one. The short deadline forces us to actually finish the game before we get too sick of it, which is helpful just for the experience and because now there are 40 more Mac-only games out there to play in my spare time. (Editor’s Note: One entry, The Belt, was cross-platform.) My next game will most likely be a fighting game with gameplay based loosely on Oni but in a very different setting.

• Title: Black Shades
• Genre: 3D Action
• Developer: David Rosen
• Team size: 1
• Released date: November 12, 2002
• Project length: 3 months
• Development hardware: G4 733MHz
• Critical applications: CodeWarrior, Cinema 4D, Sound Effects, Digidesign Pro Tools Trial

Tough Times Ahead

Right after the beginning of the contest my father’s health turned worse. Between his illness and passing away, I was busy for the first three weeks of the contest. Then, when I got back, work was in crunch mode and I needed to catch up on top of it all, pushing development of Headache! further and further off. Given those delays, it was important to keep the game within a level that was reachable before the deadline. Luckily, I had made sure to design the game concept to be scalable, allowing for basic gameplay, and letting things get added as time presented itself.

headache03.gif

Gator

What Went Right

Scalable design

In any situation where you are on a deadline it always makes sense to make your design scalable. We stuck to the core gameplay and made sure that was pretty good from the beginning. By doing this we created a fun game, and allowed ourselves to add some really great graphics and some fun extras that really enhanced the game and polish.

CVS and Multiple Development Systems

My uDevGames entry for last year, “Zed Nought,” was a pretty large game, and trying to get it to build on another system after the fact ended up being very painful. So, from the beginning, I made a decision to put everything into CVS, and to split my development time between my desktop and laptop machines. This also helped to act as backup for my source and artwork. An additional advantage to this approach was that I could do a clean checkout and see that it would build without my specialized environment.

headache04.jpg

Talking-heads

Great Artwork

Having a great artist really helped the game. It was already fairly fun to play, but once the final art made its way into the game, it really started to get a look of its own. A big part of the success of Headache! was in the art category. It is too easy for a lone-wolf developer to try to create art in a rush to ship the game. However, I feel that with each passing year the quality level of uDevGames entries will increase and having a true artist as part of the development team will become a must.

Flexibility

The final version of Headache! looks considerably different than I imagined it during the design phase. I had visualized a much more “cartoony” look and a very different sound for the music. However, the artist came up with a different look—a “realistic” one that really took the game to the next level. Also, when all testers said we needed the heads to somehow animate when they went away, it was added. However, care must be taken in how flexible you can be, as is illustrated by the next point.

headache05.jpg

Bad coder!

No Surprises at the End

There were a few things that testers (and my artist) really wanted to have me implement, but I was very wary of introducing instability at the end. I don’t mind being flexible, and flexibility had a lot to do with our success. However, there are some things that just can’t be added safely near the end of the development cycle. This was a hard lesson learned from last year’s contest. I added HID support to Zed Nought the day before the end of the contest, and then spent the next 12 hours trying to get the basic gameplay working again while adding in all of the art as well. Needless to say, I didn’t let that happen this year, and it paid off.

Memory Management

Rather than spending a lot of time hunting down leaks and agonizing over performance, I adopted and followed some good practices to keep memory leaks to a minimum. So in the end, I found only two real leaks using Apple’s tools. Of course, one was easy to fix while the other is still plaguing me, as I need to risk adding instability in order to really fix it.

Great Testers

I am lucky to have some friends that are really great testers. They all gave great feedback that made it into the game. They were especially good at helping me prioritize which issues needed immediate attention versus what could wait until after the competition. Unfortunately, I wasn’t able to get through the complete list of to-dos before the deadline of the contest.

What Went Wrong

Prioritization

There were some issues that could have been addressed had I tackled them earlier in the cycle. Some of this was because I was worried in the beginning about getting the basic gameplay done, and some of it was laziness. You always want to work on the fun stuff and find reasons to avoid the tedious stuff. Also, some of my feedback wasn’t available until later in the cycle.

headache06.gif

Everyone talks

Miscommunication

Although working with an artist was a huge boon to the game, one communication issue arose. During the concept phase, I had envisioned that users would be able to pick a “persona” that they could play as. This would be especially helpful with two player mode. However, it became clear that it wouldn’t be possible to put the characters into the game with the limited time we had left and make them look as if they really fit in the game. However, when I decided not to put the characters in, I unfortunately neglected to tell my artist that he didn’t need to make them. As he was following the design document, he spent a great deal of time creating the various characters. In the end, we weren’t able to use the many game assets he created and it would have been more fruitful for him to have worked on other areas of the game, such as the user-interface, which was left for last. Since he had spent so much time creating the characters, he was very disappointed that they weren’t featured in the final build. The good news is that I retained all the game assets, which opens the possibility for a two-player version in the near future so his characters will finally get the attention they deserve and will no doubt add yet more polish to the game.

A final issue that arose was with the witch doctor character that the artist had created. This character was pre-rendered and featured several poses based on the player’s actions. However, I had to omit the witch doctor from the game when the artist was unable to resolve a problem with the alpha-channel in the animations.

Coding Myself into a Corner

Given the time constraints, I found that I had coded myself into a corner. For example, the font renderer needed to have a way to change the color and a way to cast a shadow. However, the way it had been coded in the beginning was fairly specific to the original way it was being used. It’s too bad, because the text system is a great idea—it just had the wrong execution! The reason behind this problem lies in the next section.

headache07.jpg

Doug’s head

No Prototypes? Off with His Head!

One thing that worked really well for last year’s entry was the fact that before I added anything to the main app, I would prototype it out first. In this year’s entry, I started doing that. However, because of the system I was using, prototypes started taking up a large amount of my time. The overhead of getting a prototype up and running was getting to be much more than the time it took to implement the feature being prototyped. I’ve always found that implementing the prototype allows you to make all of your mistakes early. Then, when you rewrite the feature in the main app, you generally implement it much more intelligently.

Developing Quickly vs. Developing Correctly

I am gaining an understanding of the benefits of taking the time to code things correctly. Also, the idea of refactoring is one that really makes sense to me. Yet, for some reason, I failed to follow these principals as I should have.

The Artist Speaks

From Cartoons to the Real World

Once I had the basic concept of the game from Doug, I proceeded to make a concept game screen. The initial design document required cartoon-like graphics so I used a vector-based drawing program. The results were pleasing however I felt they weren’t enough to make the game win the graphics category. So I went back to the drawing board and went for a more realistic approach to the playing screen. Since the game was on an island, I incorporated island-like elements into the play screen, for example a jungle background, and the bamboo.

headache08.gif

Dr. Umfoofoo

Along with freehand painting in Photoshop, I used some royalty-free image clipart. The clipart went through numerous filters and other transformations before being added into the screen. To move away from the ultra-clean look, I tend to add a slight amount of “noise” to each element. In addition, the contrast and brightness was altered. These two steps gave the graphics a more “computerized” look—as though they were rendered in a 3D program.

Each element was stored in its own layer and then saved separately to give the programmer complete flexibility in layering the graphics on the game screen. Since the design document called for slight animation outside the “head-drop zone,” using separate layers would also allow for such things as insects flying in front of and behind different on-screen elements. The idea of adding extra animation to the game was very good. For example, the insects I mentioned. We also planned on having other animals pop in and out of the game, fully animated. However, since time was limited, they were dropped from the final game.

Where the Brush Ends, 3D Begins

headache09.gif

The heads

The topic of severed heads and how to make the graphics for such a game had me wondering if it would be “kid-friendly.” I felt that kid-friendly would be a necessary quality if we were to show the game at MacWorld (providing we won). I’m a strong believer that more games for the Mac need to have a “console-style” polish. So I made the heads as cute as could be. In making the heads, I first modeled a basic head shape in Cinema 4D. I then applied different morphs to the heads to provide for some variances, so the heads wouldn’t be static but provide some on-screen character, much like the classic Macintosh game Snood. In all, I made seven head colors with seven frames each. Although not listed in the design document, I also provided “evil-heads” that might be used for future versions of the game.

The game screen used a realistic art approach while the sprites retained some of the cuteness that the original design document outlined. Using a 3D application allowed for great time savings in creating sprites and also in animating them.

One World, Many Races

The initial story of the game had a cast of characters along with some background information. These characters would be used in the game to add extra polish and some interesting opponents in the two-player mode. A great part of my time was spent creating these characters in Cinema 4D. One interesting point was that I wanted to represent a wide range of people. Most games have a hero, and he is almost always an Anglo-Saxon male. The characters I created would allow gamers from around the world to see someone more close to home. I’d like to see more developers think in this manner! As Doug mentioned, although the characters were created on time, they weren’t incorporated into the final version for the uDevGames contest. Hopefully we will see a two-player mode added in the future and the debut of the witch doctor animation, which I was especially fond of.

headache10.gif

Poor menu system

It’s the Interface Stupid!

I often feel that many Mac games fail to inspire due to their user-interfaces. Looking at the platform, some companies really stand out in their approach to bring console-like menus and screens to their games. This is especially important as the demographics for Mac game players is changing, and also allows for easy localizing. With the character graphics taking a great deal of time, I left the user-interface elements for last. I envisioned having the witch doctor on the screen watching the characters’ mouse movements or interaction with the buttons. For example, if the gamer attempted to type the wrong key for the high score board, the witch doctor would shake his head “no.”

The buttons would also need to provide visual and audio feedback when selected and pressed. Time constraints forced us to use basic buttons—far below the quality level that I had envisioned! Looking at the final playable, I feel that we let gamers down in the user-interface. The buttons seem to be arranged randomly, and don’t offer the easy-to-use concept that we had planned. If I’m on the team for next next Headache! version, the user-interface will be my first priority.

Odds, Heads, and Ends

The talking-heads and gator were inspired by a fun “monkey” game by another developer. It’s a great idea, however I felt the font size and style was a tad hard to read on many screens. Hopefully Doug will address that problem and also include the many talking phrases that I created. The sound and music kept with the spirit of the game, but it sometimes gets a little repetitive. This is most likely caused by the 10MB limit. I can see the sound and music going to new heights if the game goes commercial, due to the fact that we had a great library of sound and music assets that were never utilized. Although I offered some pointers on gameplay, they were mostly for polish. Since the columns-type genre has been visited by many developers, I was always trying to push Doug towards more originality.

GoodDoug’s Conclusion

In the end, there are some very important lessons that I have learned. Using CVS and two machines for all of my coding made it simpler to deliver my code at the end of the contest. Flexibility is great, and it can be maximized by doing prototypes and being conscious of future refactoring. Also, taking time to keep all members of the development team apprised of all issues should make things much smoother next time. I’d like to give a special thanks to the people and groups that made Headache! possible: My artist Amaha, the staff at “Java Junction” on Seabright Ave. for keeping me caffeinated, my hockey superstar teammates on Strychnine and Fuzzy Bunnies for playing hard, and most of all, my wife Sandy and son Zachary (and the new one on the way, Kahuna). And of course to Carlos Camacho and the crew at iDevGames.

• Genre: 2D puzzle
• Developer: Doug Whitmore
• Url: http://www.gooddoug.com
• Team size: 2
• Released date: November 12, 2002
• Project length: 2 months
• Development hardware: PowerBook G4 800MHz and PowerMac G4 Dual 450MHz
• Critical applications: ProjectBuilder, CVS, OmniOutliner”:http://www.omnigroup.com/applications/omnioutliner/, BBEdit 6.5, Adobe Photoshop 7.0, Cinema 4D, Bias Peak

Welcome Back

Carrara was a 3D modeling and animation package originally launched during the final days of MetaCreations. Rebranded as Carrara Studio, the program is now under the control of Eovia, developers of the advanced modeler Amapi 3D. Eovia has enhanced the successor of the former best-selling Mac 3D applications Ray Dream Studio and Infini-D with numerous bug fixes. Having descended from the GUI world of MetaCreations, users will find many similarities between Carrara Studio and Bryce, as well as Poser. Eovia has done a worthy job in bringing the power of 3D to the masses with Carrara Studio’s workflow design and value-added goodies.

Installation

Carrara Studio ships with two CDs — an application CD and a content CD. The application CD contains the Carrara Studio 1.1 Installer and documentation, plus a completely functional version of the modeler Amapi 3D. During the installation process you can select to install the Smart Pack, QuickTour, help files and some other goodies. The Smartpack contains 25 third-party plug-ins that offer such features as cartoon rendering, advanced procedural shaders, and noise tweener. A complete installation of Carrara Studio will require 85.5MB of hard drive space. Eovia recommends a minimum of 64MB of RAM, however with most 3D applications having more will lead to improvements in modeling and rendering. The content CD is an extra bonus featuring additional objects, a UV mapping program, and textures. In addition, it also showcases the art of Eovia and their users.

The Interface

You have the option of going through a QuickTour when the program is first launched. It is extremely helpful as it teaches the fundamentals of the program: 3D workspace, navigation, interface, tools and trays, spline modeling, arranging objects, shading, lighting, animation and rendering. In the world of 3D, applications generally fall into three camps: separate application programs (i.e. animation and modeler), one application with a main work window, or one application with several “workflow” sections. This latter approach is the method employed by Carrara Studio. The process of creating, texturing, animating and rendering a model are all performed in unique compartmentalized steps called “rooms.” Although some designers debate this approach to creating 3D art, a strong argument can be made in its favor based on the idea that the simplified interface presents only the tools needed for a given task. In addition to improving the workflow of advanced users, the “room” concept offers an easier learning curve into the world of 3D for beginners. A side benefit from Carrara Studio’s interface is the removal of the constant need to resize or reposition windows to conserve screen real estate, a problem that seems to plague many graphic applications. The five rooms which cover every function of creating 3D art include:

Painting in 3D

ZBrush is a new painting application with a 3D rendering engine developed by Pixologic“. This powerful tool has been generating a lot of buzz in the games industry and was chosen as a finalist for Game Developer Magazine’s 2001 Front Line Award. Since my work for Strange Flavour relies on the use of 3D software for creating game assets, and having heard positive comments about it, I was eager to take ZBrush for a test drive. My initial impression of ZBrush reinforced what everyone was saying about this tool — it’s groundbreaking! My review will cover ZBrush’s 3D painting and modeling features and evaluate the performance of ZBrush for use in game development.
Tutorial.jpg

Getting Started

ZBrush is available for both the Macintosh and Windows platforms. Although many of today’s popular tools are cross-platform, Pixologic should be commended for their cross-platform upgrade policy. As a registered owner of one full-priced PC or Mac license, you are entitled to purchase another license at half price for the other platform. ZBrush is not available in stores and must be purchased and downloaded via Pixologic’s website. If the screen shots and ratings don’t convince you to try the program, a limited time demo, along with documentation, is available in their download section. The 8.8MB demo is fully functional and you can get started with the application after receiving the unique serial number that is sent to your e-mail address.

The installation of ZBrush on my PowerMac G4 MP 500MHz with 1GB RAM went very smoothly. Once running I was presented with a very ergonomic-looking interface that in many ways reminded me of the interfaces built by Kai Klaus of MetaTools fame. Although ZBrush shares a certain style with many of MetaTools’ former programs, its interface felt silky smooth and was very snappy. In fact, at times it felt smoother than the Mac OS running underneath it!

The Interface

ZBrush’s initial setup presents you with a workplace window in the center of the screen where you do all your modeling and drawing. All the menus are distributed to the right and left of this document area. This allows easy access to the menus without cluttering up the document area. The menus can be repositioned to your own preference and saved as the default configuration for successive ZBrush sessions. To conserve screen real estate, as well as keep the screen uncluttered, any menu can be iconized (and then appears in the top-center menubar) or collapsed; rarely used menus are automatically closed. Similar to Apple’s Balloon Help, pointing to any control for a short period of time will display a pop-up info window.

When you launch ZBrush, the program prompts you to navigate the tutorials. There are several automated tutorials available to guide you through most of the basic commands of ZBrush. Watching a running tutorial is a bit like watching a master artist bringing a painting alive on television. Not only are the tutorials informative, they are also fun to watch. The power of these tutorials comes from ZBrush’s built-in scripting language.

ZScript.jpg

ZScript

ZBrush’s tutorials and many other customizable features are all running on a scripting language called ZScript. This concept is not new in 2D applications such as Photoshop (Action command), but in the 3D world it is a very welcome feature. Scripts can be created to perform specific actions or to create entirely new objects. As you can imagine, ZScript forms a very powerful backbone within ZBrush and offers endless possibilities for creating new art and saving time during game asset production. Pixologic have stated that a future version will allow for further customization of ZBrush’s interface through ZScript. It is worth mentioning that their website contains free downloadable ZScripts ranging from tutorials to utilities. I expect more to be added over time as the user-base grows.

Modeling

After running through some of the initial tutorials covering the interface, I was very eager to explore the process of making my first model. Of all the objects that artists must model, creating and controlling realistic organic objects can be the most challenging. In my opinion this is the area in which ZBrush truly shines. By viewing a few ZScripts that demonstrated the creation of character models, I was able to learn some of the best ways to approach modeling a face. The first step was to create a sphere, which can be thought of as a lump of clay in ZBrush, and which was then pushed, pulled, and bent into shape — a Wacom graphic tablet or mouse helps here. This approach to modeling is also available in the 3D application Amorphium Pro by Electric Image. After a few minutes, my sphere was turned into a manga-style face that, along with some good textures, could have easily been used in any commercial game. Overall, the way ZBrush models is a bit like sculpting with stretchable putty, almost like Kai’s Goo but in full 3D and much more fun. Although ZBrush has several different sculpting tools, I found I only needed to use the two basic movement tools to get the results I wanted. The main tool you use to create your models is the Transform palette, which works on basic 3D solids like spheres, cubes, etc., that you’ve placed in the 3D area, and which also allows you to build up or subtract an area in volume as you paint on its 3D surface or push/pull an area around.

Head.jpg Anime Head

ZBrush contains many deformation functions that perform operations such as twist and shear. For modeling characters, the symmetry function allows you to mirror what you’re doing on one side of the model to the other or on multiple sides. This came in extremely handy in the majority of work that I created with the program. ZBrush is fantastic at creating organic objects and doesn’t disappoint with more mechanical ones such as spaceships, either. Experimenting with polygon reduction, and turning smoothing off on one axis, you can introduce some hard lines into an initially very organic-looking spaceship model to make it appear more structural in shape. In fact, after using the program for a few weekends I was soon finding new ways to make sleek spaceship and car body shapes that didn’t suffer from the “meta-ball” look.

The ability to export models for use in other 3D applications is an important feature for artists who work with multiple tools. The current version of ZBrush can export models in DXF or OBJ formats. I exported several DXF and OBJ (retains textures) models created in ZBrush into Cinema 4D with no problems. During the importing process, the models will lose their ZBrush smoothing effects, but Cinema 4D’s Hypernurb function can be used to rectify this. If you wish to take advantage of ZBrush’s painting tools to create textures, the same formats are supported for importing models. ZBrush also provides a very good optimize function in the deformation palette that allows you to reduce polygons on an object. This feature is especially useful for models which will be used directly in a 3D game engine and require low polygon counts. You can also import models to use as brushes for texturing. For instance, if you wanted to quickly draw a small jungle, import a tree and then draw it all over the 3D area.

Texturing and Painting

If ZBrush stopped at modeling, I would still rate it highly, but it goes even further with a generous assortment of tools to help apply textures and paint your models. Textures can be created by painting on a layer with 3D primitives or brushes you’ve created. The screen area is then captured and converted into a 2D bitmap to be applied as a texture onto an object. Alternatively, you can just paint onto a 3D object with a layer specified as the texture map. It’s quite an odd but powerful combination of 3D and 2D.

Render.jpg Rendering

ZBrush employs a full 3D-painting engine that helps to distinguish it from other 2D painting applications. In effect, you are really painting with pixels in 3D rather than moving polygons around. This mode allows you to paint using several pre-defined 3D brushes or a model you previously made onto a 3D virtual canvas. The nearest tool that I can compare it to is the $499 PaintFX plug-in by Soft Images for Maya. Which is impressive, as ZBrush costs less than most of the plug-ins for the major 3D packages and does a lot more. A good example of this would be painting a scene with grass. You would start with a blank ground object and then paint on the grass as individual blades, adding in additional objects like plants and trees from your palette of pre-modeled brushes. However, it doesn’t stop there, as ZBrush employs a materials palette with a number of definable surface types that allow you to paint the scene with any number of these while also adding more depth with the 3D brushes. I spent a few fun-filled days just playing with the painting features inside ZBrush. It reminded me of the days when I moved from Electronic Art’s 8-bit painting program Deluxe Paint to the natural media application Painter. The opportunity to utilize the painting tools to create textures for game models, screen backgrounds, or game interfaces should be appealing to graphic designers working in the game development industry.

Rendering

ZBrush has proven itself as a powerful tool for creating 3D models and textures. The next step was to determine if the spaceship and face designs I created could be easily and quickly rendered into 2D sprites. Strange Flavour’s two titles, Bushfire and AirBurst, required a great deal of sharp and attractive small sprites. For those two projects, my 3D program of choice was Cinema 4D, mainly because of the rendering quality and precision it has for creating more mechanical-like models (vital for doing small objects that will be used as game sprites). I’m always interested in finding new tools to help in this area, so I was eager to test ZBrush’s rendering engine. For my tests, I placed the models in roughly the same size I wanted for the test game, set up the best rendering mode and then tweaked antialiasing. The sprite frames were exported from ZBrush to Photoshop’s PSD format and then turned into a final sprite bank. The initial rendering resulted in sprites that lacked sharpness. One way around this problem is to render the sprites at twice their size, and re-scale inside Photoshop. However, I abandoned this time-consuming workflow after switching to Cinema 4D’s excellent renderer. Pixologic recommended that I experiment with the antialias and rendering settings to improve the output. After some trial and error, I was finally able to achieve the results I was looking for. In comparison, rendering at twice the size and re-scaling resulted in much better detail. So it seems that with this version of ZBrush, I would have to utilize Photoshop or Debabilizer to batch process the sprites. Not the end of the world, but a step I would like to avoid in the future, especially if I have 300 plus sprites to work on.

Ship.jpg Ship sprite

Thinking back to the power of ZScript I feel that there is still a place for ZBrush in my workflow. Although some time would be added from the re-scaling, it is possible that I could reduce the amount of post-process work I normally have to do in Photoshop. For example, a ZScript could be written to automatically lay out all the sprites rotations of a spaceship in rows onto one screen and at the correct positions. The double sized screen would still need to be re-scaled in Photoshop. However, you would have the complete sprite bank without needing to use a batch system like Debabilizer to pull individual sprite cells together onto one screen, which was my previous method for arranging sprite banks. So all in all, I should be able to automate most of the laborious tasks I was doing in Photoshop directly within ZBrush itself with just a few predefined scripts.

Conclusions

As with any 3D application, ZBrush requires a fair amount of time to learn. New users may either feel at ease with the MetaTools-like approach to the interface, or worried about being restricted by it. Taking the time to go through the tutorials will quickly ease those fears, as the depth of the program will soon become apparent. ZBrush excels as a game development tool not only for object creation, but for creation of textures, backgrounds, and GUI elements as well. In regards to my experiment with creating sprites, overall I was satisfied and as I learn more about ZScript, I’m sure that my workflow will greatly benefit from ZBrush. Initially, I was intrigued by the power of the modeler for its organic capabilities, however the power of ZBrush lies in its ability to seamlessly integrate its many tools into a very creative 2D and 3D package. In short it focuses technologies from 3D texturing and sculpting packages like Amorphium, Painter3D and BodyPaint into a cleverly designed close-knit system. Because ZBrush ties all these basic functions of 3D modeling together, along with some of its own cool features, it could be used on its own to create models for 2D or 3D games. If you’re writing games on a tight budget, it’s a really good investment as a primary modeler, and if you’re a large game studio then it’s worth buying specifically for its creative possibilities.

• Version: 1.23b
• Category: 3D Painting Application
• Developer: Pixologic
• Url: www.pixologic.com
• MSRP: $ 585.00

image1.jpg
alt=”AirBurst”

Originally, Airburst was going to be a simple Warlords type game (with flying cities/castles that move about when hit) that we would write over a couple of weekends under the same Strangeware license ($3 released fully featured) as Bushfire was. This was the point where Adam had a vision of cute and colorful characters with balloons rather than bricks and the design jumped up a level into a full Strange Flavour project.

The new plan would involve Airburst being written over a period of three months. Because we wanted to write a good, solid single-machine multi-player game first, and I knew that network code would add a lot of time to the project, we decided to write the single machine game initially and then write a standard network module that would give Airburst network capability and could also be reused for future network games later.
h3. The Team and the Tools
Adam and I work in a simple team set-up: Adam handles the graphics, visual design, sound effects and music, while I deal with the coding and game design. As resident egomaniac I also handle the project management. We were fortunate with Airburst in that the normal team was boosted by some excellent volunteer testers—Thomas “Hero” Bedeau, who helped us solve a particularly tricky bug in Bushfire, and an old friend, James Rhodes, who we knew from the days when we were writing Amiga games. James’ fiance Sophia also volunteered her testing skills, which proved invaluable. One thing my years of writing games have taught me is that having testers who know what they are doing and what they should and should not bother reporting can double the effectiveness of your team.

image2.jpg
alt=”AirBurst”

Our set-up is not particularly spectacular. I do my coding on a G4 Cube with CodeWarrior and test (and sometimes code when I am feeling like a change of scenery) on my iBook 300. This is actually my main development machine for my day job as well. Adam’s G4 500 MP is dual purpose, handling graphics and sound tasks.
h3. The Creative Process
When I wrote the engine for Bushfire, it was planned from day one to be the basis for future projects, so we were able to start with the basic sprites, sound and movie engine that were already done from that game. Having started and abandoned a couple of Mac shareware games in the past due to lack of time, and struggling to bend an otherwise excellent Mac game library to work the way I wanted, I gave in and decided that I’d have to write my own. The main work on the library was completed over a period of about two weeks, by which time it was ready to handle the basics of Bushfire. Apart from a faster blit function I added in later, the engine mostly uses CopyBits for the sprites; my scrolling tutorial on iDevGames actually uses the declassified version of it. The main theory behind the engine, though, was to give me a basic set of functions around which I could write a game, without having to re-work the game to suit the engine too much. Once I have a working game, I always copy the project and strip it to a skeleton to use as the basis for the next title. With a working engine and the shell from the previous game Bushfire, I was able to get the basic concept of Airburst up and playable over a weekend. It’s really important to be able to prototype and test a game idea this way, as it gives you confidence in the design and immediate feedback as to what does and doesn’t work. I used my normal method of working on both my Mac and an ordinary hard backed notebook. I also used AppleWorks (the world’s most useful application!) to write a small bug database/completion list, although I normally do these on paper as it’s more visual.

Click to Enlarge
Notebook1.jpg
Notebook1p.jpg

BCM1.jpg
BCM1p.jpga

Maya1.jpg
Maya1p.jpg
Characters1.jpg
Characters1p.jpg

Adam had the hard job on Airburst, as his idea of writing the game as a full project with full character designs and maximum eye candy meant that he’d be doing a lot of graphics, not to mention the sound and music. We have a major advantage here in that (a) we’ve worked together as a team now for nearly 15 years, so there is less time wasted due to miscommunication of ideas, and (b) I’m pretty good at coder art, so I can do any rough artwork needed to get the game running and give Adam an idea of what we need for a particular sprite, while he gets on with the proper version. This approach also works as an incentive for Adam to replace the coder art with real graphics as fast as possible. For most of the sprites, Adam models and renders them in Cinema 4D. They are then rendered down to individual sprites that contain 64 rotations for each of the player characters and their heads. Adam also renders out Alpha masks for each sprite. These sprites are then munged together to create a screen for each group, plus a matching mask screen. Post-design work is done in Adobe Photoshop before the screens are saved out as PICT Resource files and copied into the Airburst resource file.

Knowing that Adam would be spending a lot of time on graphics for Airburst, we planned to use a more minimalist system for this game. So the music was written as 13 different 2-bar loops, varying in intensity from very calm to manic. The game would then work out how manic things were and pick the next loop accordingly. For example, the number of balls and what power-ups are in play. A couple of menu introduction and Win/Lose sequences were also required. Adam’s production method varies depending upon the project, but basically it involves writing the tracks initially using Logic Audio, with the ProTools Digi001 rig to output the final mix (which is then converted to MP3 for the game). The sound effects for Airburst made use of Adam’s Virus KB synth as well as various sample library sounds. Again, these were processed through Logic Audio and ProTools before being converted to sound resources by exporting them from QuickTime Pro.

image3.jpg
alt=”AirBurst”
h3. What Went Right
Thanks to the engine being written around the way I work, it was incorporated flawlessly into Airburst and we had the basic game running in the first weekend with coder art (a very unfairly maligned school of art). By sticking to very simple formats and utilizing a fairly rigid initial design, the art and sound slotted quickly into the game. The game logic was built up in a similar fashion and did not create too many hitches. Thanks to effective testing, the majority of bugs were squashed before release.

The main thing that did go right, and I’d attribute it mainly to being able to get the idea working as fast as possible, was the game design itself. Having originally planned to take the basic idea of Warlords (four players trying to destroy each other with a fireball) and adding our twist to it (being able to rotate the bat all the way around and making the players move around the screen as they get hit), we were able to get the basic game running in a weekend. This gave us plenty of time to work on a bonus system, which was set in stone quite early on. We’ve had great fun in designing different game types and we plan to release more in the future. Thomas suggested a “Story” mode, however this would have taken a great deal of time to implement due to the required game assets. Our testers were also a major component in the success of the project. New versions of the game would be emailed out to them on Saturday and Sunday and we’d have feedback either immediately or the next day (one in France and two in the US). The testers weren’t afraid of suggesting ideas too. Fortunately, with Thomas being a budding games journalist and James and Sophia writing games themselves, the suggestions were usually realistic and practical.

image4.jpg
alt=”AirBurst”
h3. What Went Wrong
We had a few problems with the in-game music. As with Bushfire, we were using MP3 tracks but this time we planned to use short loops and generate the music on the fly by triggering different loops depending upon the level of gameplay “manic-ness” at a given time. We had quite a few problems with the callback routines that were required and this caused the project to slip by a couple of weekends. One of the initial design decisions was to make the game 800×600 to use the full resolution of the iBook (this was just before the iBook 500 came out with its 1024×768 native resolution). Unfortunately, it was only well into development (i.e. too late to change all the graphics) that we realized that Mac OS X was just not sufficiently fast at 2D to handle 800×600 quickly enough. In theory, Mac OS X 10.1 should cure this and, since our main market is still Mac OS 9, we decided to stick with it. Having received feedback from players, it has also come to light that there are a few monitors out there that don’t have a 800×600 mode. So for the first update of Airburst we added a “compatibility mode” that lets the game be played at a higher screen resolution (for future game designs, we will probably avoid using 800×600 as a primary mode).

One area that I plan to revisit on Airburst and that has been the subject of much discussion in iDevGames’ forum is the Options/Key setup screen. This was a bit too hurried in its design, and with Mouse Control (added after requests from users who have difficulty using the keyboard) and Bat speed added to it it is definitely too cluttered and awkward to use. So I’ll be doing a new page (or two) here in the next update of the game.
h3. Wrap Up
Fortunately, the careful planning at the start of the project paid off and we were able to concentrate on the game itself rather than solving basic design and code problems. The game was released on the same day as Steve Jobs’ keynote at MacWorld New York (to catch the large number of web viewers anxiously scanning websites for news), although because of the slippage we were not able to get all of the extra bits and pieces (player skins, extra backgrounds, desktop pics, etc.) onto the website for the launch. So far, user and press reviews have been very good and registration is going according to plan.

* Genre: Arcade
* Developer: Strange Flavor
* Site: www.strangeflavour.com
* Team size: 2
* Released date: July 18, 2001
* Project length: 3 months
* Development hardware: G4 Cube, iBook 300, G4 500MP
* Critical applications: CodeWarrior, Cinema 4D, Logic Platinum with ProTools Digi001 studio

airburst,strange,flavour