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 »
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…”
blackcube03.gif
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.
blackcube04.gif
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.
blackcube05.gif
Game screen
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.
blackcube06.gif
Design concept
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.
puzzle,OpenGL,3D,Carbon,ProjectBuilder
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
CodeWarrior is a software development tool for developing games and applications on the Macintosh platform. The industrial-strength Professional series offers support for multiple platforms and is very feature rich. The latest CodeWarrior Professional version includes support for some of Apple’s most recent technology. Long ago, Metrowerks’ product line was divided into Gold and Bronze versions, along with an academic version for students. Expanding into the consumer market, they released the “Discover Programming on the Mac” series targeted towards new programmers. Although the product included several online books and featured an attractive price, it lacked some important features of the higher-end versions. Some Macintosh programming books also include a tool called “CodeWarrior Lite.” This is a limited, trimmed-down version of the CodeWarrior Professional compiler that allows you to compile only the source code that is included with the book, or on the book’s CD-ROM.
I have been using the professional series to develop applications and games for the Macintosh for many years, so I was looking forward to reviewing Metrowerks’ latest product, CodeWarrior Learning Edition. As I waited for the review copy to hit my desk, I thought about the title “Learning Edition.” Which features would Metrowerks leave out in a tool targeted for the rest of us? And with its low price point, would it remain a viable development tool for programmers on a budget? After all, how do you simplify such a feature-rich program without crippling it? I expected to see a somewhat stripped down version of what I’m used to with CodeWarrior Pro 5, but to my surprise there’s nothing missing that a beginner or intermediate programmer would miss. The debugger is even better than my current debugger. Of course there are some features that didn’t make the cut, like the profiler.
The installation process is very straightforward. Just double click the Installer, select the target hard drive/folder and choose one of four options:
I selected “Easy Install” for this review as that’s what beginners would do. The installation program displays a few flash screens during the installation process while a progress-bar shows how many files still need to be installed. (Somewhere around six thousand files in total!)
The CodeWarrior Learning Edition has a simplified installation, which takes less time to install than the full versions, and also requires less space on your hard drive. This allows students and teachers to get up and running quickly.
If you are already familiar with the full versions of CodeWarrior you will notice that the Learning Edition version has fewer tools in the toolbar. This is to simplify the interface for the user. You can add more tools to the toolbar as your experience with CodeWarrior LE increases. CodeWarrior is a project-based development tool, thus a new project must be created in order to use it. A dialog will appear and you can choose a stationery for your project or you can create a blank project. This is also the window where you decide if you want to program in Java or C/C++. A stationery is a template used to create new projects. The stationery will create a duplicate of itself and give it the project name that you assign. As easy as this may seem, it can be daunting to a new user. So, to help the new user, the CodeWarrior Learning Edition comes with training materials. This includes a complete Training Manual and a comprehensive set of Lab Exercises.
There is a wealth of resources on the Internet that new users might find useful. To help them, Metrowerks has compiled a list of some of the best. To get to them simply double click on the file “StartHere.htm” in the CW Learning Edition folder. This launches a homepage with a table of contents that includes a quick start manual, learning materials, and standard documentation. Click on the Learning Materials link to bring up a list of the different areas a new user can look at to start using CodeWarrior effectively. Click on the Learning CodeWarrior link to display the first page of the training manual. At the bottom of the page are buttons to navigate around the training manual. Click on the Guide button to learn how to use the manual. Click on the Lessons button to bring up a series of lessons about CodeWarrior, in which you learn about such things as interface conventions, compiling basics, and how to customize CodeWarrior LE to your individual preferences.
I think most of you will find these resources very helpful. CodeWarrior LE and its Lab Exercises are the ideal tool for computer science classes. There is a set of hands-on lab exercises installed as part of the Learning Edition. These help the students practice what they have just learned in the training manual. If you would like to examine a typical lab exercise go to where you installed the CW Learning Edition directory and open the folder called Learning. It contains several complete lessons about CodeWarrior and programming.
During the last few years, developers have tried to reduce the costs of software development and increase speed to market their applications and games. To achieve this you need a framework that takes care of the things every application needs to do, like handling the eventloop and implementing the basic user interaction. RAD tools allow programmers to spend less time building the application’s (game’s) interface. This frees programmers from coding common parts of the program, and allows them to concentrate on what makes their application unique. A good RAD tool also allows programmers to use WYSIWYG tools to build or draw the graphic user interface of the program. As you create your program’s windows, and other portions of the graphic user interface, the RAD tool automatically generates the source code for you. If you’d like to program in C++ there’s a powerful framework that does exactly this. It’s called PowerPlant and it is one of the most flexible frameworks I know. There is also Constructor, an editor that lets you design the GUI visually. This portion of the package is very powerful but requires a bit of studying before you can become a PowerPlant guru. However, once you learn PowerPlant, you will increase your productivity and simplify your coding. I’m interested to compare PowerPlant to Apple’s Cocoa, the new framework in Mac OS X. I should also mention that there are RAD tools for Java development in CodeWarrior LE.
CodeWarrior Learning Edition is everything I expected it to be and then much more. It’s a great tool for those who are new to using CodeWarrior and to programming. It has a simplified yet powerful tool bar. It also contains comprehensive online training and an abundance of learning resources. The training lets you see what CodeWarrior can do and the lab exercises provide practical experience. This experience is further enhanced with the Computer Science AP package. Combining training with hands on lab exercises helps you to become a powerful code warrior.
CodeWarrior LE is a comprehensive and very powerful tool. And for $49 (US) it’s also a bargain. If you want to learn programming and code C/C++ games for the Macintosh, then pick up CodeWarrior LE. You can also add the latest Carbon SDK (Software Development Kit), which is available from Apple, and you’re ready to develop for Mac OS X.