Among the topics covered are: Development tools, OpenGL, PPC optimizations, VAR (Vertex Array Range), Carbon, Audio Playback (QuickTime & OpenAL), Input (mouse, keyboard & HID manager), Networking, and Marketing & Selling.
Related Links:
I knew at the beginning of the contest that this was a huge project to take on for a three month time frame. I did as much planning as I could ahead of time, and studied all of the technologies I thought I’d need. I wrote up a thorough design document, and showed it around to a bunch of other developers for feedback. When the contest start date finally came around, I felt pretty well prepared for what was ahead.
I used Project Builder as my IDE. Up until the contest, I’d been using-don’t laugh-MPW. I nearly ended up using MPW for the contest, but recent events convinced me that it was finally time to drop Mac OS 9 support, and move on to Mach-O. I’ve looked at Xcode, and I feel that it is rather bloated and unintuitive. While a bit older and no longer officially supported, Project Builder seemed a better choice to me, and it worked without a hitch.
BBEdit was the most essential tool for me. I’ve been using it for code editing for years, and it’s the best text editor I’ve ever used, hands down. Syntax coloring, regular expression find and replace, and many other features make it a fantastic programming tool. In September, I upgraded to the newly released BBEdit 8.0. It had a feature that made my workflow much more efficient: single-window, multi-document editing. I had previously been minimizing each source file’s window to the dock—not a good solution when you have more than a dozen source files!
I tried out several different image editing programs early on, and was having trouble finding one that suited my needs. I don’t own a copy of Photoshop, and didn’t have the money to spend on one. Eventually, Daniel Lurie recommended the GIMP (GNU Image Manipulation Program). I was initially turned off by it, as it ran in X11, but after using it for a while, I found that it really worked quite well. It served me well over the course of the contest, and I feel it gives even Photoshop a run for its money.
I used two programs for audio: Amadeus II and Reason. Amadeus II is a great little shareware audio editing program, and one of the few shareware programs I’ve actually registered. I had a bad experience with Audacity, and there didn’t seem to be anything else usable out there. Some sound effects were recorded, some were artificially created, some were copied from the original Water Tower (a fact of which I’m not proud—I wish I’d had time to redo them), and some were created in Reason. I wanted to write background music for the game, but unfortunately, due to lack of time and lack of musical talent, that didn’t happen.
I looked at a few modeling programs, but they all seemed to have a rather steep learning curve, and I couldn’t be bothered to spend the time choosing one and learning to use it. None of them quite managed to fit my needs anyway. I ended up creating my own model format, and typing in most of the models by hand. For some of the more complex models, such as the deadly block, I wrote a small console application to generate them programatically. While far from an ideal solution, this at least allowed me to get the job done and move on.
Since I was building on a game concept I’d created the previous year, I didn’t have a whole lot of work to do here. Essentially, I just had to figure out how to make the transition from a 2D world to a 3D one. I had some crazy new ideas for game features, but a lot of them didn’t make it. By the end of the contest I had a game that was very similar to the original. While I would have liked to explore new concepts a little bit further, I feel the original gameplay survived the transition to 3D very well.
I had learned a lot about writing better code since the uDevGames Contest from the previous year. Working with another programmer helped me see new and better ways to write things, and after adopting what I feel are better coding practices, my coding has become more efficient. Toward the end of uDevGames 2003, the Water Tower source code had gotten to be such a mess that I could scarcely add a single new feature without causing three new bugs. Water Tower 3D was a completely different experience. The code remained clean and readable throughout the entire project, and was very flexible. Adding new features was almost always painless and easy. Keith Bauer, another programmer, looked over my code toward the end of the contest, and told me it was nicer and more readable than most other code he’d seen.
When I was planning the game before the start of the contest, I knew that character animation was going to be one of the bigger challenges. I did some research, asked some people who had done this sort of thing before, and came up with a system I thought would suit my needs. I wanted to get as much research as possible done before the contest started, and since animation seemed like such a large unknown, I spent most of the month of July working out how to do it. When the contest started in August, I was pretty satisfied with my animation system. When the time came to implement it in the game, it was up and running in a matter of about two days. The results were quite pleasing. During the course of the contest, I got many compliments on how well-animated my character was.
Managing assets for the game was a pretty smooth process. I had a directory full of human-readable ASCII files that were used for models, animations, and textures, as well as a separate directory for the texture images themselves. I could set up material properties for each texture, and change which texture is used on a model by changing a string in my model file. My model and texture loading code loaded all of the files in the directory at startup, so no additional loading code was needed when I added new models or textures.
The biggest trouble I ran into during development came when I tried to implement water. I wanted a system where the water would flow more realistically, as opposed to a flat plane rising at a constant speed, as it was done in Water Tower. I started on the water system in September, thinking I could get it up and running in about a week.
A week passed, and it still wasn’t working, so I figured I’d give it another week, as it was a very important gameplay element. Another week went by, and another… Before I knew it, I had spent more than a month of development time doing almost nothing other than work on the water system. That’s a gigantic loss of time for a three month contest! Eventually, I realized that if I continued on the water system that way I had been, I wouldn’t have anything even close to releasable by the end of the contest. I cut my losses and implemented Water Tower-style water, and was done with it in an evening. To this day, it’s the thing I’m the most disappointed that I wasn’t able to do in the game.
I knew from the start that this project was really asking a lot of myself in such a short time frame. With everything I wanted to do with the game, there was no way I could get completely finished in three months. I tried to prioritize the most important game features so that I could at least have a working, playable game by the end of the contest. I don’t feel that I did a very good job on this. Some fairly essential game features were still missing by the time voting started, and there were some other things I really could have done without that took a lot of time. I do feel that I’ve pushed my limits and done more than I could have imagined in the time given, but the project was still much too large to be appropriate for uDevGames.
Another big unknown was the character model. I had very little experience with any modeling program, and hadn’t ever modeled anything as complex as a human before. For the first half of the contest, I was using a white stick figure for the character. I would have liked to create a more realistic human model, but I didn’t even know where to begin. When I was showing the game around to coworkers one day, someone had a suggestion for at least a start: stick with the model I had, but give it colors to make it look like a character from the Atari 2600 era. The effect wasn’t too bad; a definite improvement. I spend some time proportioning the character to look less like a stick figure, and eventually decided the result was good enough for the contest. While not really satisfied, I was at least able call it “done enough” to move on to other things in the game.
There were some usability issues that I unfortunately never addressed. One problem, which seems to be inherent in any 3D game, was the camera. I put all of the responsibility of moving the camera on the player. While it’s nice to be able to control the camera, it’s not something most people want to have to worry about in the middle of the action. I had some ideas for how to make this nicer: I was going to have an invisible object that could be placed in the level editor that I called a “camera hint.” When the player walked over a camera hint, the camera would pan to a predetermined angle. Well-placed camera hints in a level could make it unnecessary for the player to adjust the camera at all. Add that to the long list of features that didn’t make it.
I wanted to have at least four different level sets finished by the end of the contest: Tutorial, Easy, Intermediate, and Advanced. Sadly, the levels you see in the contest version are none of those; they’re still placeholders. The difficulty is about at Intermediate level, which is also a problem…the game has a rather steep learning curve for beginners. I have to wonder how many people stuck with the game long enough to get the hang of it.
While I’m proud of what I’ve done with the game, I have to admit that it was simply too large of an undertaking for a contest of this scope. However, if it hadn’t been for the contest pushing me to finish, I probably would never have gotten anywhere near this far with the game. It would have been just another project on my this-would-be-cool-but-I’ll-never-get-around-to-it list. I’m planning to come up with a somewhat smaller project for the next uDevGames Contest. It would be nice to be finished by the deadline for once!
I was told by many developers that I was crazy for trying to do this alone. Many times when I felt overwhelmed, I considered looking for other team members to take some of the load off, but I stuck it out by myself to the end. The main reason I enter uDevGames is to learn new things; how can I learn if someone else does the work for me? This experience is invaluable. I feel that I’ve furthered my abilities as a programmer, an artist, a designer, and a musician. This is my goal. This is why I do what I do, and why I enjoy working alone.
A big thanks to iDevGames and all of its staff members for organizing this contest. It’s one of the best things in which I’ve ever participated. Thanks to the sponsors, for donating some great prizes to motivate developers to do better. And thanks to Apple, for creating this wonderful computing platform.
My interest in space games dates back many years, when I played Elite for countless hours on a Sinclair Spectrum. In later years, I found myself enthralled by Frontier, the ‘sequel’ to Elite, and the vastly underrated plot-led combat sim Warhead. Both of those games more or less typify how I expect a space game to work: convincing physics, true 3D and immersive environments.
The thing that brought these old gaming memories back was a recent remake of Elite written by Giles Williams, the punningly-named Oolite. As much as I liked Giles’ game, I really wanted to see a space sim with more graphical realism and a sort of crude, industrial look. Also, where many space games revel in high-tech heads-up displays, I wanted to place the player directly in the cockpit, looking around at the clunky hardware as well as out at the stars.
I’m always reluctant to exactly copy existing games, so I began to think of ways to make my game stand out as I laid down the design for the gameplay. I decided that it would be most interesting to shy away from the usual ‘dogfights in space’ gameplay and go for something a little more unusual: a more passive kind of gameplay where you have to rescue asteroid miners from certain doom. No guns, no shields, just a chunky industrial space tug, a set of mining tools, and your flying skills to keep you alive. Having settled upon this cursory design, I began coding.
One of the first decisions I made was to drop almost all the code I had ever written before. I had wanted to take this step for quite a while because I had become weary of working with the same rotten old code, which I first started writing several years ago. I used this code to make Super Phoenix and Yoink, and it works adequately as far as it goes, but it has deep seated design problems that I’ll probably never manage to eliminate. By starting afresh, I hoped that I would be able to create a clean, focused basis upon which to work, and that would help me to make a better game.
I also wanted to try several technologies which were new to me. My earlier games are still compatible with Mac OS 9, using the CFM runtime and the Carbon API. For Rescue, I thought I’d go a step further and build a Mac OS X only Mach-O game for the first time.
Having disposed of my own source code resources, I decided to replace it by utilising as much freely available, widely used source code as possible. I mainly wanted to avoid reinventing the wheel, but I also hoped to learn some new skills and techniques by delving into other people’s code.
I chose SDL as the foundation of my application. It has a good track record, it’s popular and as a bonus it’s abundantly cross platform. SDL also has an extensive selection of standard (and not-so-standard) additional libraries, and I picked two of the best respected – SDL_image and SDL_mixer – to handle image file loading and sound, respectively.
For my math and physics code, I decided to try WildMagic, a huge and rather complex C++ library. WildMagic had a large number of features which I didn’t really want to use, such as a built-in scene graph and an application framework similar to GLUT, but I was able to use the functionality I wanted (vectors, quaternions, matrices, intersections and so on) without picking up too much unwanted overhead.
I needed a way of loading 3D models, something which I haven’t even thought about since the last time I used QuickDraw3D. Because I had no experience in writing my own model loader, I decided to use the OBJ format loader written by Karl Berg, another member of the iDevGames’ forum. I found his loader particularly interesting because the example program supplied with it showed a spaceship model with attractive specular highlights and an illumination map.
For other data files, I decided to use TinyXML, a simple but effective XML library written in C++. I used it in the creation of my uDevGames 2003 entry, Yoink, so I was already satisfied that it was the right tool for the job.
I wanted to make an infinitely large, densely populated asteroid field with a large visibility range. This was going to cause obvious problems in terms of the frame rate, so I had to use some tricks to keep things moving quickly.
I used simple cubic space partitioning to control the culling of invisible objects. Partitions which are outside the camera frustum are not drawn. I had considered using octrees instead of plain partitions, but I decided that it would be too complicated and not necessarily much faster. However, I did go on to use an octree routine to lay out asteroids in space partitions in a way which prevented two rocks from overlapping.
In addition to this, I needed to cull objects by distance. I was only able to render about a hundred asteroids before things started to get too slow, but this meant that either my visual range was very short or the asteroid field had to be very sparse. I dealt with this by reducing distant rocks to a silhouetted polygon on a billboard, and using fog and careful scaling to make the level-of-detail pop less noticeable. It wasn’t clever, but it allowed me to display several hundred asteroids instead of just a few.
Elsewhere, I used very few optimizations. Apart from having to make some minor changes to WildMagic to get a big speed increase, I didn’t do anything much to make things efficient, so the game wasn’t very fast or smooth on slower computers. Machines with old graphics cards such as the ATI Rage 128 were almost bearable, but most people weren’t able to tolerate the game at such a low frame rate, so I necessarily cut a lot of users with lesser machines out of my potential audience.
When I embarked upon the development of Rescue, two weeks after the start of the contest, I was really only using the contest as a chance to experiment in a formal setting. I didn’t even sign up for a several weeks. However, out of the blue I was contacted by a freelance musician, Mikko Tarmia. He said that he had seen Rescue and wanted to write music for the game. I was flattered that he liked what I had done and I really liked the sample pieces of music he showed me, so I was very keen to ask him to contribute.
It then struck me that my little game experiment was now much more serious. It wasn’t just my effort and reputation on the line, but Mikko’s too, so I felt that there was no way I could afford to let him down by slacking on my part of the deal. From that point, no matter what happened, I was determined that I would do my best to reach the end of the contest without quitting.
Later in the contest, I realized that, while I had nice spaceship and asteroid models, as well as pretty star and nebula textures, I was going to have a hard time adding textures to the 3D models. My modelling software, form-Z, is rather good at low-poly modelling, but is lacking in features for manual UV mapping. I could also see that I was going to be pushed for time if I concentrated too much on making textures. Having already formed a small team, I was much less reluctant to ask for extra help than I had been on previous projects. With this in mind, I asked my old friend Brian Smith, a skilled graphic designer and 3D model maker, to join the team and work on the textures.
I had never developed a game as part of a team before so all of this was a whole new experience for me. I’m pleased to say that I found the whole collaborative working process very smooth and easy to deal with. My teammates were both very professional and delivered high quality work right on time, and they were thankfully tolerant of my requests for changes and criticism! Mikko and Brian wrote their own accounts of their parts in the project, which you can read below.
As was the case with Yoink in uDevGames 2003, I found that the game I had designed was much more complex and time consuming than I had imagined. I still find it difficult to perceive how long things will take at early stages of the project.
My failure to devise a schedule and stick to it meant that many features had to be omitted from the game, so much so that the resulting gameplay was nothing like what I originally envisaged. I had planned to make Rescue a much more innovative game, in which stealth and lateral thinking were your only weapons against a much more powerful enemy. Among some of the features I had to omit:
Another problem in common with last year’s project was the proper scheduling of the development process. I don’t particularly like to work to a fixed timeline, so I spent my first two months producing code and game assets with no regard to the deadline.
Much of the work was comparatively easy and quick to produce, since I had already written similar code for my other games. For example the time-based animation system and simple scene graph were quite elementary and didn’t take long at all. On the other hand, several essential elements ballooned out of control and ate up significant chunks of the development time and my patience. The collision detection system was an especially major source of wasted time.
I also spent a whole week doing nothing but trying to redesign the cockpit model. I had an existing cockpit model which appeared in early versions of the game, but I wanted to replace it with one that was much more immersive and full of equipment. This became a huge source of stress and annoyance because I simply could not get the result I had in my mind. In the end I had to compromise and revert to the version of the model which was closest to my original intent.
I chose to write my own collision detection system from the ground up instead of using a library such as ODE. This seems odd with hindsight, as I was trying to utilize third party code as much as possible, but I suppose I was afraid of its complexity. I have since discovered more about ODE through the experience of other developers, and it seems that it is indeed fraught with tricky problems. Maybe I made the right decision for that moment in time.
I designed a rather complex but crude mechanism which utilised WildMagic’s intersection routines to handle interactions between primitive spheres and capsules, groups of primitives, and rays. It took about two or three weeks to write because I kept deciding that I had made design mistakes and refactoring it. Even after all that hard work it still didn’t work properly, and many of the features were never used in the finished game because they weren’t reliable.
As it stands, my collision detection system is still too crude for my liking, and this shows in various places. For example, the requirement that all objects must be capsules forced all of the asteroids and buildings to be roughly capsule shaped. Unfortunately, you can sometimes still see weaknesses in the system when you get close to irregular objects while looking at the external view. This code will all need replacing in some future version.
While I managed to make good headway into the technical issues of making the asteroid field limitless and the spaceship fly the way I wanted, I didn’t pay enough attention to the little niceties that gamers expect. The title, end of level and game over screens are extremely lightweight in their presentation. There’s no in-game menu; everything is just ‘press a key to continue’ (and it doesn’t even tell you to do that!). Also, there are no in-game preferences and there’s no way of redefining the controls. I did manage to have an editable XML preferences file, but that’s probably too technical for ordinary gamers.
As I expected, I’ve had quite a lot of feedback asking for redefinable controls, so I have put this on my to-do list. Of course, I don’t intend that the game will continue to have a horrible in-game GUI — I shall also deal with this in time.
I did have a little success with the manual I wrote. The final version of the manual was illustrated and had detailed instructions to help novice pilots figure out how to land and escape into hyperspace. I know that many people won’t read the manual, but I’ve had positive feedback from those that did, so I’m happy that it wasn’t a waste of time.
There were several occasions when I was forced to deal with problems that were not of my own making, but which came instead from the way the various libraries and other incorporated code worked.
The first thing which hampered my progress was a strange bug in CodeWarrior 8.3 which prevented SDL_image and SDL_mixer from being linked to my application. A little research revealed that the problem was caused by the underscore in the libraries’ names. I dealt with this quite easily by making my own versions which were renamed to remove the underscore.
The only thing which concerned me about this modification was compliance with the license. Since the SDL libraries were released under the LGPL, I didn’t want to fall afoul of the license’s rather complex wording. My modifications were extremely minor, so I simply asked Sam Lantinga, the author of both libraries, for permission to make the changes without getting embroiled in the licensing concerns. Much to my relief he gave his permission!
WildMagic also needed modifications, although it was less worrying to me because its license permits almost any modifications. The problem was that the programmer had inexplicably decided to use the memcpy() function as a means of implementing copy constructors and assignment operators for almost every class. For frequently used types like vectors and quaternions, the overhead of calling memcpy() all the time was substantial and showed up as a large blip in Shark profiles. At the time, I felt that Rescue wasn’t running fast enough on slower computers, so I tackled this by simply commenting out several of the most commonly used constructors and assignment operators and rebuilding the library. This increased the speed of the game by no less than 30 percent, so in the long run this was a great benefit!
Karl Berg’s OBJ loader was the other component that I changed, and again it was helpful that his license amounted to the freedom to make any changes. In its original state it was only able to support BMP textures and didn’t look for texture and material files in sensible places. I addressed these issues by adding support for SDL_image and adding a function to return the application bundle’s resources folder.
At some point I would like to make some more radical changes to Karl’s code. His coding style, essentially C with classes, doesn’t really marry well with my own, and there are some outstanding bugs I’d like to fix. I plan to strip down his code to the bare parsing routine and build it back up in a way which is more suitable for my purposes. I’d especially like to add features which allow code to examine the model geometry, as this would be useful for collision detection.
I saw this coming but I somehow didn’t manage to avoid it: I reached the uDevGames submission deadline and I still didn’t have any gameplay to speak of. You could fly the ship around, pick up miners and hyperspace to the next level, but there was no threat and nothing to force you to take any risks, so if you were a careful driver you’d be able to play the game forever.
About three hours before the deadline I took the drastic step of adding a simple time limit. This was something I really didn’t want to do because it made Rescue seem very similar to Asteroid Rally, Matt Diamond’s game from uDevGames 2003! At this late stage I saw it as the only way to turn my basic spaceship flight simulator into something like a proper game. Thankfully, it only took me a few minutes to implement the time limit itself and the ‘out of time’ game over screen. Once in place, the time limit did indeed have the desired effect, and it was now necessary for the player to rush from one mining installation to another to complete later levels in time, putting their ship at risk in the process. After a little tweaking of the difficulty level, I finally reached a stage where my game was fun and exciting for me to play, not just mildly interesting! Satisfied that the game was now just about acceptable, I packaged it up and submitted it just one hour before the deadline.
I used the Metrowerks CodeWarrior 8.3 IDE to write and build the game. However, in an attempt to make the source code more accessible to the community I’ve since made an Xcode project as well. This was a useful learning experience in itself!
The spaceship exterior and interior models, as well as the buildings and some of the asteroids, were built using form-Z, a highly accurate and complex modelling package I use for my commercial visualisation work.
Brian used Cinema 4D for UV mapping and texturing the models, as well as making some additional asteroids.
Carrara 3 was used to make the stars and sun. I had hoped to make better use of Carrara since it was one of the prizes I won in last year’s contest, but as it turned out I wasn’t able to learn its polygon modelling feature set in time to do something useful with it. I used Photoshop CS to make the font and various other graphics, while Brian used Photoshop 7 to work on the textures.
For audio, I used Reason, another prize won in uDevGames 2003, just once to make the first sound effect! Had Mikko not come on board to make the music and the rest of the sound effects I would have had an opportunity to put it to better use. Never mind, Yoink still needs music!
Now that that the contest is over, I can clearly see that I made many of the same mistakes as last year. I devised a game idea which appeared at first glance to be concise and manageable, but which with hindsight couldn’t possibly have fitted into the three month development period. Maybe if I had unlimited amounts of free time it might be possible, but when I have to fit all this hard work around a full time job and other obligations and interests, it’s can’t be done.
Still, even though the resultant game didn’t match my original vision, I’ve benefited in several ways. I’ve learnt a lot about several very interesting APIs. I’m now very interested in using the SDL libraries and WildMagic in future projects.
I’ve worked as part of a development team. I’m used to teamwork in my day job, but it’s a bit of a breakthrough for me to be able to share my personal creative work with other people. It has been enlightening to work with other people’s opinions and contributions in mind.
My objective of making a reasonably complete space game engine has finally been achieved. I (and others) can now build upon this project to make more sophisticated games. I now have another partly finished project to hang up on my web page!
Where shall I take Rescue now? I plan to add all of the features I was forced to omit before I go any further. Replacing my home-cooked physics with ODE, renovating the OBJ loader to suit my needs, building the enemy ship models, putting them into the game and giving them AI — all of those things are achievable now that the deadline has passed and I’m free to work at my own pace. It seems that Mikko and Brian are both interested in seeing the project completed, so it looks like I’ll be working hard on Rescue for the next few months.
Neil Carter
I almost cancelled my intention to participate in this contest because I had a great deal of work with other projects going on. But then a big project was cancelled and I had some time again. I found Rescue, which is sort of a slow action game (I was actually looking for an action game), and contacted Neil.
After trying the early version of Rescue, I quickly had a vision of what the music would be like. Neil didn’t want it to be too modern in terms of its harmony, so I followed this rule. I’ve usually created this kind of stuff by using orchestral instruments only, but this time I wanted to add some electronic sounds to it. The ambient in-game track sounds electronic, but actually most of the sounds in it are “real” (low strings, choir). The main theme reappears in the action track too, to make the game audio more coherent.
I also promised to help Neil with sound effects, so I made them after the music was ready. I didn’t notice the rapid passage of time and was actually a bit rushed to finish them before the deadline!
I didn’t have any problems with this project. Communication was great and things worked out nicely. The only thing I got a little worried about was when Neil decided to change the purpose of certain music tracks to deal with changes in the gameplay. Fortunately the game developed in a way that meant we didn’t have to throw anything out. Just some of the sound effects I made have not been used in the game (yet).
I was happy to accept when Neil asked if I would like to produce textures for Rescue. Like Neil, I tend to start lots of projects but only finish a few and so the competition sounded like a good incentive.
The first step was to make sure we could transfer Neil’s models from form-Z to the 3D package I use, Cinema 4D, UV map them and then export the models as Wavefront .obj files which the object loader library could use. We soon discovered Cinema’s .obj file exporter reversed the surface normals. This was easily fixed by inverting the models’ normals before exporting. There also appeared to be a problem with the UV mapping in Rescue. By examining the UV data in Cinema 4D’s Structure Manager I discovered that the first UV coordinate was being zeroed when the models were opened by the object loader library. Neil and myself decided that this glitch should be worked around by editing the .obj model files (copying the first set of vt coordinates to the end of the UV list and then updating all references to it in the f polygon list) to save time hunting it down. Cinema 4D also didn’t export material files with the .obj model files and so manual file editing was required to construct them and link them to the model files.
The most time consuming part of my work was UV mapping the models. This was done in Cinema 4D with the freeware plug-in, UV Toolkit. The asteroids proved tricky to flatten as they had continuous surfaces. I decided to minimise variation in texture scale and shearing at the expense of creating seams. I also chose to stick to a single 512×512 texture for all the asteroids to save time and conserve VRAM. To change the texture scaling to fit the different sizes of asteroid I first mapped the larger asteroids to the full texture space and scaled down the smaller ones proportionately. However, this resulted in a very blurred texture on the large asteroids. I later realized that the object loader would tile the texture if the UV coordinates were outside the 0.0 to 1.0 range and so the smallest asteroids were assigned the full texture space with the larger ones scaled up, to a maximum of 4x for the biggest ones.
For the buildings and tug UV maps I found the best method was to break down the model’s surfaces based on the most suitable type of projection. For example, first I assigned UV coordinates to all the surfaces that could be mapped with flat projection, then all those that need cylindrical projection and so on. With all the elements mapped the largest surfaces were placed and scaled within the UV map. Finally the smaller elements were slotted into the remaining spaces. Much fine tuning of elements’ scales was required to optimize texture space usage. For most models the texture space assigned over its surface needed to remain constant. However the tug cockpit model was to be viewed from a fixed position so I skewed the scaling so that the surfaces nearer the viewer were allocated more texture space.
The textures themselves were based on reference images supplied by Neil (a photo of an asteroid, a shot of the Space Shuttle cockpit and so on) and discussions that occurred as the textures where developed. I took screen shots of the UV maps in Cinema 4D and opened them in Photoshop. All the textures were painted at twice their final target resolution. They were rendered using a mixture of filled and stroked selections and hand painting. Public domain photos from the web were overlaid on the painted texture to add detail to the metal, concrete and stone surfaces. I also placed blurred highlight lines along the model edges where I wanted emphasis.
Overall, given the limited time I had available to UV map and texture the models, I am pleased by the results. I would like to get involved in more game texturing in the future and am sure that what I have learned from this project will come in handy.
Brian Smith
BugThug is the first game I have completed since nine years ago. In that time frame I had gotten very close to completing a game for Mac OS 9, but got caught up in the transition to Mac OS X and had a lot of dead technologies with which I was very familiar. Fast forward to 2004, and I was working on my uDevGames 2003 entry privately. Seeing the entries so far, and reading the rules for this year’s uDevGames, I decided I should enter in the hopes of providing a simple SpriteWorld demo for people to learn from. I dropped what I was doing in the game I was working on before and during the first half of the contest, and dove right into BugThug. In hindsight, it was a very good decision for me.
Read the rest of this entry »
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.
When the uDevGames 2002 Contest was announced I told myself that I didn’t have time to write a full game in three months, but a voice in my head kept telling me to try. After three days of internal debate I caved in and began to work on Black Cube. My goals were to develop it using only inexpensive or free tools, to learn OpenGL, and to deliver a completely finished game by the deadline (I didn’t want players to think, “That was a fun demo, it’ll be really nice once he finishes it.”). Also, the knowledge that I would never have to work on it again after three months was a powerful incentive to keep pounding away at it. I kept telling myself, “Just think, once you finish this you can go back to playing Warcraft III”
I only had three months to write a game from scratch, and in my spare time. Given that my last game took me six years (off and on) to complete, clearly some changes in my work habits would be needed. On the plus side, I have many years of professional software development to draw on now. On the minus side, I now have a family and a demanding job, and not a whole lot of spare time — I needed a plan.
Given that time was not on my side, the number one factor to my success in finishing Black Cube before the deadline was scope control. I have many game ideas (don’t we all?), but fortunately one of them was this puzzle game. The graphics were simple enough that I expected good performance on any machine capable of running OpenGL and Mac OS X, so very little time would be needed for performance tuning. Likewise, the sounds could be quite simple provided they were appealing enough. Granted, I did not know OpenGL yet, and hadn’t yet used Apple’s development tools, but this game seemed like a good project to learn those on.
During the actual programming of Black Cube, I kept my eyes firmly on my goal of delivering a complete game. This helped me cut the right features as the deadline approached. For example, I originally imagined a background story to the game, involving a stellar cartography mission. Mapping the pockets of “dark matter” would allow ships to pass safely through the area of space represented by the board. But as time grew short I concentrated solely on the puzzle element, because without that I had nothing. I can’t say enough how important clear goals and scope control were to this effort. Whenever things went wrong I reviewed the ultimate goals of the project and adjusted my plans.
Deriving the new rules was interesting. An important principle of the original 2D game was reversibility: if you fired a ray in reverse, it would travel the same path as the original ray, but backwards. Most of the 3D rules can be derived from the 2D rules and this principle. The hardest rule to come up with was the 3D corner rule, and even after I had the flash of inspiration that the ray should split in two, I didn’t quite believe that it solved the problem (thankfully my friend John McIntosh understood the rule immediately and convinced me that it worked!)
My biggest fear until the game was finally completed was that the new rules would be too complicated to be fun. Each player has to decide that for themselves, but I enjoy playing the game and I’ve heard from some other players that they like it as well. The rules are rich enough to yield some interesting bounces that are difficult to interpret.
Aside from creating the uDevGames contest, iDevGames offers many useful resources for Mac game developers. In particular, all of Black Cube’s sounds were provided by iDevGames, as was most of the code I used to load and play sounds. Two weeks before the contest deadline Black Cube had no sound, and only a week before the deadline it did.
One asset that I had less control over was the quality of the feedback from people testing the game. Fortunately the friend who had helped me figure out some of the rules for Black Cube took a shine to it and played it a lot. He sent me several pages of useful feedback. He even figured that the deflection rules allow the ray to bounce around the board infinitely! To my knowledge this has never been seen in an actual game, but thanks to his warning I made sure the code handles it gracefully (basically, a ray is “absorbed” if it travels for too long). I also got some useful comments from people who didn’t play the game as much, and it all helped the final game immensely.
As strange as it sounds, the lack of time I had each day to work on Black Cube wasn’t always a bad thing. Rather than jumping in and coding each day, I was forced to think about what I was going to do. During my driving commute to work each day I would mentally design changes to the code, and sometimes I’d realize that my first approach wasn’t going to work even before I’d written anything.
However, the short deadline did force me to cut certain features out. Some examples: the game is not localized for languages other than English, and is not designed to make localization easy. It relies heavily on color and may be unplayable by color-blind people. High scores are not saved. And last but not least, I had to drop plans for a Mac Classic version early on.
Perhaps the worst problem with the game as it currently stands is that it is a CPU hog. One of the reasons is that it polls for events (using the function WaitNextEvent) rather than using Carbon Events. If this were a full-screen game perhaps no one would have noticed, but early in the project I converted it into a windowed app for various reasons. I did get a couple of complaints from players about CPU usage and I may address it in a future update.
My artistic skills are limited, and so are my tools. To model the game arrows I used graph paper and typed polygon coordinates into the code by hand. This was adequate for a puzzle game with simple screen elements, but in the future I’m going to have to invest some time and possibly money in order to make the game art more interesting.
My other artistic failure was Black Cube’s icon. It wasn’t incredibly bad, but it looked like it was drawn by an amateur. Fortunately a passing graphic designer named Jesse Holden took pity on me. After playing the first release of Black Cube he asked me if he could make me a better icon. I really like what he made and feel that it helps makes a good first impression when someone is about to play my game for the first time.
Looking forward, it is clear to me that the kinds of games I write in the future will be limited unless I start to involve someone else to help with the art assets. That’s a big decision for me to make because I get a lot of flexibility by working alone. If I don’t like how a game is turning out, for instance, I can make big changes without consulting anybody. Conversely, when my professional job becomes especially stressful I sometimes have to cut back on my programming hobby.
I relied on sample code to get two parts of the game up and running quickly: Apple’s OpenGL setup code, and iDevGames’s “Core Audio Test” example for my sound code. In both cases there were problems introduced by the sample code that I almost didn’t have time to resolve. For the OpenGL code, Apple’s full-screen example does not allocate a sufficient depth buffer for most 3D applications. I spent over a week trying to figure that one out before I finally got help from someone on Apple’s OpenGL mailing list.
The problems in the sound code were easily fixed, but since I added sound last I would not have had time to fix any significant problems. It also meant that much of the beta testing did not test the sound code. That was an unnecessary risk, but I did have the fallback plan of releasing Black Cube without any sound.
Lesson learned: leave adequate time to incorporate third-party frameworks and code, and put them in the code early so that they get the same amount of testing as the rest of the game.
I am very pleased with Black Cube. Although it is not a game that appeals to everyone (“not twitchy enough” was a comment I heard), the people who like it seem to like it a lot. And of course it feels good to have written a game again, after so many years. I am indebted to Carlos Camacho and iDevGames for the incentive and helpful resources that pushed me to develop this game.
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.
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
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
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.