iDevGames

What Went Right

NeHe and Cocoa

Learning OpenGL and Cocoa in three months is no easy task! The first step was reading my uDevGames 2002 prize, ‘Building Cocoa Applications.’ This is a great book; after reading about 200 pages and building the project with the book, I had a solid understanding of what Objective-C was, and the incredible powers of object oriented programming.

Next was learning OpenGL, which seemed twice as intimidating and complex. Actually, it turned out to be the best thing to happen to this project. Using the tutorials from NeHe, I was able to learn the basics of OpenGL in only a few days. OpenGL allowed me to get a visual start to GL Golf very quickly. Using a height map made in Photoshop, I could create decent quality levels very fast.

A Good Math Background

Having already completed trigonometry and algebra three, along with taking calculus, helped tremendously. When you go down to each line of code, everything is just a bunch of numbers, and most are very simple, but some of them are complex enough to give you a headache. After digging through about 10 different collision detection tutorials, I found one that made sense. After a few weeks of coding, I had collision detection and response implemented, but as I found out later on several occasions, the tutorials had some very big errors. For example, it gave the incorrect equation for finding where a ray and triangle intersect, which caused the detection not to work at all. So to make a long story short, keep taking higher-level math courses, because that’s what programming is all about.

iChat and iDevGames.com

Without the help of the iDevGames community there is no way I would have finished this game. Whether it was something as simple as asking how to convert a char array to NSString, or asking how to get smooth shading implemented, someone was always there. Thanks to everyone that helped!

What Went Wrong

My Stupidity

Often programmers do something wrong, but it still works anyway. This happened to me, and it was such a big mistake that it cost me an 80 percent slowdown. Luckily it was something as simple as calling GL_Begin(TRIANGLES) about 4,000 times each frame, when I really only needed it about 10 times. This alone multiplied my frames per second by five, making the game playable on almost all Macs.

Lack of Motivation

This is the biggest problem plaguing independent programmers today, and I’m no exception. If I programmed 20 hours a week every week of the contest, there’s no doubt in my mind that my game would have been twice as good. I had spurts of time where I programmed 20 hours in two days, and then times where it took me three weeks to get 20 hours of work in. I don’t know any good ways to fix this; you just have to do it, and when you see new results the urge to program will come back.

The Forum

I spent way too much time reading the forums while developing GL Golf. This was both a good and a bad thing. While I received much needed help from forum members, I also drained lots of time there. For some reason I would check the forums as often as I compiled my game, which ate up valuable developing time.

Tools

My primary IDE for GL Golf was Project Builder, with a little help from METAL Basic. I used METAL to reformat my Meshworks animated models to a nice useable text file. I used Meshworks to make the golf club (which will be changed shortly), and Photoshop 7 to do all the other graphic work. I also used Photoshop to make the levels. While it was hard to actually make a hole, one could be created in 10-20 minutes. My development system was a Quicksilver 733MHz G4 with a Geforce2 MX card. This was a good machine to use, because it was an average system, which kept my system requirments low.

Summary

Overall GL Golf was a great experience, and the uDevGames 2003 Contest made it all the better. I now have the knowledge to program a high quality 3D game, and I plan on doing so for the next uDevGames contest. I plan on continuing development on GL Golf, and within the next few months I hope to have a shareware version finished. I am already looking forward to uDevGames 2004, so get ready for another great game!

• Genre:
• Developer:
• Url:
• Team size: 1
• Released date:
• Project length:
• Development hardware:

• Critical applications:

Tools

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”

What Went Right

Getting on the right track

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.

Making my own animation program

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.

Beta testing. Lots of beta testing!

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.

Entering the uDevGames Contest

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”

The Eye-candy

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.

What Went Wrong

No planning

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.

System requirements too high

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”

Sloppy code

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&lt;sup&gt;2+b&lt;/sup&gt;2)&#38;<c instead of if a&lt;sup&gt;2+b&lt;/sup&gt;2&#38;<c^2, which does the exact same thing but runs much faster.

Working alone

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.

uDevGames & the Future

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.

• Developer: David Rosen
• Genre: Arcade
• Site: http://www.wolfire.com
• Team size: 1
• Released date: August 2001
• Project length: 2 months
• Development hardware: PowerMac G4 400MHz

• Critical applications: CodeWarrior, Meshwork, Photoshop, 3DMF tools by Pangea Software, GraphicConverter, GLSee