iDevGames

Another interesting thing to note is that my target audience for Pirate Isle was much younger than those I normally develop for. One goal for Pirate Isle was that it would be fun and appropriate for gamers of all ages, and this resulted in a number of technical and game design considerations. I tried to keep the number of individual controls down to a minimum (the gamer only has four buttons to control Slash fully: left, right, jump, action) and the default configuration is set up so that two children can control Slash at once.

Not only did I choose a different target audience and genre of game to make, I also decided to explore different technologies with which to make the game. The entirety of Adventures on Pirate Isle is defined in a number of XML files which are then interpreted by the executable to display the game, much like how your web browser interpreted the HTML of this document in order to render this web page. The engine I created for Pirate Isle utilizes XML to provide structure and easy parsing of the game objects, but without some kind of scripting language it is nothing more than a file format to store definitions. For the brains behind the brawn, Pirate Isle uses Lua.

Yo ho ho, and a bottle of rum!

pirate_isle_2.jpg

Slash against the octopus

I found Lua to be simple to incorporate, easy to learn, and quite powerful in its own right. I had no experience with scripting languages before writing Pirate Isle, so the first thing I did was research the various languages. As normally happens, this particular topic of discussion had already been flushed out on the iDevGames forum. What excited me about Lua as opposed to the other scripting languages is its small footprint. Incorporating Lua into my project was a snap, and it handled running on Mac OS 9, Mac OS X, and Windows beautifully. Lua is also a simple, easy to read language, perfect for allowing interested parties to modify the game to their liking.

Even though Lua is as cool as it is, it is still an interpreted language. This means it lacks what games need most often, performance. My initial tests with Lua showed that it was too slow and cumbersome to have it handle every aspect of the game (such as storing and rendering the sprites). After some more tweaking and brainstorming, I ended up with what is best compared to a car and its driver. The car in this case is an OpenGL engine written in C—clean, fast, quick to respond and handles all the brunt work of going from here to there. Lua then fulfilled the role of the driver. Lua tells the car where and when to go, but leaves the specifics of how the car travels along the road and bounces against the rocks to the car. This approach improved performance dramatically.

That’s great, but now that Lua has been “demoted” to just being the driver I ran into another problem. How should all these scripts be structured, and what API needed to be developed in order to place the least amount of burden on the scripting language?

Hello XML

Using XML allowed me to define separate sprite objects, each with its own initialization, update, and event Lua scripts for unlimited customization. Once this was in place, I had a quick and easy framework for adding new, unique sprites to the game. This was also extremely useful for quick prototyping of new sprite animations, as well as doing quick fixes since modifications to the script did not require a recompile, and in many instances didn’t even require the game to be reloaded!

Avast ye ZBrushers!

pirate_isle_zbrush.jpg

ZBrush in action

I found out quite quickly that making a platformer is hard. I enjoy switching between genres when choosing games to make, and I must admit that the amount of work it takes to make a decent platformer is far beyond what I originally anticipated. If the sheer number of assets were not daunting enough, the intricacies of level design and the pressure to balance it just right are enormous. When I first developed the idea for Pirate Isle, my thoughts were to use pixel art in order to recapture some of the “retro” gaming experience. An example of this can be seen in the first color version of Slash in the image at the top of this postmortem. However, after about two weeks of some serious sprite creation and animation framing, I realized that at my current rate of graphic creation I would never make the deadline in time. Also, my pixel renditions of Slash didn’t have the “cute and cuddly” feeling that I was going for (as my lovely wife so pragmatically put it the pixel version looks like a “drowned rat”).

It was too late in the contest by this time to redo many of the hand-crafted game items I had already made, and Steve was already working on some hand-drawn enemy sprites, so I was forced to make some tough decisions. I settled on using the hand drawn objects I had already created (for instance, the fruit power ups, the tombstones, etc) and the hand drawn sprites Steve was making, and I would use a rendering package to create the backgrounds. In steps ZBrush!

