Apple has now posted on their website a very helpful web-page assisting coders to move from the aging (and soon to be obsolete) CodeWarrior to Apple’s very own Xcode. While die hard CodeWarrior users may find this a smack in the face, and possibly offensive, the rest of the user base may find this eases their switch. Viva La Xcode.
However, we did not use CodeWarrior to build the game itself. We are using it to develop both the Mac OS X and Windows versions of the iGame3D plugin and the Windows version of the iGame3D Player.
The source code for the Mac OS X version of the iGame3D Player was done in XCode. The Dead Days application is a special version of our iGame3D Player. This needs some explanation: games in the iGame3D engine are actually written in our custom scripting language inside the Runtime Revolution environment with the plugin. The iGame3D Player application can run these games. Just copy the game files into the player application package and the game is done. It would have been enough to just release the game code (written in our cryptic scripting language) since that’s what actually makes up the game, but it wouldn’t be very useful to anyone. So we decided to release the source code of the player application itself! The source code for Dead Days is nearly the same as the original iGame3D Player source code. It has some little changes for licensing reasons. Check out the ReadMe that comes with the source code for more information about this.
The simple text editor that comes with Mac OS X was used to create the ReadMe files for the game and the source code. Smultron was used for text operations like “Find and replace” on the game scripts.
h4. Game Assets
We used Sound Studio to record and edit the zombie growls and screams. By the way, those have been pitched down, these are not our natural voices. The background music for the training level was played on a keyboard and recorded with Sound Studio. The sounds came in through an eMac’s built-in microphone. We edited some royalty-free sound effects from the web in Sound Studio as well, like the gun shot and the punch.
We made the background music tracks, except for the one in the training level, in Apple’s GarageBand using some of the built-in loops and our own melodies. QuickTime Pro was used to convert the sounds into an AIFF format that Ogg Drop X could handle correctly. iTunes was used to convert the music to MP3. To compress the huge AIFF audio files into the OGG Vorbis format we used Ogg Drop X.
GraphicConverter was used to convert images into the PNG format. We also created the alpha channels for some images in it. We used Photoshop to do lots of the textures, and images. We used Cinema 4D to reduce the number of polys on the zombie model. The original zombie model was created a year ago in Lightwave by the multi-talented Charles Goran.
h3. Tripping up in the Valley of Shadow
Obviously entering the contest only a few days before the deadline made the process a real rush. We did not have time to test the game on many machines so there was some bug-fixing during the public voting period. There were also issues with the camera that we did not notice until players brought the problem to our attention.
We mistakenly assumed that Mac OS X 10.3 “Panther” was already the standard Mac operating system, especially with the OpenGL updates and bug fixes that shipped with it last summer. Almost immediately after releasing the game we received requests from people who wanted to play “Dead Days” on Mac OS X 10.2.x. After some re-coding and testing about two days into the voting period the game was built to be compatible with Mac OS X 10.2.x.
The newer version of “Dead Days” also had trouble for nearly the whole voting period due to an issue of using the .sit archive format. Certain versions of the StuffIt Expander corrupted the application package on some gamers’ machines, causing it not to run at all. With six days of the public voting left we released the game again using Panther’s .zip format which seemed to fix the startup issues.
Getting adequate feedback was almost as tough as making the game itself. We had about a thousand downloads before the first complaint came in and about three thousand downloads before we received feedback that actually pointed us in a possible direction to fixing the problem.
In the tunnel vision rush to make a playable game some of the essential non-game elements get overlooked. We did not expect the public to go looking for an “Options” screen to change the keyboard settings, screen resolution and mouse sensitivity. We also didn’t think they would skip the training level and proceed to mash every key on the keyboard trying to figure out the game. These instances revealed a missing link in our engine that we surely need to work on. Our custom scripting language allows us to check the state of specified keys, but changing these keys would require a change in the script files which are neatly hidden inside the application bundle. An easier way to configure the keyboard controls and changing the screen resolution in the game is now high on the to-do list.
The current iGame3D editor, which is still in production, has not been tested to see if it could efficiently make a game from the ground up. Several bugs or cumbersome user interface actions in the editor also cost us some time in the rush to complete the game.
h3. Return of The Living Dev
The eight to nine days and nights that “Dead Days” was in development, Tobi finally had absolutely no other obligations to tend to. Life was reduced to game development, food and a little bit of sleep. Bill managed to tear himself away from iGame3D development, survive each day of child care and pull through the graveyard shift until dawn to edit the levels and add textures.
The goal of iGame3D finally proved itself for us, we didn’t have to start coding from scratch. For “Dead Days” the only C coding neccessary was the fixing of bugs that the development of this game revealed in the iGame3D engine. With very few quick fixes to the source we were then allowed to concentrate on the creation of the actual content and gameplay.
We benefit from the fact that we have already been working together on iGame3D and related projects for nearly three years. We are well aware of each other’s abilities and use this knowledge to efficiently delegate responsibilities, to prevent production pipeline bottlenecks.
Because of different time zones, it is common that we meet up on the internet and discuss plans, changes, and production just before one of us passes out. Although some problems arise from this, for “Dead Days” it acted to our advantange in that when either of us woke up there were always cool new textures, levels, models, and music to check out. The iGame3D Team worked like a twenty-four hour assembly line.
The process of creating a game was an intense test for the iGame3D engine and its user interface. The process revealed some bugs and showed us which parts are functioning well already and which parts still need work.
h3. Reflections in the Wisdom Pool
It was an honor to have taken part in this unique contest. Once again uDevGames openly challenged us to create and release a game to the Macintosh gaming community. It’s great to have uDevGames as an annual event and we hope that it continues successfully for many years. In our opinion, everyone who was able to create a game in this 3 months is a winner. After this contest the team will continue their work on the iGame3D engine and application. The success of this year’s entry is a confirmation for us that iGame3D is going to succeed and sets our expectations that much higher for what comes next.
h3. Le culte des Ghoules
h4. Tobias Opfermann
This 20 year old German programmer started towards a career in game development when he began to create his first applications with the card-based programming environment Hypercard in 1996. With that he produced a tool for the Mac Game “Damage Incorporated” (Marathon engine) that helped in making levels, which in turn was used to produce a custom add-on scenario called “Year of the Tiger” in 1999, together with other fans of Damage Incorporated.
After this, the C language in CodeWarrior 5 was where he experimented with very simple database programming and later a freeware OpenTransport chat application called “P.I.N.C.”
Using REALbasic he introduced the world to the “Oni Savegame Editor” in 2000. This program was widely used among Oni game fans, gained a feature story on the German TV station NBC Giga, and continues to receive positive feeback from Oni players four years later.
h4. “GL Thrill”
After the migration to Mac OS X in early 2001 he entered his first game into that year’s uDevGames contest. The contest provided a challenging call to step up his experience of game development and he found much to learn at the iDevGames forum. Stepping ahead of his background in HyperCard, MetaCard and RealBasic, Tobi’s 3D first person shooter, “GL Thrill,” placed eighth in that year’s contest using C and OpenGL.
In 2004 Tobi graduated high school and has since split his time giving back to his community, both at his employment in a care home and with his personal dedication to the iGame3D project.
h4. William Griffin
What smells like New Jersey and makes games? You have to a sense of humor if you are going to make games with Bill Griffin. This 34-year-old New Jersey father of one quotes himself as saying, “Writing about myself in the third person is freaky.” That’s the kind of guy he is.
After a combination of 13 years toiling in the graphic arts, entertainment, video and tech support industries, Bill came to the conclusion that he had taken his two years of community college as far as it seemed likely to go. Those years of clocking infinite over-time gave him the opportunity to attend the annual design technologies exhibition SIGGRAPH on three occassions and to take two excursions to E3, the annual Electronic Entertainment Expo, looking for a door into the world of game design.
Bill recalls one of these high tech events with an embarassed grin, “I spilled beer all over my pants at the Apple/Newtek boat party, damn!” The 2001 E3 event, however, is especially remembered for a very encouraging conversation with an important games marketing manager from a big name company that left Bill Griffin convinced that it was time to put away the old things and to take up his lifelong goal of being a game developer.
h3. Team iGame3D
In early 2002 Tobi posted a demo of the game engine he was producing with the skills he had cultivated while making “GL Thrill.” Bill responded to this by offering his willingness to take on whatever non-programming job was necessary to make a game happen in this engine, and a game design team was born.
That spring and summer they used the engine to create a level builder and player called “T3DEdit.” Thirty-five custom scripting commands that were needed to produce a first person strategic target shooter with exploding ants were added to the engine during the uDevGames 2002 three month development cycle.
With most of their time focused on creating a tool that would continue to be relevant in the future, attention afforded to the absolute needs of making an amazing game capable of winning the contest was sacrificed and their entry “Antack” placed sixteenth in a very competitive uDevgames that year. Much to their surprise “Antack” would attract over eighty thousand people to download the game within the next twelve months.
By the time that winter came to a close, Bill had used the “T3DEdit” application that was created for making Antack to explore several dozen directions of the engine’s abilities. First Antack evolved into a space combat simulation, then there was a castle building routine, which was followed by testing a 3D clone of the Tank level in the 1984 game TRON, there was a vampire rampage, a famous space tunnel run screen saver, the iGame3D dancing groupie screen saver, a test for tic tac toe, another for pong, a coin platformer example, survival horror concept, a ‘shoot down the 3D flying saucers’ design tutorial and an early concept for a racing game. These were among dozens of test levels that came out of the early editor.
The code and knowledge gained from making “Antack” was taken to the next logical step feature after feature to build the foundation for the 3D OpenGL game design environment that is now “iGame3D.”
Spring of 2003 brought that name change, removal of some parts of the scripting language, and a switch to Metacard, a powerful card-based development environment which finally gave Bill the ability to turn his ideas for iGame3D into living tools. Summer brought the last sad Macworld to Manhattan, where by pure luck Bill met Kevin Miller, President/Owner of Runtime Revolution, the company that had just acquired Metacard a week or two earlier. With iBook in hand and the very limited alpha version of iGame3D, Bill gave his first software engineering demonstration to a corporate executive.
Bill confesses, “It was ugly as sin, it had bugs, and I was having the time of my life making it.” Purchasing a Revolution license meant being free of the 10 line restrictions limiting the first Metacard Demo-based version of iGame3D. Bill set himself to the task of learning the transcript language by jumping head first into creating a full featured interface for a complex application based on external engine programming by Tobias Opfermann, that listed support for particles, several standard 3D formats for import and export, polygon drawing tools and commands, an expansion from an original 35 to 125 script commands, and a screen saver stand-alone, among its many abilities.
For the length of uDevgames 2003 Bill was lounging around the iDevGames internet chat room, between moments of developer inspiration and burn out, and found that sharing the creative process on an up-to-the-minute basis with nearly two dozen game developers was much less stressful and much more educational than focusing all his attentions on one game in the competition against them. At the end of that year’s contest Bill was the proud interface programmer of a fully operational iGame3D beta version with nine demo levels to present to the world.
Then Tobi sent him a barely functional example of a new version of the application with the plan: “Let’s make a new interface, one that is so easy people don’t need to read any documentation.”
A year later finds the team working on their sixth user interface revision for iGame3D, which has taken bold steps away from its dependance on using models from Meshwork and is now hosting its very own 3D format with self-contained animations, material shader properties, and bones, as well as other tricks up its file structure. Their 3D third person action adventure game “Dead Days” showcases the abilities of the new models along with improved OpenGL lighting, the addition of particle effects, and the effectiveness of the 3D modeler built into the engine. The team hopes that a version of iGame3D suitable for general public use will be ready at the end of Winter.
* Runtime Revolution with iGame3D Pro external
* Metrowerks CodeWarrior 8
* Apple Xcode 1.2
* Sound Studio 2.1.1
* Apple GarageBand
* Apple QuickTime 6
* Apple iTunes
* Ogg Drop X
* Apple TextEdit
* GraphicConverter
* PhotoShop
* Cinema 4D
* Smultron
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.
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.
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.
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.
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.
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 8 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.
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.
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
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!”
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.
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.
blackshades05.gif
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.
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.
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.
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.
My development tool of choice is Metrowerks’ CodeWarrior 5.0. I noticed that Metrowerks was a sponsor of uDevGames so I crossed my fingers that I could win and get my hands on the latest version. For working on 3D models, Joe Strout’s Meshwork can’t be beat. It is great at creating optimized models and includes many features. Joe is also always improving Meshwork so if you are not familiar with it, take a look. Textures and other eye-candy were of course created in industry-standard Photoshop. Don Murta’s GLSee was also very helpful in converting the 3DMF files into OpenGL code. Long time Mac-first developer Pangea Software tools were also used: 3DMF Optimizer and 3DMF Mapper. The machine gun model was designed by David Drew and the sword texture was provided by Elizabeth Lim.
image2.jpg” alt=“GL Fighters”
The first version that I started was completely on the wrong track; I had been making every pose in Infini-D and then exporting it as a 3DMF, running it through 3DMF Optimizer and then loading it up in GLSee (which converted the 3DMF model into the C code) for drawing it, and had then copied that code into a function in my game. This was far too time consuming and pointless, and resulted in low-poly models that moved jerkily. Sometimes, developers need to look at the process and decide when the development needs to be turned on its head. It was a wise decision to change my workflow early on so that the game could be submitted on time.
I was used to making animations in Infini-D by defining key frames for various points in time, which the program moved smoothly between, so I designed my character animator on that principle. There is a separate model for every body part, and each of these body parts smoothly rotates to each pre-defined animation frame. Utilizing my own animation program instead of a third-party tool allowed me to easily add in the features I needed. After spending lots of time tweaking all the animations they ended looking like I wanted them to.
There is a computer lab at my school (all Macs of course) with a variety of modern computers, and a lot of interested classmates who were more than happy to have an excuse to play computer games between classes. This was very convenient for beta testing because the testers tried a lot of silly things that I would never have thought of, and found many bugs that I would never have found. The immediate feedback was also helpful in improving the game design.
Around the time that the uDevGames Contest was announced, I had just started another project and was not actually going to do anything with GLFighters. The uDevGames Contest was exciting because I would have a vehicle to distribute my game and win some prizes, such as CodeWarrior, which I sorely need for my next project.
image3.jpg” alt=“GL Fighters”
I believe my game is an example of “programmer art” that is less terrible than the norm. All the models were created with Meshwork, textures created in Photoshop, converted to .TGA (Targa) with GraphicConverter, mapped onto the model with 3DMF Mapper, and then brought into the program by GLSee.
I had started with a very vague plan for a game that never actually became concrete. I just started with a guy running around on a platform, which became two guys, and then added various features such as changing backgrounds, multiple weapons, jetpacks, cloaking, multiple skins, first person view, AI, map editor, etc., which were all just random ideas from various sources jammed together. For example, I was once showing it to a friend and he just thought it would be nice if you could use two swords to fling people over your head with them, so I spent the next several hours making the animations and fixing the huge number of bugs that suddenly appear whenever I add anything new.
I designed this game on a PowerMac G4 400MHz (it was powerful at the time!) which meant it was harder to know what needed optimization since it almost always ran at an acceptable speed. This will definitely be much harder now that I’ve got a PowerMac G4 733MHz with a GeForce3 and almost a gigabyte of RAM. Due to the high system requirements, many gamers could not run the game at acceptable speeds.
image4.jpg” alt=“GL Fighters”
This was one of my first games in C++ so I was not yet aware of the wonders of #pragma mark - and descriptive function and variable names. Even now when I look at my code I can barely figure out what’s going on. I now group all functions by what they affect and put those great #pragma mark -’s between the groups. Also, I knew nothing about optimization so I used all sorts of unnecessarily slow commands like if sqrt(a<sup>2+b</sup>2)&<c instead of if a<sup>2+b</sup>2&<c^2, which does the exact same thing but runs much faster.
It is much harder to be motivated when working alone; it is too easy just to take a break for a week or a month or two with no one to remind you that you have to keep going. Working alone also led to the game being released in an unfinished state. However, I’m now working with two artists and a programmer so adding new game assets or code has helped in my current development efforts.
Overall, it was a very rewarding experience and I was glad to see iDevGames pull it off. I’ll be interested to see the games that will be released in 2002. The number of prizes was also great and hopefully I can get a new version of CodeWarrior so I can work on Phantom Strike more effectively.
I am working on a new game called Phantom Strike. There are two artists and one other programmer helping me create this new first/third person shooter. So far, our progress has been very good. I don’t want to give away too much, but the game will (hopefully) be a bit like Halo but set in the near future of Earth.
A game programming contest dedicated to Macs? Never! Yet, reliable sources indicated otherwise, and I found myself in a bit of a pinch. As I said, my current project had been Furae, so I briefly considered sprucing it up and submitting it. After reading further through the rules, I noticed the part about a two month time limit on entries. While Furae was still a legal entry, I had already put seven months into it, and I felt such a length of time would be an unfair advantage over other games that might enter. Without apprehension and already two weeks into the contest, I made the decision to start a game from scratch. I resurrected my idea of a mixed puzzle/arcade game, spent a few days filling in the holes that I expected would arise from gameplay, and began forging the preliminary graphics to the game engine.
The initial design of Turtle Turmoil was a puzzle game that involved some sort of a grounded foul, a chicken for instance, that would hop around on top of movable blocks. The goal would be to move the blocks so that the creatures in danger could hop to the safety of their nest, all the while dodging enemies that lurked on the ground below. There were also only to be two types of blocks, those that could move and those that could not. The best part about creating a game is that one never ends up with the same thing one starts with.
Turtle2.jpg
alt=“Turtle Turmoil”
I used a few different tools in the development of Turtle. My trusty compiler was Metrowerks’ CodeWarrior 5. All the graphics that I created were made in Infini-D 4.5, and all tweaking was done in Photoshop 5.5. Resources were compiled with Resorcerer and Ambrosia’s Bubble Trouble lent some inspiration.
Mike “Mojo” Apolis, my talented graphics artist, sound expert and musician, also used Infini-D and Photoshop for his graphics, along with MixMan Studio for the music.
Turtle Turmoil also includes a few libraries that deserve to be noted. The first of these libraries, and one of the most important to the game, is Ian Ollman’s SoundTerrain Library. SoundTerrain is an amazing sound system for Macintosh games. Unfortunately, Turtle Turmoil doesn’t implement all of its great features. Aside from ease of implementation (excellent in my opinion), it features playback in complete 3D space, pitch shifting and bending, Doppler effects, and complete control over the technical details of the sound engine itself—simply fantastic. The second of the external libraries I used for Turtle Turmoil is Fredrik Andersson’s SliMPEG MP3 player. The library itself includes about seven different calls. Four of these are the heart of the library: initialize, play, stop, and set_volume. When time is the defining factor in the development of a game, a library such as this is crucial for meeting deadlines.
Finally, though not technically a library, was my graphics engine ‘SchweetWorld.’ It was started about three years ago as a means of displaying the sprite based graphics in a game in a clarified, unified way. The very first version was laden with bugs and lacked many features. However, it laid out the world to layer to sprite architecture, and provided a solid foundation that, since its birth, has been modified and changed in so many different ways that it’s doubtful if a single line of code has remained the same in the 2,600 lines that comprise it. I’m proud to say that as of this writing it’s completely Mac OS X compatible, supports lighting, tiles, transparency, easy but powerful text drawing routines and a built-in support for drawing basic QuickDraw objects.
Turtle3.jpg
alt=“Turtle Turmoil”
Fortunately, just about everything slipped into place without major problems. The development of the game followed a well-defined path at the very beginning, which is invaluable for staying on track later on. The project started initially as a one-man show. During the first two weeks I spent more time creating graphics than I did actually programming. It was a highly aggravating experience to spend five hours in Infini-D and then two more in CodeWarrior implementing the graphics that had been rendered.
After I completed most of the filler graphics (I thought they would be final when I first created them, but very few of them actually were) I presented it to a few of my friends on IRC. One of them, Mike Apolis the graphics artist, informed me that he would like to help me out in my quest for glory. I breathed an immense sigh of relief and agreed. Three days later he sent me the same app back, completely and totally changed with beautiful graphics. From then on he became the lead graphics artist for Turtle, as well as providing other various resources as needed.
Mike truly was a life saver in regards to the completion of the game. We had excellent communication, and often times I would find myself just saying to him, “I need this graphic, in this size,” and within a few hours, I would have a package waiting for me in my mailbox. Regardless of what I thought it should look like, I found that he often had better ideas.
I also had strong support from friends on IRC, who would constantly give me feedback on gameplay and ideas. Creating a game by yourself is usually a very bad thing to do. The programmer is always biased towards his own preconceptions, and many of these are simply detrimental to the fun of the game. As cool as having pheasants that hop around on rocks is, it really doesn’t do much for the happy factor of the game.
One fellow who gave me all the programming support I could have asked for was Ian Rickard, an amazingly smart and talented programmer. He is the third member of the Turtle development team, and was responsible for telling me what to do when I just didn’t know. For example, Ian influenced most of the changes to SchweetWorld. The only function in SchweetWorld that does not begin with SW is InioBlit(), which was created completely by Ian. He is the blitter-master.
Turtle4.jpg
alt=“Turtle Turmoil”
Music was a particularly troubling matter. At first, neither Mike nor I knew exactly what kind of music Turtle should include. We debated using MOD files taken from various archives, but we knew that it was against the rules of the contest. In any case, finding music to match the gameplay on those databases was incredibly hard, and pretty much a lost cause as it was. We looked into some royalty-free MP3s, but we couldn’t find enough to match the style. Finally, Mike just told me one day that he had “thrown a little something together.” Voila!—we had Turtle Theme.mp3. From there on out, he just “threw together” three more songs in Mix Man, and we were set.
The porting of the app to Mac OS X presented much more of a difficulty than I had initially expected. When I first reviewed the rules for uDevGames, I noted to myself that the judges would be highly interested in looking for games that would run on Mac OS X. “Wowzers,” I thought, “I have no Mac OS X compatible code whatsoever.” I decided that this contest would be a great catalyst to get me off my lazy programmer arse and clean up my code for Mac OS X. After I had the graphics engine running entirely under CarbonLib, I proceeded with development as normal. I somehow thought that when the time would come to test it under Mac OS X, simply adding a “carb” resource of ID 1 would do the trick. Ha, not quite! Once the gameplay had been completed, I would spend about two hours at a time trying to get SchweetWorld and Turtle to work in Mac OS X. Around that time, I had completely lost any patience I had for the OS. This went on for about two weeks. The real problem was that I was developing Turtle on a non-Mac OS X compatible compiler, so I had no use of any kind of a debugger. I tried a couple of times to convert it to a Project Builder project, but failed repeatedly. Eventually, through many log files and dialog alerts, I tracked all the errors that kept Turtle from running in Mac OS X, vanquished them, and made it officially Mac OS X compatible (although version b6, the version submitted to the uDevGames Contest, is not).
Turtle5.jpg
alt=“Turtle Turmoil”
I will go on to finish Turtle Turmoil to a well polished luster, and release a final version outside of uDevGames. After that, who knows. I will probably go back to working on Furae, and begin learning OpenGL for use in an upcoming adventure game featuring a heroic squirrel! Someday I might bring Brainfreeze Entertainment out of a hobby state, but until I can make more than zero dollars per game, I’ll just stick with pizza delivery.
Mike Apolis summed it up best when he said, “It was pretty cool to be a part of a contest that produced a good handful of games for the Mac in two months.” I share the same thoughts as Mike. As a Macintosh developer, the chance to create a project and have it put on display against one’s peers is a tremendous driving force. This force fuels the drive for quality, at least it did for me. It was this “push from behind” that made creating this game in such a short time so much fun.
I think that the two month time limit was a bit tight, but very healthy as well. For me, it presented a worthy challenge and created a very strong desire to make as polished and enjoyable a game as possible in a minuscule amount of time. Somehow, amazingly, I managed to fulfill my expectations of myself and had a great time in the process.
Having to submit my source code was comparable to being a magician and not wanting to give away the secret of the trick. However, I realize that iDevGames is working towards building a community where all Macintosh developers can benefit, regardless of level. Anyways, how can other magicians come to be if they don’t also learn the secrets of Macintosh game programming? Merci beaucoup, iDevGames!
Image 1 — August 2nd
Possibly the very first working version of the game. Because of the appearance of the rocks, I liked to joke that I was pulling teeth at this stage of development.
Image 2 — August 6th
I got quite a few graphics added to this version, most notably the background and the ugly ogres. Gameplay was still very limited this early on, and there was no interaction between the characters at all except for Tort to the rocks and the rocks killing the ogres.
Image 3 — August 14th
Because this was the first version to make use of the level sets, and because I hadn’t built the editor yet, this screenshot lacks in visual flavor. However, this was the version built after Mike got his hands on the graphics. Pretty, huh?
Image 4 — August 19th
This is a screenshot of WAR mode in b1. At this point almost all the internal workings of the game were done and almost all of the graphics had been finalized. Gameplay still needed quite a bit of work, though. This version didn’t use the symmetrical creation of WAR maps either, and makes it fairly obvious as to why I changed it.
Image 5 — September 20th
Here is Turtle Turmoil as it looks today. I was asked many times in game development to add certain blocks to make puzzle creation easier, and one of these was the tree stump (a breakable wall, not included in b6). I believe this screenshot shows all the main graphics Turtle Turmoil offers in game play. The blue border was created with a plug-in, which Turtle Turmoil now supports for the modification of graphics.
Infini-D,MixMan Studio,SliMPEG,SoundTerrain Library,QuickDraw,CodeWarrior,blitter,CarbonLib
I used CodeWarrior 5 and ResEdit for all the programming and development. On the graphic front, Photoshop 3 and GraphicConverter were utilized to create and edit textures for the game. The sound samples came from various freeware sound libraries. As the 3D models didn’t contain complex geometry, they were coded in directly.
image2.jpg
alt=“Silly Balls”
One of the best decisions I made was to create an editor for Silly Balls. Although this took some time, the amount of time saved in creating all the levels was enormous. The editor is far from perfect and still requires the use of ResEdit for complete level creation. However, having the editor allowed me to submit the game on time. I’d like to advise new game programmers that a good level editor will not only save time, as in my case, but also contribute to the game’s development process.
The format for the levels was flexible in that I was able to add in extra features without the game engine breaking. This is another tip for new programmers: when creating your format to contain your game’s level, plan ahead so that new features can be added without the need to create major modifications to your game code. I hope to continue development on the level editor so that I can release it to the public in the future.
As you play your own game continually from concept to finish, your own view of how easy and how good a game it is tends to change. Hence the importance of outside play testing is crucial. This is something I didn’t do until a little too late. Silly Balls is far too hard in my view, although I can complete it without losing a life. The other major problem with Silly Balls was the lack of a design document for the uDevGames 2001 version. My plan was to release the game for uDevGames and continue work on the game even after the contest was over. However, knowing which features should make it to be included in the contest version became a challenge. Looking back, I should have made a concrete decision on what features would make it into the submitted game, and which features would be added at a later time. The music was also a weak point in the game. It was added at the last moment so I wasn’t able to test it thoroughly. (Note to self: never add features on the day of final submission.)
image3.jpg
alt=“Silly Balls”
As for the future, my next project is to Carbonize (and debug) Silly Balls. Then I will continue to work on that and a 3D tank game. I’m also looking to enter the Independent Games Festival ‘student competition’ after Christmas. Looking further ahead, I plan to move away from Carbon and concentrate completely on Cocoa and Mac OS X. Like many developers, I have always wanted to write an adventure game, so perhaps I might go in that direction when the time is right.
I found that it was great to work against a deadline, and it made me concentrate on finishing what may have taken years otherwise! My advice for uDevGames 2002 developers would be to get your game out as soon as possible. This allows for more play testing and polishing of the game before the voting period begins.
My last comment concerns public feedback. It is a vital process for fine-tuning a game so that it is fun and runs well on a variety of machines. However, I recommend that you find some committed beta testers early on and don’t count on the public for 100% of your testing. The reason is that some players may not be eager to re-download a large game due to limited connection speed or interest. I think that setting up a home page specifically for your game entry that allows gamers to easily add their comments or to download small patches before the voting begins would be a smart move.
Overall, the competition was a great success and the benefit to the community in terms of working code is enormous. I look forward to browsing the code from the other games and hope that uDevGames 2002 will be an even bigger event.
3D,puzzle,RedEdit,Cocoa,Carbon,CodeWarrior
We kept our development pipeline simple. While I wrote the game code with CodeWarrior, our artists Genki and Sean created the game’s original graphics. Genki did most of the character animation, and his primary tool was the old Mac program, Aldus Superpaint. We utilized Superpaint over more complex editors like Photoshop mostly for its palette manipulation and painting tools. Sean, who created most of the level art, also used Superpaint almost exclusively. Andrew, our musician, built us several tracks using the PC programs CakewalkPro Audio 8 and CoolEdit, along with the arsenal of samplers and keyboards he keeps in his studio. Most of the game code was written on a PowerComputing PowerTower Pro 225, while the art was done using Apple’s 7600 range machines and Wacom art tablets. While we were familiar with various third-party sprite systems available on the market (e.g. SAT, SpriteWorld), we decided to build our own animation and map systems. We built the map editor into the application, and this unity allowed us to include the tool with the final version of the product. When we began development, Apple’s GameSprocket technology was still in its infancy, so we elected to write our input and drawing systems ourselves. This actually turned out to be a good solution in the long run, as we were able to tune our game to run as fast as possible.
h3. What Went Right
h4. Realistic Goals
From the beginning, we had our sights set on our desired features and their estimated development time. Though Bakudanjin ended taking almost two years to complete, this was mostly because of school and other interruptions. Looking back on the work we put into the project, I think we could have realistically finished in under six months if we had been able to devote more time to development. Our focus on design saved us several times from feature creep. We did add a few extra game modes and game play devices along the way, but we quickly discarded many ideas that seemed too difficult or time-consuming.
h4. First Playable Finished Early
When we began developing Bakudanjin, we concentrated on the core game engine features first. As a result, we had a first playable build after only two weeks of development! In this time, not only had the animation engine come together, but two character sprites, some basic level tiles, and an enemy were completed as well. Being able to test our game out this early in the development cycle was invaluable; we were able to identify design problems and control issues almost immediately. Building an early prototype also forced us to build a level editor, which turned out to be extremely beneficial.
h4. Level Design as a Puzzle
Though Bakudanjin is all about blowing up the enemies, we built each world such that puzzles could be constructed out of the levels themselves. We also added three different playable characters, each with his own attributes. We tried very hard to design levels that would be easy for some characters and hard for others, thus creating a different experience for each playable character. For example, the Soldier character, who is the fastest character in the game, has the ability to avoid quicksand. However, this ability is only useful in the first game world, making later levels more difficult.
h4. Targeting Low-end Machines
When we began Bakudanjin in 1997, we decided that our game should run on even the lowest of low-end Macs. We used my old Centris 660AV, a 25MHz 68040 machine, as the most basic system that needed to be able to run our game at 30fps. Though this required a lot of optimization of the drawing code late in development, we were able to attain our goal. As a result, our game can be enjoyed by a much larger audience than many other titles, and it drove us to write clean and efficient code. Though 68k support is much less of an issue today, I am still quite glad we made the decision to support lower-end machines. Bakudanjin was developed before Apple released CarbonLib and the Carbon Dater program, and is consequently not Mac OS X compliant. However, converting the code base to Carbon would be fairly easy, and we are considering a patch to make Bakudanjin Mac OS X native.
h4. Multilingual Support
Though it was rather last minute, we decided to include support for Japanese as well as English for the Bakudanjin user interface. Our goal was to make our game as accessible as possible, and we knew that a lot of gamers in Japan might be interested in our title. While support for Japanese did not extend past a few translated menus and dialog boxes, we did translate the entire manual, and saw several Japanese registrations as a direct result. Surprisingly, more than half of all our registrations to date have been from Europe, and in our next title we will definitely include some kind of support for European languages.
h3. What Went Wrong
h4. Part-time Game Development
Bakudanjin was developed while we were all in school, and as a result took an incredibly long time to finish. This was particularly frustrating because we had a playable game from the very start of the project. However, we realized that if we did not meet our design goals the game would not be nearly as fun, so we continued to work in our spare time. Hobby programming is quite a challenge when free time is scarce, and in our case our development time suffered immensely.
h4. Unclear Distribution Goals
We originally decided to press Bakudanjin on CD and sell it via our web site, and some of our initial design decisions were based on this plan. Our musician built five awesome tracks for our game from scratch, and delivered them to us as 40~50MB WAV files. I wrote audio CD player code with the full intention of burning CDs with the music as audio tracks. However, it became clear towards the end of development that a CD would not be feasible. As a result, we were stuck with five high quality musical tracks that took up one hundred times more disk space than the actual game. We considered compression techniques such as MP3, but our low-end target platform was too slow to decode and play such formats on the fly. In the end, we decided to distribute via the web and were forced to use only 10 seconds from the main theme.
h4. Being a Clone
Though we learned a lot and produced a great game, Bakudanjin will forever be thought of as a Bomberman clone. Borrowing a simple mechanic has been done before, and we were hardly the first to be inspired by Hudson’s great game. However, many doors were closed to us because our game too closely resembled other titles out there. One magazine even refused to run a short segment about us, citing recent problems providing software that had “similarities to programs currently available on the market.” Though we believe that Bakudanjin is an original work, we found that Bakudanjin’s concept was not unique enough to break out of clone status.
If you are a developer thinking of building a game based on an established game play mechanic or look, be aware that your game’s sales may suffer because customers will not consider your product original enough. On the other hand, it is much harder to create a fun game design from scratch than it is to borrow features from established titles, and there is a market for new versions of old games. Witness “Ambrosia”:http://www.ambrosiasw.com/; the majority of their titles are not based on original game play designs. Nevertheless, they continue to produce high quality games and generate lots of revenue. In Bakudanjin, we attempted to balance classic Bomberman game play with original characters and game play modes we added. I think that we were fairly successful, though in hindsight there are several things we could have done better.
h3. Conclusion
All in all, developing Bakudanjin was a great experience. Though not everything worked out as we had planned, we all learned an incredible amount by building the game from scratch. We have been selling Bakudanjin for almost two years now, and have been successful with a wide audience of men and women of all ages. One customer’s comment in particular made the entire experience worth all the time and effort we put into it, and reminded me why I got into game programming to begin with: “_My boys will be very excited! They love the game and we are constantly greeting one another with the noises that are derived from the game._” In our next project, an as-yet-unannounced adventure RPG, we hope to avoid some of the challenges we faced with Bakudanjin by focusing on design and the strengths of our previous projects. Our next game uses a top scrolling tile engine and a highly customizable sprite interaction system, and we hope to release our tools with the game. It is our goal to continue to produce games that are fun and appealing to people from all walks of life.
Bakudanjin
* Developer: Dream Dawn
* Genre: Arcade
* Site: http://www.dreamdawn.com
* Team size: 4
* Released date: October 1999
* Project length: Two Years
* Development hardware:
* Critical applications: CodeWarrior 9 Gold, Aldus Superpaint, Photoshop, Cakewalk 8, SoundEdit 16
* Demo
bakudanjin,dreamdawn
Of course, there are hurdles a student developer must overcome other than simply learning how to program. Although time and determination are certainly factors, a student developer also needs to acquire the tools to handle artwork, sound and 3D model generation. For 2D image processing, I would suggest Adobe Photoshop (if you’re lucky enough to be able to afford it), or use GIMP. There are several freeware and shareware alternatives, but I have not used any so I cannot comment on them. For sounds, I used an older shareware program named SoundEffects, which still works quite well today.
In the beginning, I defined simple OpenGL models by hand. However, anything complicated required the services of a good modeling program. Finding the right program turned out to be tricky, since unlike paint and sound programs there is no standard OpenGL model file format. This means that you need to write custom code to read in the output of whatever modeler you choose. I already owned a copy of Ray Dream Studio, and its full feature set is wonderful for creating pre-rendered graphics. However, it was a little too bloated and under-documented for my purposes (especially on its file format). What I really needed was a simple model editor that exported to an easily readable format. My answer was Joe Strout’s Meshwork! This deceptively simple trimesh modeling program has a slew of handy features, but even better it exports to many different file formats. And although I didn’t use it, there is sample code on the Codenautics website that converts 3DMF files to an OpenGL compatible file.
With the right tools and the programming knowledge, the student developer now has everything they need to create a great game. So, that’s it? Not quite—students also have the unique opportunity to meet and interact with the game development community and to display their game to hundreds of viewers at the Game Developer’s Conference for free! How is this possible?
h3. Independent Games Festival’s Student Showcase
Perhaps the best thing to happen to small-time developers since open source has been the Independent Games Festival. It is a unique opportunity to get out and interact with others in the game development community. While it is a neat chance for all independent developers, in my opinion students stand to gain the most from the experience. For more info on the regular IGF, please refer to www.indiegames.com.
Vortex Next Generation was one of the top five finalists in the First Annual IGF Student Showcase, and this was by far the best thing to come out of developing Vortex NG. For winning the Showcase, myself and up to five others were given free passes to go to the 2001 Game Developers Conference in San Jose, California (for the overly curious, this amounted to nearly $3000 in prizes of itself). They also gave the winners $500 in travel expenses—a huge benefit for me since my wife and I flew cross country to get there. At the Conference I was supplied with a display pod near the front of the main Expo doors to show off Vortex NG to any and all who wished to see it! The advice and opinions I got from this alone were worth the trip, not to mention the Conference itself and all the developer parties you get to attend.
So, what are the rules? Simply have a working game by January 10 of next year and submit it on three separate CD-ROMs. No submission fee required! Of course, you are not allowed to have any in-depth help from development professionals, you cannot have signed on with a publisher, and you must be a full-time high school or college student (please refer to the web site for complete official rules).
Was it hard to get into? Not really, I just got in touch with the person in charge to make sure a Mac only game was OK to enter. I encourage more Mac OS student developers to submit their best work, and perhaps you’ll be there next year! This year they are going to have ten Student Showcase winners, instead of just five as in 2001. It would be a shame if my next game is the only Mac OS one there next year.
h3. What Went Wrong
h4. Supporting Mac OS X
From my own experience, supporting Mac OS X this soon was probably my worst mistake in developing Vortex NG. The game is still having trouble just getting a full screen OpenGL context on many systems! There were also major performance problems with glTexSubImage2D() and glDrawPixels(), dropping Vortex’s 40-50 fps down to a terrible 8-10 fps. The lack of InputSprockets was also harsh, and left the keyboard as the only available input device. Getting mouse deltas proved impossible to do with Carbon and CodeWarrior without gutting the entire event messaging system and replacing it with Carbon Events. I even had trouble getting the sample source code to compile! I will admit that many of these problems magically disappeared in my recent efforts using Cocoa. The Cocoa development environment is very powerful and simple to use and I have had nothing but joy in my experiences using it, except for the fact that there is still no easy way to get a full screen OpenGL context in Cocoa!
h4. Vector-based Font
A design mistake on my part was implementing a generic vector-based font to use with OpenGL (as opposed to creating a sprite-based alphabet). My main reason for doing this is that I wanted a scalable solution that would impose the least performance hit possible. However, many people felt that it was hard to read and distracted greatly from the nice graphics around it. This is a mistake I will not make twice!
h3. What Went Right
h4. Protective Memory in Mac OS X
Yes, believe it or not I did find many good things about Mac OS X. One cool thing was the side effect of running on Mac OS X’s protective memory. Quite a few bugs were flushed out when trying to get Vortex NG running on Mac OS X, bugs which Mac OS 9 would happily ignore till it finally crashed.
h4. Industry Networking
Getting in touch with the folks from Macally was also very rewarding. They sent me a couple of developer seeds of their new iShock II controllers, and I was able to add support for them before going to the IGF Student Showcase. Based on my experiences with them, the folk at Macally are super people who are dedicated to releasing new and different products for the Mac. Who else is pushing to bring us Force Feedback? No one—not even our beloved Apple!
Of course, no one should write a postmortem for a Mac game without mentioning the warm and welcoming community that Mac developers share. There are so many knowledgeable people out there, and it seems that many of them do nothing but answer questions posted to the various newsgroups and mailing lists. If you get stuck, there is almost always someone who has solved the same problem, and they’re more than willing to help you through it.
h3. Wrap Up
Despite the mistakes and trials from Vortex Next Generation, I am already working on my entry to next year’s IGF. I won’t say too much about it here, but due to the nature of the game, it will require a huge open beta to help work out issues that I could never hope to solve alone. Stay tuned to Feline Entertainment’s website for further news!
* Developer: Feline Entertainment
* Notable: Student Showcase Winner – Independent Games Festival
* Genre: Arcade
* Site: homepage.mac.com/felinegames
* Team size: 1
* Released date: May 2001
* Project length: 1.5 years
* Development hardware: PowerBook G3
* Critical applications: Photoshop, CodeWarrior, Meshwork
vortex,ng,feline,entertainment
Not really. I do submit bug reports and occasionally post to the developer mailing list but that’s all. I used to be more active in the REALbasic early years.
Coldstone is divided into two parts: the editor and the compiler. The editor lets you manage the different parts of your game and put them together to create the story and gameplay. The compiler then takes all this stuff and creates a stand-alone application on either Mac Classic, Mac OS X or Windows. The editor is almost 100% REALbasic code but the compiler and the resulting applications are 100% C++. This allows for fast and professional games. We used Metrowerks CodeWarrior to develop the engine core.
Photoshop, 3D Studio Max and Graphic Converter.
First, the sprite engine supports multiple layers and sprites of any size. This lets you create any type of world you want by placing several different pictures here and there, or you can use one big picture for a whole map (like in Baldur’s Gate). The sprite engine (and editor) doesn’t make any distinction between an animation and a still picture (with little exceptions). This means that you can use the very cool (yet powerful) animation editor to create an animation and just add it in the map, in any layer you want. Second, the engine is true 32-bit color, which means that translucency effects are possible with picture formats that support alpha masks such as PNG. Also, all the game “windows,” like the shop interface for example, are rendered by the sprite engine to make them platform independent.
There is no limit. You can have an 800×800 character but it may be hard to control on screen. As for frames, it’s unlimited and really up to you. You could let your game take 200MB RAM if you wanted to.
Once again, RAM requirements are your only true world limitation in Coldstone. However, if you want to be able to edit a 1000×1000 map in the Coldstone Map Editor, you may have to give some more memory to the application. RAM really is the only limit you have. Give it more RAM and it will give you the power you need to create that 5000×5000 map you always dreamed of!
The developer can decide at which resolution and color depth the game will run.
Coldstone allows enhancement to the game but not to the engine itself. A Coldstone developer has the option to enable plug-in support for their game. So hopefully a good community of plug-in developers will also grow. Things like creating a new renderer or new battle engine through a C++ plug-in aren’t possible though.
When you create a Coldstone game, you have to specify a creator code. If a developer creates a sequel to their game and gives it the same creator code, the saved game would be compatible between the two games.
There is no real physics engine in Coldstone. You could easily fake physics with the animation editor and its keyframe animation abilities though.
The combat system core is hard-coded but the gameplay isn’t. While you can’t recreate the AD&D combat system, you can be very creative in your opponents’ look and behavior. PoG, the game we are developing with Coldstone, is a good example of this. We have standard rush-at-the-enemy monsters, but we also have original ones like earth elementals that summon earth columns from down under you (and that hurts!). The spell system is also very open and opens a wide range of new possibilities to the game designer.
Theoretically, the magic system in Coldstone works with spell points. You could, however, use the event system to script yourself a new kind of magic system. Who said that it must be called “magic” anyway? You could create a futuristic game and call those “Bionic super powers” or something neat like that. The nature of these spells or bionic powers is all yours to create! Coldstone is bundled with a user-friendly spell editor.
Coldstone offers the developer the ability to create “global keydown events,” which are basically events that are fired when the player presses a certain key. At this point, the only limitation is the event system.
No.
It creates a stand-alone application for Mac OS Classic, Mac OS X, Windows 95/98, and Windows ME/2000.
REALbasic seamlessly did most of the work for the editor. REALbasic has some nasty Mac OS X bugs so I had to code a couple of workarounds, as well as modifying the interface and the help system to fit Mac OS X standards. The compiler of Coldstone is, however, pure C++. Again, it wasn’t that much work since it has been designed from the start to compile on Mac OS, Mac OS X and Windows.
Ambrosia has the online infrastructure required to support such a product. They have a very good web board system that will let the Coldstone developers exchange tips and tricks, as well as a good archiving system so that the Coldstone community will have a place to download up-to-date add-on files for Coldstone and upload their creations. This will also let people of various professions (musicians, 3D artists, etc.) meet and create cool new games. Beside this, Ambrosia has a cool and helpful staff, not to mention their marketing potential in the Macintosh gaming market.
Such details are unsure at the moment.
Again, this is not set in stone but the developer will probably be required to display the (very nice) Coldstone badge somewhere in their product.
coldstone06.jpg
They both let you create RPGs but the difference lies on the creation freedom level. RPG Maker lets you create an RPG within a fixed frame. That makes it easy to use because the creator can concentrate on the content rather than the packaging. While Coldstone offers very good tools to let the user shape their own worlds, it also provides them with the ability to modify the container: game interface, menus, even a plug-in system that you can enable to let other developers write add-ons to your game. To make things simple for beginners, Coldstone comes with a game wizard that creates a fully working game frame for you to modify. Coldstone comes up with a default medieval set but allows you to modify it at will or start from scratch and create your very own style. You can have your very first game up in minutes.
The goal was to make an engine that is appealing for both the wannabe game developers and professionals that want to quickly create outstanding cross-platform games. Coldstone is like Mac OS X — a powerful core wrapped in a beautiful user-friendly interface. Coldstone also comes with more than 10,000 graphics and animation files to help beginners create professional-looking games. There will be some low-quality games produced with it of course, but those will help the Coldstone community by providing game examples rather than hurt it, I think.
Since 1998, iDevGames has been educating, supporting and enhancing the community of game developers that develop video games for Mac OS X & iPhone. Subscribe to our news feed for the latest news, reviews, tutorials, postmortems and more.