ZBrush has got to be the finest character creation tool I’ve used yet (beating out such packages as Carrara Studio, for example). My good luck in the 2002 uDevGames Contest nabbed me a copy of ZBrush, and utilizing it for Pirate Isle helped give the game some character. I used ZBrush when creating the “tiki” statues, the jackal statue at the end of each level, and the “big-boss” octopus at the end of the sixth level. Using ZBrush for this purpose was incredibly simple and an enormous time saver. ZBrush allows you to start with a simple geometric object (I used a sphere when creating the octopus and a cylinder when creating the tiki statues) or you can use their unique modeling technique known as ZSpheres (ZSpheres are the 3D modeler’s equivalent of the little 2D mannequin most artists use to get proportions and posture right. I used ZSpheres when creating the jackal statue). Once you have your basic object, you can then mold and sculpt that object in a very intuitive manner, allowing for the creation of eyes, nose, mouth, and other facial characteristics in a matter of minutes.

In the end, the mixed-and-matched nature of Pirate Isles graphics hurt it more than helped. Poor planning in the beginning and my underestimation of the amount of art work required to make a good platformer caused Pirate Isle to suffer more than it should have. The experience was not a waste however, since I had a blast learning how to create “pixel art,” as well as spending more time with ZBrush.

Clear sailing ahead!

pirate_isle_3.jpg

Game Map Screen

Building upon past experience

Although the uDevGames Contests are only three short months long, I always try hard to make sure I code with an eye for the future. In some cases this “future planning” results in some wasted time, but in all too many cases it results in saving even more time. Adventures on Pirate Isle uses the same engine code that I wrote for The Belt last year, and it is even an evolution of the base code I wrote for Imp Fodder in the very first uDevGames Contest. Reusing this code allowed me not to worry about the average stuff such as how to open a window, or take over the fullscreen properly, or develop an architecture for my animation…you get the picture.

Utilizing a Scripting Language

We’ll be revisiting scripting languages in the “What went wrong” stuff below, but using a scripting language had many advantages. It allowed for quick bug changes, provided for much more stable code (when there is a problem with a script it simply displays an error and doesn’t crash the entire program), and it allows for artists and gamers to easily modify the game to their liking. All in all using Lua saved me both time and effort.

Non-tile Based, Polygonal Collision Detection

Although this may be a little noticed feature, Pirate Isle was not based on tile like most traditional platformers. All of the objects in Pirate Isle could be an arbitrary size, and all of them could have an arbitrary polygon as their collision boundary. This allowed for Pirate Isle to develop a non-tiled, more natural look, although the added complexity in the collision detection routines required some last minute fine-tuning for it to work on older computers.

An Enthusiastic Musician

Dori Eggan is the wife of a relatively new friend of mine, Nate. Dori and Nate both came from my home state of Ohio, and Dori happens to have started a career as an educator in music. I approached her to see if she would be interested in experimenting in the world of game music, and I found she was quite enthusiastic about creating some original content for Pirate Isle. This panned out well, considering this was her first foray into the digital music realm and Pirate Isle scored sixth in the Sound and Music category. I sure next year she’ll be bursting with ideas and pent up talent, so watch out!

A Cool Artist

While I did 95% of the artwork for Pirate Isle, all of the creative genius which provided for the enemy sprites came from Steven. For his day job Steve does the cool art for many of Freeverse’s titles, but sometimes drawing monkeys for a living can get repetitive. When Steve let me know he’d be interested in redrawing a few sprites for Pirate Isle I was ecstatic, and would have been a fool to say no to such a talented artist. The various enemies Slash encounters are one of my favorite parts of the game, and thanks to Steve they didn’t disappoint!

Good Vocal Talent

Finding vocal talent for a game is challenging, especially for a freeware title being developed in under three months! So when the time came to create voice-overs for Slash my wife and I both sat down and recorded our voices. Needless to say her voice-overs were an order of magnitude better than mine, and thanks to her Slash has a voice instead of just little text bubbles. Some extra work could have gone into the sound processing of the vocals (to help reduce some of the static and such), but all in all I was pleased with the results.

Anyone want a peanut?

pirate_isle_4.jpg

Battleboard Screen

Interpreted Languages are Slow

Here is where we admit that scripting languages have their faults. First and foremost is performance. Lua is also deficient in that it does not have a C API for separate compilation and later loading of these pre-compiled chunks. Now, before I get a ton of emails saying that luac can input a Lua script and output the compiled version, note that this is not what is needed in this instance. The whole point of XML encapsulated Lua code is that it becomes simple for gamers to modify the game. This means that pre-compilation or running the scripts through a conversion tool is not ideal. What I really needed was a lua_compilestring() and lua_runcompiledstring(), but even after digging into the Lua library code myself I was unable figure out a good way of doing this. In the end, I was able to simulate pre-compilation by having my C code encapsulate all of the scripts in their own unique function. This reduced my script compilations from 60-200 lines of code to a single line of code. This managed to get the game to run well on 400MHz machines.

Lack of Audio Input

When my powerbook died late last year, I was forced to upgrade to a “Windtunnel” G4. This was nice development-wise, but one small speed-bump is that regular old microphones don’t work with this computer. I’m no audiophile, but apparently you need a special kind of microphone that I didn’t have the money for in order to use the audio input jack. I ended up borrowing my mother’s DV camera and recorded sounds and voice that way, but this turned out to be incredibly cumbersome. My disappointment in spending a little over $2,000 for a new computer and not being able to use a regular old microphone was profound.

HID Manager Woes

HID manager is actually a simple API to use. In a few days I developed a nice wrapper for it, had it integrated into my game, and was running Slash around with my little Gravis Gamepad. Unfortunately, it was something as simple as keyboard input that seemed to give HID manager all kinds of trouble. Yes, I understand all keyboards are evil since keyboard rollover is in their hardware, but for some odd reason HID manager itself was missing some key combinations which regular Carbon events were getting fine. My particular example is with the arrow keys. When I was gathering events with Carbon events, using the left, right, and up arrow keys in conjunction with the space bar worked flawlessly. When I switched to HID manager only, this key combination no longer worked. So although keyboard rollover still effects the Carbon events code, there must be some other bug in HID manager which caused that oddity in behavior. In the end I used a hybrid system of Carbon events for keyboard and HID manager for other input, and that seemed to work best.

Limited by the Design

As I mentioned earlier, I underestimated the amount of work that a platformer needs. My original plan for Pirate Isle was to release the uDevGames version with three separate worlds having different scenery and enemies, and each world with 5-7 individual levels. As you can see, I only got one world with six levels completed, and by then there was not enough time left to consider making an entire new world.

Hoist Anchor!

This year for uDevGames I wanted to explore new areas of game development, experiment with different art techniques, and ultimately just have a fun time creating a game that children of all ages could play with their parents. It is doubly satisfying hearing from others that “the sugar glider hero is very cool” or that “Slash is so cute,” because coming up with a good hero character and portraying that character well to the audience is probably the hardest thing to do in any medium, be it movies, literature, or games. Although my willingness to explore new areas resulted in somewhat of a “melting pot” of graphical styles, I had fun doing it and feel that I’ve gained much from the experience.

• Genre: Platformer
• Developer: Rocco Bowling
• Url: http://homepage.mac.com/felinegames/
• Team size: 1
• Released date: June 20, 2003
• Project length: 3 months

• Development hardware: “Wind Tunnel” PowerMac G4

I began to produce Raptor to educate myself. I wanted to learn everything there was to know about TNT Basic, a new IDE I had purchased. As a result, I designed Raptor to take advantage of nearly every technical aspect of TNT, including the special sprite functions, music, sound effects with stereo panning, and more. Patrick Graham and Miyaka Cochrane joined the team when they realized how cool Raptor could be. As Raptor grew and reached many people, its final purpose has served to help us gain recognition and to entertain people.

The Team

The Raptor team, Constant Variable, was formed out of a group of friends. Patrick Graham, being a close friend of mine, has always been eager to help in anything I do. Patrick ended up designing the latter levels when I was too burnt out to continue on. Miyaka Cochrane, whom I met through Patrick, loves the genre of top-down scrollers so he was eager to volunteer his music skills. After the first few weeks of development, when things got more serious, we started having meetings over at my place.

The meetings were an interesting experience in cooperation. We sat at a circular table, each of us at our respective computer. I would work at my PowerBook G4 667MHz. Miyaka worked at his PowerBook G4 as well. Miyaka’s PowerBook is adorned with a bumper sticker that reads “Not all who wander are lost,” which reflects his personality well. He would work while a constant stream of music pumped out of his heavy duty headphones. Patrick would work on our old iMac, learning a bit about programming, making levels, and every so often checking out what I was doing. Being physically together helped with the motivation factor in getting things going. In a single meeting we might have been able to pump out one music track, one level, and one or two new types of enemies.

The Tools

During the process of developing Raptor we used a lot of software tools. For example, when producing an enemy, I might start by designing it in Macromedia Flash 4. I used this because I had no other vector drawing programs. Once I finished drawing, I would take a screenshot, open that in Adobe Photoshop and format the graphic, as well as add special effects like dodging and burning to give depth. I would also use Photoshop for the image mask. Map tiles were first made in Bryce 4, then formatted in Adobe Photoshop. Interfaces and backgrounds were done completely in Photoshop. Miyaka’s music was done in Ableton Live. All this, as well as the code, was then put together in TNT Basic.

TNT Basic is an excellent program for beginners as well as more advanced programmers who just want to create a game at a faster rate. For Raptor, it acted as the central hub, managing code, sounds, music, and map files. Its integrated map editor was a joy to use. Using it we could easily place map tiles, and map objects. Map objects could then be read through a simple bit of code which could then spawn enemies at the coordinates they would be on the map. In general, TNT Basic is very easy to use, and there are lots of well-documented examples on TNT Basic ‘s web site. This, combined with an easy to reference user manual, makes TNT Basic a formidable choice for rapid game development.

What Went Right

In the production of Raptor, we had all the right software. Using TNT Basic allowed for rapid development; its map editor suited our purposes perfectly. Adobe Photoshop also worked well, especially for compressing the graphics to comply with the contest’s 10MB imposed limit on file size. We also had access to the professional music software Ableton Live, which Miyaka was able to use very well to create music that fit the mood of the game.

Having someone besides me do the music was a real plus. Not only did it free me up to do what I really do, it also allowed for music much better than I could have found in some copyright free database. We’ve gotten a very positive reaction regarding the music.

Another positive reaction came from the fact that Raptor is freeware. I would suggest to anyone who isn’t going to make much money off of a shareware game to just avoid the whole hassle of setting up registration and release it for free. Keep in mind that people appreciate things that are free. People will rate things higher if they are free. People will send you fan e-mails if you give them a product for free.

Finally, distributing Raptor over the internet was a great experience. Submitting it to sites like Version Tracker, Mac Update, and Mac Game Files made it easy to put our game in the hands of tens of thousands of people. This instant and wide user base, which wouldn’t have been possible in the days of floppy disks, resulted in a ton of feedback. It also gave us our first fan mail. Of course for every fan e-mail we got, there were around two or three reporting bugs.

What Went Wrong

Not much went wrong with Raptor except that it suffered from an identity crisis. I had originally programmed Raptor just to teach myself TNT Basic. I didn’t know when I was just beginning the amount of time I would eventually spend on it. Therefore, I never took the time to create a design document for Raptor. In the beginning I never even asked myself what I set out to do. I just sat down and programmed.

My approach to making Raptor followed a pattern something like this: I would ask myself, “I wonder if I could program a scrolling landscape made from map tiles.” Then I’d do it. Then I’d say to myself, “That’s pretty cool, I wonder if I could add a plane that flies around.” Then, of course, I’d do that. Afterwards, being very proud, I’d ask myself if I could program a map object of a cloud and have it be read from the map file into the spawning code. The process would continue for a long time. Since I didn’t even know what what I was programming would become, there was no chance of me producing a design document.

Although it is true that sometimes games never get off the ground due to too much planning and not enough doing, Raptor suffered from the opposite. Raptor soared like an eagle unsure of its direction. I think that if I had planned by giving Raptor a plot-line, an original setting, or an original objective, it would have stood out more from the long line of scrolling games that had preceded it.

Conclusion

Raptor is my first entry to the uDevGames Contest, and my first contribution to the Macintosh gaming community. I value the uDevGames Contest because it offers incentive to develop in the form of prizes, and, more importantly for someone making shareware, it offers a deadline! A wise man once said that games are never finished, you just stop working on them. If not for the time frame set by the contest, Raptor’s development might have gone on indefinitely, and thus it would never be finished. Thankfully it’s done, and now I can look on to the future.

I’m currently learning OpenGL use that in the future to create state-of-the-art 3D games. With the prizes I’m getting out of the uDevGames Contest, I hope to be able to export the 3D models I create into a format in which a function in my future game could load. It’s going to be a long haul, but this isn’t the last you’ve heard from Constant Variable!

• Size: 9.7 MB
• Genre: 2D Shooter
• Developer: Constant Variable
• Url: http://solidmag.vze.com/raptor/
• Team size: 3
• Released date: November 17, 2002
• Project length: 3 months
• Development hardware: Two PowerBook G4s, iMac 333MHz

• Critical applications: TNT Basic, Adobe Photoshop, Bryce 5 Ableton Live