iDevGames

First stop was Apple’s ProjectBuilder, but I was a bit overwhelmed by Objective-C so my search continued for a tool that had a kinder learning curve. After a few more missteps I came upon a low-cost tool called TNT Basic, by TNT Software.

TNT Basic was everything I was looking for; it was user-friendly, fast, stable, contained helpful tutorials and integrated help. Believe it or not, this was my first experience with the Basic language. With its excellent sprite support, it’s safe to say that it isn’t your father’s Basic.

I spent the next 48 hours working on a shoot-’em-up, a genre which is within the ability of most beginners. Having visited iDevGames almost everyday, an important point was firmly in my head: start with a short game and build on my experiences. It seems that each week iDevGames’ forum has a post from a beginner wanting to make the next Zelda, Quake, or EverQuest online game. That train of thought leads nowhere! Shooters are the perfect genre for learning the ins and outs of game development, and iDevGames’ excellent free game assets make it even easier to finish your first game.

As with many first games, my own project wasn’t so worthy of public distribution, but the process proved to be a great learning experience. I was really amazed at how enjoyable game programming was—much better than game playing! My mind was constantly filled with thoughts on how to add to my games by moving sprites, creating power-ups, and adding polish. The first days of programming are really fantastic and you will find yourself thinking of algorithms to solve various problems all day long. I recommend that all gamers or application developers spend 15 days of game programming!

Similar to many human relationships though, the next period brought my head out of the clouds a bit. At this point, I felt that I had a good Basic understanding of game programming but the “lack of motivation” stage settled in. It took some time to find the right game design, but eventually ideas began to take shape and soon the concept for Radical Rebound was born.
h3. Making of Radical Rebound
The core concept is a shield that would rebound objects. The first design was top-down and featured a sword and shield-welding warrior that deflected bolts while slaying enemies. However, this design didn’t get off the ground since the game asset requirements were beyond my abilities. A quick search though iDevGames’ download section yielded some great game assets made by Carlos Camacho.

With Carlos’ art, and a new game design, version 1.0 of the game (which was approximately 1000 lines of code) was completed in 20 days. Outside of problems recalling trigonometry from my high school days, development went very smoothly. However, Version 1.0 was far from perfect since the background lacked eye-candy. To me, however, it was a dream fulfilled—my very first true game!

postmortems/2003/radicalrebound03.jpg
alt=”Radical Rebound”
h3. Thick Skin and Polish
Flushed from success in my development, it was time to venture to the next step, marketing my title. A bare bones website was launched, and the game was posted to VersionTracker, MacUpdate, and MacGameFiles. I then waited for the flood of emails that I would get for my “first born.”

In hindsight, I was a bit naive, since as the developer of the game I expected gamers to love it as much as I did. I suppose that is to be expected with a first release. The experience did teach me valuable lessons, such as the expectations of the public and feedback from developers. Overall, it seemed that the advice from people who understood the work involved in game development was encouraging, but many gamers expect an A+ level game for their download troubles. Even with a modest download size of 3MB and distributing the game as freeware, some gamers were pretty brutal. People expect good eye-candy and effects, even if they are getting something for free! Thinking on how far I had come in seven short months, the bad reviews were a bit disappointing. Lesson: don’t expect a hit on your first time at bat.

The experience made me take a break from my frenzied development schedule and rethink elements of my game. First on my agenda was to add more polish; once again iDevGames to the rescue. Soon I had great space backgrounds and sprites from the “Insecta” pack. The sprites were a bit dark so I added a glow to them—that really helped in the polish of the game. For the space backgrounds, TNT Basic made scrolling trivial without any major speed hits. Audio was added through collaboration with a musician from the MOD demoscene. Again, TNT Basic’s speed kept right up! Using MOD files in place of the the former music files in the game actually increased the speed. The game was now up to version 2.0 and contained 2000 lines of code. As you might expect, this version was the first to bring in good reviews. Compliments on the graphics and music were often mentioned.

A good game isn’t just about eye-candy and killer audio, gameplay is also an integrated part of what makes a game fun. Thus, I extended the game to contain 40 levels and created four difficulty levels. This version of the game was much more structured and gave you a reason to continue playing it. One small touch was the addition of real names to each level. Believe it or not, some gamers continued through each level simply to know the next level’s name! (Note: The levels in Radical Rebound are generated randomly.) To bring the game up another notch, additional music tracks were added to the end.
h3. Movin’ On Up
Now up to version 2.153 (2,500 lines of code), and the positive reviews started increasing. Things were looking up when something very unexpected occurred: a gamer from England sent me $10 through the mail. As I mentioned, the game was distributed as freeware, yet this gamer enjoyed the game so much that he felt it worthy of $10. There is a special feeling as a developer to have someone enjoy your game, and having them enjoy it so much that the reward is even better and makes all the hard work worth every minute!

Re-invigorated by the donation, I returned to iDevGames to find more goodies to add to my game. I found some amazing cute anime style characters and knew I had to use them in some way. My first thought was to start working on an RPG, but that genre was still off in my future. In the end, I found a way to integrate them into Radical Rebound. Again, I can’t say enough about what a great resource iDevGames has proved to be for this non-artist. The characters were used as players with some Basic stats. The system worked a bit like Street Fighter and added a new aspect to the game. After adding 20 new power-ups I was up to 6,000 lines of code. Back in my Pascal days, if someone had told me that I would someday be making a 6,000 line program I would have laughed him or her off!

With Radical Rebound achieving better reviews, my thoughts turned towards marketing the game as shareware. With a much improved website and payment system through eSellerate, Radical Rebound has been doing very well.

radicalrebound04.jpg
alt=”Radical Rebound”
h3. What went right
h4. Game concept
I may be biased, however I feel that Radical Rebound offers great gameplay. Overall, it takes elements of past hits and adds a bit to them. A colleague of mine mentioned that the game played a bit like Strange Flavour’s Airburst, though I had never played the game until very recently. I feel the ability to move your ship makes Radical Rebound a bit more dynamic.
h4. Low-cost Tools
The world of game programming can seem beyond the reach of many people. The learning curve and costs can be a barrier to many would-be game programmers. On the other hand, low-cost tools can sometimes be underpowered or make you feel ignored by fellow developers who insist that only “real” game developers use C/C++ or Objective-C. It isn’t about the tool but the end product. TNT Basic opens the doors to many people with its low cost and user friendliness, while providing enough power to make most 2D-based games. In the end, I could have spent months poring over books, manuals or documents at Apple’s website, but I picked a great tool and now I am making games with rotations, scaling and transparencies. Another low-cost tool in my “tool chest” is AppleWorks. Though far from Photoshop, it proved very handy for working with images.
h4. iDevGames’ Resources
I used to think that creating a game was mainly a problem of coding. I was wrong, it’s a problem of graphics at least as much. Today’s gamers expect quality whether it is in a box at the store or in the form of an electronic download, and “free” doesn’t get you much sympathy either! My game would not have been possible had it not been for iDevGames, and Carlos Camacho, the designer of most of the game assets.
h3. What Went Wrong
h4. Almost the dream tool
For all the praise I have heaped on TNT Basic (did I mention it costs only $25?), there are some issues that have limited my project. For the most part, it provides respectable speed, however a game with high onscreen object count, such as Radical Rebound, can really push TNT Basic. Complex calculations can also tax it. On my iMac 350MHz, I get 25-27 FPS in Radical Rebound when scrolling the background and moving 30 or so sprites with scaling, rotations, and transparencies. At this point, I may be reaching the limits of TNT Basic, so to enhance Radical Rebound I will either need to optimize my code, or wait for the next TNT Basic upgrade.
h4. Low-cost Image Editor Wanted!
AppleWorks is an amazing value, but its scaling is pretty horrible. On Mac OS 9, it had a tendency to crash on my system. Overall, it is a handy tool but no Photoshop. In fact, it doesn’t even come close to the excellent Mac image editor Color-It!. I’m unfairly picking on AppleWorks mainly because of the lack of low-cost image editors for the Macintosh, so hopefully a savvy programmer will bring one to the market!
h4. Lack of Testers
My website is hosted by a friend and uploading new playables can be a chore. This limits my ability to work with beta-testers. Thus, most of my testing is done on my own machine. Not only does this workflow affect bug testing, it leads to lost time that I could be spending on development.
h4. Missing uDevGames 2002
Unfortunately I learned how to program games a bit too late as uDevGames 2002 was finished before I felt comfortable with my new hobby. With uDevGames 2003 starting later than I expected, the release of Radical Rebound removed the opportunity to enter the 2003 contest. I think entering the contest would have provided more motivation and feedback, and increased the overall polish of Radical Rebound.

radicalrebound05.jpg
alt=”Radical Rebound”
h4. Self-publishing
With the work involved in creating a game, a developer can easily feel that they deserve every bit of the profit that the game generates. Self-publishing can be very rewarding but it isn’t always the best route to take. Time spent dealing with the business end is time away from development. In the end, seeking a publisher makes sense in terms of getting the game noticed and reducing support problems. I highly recommend that budding game developers with a good title on their hands shop around for a publisher.
h4. Dealing with Bad Reviews
Releasing games is like releasing your kids into the world; you want everyone to like them. How you handle negative reviews defines you as a developer. With my limited experience, it was too easy to want to strike back at the people who posted feedback like “Stupid, don’t bother downloading.” It’s like a slap in your face, and can really kill your motivation, as it did at times in my case. My parting advice is that in time you will develop a thick skin, and learn to take the bad with the good. Of course, this doesn’t mean to ignore criticism; in fact, you should examine it, and try to understand the viewpoint of the gamer as much as possible. In addition, don’t expect that your first game will be a hit. In most cases, it will flop, and the next one as well. In time though, you’ll start seeing those 5 star reviews and gain the respect of your peers, something that is extremely rewarding!

* Developer: Matteo Guarnieri
* Genre: Arcade
* Site: www.radicalrebound.com
* Team size: 1
* Released date: August 27, 2003
* Project length: 7 months
* Development hardware: iMac G3 350, iBook G3 400
* Critical applications: TNT Basic, AppleWorks

radical,rebound,matteo,guarnieri

ishell01.gif Tribeworks

Overview

Tribeworks’ iShell is a multimedia authoring solution, much like Macromedia’s Director and the now defunct HyperCard. It can handle web streaming of videos, MP3s, and Flash. It also supports XML and several Internet protocols including: HTTP, FTP, RTP, and RTSP. Access to documents is URL based, so iShell can easily retrieve remote files through the Internet. Unlike Director, however, it cannot do true 3D or export to Shockwave for the Web.

iShell is based on an editor-runtime approach which works surprisingly well. Among other things it allows for one project file to be run on both Mac and PC seamlessly. Essentially, one can author in either platform and distribute on both because each runtime is tailored for its designated platform and reads from the same data file. Also of note is that a project can be time-based or event-based, or even a combination of both (e.g. have events trigger time-based animations). This is evidently more flexible than Director’s approach, which is always time-based. With iShell the interface is much more adaptable to what you are doing.

Installation

The authoring environment works both in Mac OS 9 and Mac OS X. Though apparently it is not Carbonized—a different binary is offered for each system, so you still get native authoring whichever system you use. However, be aware that iShell is strictly being supported and developed for Mac OS X 10.2 (Jaguar), and in Mac OS X 10.1 suffers some deal-breaking bugs. Keep away from Mac OS X 10.1 like I should have done. In my experience, running iShell in Mac OS X 10.1 won’t break anything essential, but has some nasty bugs. For example, the lack of working mouseUp events in the runtime can jam a presentation at the worst of times.

The whole of iShell takes up no more than 3MB, editor and runtime, although it will be more if you insist on having the manual and the nifty modules which add functionality to the program. Normally the tryout version would only last 30 days, but Tribeworks is considering releasing a no-time-out version for evaluation. There would still be restrictions, such as a requirement to purchase a commercial license for distribution.

The Container Metaphor

My RPG’s GUI

ishell02.jpg

The main driving force behind iShell is the concept of containers. Briefly, every element used in a project is placed in its container (or shell, if you prefer) and acts just like an object in Cocoa or similar OO(Object-Oriented) languages. Now on their own these containers simply exist without accomplishing anything. In order to move things forward you have to connect them together through the timeline and triggers or through an event-response system.

This is all achieved with three key types-elements, commands, and eventsand their interactions. For example, one could assign a mouseDown event to an image element representing a button and this event would send commands that change the contents of a text element elsewhere. Special commands like Set, Get, If, ElseIf, While, and others are used to create more complex behavior. One of the strengths of iShell for easy development is that everything has pop-up menus with which to select the right parameters-you don’t have to type any actual code. For those who’d like to do even more intricate things you can write scripts in a language called Key, and it is also possible to create plug-ins to extend the functionality of iShell. Another important factor in all this is the full integration of QuickTime.

Using iShell For Game Creation

It seems that every time a new product lands on the market that can potentially create applications with a basic level of interactivity, someone gets the ever-so-bright idea that it can be used to make games. Well, if something as basic as AppleScript can be used that way, then surely iShell can do better. Because iShell is really at its best when doing what it was built for, which is making presentations; games that leverage this will make best use of iShell.

In spirit, it is similar to HyperCard, and hence games like the Myst series are the kind iShell can do best, especially considering its integration with QuickTime VR (QTVR). In fact, the game The Crystal Key made extensive use of both iShell and QTVR. For my example project, I’ve chosen to do a retro-style Role Playing Game (RPG) since iShell immediately triggered memories of the HyperCard days when large numbers of RPG stacks were produced. Also, my first ever project with Director had been an RPG which ran aground quite quickly since the tool did not fit well with the project.

Currently, there is no easy method for direct image manipulation, therefore some game types should be avoided. Most notably, iShell does not do true 3D games, but most 2D games ought be fine so long as the sprite count is rather low. Allow me to explain why. For each of a game’s sprites, you will need to use a container. Every container uses a certain amount of memory space, and also some visual space during the editing. If your game board is an 8×8 grid, that makes 64 containers to track at all times. Also, it makes 64 entries in the editor, which takes up a lot of screen real estate. For a fast machine the theoretical sprite limit is higher, but things will get quickly bogged down on slower machines.

Games that can be created with relative ease in iShell include basic arcade games like Asteroids or Space Invaders, and virtually any turn- or event-based puzzle game. Keep away from tiled scrolling games that are fast-paced, such as a tiled Reckless Drivin’. There are currently some issues with the timers-they fire precisely but not consistently-that can cause sprites to fall a few pixels short of target.

Pieces of The Puzzle

ishell03.gif Screenshot 2

The first file created when a new project is born is the .xp file. This is what gets sent to the runtime to execute. This is where the settings of the project are made, including the size of the window and the main .xd file that is first loaded when the project is run. Every included media file is listed here, as well as the global variables, the triggers, and so on.

However, where the bulk of the work will take place is in the .xd file. Think of these .xd’s as the different cards in a HyperCard stack. You can have as many of those as you’d like and they can be used in exactly the same way as cards. Each .xd file has its own timeline along with its own set of attributes, elements, events, and properties. Everything is neatly organized and when a container that contains something is minimized, its contents are briefly listed as well.

The usual drag and drop behavior is supported throughout the environment and if you want to add an image element, it is as simple as selecting that element from the toolbar and dragging it into the element heading of the .xd file. You’ll note that on the upper right hand corner of the window there are two little squares depicted. These offer you easy access to the layout window and the .xp file respectively. The layout window also offers these two access points that lead to the .xp and .xd files. This ingenious idea of easy access points from window to window helps manage window clutter efficiently and elegantly. Also, once you’ve got an element that includes complex command structures or something similar that you may want to reuse, you can simply copy and paste them.

Laying It All Out

ishell04.gif Screenshot 3

Every time you drag an element onto another it creates a hierarchy that is respected when moving elements on the layout window. Moving a master image element will move the attached image elements proportionally. When you drag an event on an image element, the event is placed under the image heading and so on for commands attached to events.

As can be seen on the interface screenshot, I decided to set up a 8×8 grid of flipbooks (described below) to display the contents of the room. The statistics of the character are placed to the left of the grid and are affected according to what is going on in the grid, such as a battle. A short description of the room is placed directly below and an input field is placed below that to interact with objects that are not immediately visible or part of the scenery—for example, a candlestick to open a secret door. Movable sprites are placed above this grid for monsters and visible objects.

The main method of creating sprites, and thus animation, is through the use of flipbooks. These are apparently unique to iShell, which is unfortunate because of their tremendous abilities. Basically, one would create an image element whose URL refers to a master image. A master image could contain all of a character’s animation frames, or all possible tiles used in a dungeon.

What the flipbook does is allow you to subdivide the image element into rows and columns where each entry would represent one image of the sequence. By changing the current index of the flipbook over time you can achieve animation and many other neat visual effects. One way to animate a flipbook without going through the timeline is to use the Tween command/event combination. Essentially the flipbook contains a Tween element that is activated through a Set Tween command under specific conditions.

Tank Brigade Tween example

ishell05.gif

Adding in Interactivity

Great, so now the window is set properly, you’ve included every file and (due to great planning) every possible variable as well. All the elements are in place, including images, sounds, planned fields, and text boxes for your first screenful of goodness. Using the layout window you’ve even dragged and dropped everything in its right place and resized them to your heart’s content. But when you hit that run command there’s just one thing lacking: interactivity.

There is the keyboard event that is triggered whenever a key is pressed. One could use this to animate a sprite on screen by associating a tweener as discussed above. However, as my goal is an RPG and not a fast-paced game, there is another way. As you may have noticed in my interface, there’s a little box at the bottom that does not contain anything. This box is an input field where the user enters commands recognized by my game’s logic that create various effects. Although it is not very advanced in its current iteration, the player can both look and move around, examining key features of a room.

Now, every command in my example is triggered on the basis that the user inputs the right line and presses enter. The keyboard event can respond to most keyboard input but does not cover alt-, command-, or control-key combinations. For my example, I set up directional commands (“north”, “east”, “west” and “south”) and some specialized commands like “look.” A great tool for interactivity is the switch command. I made use of it to change the description in the box just above the input box where the room is described. By entering “Look Floor” the description will be switched from its current .rtf file to the floor.rtf file which describes a loose stone in the floor to which the user could eventually apply actions with other commands.

Input commands

ishell06.gif

Similarly, the character sprite shown on the grid can be moved one square west by entering the “west” command which will also trigger the sound of someone moving. Through the use of triggers, items and enemy AI can be introduced to complete the RPG experience. Moving from room to room can be accomplished by switching the .xd file for another one that represents the room moved into—again, much like a HyperCard stack would function. Another way to move locations is to use hotText and the browse command, exactly like a web-page would do it. Along with that, a transition could be added to help polish the game. Transitions are very easy to add, just put in the effect or effect lite command in the appropriate position (before the switch), play with the settings, and enjoy.

What If Something Goes Wrong?

It isn’t always obvious how a certain command works or what exactly it wants as parameters to successfully deploy. Or perhaps you’re trying a very complex series of specialized commands that don’t work out in the test. Fortunately, iShell includes a solid debugger with the usual suspects: breakpoints, a log, and the means to keep track of variables.

However, this debugger goes one step further by offering the means to debug without breakpoints. That’s right, you can follow every step without interrupting the flow of your project by using a trace. Although it will ruin your time-based effects and animations, it can quickly find the culprit, and saves you the trouble of having to press for the next step after a breakpoint. Generally that is enough, especially given that iShell includes pop-up menus for almost every parameter of a command or event, which helps reduce silly errors caused by typos or a missing character. The whole of iShell itself seems to be geared toward not only ease of use but also programming speed.

The Less Elegant Side

ishell07.gif Screenshot 6

Generally speaking, the interface has a very clean feel, but it sometimes felt sluggish when a number of windows were open in the background. It’s generally a bad idea to test and edit simultaneously; sometimes it’s difficult to tell between the layout and test windows. It was a little odd testing through the windows menu rather than the file menu, but you get used to it. The elements of a project file are usually listed with an icon and label, but for projects containing large quantities of elements with similar names and functions this becomes very unwieldy, especially since there is no other way to display them. A good example of this is the grid squares used to display a room in my project; that makes 64 entries on the project list that really represent only one part of the project. The windows can magnetically stick to certain parts of the screen (somewhat similar to Interface Builder’s guidelines), but having more points on the magnetic grid than the edges would have been handy.

One thing I greatly appreciated was the ability to organize things easily, like placing the grid flipbooks under the background image. This meant I could both reduce the amount of elements visible in the outline and also move them all at once by selecting the background image. Still, it’s not entirely bug free: while working with .rtf files and special effects, I noticed that one file I placed in my project came out incorrectly in the editor (although it worked fine in the runtime).

Working with iShell can be tedious when you don’t “get” how something works. My first days with it felt like a nightmare. Not only did I not know how anything worked, but the short PDF manual gave me far too little information on how to use features and only explained what they do—even then it was very miserly with information. In fact, things were extremely rough throughout the review time frame, until some tutorials and samples started appearing on the website for version three. Before that, everything they had was for version 2.5 (which was not Mac OS X native).

iShell Version 3 will be available shortly, and if you’ve tried it before but flunked out due to inadequate documentation, then try it again, you won’t regret it. Still, to ensure the best possible experience, use Jaguar and not Mac OS X 10.1. It will save you a few headaches and your bug reports won’t fall on deaf ears.

Conclusion

iShell is well integrated with QuickTime, which is clear from its ease of use when it comes to adding sound and video to a project. One of the more interesting sample projects displayed by Tribeworks is an MP3 player. It could be easily expanded to include iShell’s streaming audio capability to offer a powerful application built very quickly. Once one becomes a master of this application, projects can be generated at a rapid pace, in large part due to the reusability of elements and also because of the general ease of use of the application itself. There is something of a learning curve, but with the appropriate book things should move along. The extent of iShell’s commands is not very great, and that is a good thing. This is in sharp contrast to Director’s more-than-full feature set, with its impressive array of semi-obsolete or redundant commands.

One of the key features missing from iShell, however, is anything like Director’s imaging Lingo to allow for direct image manipulation—with this, the possibilities for game creation with iShell would increase tenfold. Perhaps the biggest draw is the cross-platform capability; for roughly the same price as Director you get to play on both sides of the fence. To do the same with Director you’d have to buy the program twice, once for each platform.

• Rated 08
• Version: 3.0
• Category: Multimedia authoring tool
• Developer: Tribeworks
• Url: http://www.ishell.com
• MSRP: See store for details.

ishell,3,tribeworks

articles/2003/kgagolf02s.gif

alt=“Screenshot”

Project Details

The final version of KGA Golf was 2MB compressed. This included the game, all the necessary game assets, and two courses: one 18 hole and one nine hole. I would have loved to include more holes, but I simply did not have enough time to make them. I was ecstatic when Jesse Holden, a player who had stumbled across my game and was kind enough to create some holes, submitted a nine-hole course for inclusion in the game.

Development started in July 2002, but made no real progress until September, after I found out about the uDevGames Contest. The game was finished on November 19, 2002. Development began on an iBook 500, but in October I got a beautiful new G4 iMac. This really helped things since my entire system felt spunkier, and I could multitask much better. Most importantly, it stopped me from using the non-ergonomic laptop. I was having wrist pains, which I’m still a bit worried about, and that is why I decided to purchase the iMac. The movable screen is absolutely wonderful, and I would encourage anyone who does a lot of computer work to invest in the iMac’s comfortable movable display.

Using my development environment, MetaCard, I knew I could take many things for granted and concentrate on actually writing my game. Tools like a hole editor and course editor, though they would take extra time to create, would be essential for both myself and anyone else who would be interested in creating courses. I considered it essential to develop both those tools.

articles/2003/kgagolf03.jpg

alt=“Screenshot”

What Went Right

Peer Feedback

Getting good feedback from users is an essential part of making good software, and I received some absolutely invaluable feedback from people on the iDevGames forum. This included many common sense things that a programmer can overlook in the heat of trying to get the #$!@% thing to work. My Aim slider initially suffered from poor design. A member in the forum said I should make the aim move to the left when the slider is pulled left, and the same for the right. I had never considered such a tiny, but essential, part of the game, so I’m glad other people noticed and informed me of silly problems like that.

I also had great feedback from people in my dorm. My neighbor loves Macs, and we share many files, so I just sent him my game and he started playing, finding lots of bugs and giving me his honest opinion. Others on my floor also tested my game, even those with PCs, because MetaCard allows me to build my project as a Windows executable.

Encouragement to get the game done was great, too. I casually mentioned I was entering a contest to a few people, and they kept inquiring, “How’s the game going? Is it done yet?” Simple questions and encouragement like that can mean the difference between finishing a game and letting it slide away into oblivion. For programmers who write games completely by themselves-like me-I think a good system of friends is one of the most important aspects of finishing a game. They’ll keep you going when you don’t want to, or don’t think you can finish. Of course, it’s also a little difficult to answer the question, “So, Karl, did you win?” with a whimpering, “Uh… no.” But that makes one want to do all the better next time around! I just hope my grades don’t suffer as a result.

Zero-fault Programming

Earlier in the summer I read an article on iDevGames called “Zero-Defect Software Development.” MetaCard lends itself to this type of development wonderfully. Each piece of code (which is actually script) is contained within its own object, so modifying a script in one place will usually not affect other objects.

articles/2003/kgagolf04s.gif

alt=“Metacard IDE”

articles/2003/kgagolf04.jpg

As long as I didn’t incorporate a script until I was sure it was tested and stable, I would have a game that could be distributed immediately and without worry. Unfortunately, some odd bugs did show up in the end, but they were limitations of my development environment more than my own coding. Still, slightly better Quality Assurance testing would have been beneficial. MetaCard is a scripting, Object Oriented development tool. It’s similar to REALbasic in that you can simply draw out controls onto the screen. However, MetaCard scripts do not compile, but are interpreted at run-time. While this may lead one to believe command execution would be quite slow-like in the days of Apple’s HyperCard-speed is not really an issue. KGA Golf itself can help you determine how fast MetaCard really is, and whether it’s something you’re interested in using in your own projects. Being an old HyperCard guy, MetaCard is perfect for me.

Easy-to-implement Graphical and Sound Touches

After releasing one of the first betas of the game, I realized that my graphics and overall presentation were quite shoddy. I decided to experiment with implementing textures in the game by writing script for about ten minutes. Though doing this essentially negated the ability to choose custom colors for ground types in the course editor, it provided a much better player experience, making the course actually pop out at the player rather than appear to be construction paper cutouts. I also implemented most of my sound quickly, near the end of the development cycle, using some sounds from iDevGames’ download section.

articles/2003/kgagolf05.gif

alt=“Course Editor”

Reasonably Good Planning

When I first decided to enter the contest, I laid out a plan of action for myself. I set one task to be finished each week for the next six weeks. Each task was not very difficult to do. I actually had real bullet points that I could check off, which is an important thing to have for yourself, as I had learned from previous projects. Having specific goals is invaluable, especially in time-crunch situations like this. However, as I discuss later, I got lazy.

Hole and Course Editors

Easily creating holes and courses was something I wanted to do since I began the project, and I knew I had to develop hole and course editors. I personally understood the editors, but unfortunately I didn’t get around to making them user-friendly for others. Documentation was essentially nonexistent, so I’m not surprised that very few player-created holes were sent to me. However, I must thank Jesse Holden once more for submitting nine holes. I feel these were very important to the game since players could finish a game on his course much more quickly than on my 18-hole course. It gave the game more of a pick up and play feel.

The course editor was put together very quickly, since I did not have a good idea of how to store course data. Deciding on a format was rather important, since I wanted to have full backwards compatibility between new and old versions of the game and courses. I decided on a scheme and, for my own purposes and considering the deadline, it turned out fine.

articles/2003/kgagolf06.gif

alt=“Hole Editor”

What Went Wrong

Lack of Feedback from Testers

Most of these testers are people I know personally who simply use the computer, so there was no real pressure for them to get back to me. iDevGames’ forum, however, was awesome. I got pages and pages of replies about my game, which I printed out, made check boxes out of requested features, and am currently incorporating into the next version of KGA Golf.

Lack of Motivation.

When working on a team, the team members can encourage each other to get working and get something finished. Each team member expects the others to complete their parts and be serious about finishing the project. When working alone, however, one can get very lazy and simply do things other than work on a game.

I guess I’m not using the word lazy in its truest sense. This game was written entirely while I was preparing for and attending my first semester of college. I had many other things that demanded my attention, and not only homework, though I did have a couple of challenging classes. Overall, I’m happy with the finished product, but I do wish I could have been more focused on actually finishing my entry little by little instead of giving such an intense effort near the contest deadline. Almost all video game postmortems written nowadays talk about a huge rush at the end trying to finish the product, which I see as saying something negative about the industry… but, hey, I’m not waxing philosophical today!

articles/2003/kgagolf07.jpg

alt=“Screenshot”

Download Statistics

Because I feel there’s a lack of data (i.e., cold, hard numbers) regarding how many downloads games receive, I’d like to mention how many KGA Golf received. From November 18th to the 30th, KGA Golf was downloaded approximately 11,000 times. 8,600 of those downloads were for the Mac OS X version, and 2,500 were for the Classic version. The Golf Editors were downloaded around 2,500 times, with 1,800 of those being for Mac OS X, and 700 for Classic.

It is interesting to note the percentage of people who downloaded the optional hole and course editors. About 20 percent of Mac OS X users downloaded the editors, whereas 29 percent of Mac OS 7-9 users downloaded. Are Mac OS Classic users more creative than their Mac OS X counterparts? Eh, probably not.

As far as downloads and feedback go, KGA Golf was my biggest game launch ever. No doubt the contest helped out a lot. An article on MacCentral was also a huge boost to the game; the day that was posted I got about 3,000 downloads.

From December 1st to the 9th, after the hullabaloo of the contest (though during a time when Inside Mac Games featured my game on their site), the Mac OS X version received 2,200 downloads, while the Classic version received 700 downloads. The game was also included in the monthly magazine ‘MacPeople’ in Japan.

Conclusion

KGA Golf was completed on time, was polished to my level of satisfaction for that time period, and, I think, was fun to play. The game was quite popular, garnering 11,000 downloads in a little under two weeks. The fact that it placed 12th overall out of 41 games, and 8th in the gameplay category, highly pleased me. Overall, KGA Golf is a success in my mind, even if it didn’t win any prizes. The feedback I received and the fun I had creating, playing, and watching others play the game was a worthwhile experience in and of itself.

• Developer: Karl Becker (KB Productions)
• Site: www.karlbecker.com
• Genre: Sports
• Team size: 1
• Released date: November 18, 2002
• Project length: 5 months
• Development hardware: iBook 500MHz (384MB RAM), iMac G4 800MHz (784MB RAM)
• Critical applications: MetaCard, GraphicConverter, Adobe Photoshop, AppleWorks, Fireworks, iCal, iTunes

MetaCard,Zero-fault programming,zero-defect software development,HyperCard,

I’m Kicking Myself

I had decided not to look into Cocoa and Objective-C, as I already have enough projects and miscellaneous work on my hands as it is. I told myself that I don’t need more trouble. However, after a few subway hours with Aaron’s book, I’m hooked.

On the back of the book it says: “The practical guide everyone says you need.” I don’t know about that, but now I at least feel the need for Cocoa. And that could be interpreted as a good mark for Cocoa, but I can assure you nothing less than this book could have pushed me over the edge into giving it a try. Aaron says it pretty well in the introduction: “You will love Cocoa, but perhaps not immediately.”

In Safe Hands

What comes to mind when I try do describe this book is the word “safety”. Aaron doesn’t allow any doubt or low self-esteem, and it is clear that he’s an astute teacher. He starts off with a few short paragraphs on how to read the book and how to think when learning Cocoa — a short pep talk. Then he does what no other programming book I’ve read has done, and which worked surprisingly well with me. I’ll quote him clean off the pages: “Many books would start off by giving you a lot of philosophy. This would be a waste of precious paper at this point. Instead, I am going to guide you through writing your first Cocoa application. Upon finishing, you will be confused, and ready for the philosophy.”

And my, that worked really well. When the first chapter is through, a short Cocoa application is under your belt, and you have, without even noticing it, gone through Project Builder, Interface Builder, and a little Objective-C. After that, a short bombardment of Objective-C knowledge, and then you’re off into Cocoa. One thing to notice is that Aaron effectively avoids making the reader feel bored at any point. The boring stuff is sprinkled among the fun, meaty parts of the course, and his natural and nice language makes it all very pleasant to go through.

Aaron’s style of writing is vocal and very humble. You feel appreciated and noticed through the entire book. It’s like taking a private lesson, really. It’s a brilliant introduction to Cocoa, and if you feel like you need that little push in the right direction to get going, then I really suggest that you pick up this book. According to other reviews of it, it seems that it truly is the best entry point (however, this is the only book I’ve read on Cocoa so far, so I can’t second that). The only thing I can complain about is the ordering of the chapters. Although they feel very fluid, I’m sure that a slight reordering could make the trip through Cocoa even more natural.

But hey, that’s being picky. You’ll go through all the chapters anyway, just for the fun of it. I really can’t complain about anything here, I find it to be a very solid book. Aaron’s intention is not to make you a full-fledged Cocoa programmer, but to help you over the hump in the learning curve, and he comes through with flying colors, staying true to that intention. From here on, it feels like a no-brainer to take on Apple’s Cocoa Documentation.

Conclusion

Whether Cocoa is right or wrong for you, I can’t say. I know I’ll do a lot of Cocoa for writing editing tools, but if you feel the least urge to look into it, I strongly suggest this book.

Related Books:

• ‘Cocoa Programming’
• ‘Learning Cocoa with Objective-C, 2nd Edition’
• ‘Cocoa Recipes for Mac OS X’

416 pages 1st edition (December 3, 2001)

Addison-Wesley Pub Co

ISBN: 0201726831

http://www.amazon.com/exec/obidos/ASIN/0201726831/idevgames-20

nost02.jpg

Atari ST

What led you to create an Atari ST emulator for the Macintosh?

I have always missed some great games from my Atari: Elite, Bubble Bobble, Defender of the Crown, and some others. One day I saw PaCifiST, a great and maybe the first real ST emulator for MS-DOS. I wanted such software on my Mac, so I started to study the UAE (an Amiga emulator) source code because it also uses a 68000 CPU. Five days later, I started to write NoSTalgia, and one week later it was far enough along to display the GEM¹ desktop. At some point, I demoed the emulator to a friend and he convinced me to compile a public version. A few days later, NoSTalgia 0.1 was released.

Can you describe the tools used to develop your emulators?

I have used Metrowerks’ CodeWarrior to write all versions of NoSTalgia and PowerST. CodeWarrior was fast and easy to use, albeit a tad expensive. I recently switched to Apple’s free developer tools for Mac OS X, ProjectBuilder. There is a lot of documentation about the ST hardware on the Internet, including the source code of some ST emulators. The developer of PaCifiST, F. Gidouin, greatly helped me, in addition to the ample documentation on the MFP ACIA (Circuits of the ST), and helped me to find some bugs.

nost03.gif

Atari GEM OS

What is most challenging in creating an emulator?

Writing the MFP (interrupts controller) code was not easy. This is because most programs and games running on the Atari ST intensively use the hardware. That’s why you have great programs but poor compatibility between all the Atari hardware.

NoSTalgia appears to be compatible with most Atari ST software. A few, however, don’t work or lack sound. What are the causes?

The sound part of NoSTalgia-MIDI and normal audio-was written by Francois Menu, and with his latest code, the sound is now working correctly. However, some software is incompatible with NoSTalgia because emulation on any level is very difficult. In addition, programs that used some type of “tricks” are very difficult to emulate. Of course, sometimes it’s just a bug, but more often than not it comes down to a limitation of the emulator. I should mention that some things are not emulated to keep performance at an acceptable level. Hopefully with the help of the users, I can debug and fix programs which have problems running correctly.

Can you describe your experiences in Carbonizing the emulator and challenges of working with Mac OS X?

It was really easy to port the NoSTalgia emulator to Mac OS X, taking only two days. That said, Mac OS X is a true multitasking OS and some portions of the emulator needed some adaptations (i.e. graphic interface, and speed control of the emulated CPU).

Do your emulators take advantage of technologies such as OpenAL or OpenGL?

No, I’m focusing on the compatibility with the Atari ST software first.

Many die-hard Atari and Amiga users refuse to let go of their platforms, and we even hear occasional attempts to introduce new machines. Do you think there is any market for new models?

Not really. I can’t see any application, software or hardware-wise, that a Macintosh or PC wouldn’t be able to handle. The Atari ST was a great machine, especially for having a built-in MIDI port, but its time has passed.

Is there any hardware which hasn’t been emulated that you would like to see available for the Mac?

Not really, as I am only interested in one platform, the Atari ST, and NoSTalgia handles all my cravings for classic computing. I do however sometimes use VirtualPC to run Steem and PaCifiST (both are Atari ST emulators) or a C64 emulator to play M.U.L.E..

On the Macintosh platform, the current king of emulation seems to be Richard Bannister. Have you tried his emulators or spoken with him?

Yes, Richard Bannister helped me a lot with the first version of NoSTalgia. In fact, some parts of the source code are from him. Remember, NoSTalgia was my first “public” application. He was a tremendous help with the design and performance.

nost04.gif

ProjectBuilder

Emulation has come a long way, and today’s emulator fan can even emulate computers and consoles that were recently placed into the marketplace, such as Nintendo and Sega consoles. Do you think the interest in emulation for older classic hardware is fading?

Not really. I have a lot of feedback from NoSTalgia users. They like the old games better than the new ones, even if they do have much better graphics and sound. I think these games are appealing to users because their concepts were easier to grasp and get right into. The game Elite is a great example.

What language are you using to develop your emulators?

NoSTalgia is written in C, with Assembly code for the monochrome screen drawing code. PowerST uses an Assembly CPU core; it’s three times faster but less compatible and not compatible with Mac OS X.

With the speed of today’s processors, it seems many programmers have ignored Assembly. What are your thoughts on this?

In the case of my Atari ST emulators, the screen rendering code uses most of the CPU time. The emulator’s performance is very dependent on the CPU, the system bus and video. For example, in NoSTalgia, I modified the screen drawing code to use only 32 bits access. The performance of the emulator almost doubled! I think that Assembly code is not easy to write for a CPU like a G3 or a G4. In addition, most modern compilers produce very good code.

Your emulators are distributed as shareware. As a somewhat “niche” product, how are sales going?

NoSTalgia is free, while PowerST is shareware. I’m not trying to get rich with these emulators. To be frank, it’s not really fun to see serial numbers of PowerST on the Internet after so much work. And so that is why work on PowerST was suspended.

What are some of your favorite games from the Atari ST era?

Elite!!, Bubble Bobble, Defender of the Crown, Captive, Colonial Conquest, and Dungeon Master.

Is there any feature from the Atari ST’s Operating System (TOS) that you would like to see implemented on Mac OS X?

Not really, but I like the fact that the TOS is only 192kB of ROM. Mac OS X consumes 1GB on my hard disk. Also, my Mac boots in a little over a minute while my Atari ST could boot in five seconds. But I suppose that is progress for you.

The Amiga and Atari ST featured great 2D graphic games, along with very nice sound, while being based on a 16-bit CPU. Looking at some 2D games for the Mac available today, they often seem to lack the speed, graphic wizardry and sound. What is your view on today’s 2D games compared to what was available for the Amiga and Atari ST?

I think most of today’s games are not optimized, and of course stay away from Assembly code for portability. Overall, I think most developers don’t do enough to really try to optimize their software (RAM and CPU usage).

There is a new Atari ST emulator from Germany called “MagiCMac.” Do you keep a close watch on your competitors?

Yes, of course. MagicMac is great but it’s for “serious apps.” What I mean by this is that MagicMac is not an emulator per say, it’s “Magic” (an Atari ST line OS) for the Macintosh. NoStalgia is a real plain Atari ST emulator—for games, MIDI, and other software.

The Atari ST, like the Commodore Amiga, was based on Motorola’s 680X0 processors. The Mac version of the Amiga emulator “UAE (Ubiquitous Amiga Emulator)” seems to be in limbo—have you ever considered working on an Amiga emulator?

Not really, although I do have the source code of UAE and I also helped to debug some CPU bugs in it. I’m not really qualified to work on an Amiga emulator since I don’t even know how operate a real Amiga!

Most emulator developers are careful in stating that they do not provide ROMs, and that users should only use ROMs that they legally² own. However, it is pretty clear that the vast majority of emulation fans do not own the games and software they are using with their emulators. What is your view on this subject?

I don’t distribute ROMs or software since it’s illegal.

nost05.gif

Xenon 2”

Creating an emulator seems to be a complex undertaking. Why not develop shareware games for the Macintosh instead?

Because it’s a challenge for me, and I have written NoSTalgia to play my favorite games. As I said earlier, I’m not really trying to generate income, I’m more interested in re-living the games I so much enjoyed from the past that I owned.

At their height, the Amiga and Atari ST boasted much better hardware and software than IBM and Apple’s offerings. However, the world moved towards these platforms. Can you briefly give your view on what you believe went wrong?

Piracy played a big hand—who wants to write software that will be pirated the next day? Just look on the Internet today, you can find almost every Atari ST or Amiga program ever released. In addition, while initial Amigas and STs were groundbreaking, they didn’t move far beyond their initial designs, while in four short years the Mac moved from the 68000, to 68020/30 CPU. Same over in the PC camp.

The Amiga vs. Atari ST debate still carries on to this day. As an Atari ST user, can you state in one sentence why you feel the Atari ST was a better machine?

I don’t know if the Atari ST was a better machine. Both the Atari ST and the Amiga were two really great computers with a lot of nice software. I think I’ll side-step your question as I don’t want to enter into the “Atari ST vs. Amiga” war.

If someone wants to dive into emulation programming, where should they start?

Since I don’t have a long track record as an emulation developer, as well as concentrating on one platform, I can only comment on the path I took: I downloaded the UAE source code, since the Atari and the Amiga use the same CPU, and tried to first understand how it worked. Then I modified the code to run the TOS software. Later, I moved towards adding lower-level support for Atari ST hardware, such as screen, shifter, MFP, and so on.

nost06.gif

Pang”

Interview with Francois

Hi Francois, could you please introduce yourself and your history with Atari and Mac? Do you currently own any Macs?

My very first computer was a Commodore CBM 4016, an “all-in-one” computer which had a 40 column character green monochrome display, a 1MHz 8-bit 6502 processor and 16kB of RAM! Although the machine lacked graphic possibilities, it featured a nice built-in BASIC, as many machines in the eighties did. This computer led me into programming. Around 1985 it was time for a new computer and I really wanted a Macintosh, but they were by far too expensive. I would move up to an Atari ST in 1985, and a few years later I joined the Macintosh community with a PowerMac 8600. At that time I was using Macs in my job, developing multimedia CD-ROMs with Apple Media Tool. Using a Mac for professional work every day is the best way to be converted to the simplicity and power of Mac OS! In 2000, I needed a new Mac to run Mac OS X, so I purchased the best computer Apple ever produced-the G4 Cube. It’s a great machine, especially in its lack of “noise,” and I’m glad I purchased one before Apple discontinued the line-which is a shame in my opinion.

Philippe mentioned that you’ve developed the sampled sound portion in the upcoming emulator NoSTalgia 1.4. How did you join up with him?

Philippe posted a message a while back in the newsgroup fr.comp.sys.mac saying he was about to develop an Atari ST emulator, and asked for technical documentation about the Atari ST. I thought, “Woo, that’s cool!” So I offered to send Philippe a fair amount of documentation that was gathering dust on my shelf—fortunately, I didn’t have to send it overseas, only “Outre-Quie’vrain.” My only requirement was to be one of the first beta testers so that I could start replaying all of my old games.

My first programming efforts for NoSTalgia were working on the MIDI routines. In my job, I was developing software using QuickTime, so one day I thought, “Why not use the QuickTime software synthesizer to play what’s coming from the MIDI ports of the Atari ST?!” I told Philippe about my idea, and he was kind enough to accept it and let me work with him on his emulator.

nost07.gif

Cubase Lite

As the QuickTime Player is able to play MIDI files, I was thinking the code would be fairly simple, and just a matter of “virtual wiring” between the Atari ST’s MIDI ports and the QuickTime synthesizer. However, it wasn’t that easy because QuickTime knows how to import a MIDI file, but doesn’t know about MIDI codes sent in real time. I had to write a complete MIDI interpreter to pilot the QT synthesizer from the Atari ST! The MIDI protocol is well documented, and not very complex, so the code came along nicely. Interestingly enough, that same code from the Mac OS 8 era is still in the Mac OS X version of NoSTalgia. The next obvious step was being able to control a real MIDI synthesizer from the emulated Atari ST running on the Mac. At that time, OMS (Open Music System) was the “standard” library for writing MIDI software, so that’s what you have on the Mac OS 8/9 version of NoSTalgia. I’m planning to update these routines with CoreMIDI on Mac OS X. OMS, and soon CoreMIDI, allows NoSTalgia to control a synthesizer, but it handles “MIDI in” as well, so you can record yourself playing on the synthesizer completely by keyboard (using the very first version of Cubase running in the emulated Atari ST, for example).

The first version of the sound emulation in NoSTalgia had been written by Philippe, but it didn’t have sampled sound support, so after writing the MIDI code, it was a new challenge for me. That was tough! My version improved the quality of the sound (thanks to a better accuracy of the emulation), but still no sampled sounds were playing. Instead, there were some cracking noises, because I had completely overlooked the need for precise timing—my code was only accurate to 1/50 of a second. You couldn’t tell the inaccuracy when playing notes on the sound chip, but for sampled sound you have to be precise to 1/44100 of a second (in the case of CD quality)! Now that NoSTalgia is Mac OS X only, I updated the sound routines from Sound Manager to CoreAudio, which is a dream to use.

What was your previous experience with sound on the Atari ST ?

You may not believe it, but I didn’t have that much experience with sound on the ST! I did know roughly how the sound chip worked, but how sampled sound was played through that chip puzzled me at the time, as I wasn’t able to find any documentation on that particular subject. Now that I have worked on emulating the chip, it’s all fallen into place.

The Atari ST featured a Yamaha YM2149. Could you give us some historical and technical background on Atari’s soundchip/system?

This chip is a clone of the General Instruments AY-3-8910, or perhaps the other way around. Either chip has been used in a lot of microcomputers such as the Sinclair ZX Spectrum, Amstrad CPC, Oric Atmos, and arcade consoles. It’s an interesting musical device; it has three independent channels that output a square wave. You access the chip registers to control it, setting the frequency, amplitude for each channel and the period and shape of a global envelope. It’s like playing notes on a keyboard. There’s a noise channel too, for the explosion effects in games. It’s fairly easy to use, and you can produce great tunes without any sort of load on the processor. Except for sampled sound, which uses an undocumented trick to turn the chip into a digital-analog audio converter, but the processor has to send the samples in perfect synchronization to the chip—you need an 8MHz 68000 to do that!

What was the most challenging part in writing the sound code for NoSTalgia?

Sound is real-time! You have to be sure that everything stays in sync, as well as understand how the system wants to take your sound to play it on the hardware. On Mac OS X, understanding CoreAudio is the key. There’s some good examples code in the SDK.

What other projects, if any, have you done on the Mac?

Professionally, I’ve worked on several multimedia CD-ROMs, back in the golden age of multimedia.

Do you have any complaints about the Macintosh APIs or Apple’s documentation?

For programmers, there’s never enough documentation. Seriously though, sometimes the existing documentation is outdated. However developing on Mac OS X is great, heaven compared to “Classic” Mac OS. You can have never-ending loops, memory leaks, crashing bugs in your application, yet the system stays solid as a rock. As Mac OS X’s sound is real-time, it’s not really handy using a step-by-step debugger on your code. But putting a lot of trace in it helps a lot, and those traces show up in the console immediately. You know what’s happening, when it’s happening.

Bio

Philippe is living in Belgium (not far from Brussels) and is 35 years old. His first computer was a Canon X-07—a portable computer with a small LCD screen.

¹ GEM is a GUI desktop environment produced by Digital Research about the time that Microsoft did the first version of Windows. The Atari ST line used a modified version of GEM.

² Infringement of intellectual property rights is a serious issue, and there are many views on emulation. To read a counter view on the subject, please visit Nintendo’s policy page.

developers,atari,st,emulator,nostalgia

Introduction

Who can resist a title like that? Sometimes I damn myself for not being able to resist the discount table at my favorite computer book store, but this time I didn’t. There is a funny little quirk to this, though: I got it at a 50% discount, and it really, truly feels like this is half of a book.

‘Designing3D Games That Sell!’ is divided into two parts, of which the first looks into the business aspects of game development and the second into the actual designing of the game. I may sound a little unfair here, but here goes. The second part of the book is, in my eyes, of zero value. I don’t think that it will be of value to any Mac programmer, as it covers the Genesis3D game engine and Reality Factor, neither of which are ported to the Mac. Fair enough. However, even for the Windows users, I can’t really understand why the second part of the book is there. It feels like a collection of copied-and-pasted basic Genesis3D and level design tutorials that could be found anywhere on the Internet. It is really misplaced in this book. But, as it is of no worth, I’ll leave it at that and focus on the valuable part of the book, which is of high quality.

Getting a Game Published

For any game developer who hopes to get a few bucks out of his or her production, this book is money well spent. It will definitely kill that naive view of the game industry as the Dream Factory where you become filthy rich by writing a Tetris clone. It focuses on the publisher instead of the developer, and tells you what you need to know to land a deal. I’ve only been into this book for less than a week, but I already feel like I’ve grown as a game developer, maturing. I’ve been told what I have to consider as a developer, how to find my audience, how to market a game (which is basically the old did-you-know-you-can-market-through-the-Internet talk, but pulled off with grace), and what are the common pitfalls while doing so. Then we come to the really interesting stuff, namely, a long talk about the publisher, and a lengthy explanation as to why publishers might be reluctant to give you one million dollars for your Tetris clone, no questions asked. This is the business manual everyone needs to read. There is much wisdom in this portion of the book, and I found use for it after just a few days of reading. It explains what risks the publisher is taking, the costs of marketing a game (and they are way higher than I had ever thought), and what the important goals are. This section is mighty discouraging, and it makes you wonder how anyone has gotten a game published — ever. Good thing the next chapters let you in on the secrets.

You are about to learn what the publisher wants. Ahearn provides instructions on how to write a game proposal (the section on opening lines is invaluable), how to analyze the market, how to make the design document attractive to publishers, and, very important indeed, how to make up a budget and a schedule. And boy, are there a lot of things that I would never have thought of if I hadn’t gotten this book under my fingers. This part is very encouraging, though, as you quickly see where you must improve your game proposal. The irony here is that you need to do a great deal of marketing for your game in order to persuade the publisher to market it.

And then, we go visit the publisher. This chapter is an interview guide that you could probably expect to find in any job interview guide book. However, it is actually quite valuable as it is all focused on getting a game published (rather than a general interview guide). The subheadings for this chapter are: “Things you must get right the first time”, “Let the publisher talk”, “Etiquette”, and “Remove stressful and on-the-spot situations”. It even carries a section on how to handle a rejection letter. Finally, a chapter with legal advice on closing a good deal — and how to avoid getting ripped off.

Conclusion

Actually, this book is excellent. It is well worth its money. It points out what you should do, but also the pitfalls and mistakes to avoid. The language is clear and easy to get through, so this book isn’t one of the business bricks you might expect it to be. Finally, what I very much appreciated is that ‘Designing’ is also directed towards the beginner developer, that might have only a few or no titles in his or her track record. It is a tough thing to land a deal, but it seems to be very possible, and Luke Ahearn sure makes me more confident. Just rip all the pages after page 171 out, and you’ll feel great about this book!

Related Books:

• Game Design: The Art and Business of Creating Games’
• Game Design Perspective’

Staff note: the original tutorial that was sent in was spread over 16 html files. The html was in pretty terrible shape. I removed it all, and converted to Textile but the tutorial still needs better flow and layout. Do your best to make each step consistent. Re-write passages for clarity as well. Thanks!

Castles Music Sound FX Walkthrough

Resources/0.gif

alt=“Basic Sound Effect Design, March 2003, Castles Music Productions

Resources/0a.gif

What was supposed to be a simple “how-to” on Sound Design has turned into this article! You can blame all the indie game developers I have ever worked with for inspiring what you are reading.

This article is in two parts.

Part 1 — Things to consider before designing sound.

Part 2 — An example of creating an Explosion sound effect.

Note: I’m using Macintosh software and the walkthrough uses some shareware mac software. You can replicate most of the steps in your favourite PC editor like Goldwave, or SoundForge.

Sound FX Walkthrough 01

Resources/0b.gif

Part 1 — Preliminaries

Resources/0c.gif

Resources/0d.gif

When you are designing the concept for your game, spend a little time working out how you want it to sound. Is it going to be a full-on arcade assault with bleeps, bloops and explosions all over the place. Or are you going for a tense sparse atmospheric feel?

Some things to consider when you are thinking about sound.

• Type and Number of Sounds
• Space requirements or restrictions
• Formats

Sound FX Walkthrough 02

Resources/0b.gif

alt=“Part 1 — Preliminaries

Resources/0e.gif

Resources/0f.gif

It would be useful to define some different types of sound effects: Ambience, Normal Effects, Special Effects, and Interface Effects.

• Ambience: Sounds that occur in the environment of the game (also called Environmental sounds.) These are often loops (constantly playing in the background) or sometimes one-shot (played only once at random intervals.)

They can really add to the vibe of your game—mad screams from inmates can be heard down the corridors of the insane asylum, birds tweeting, leaves rustling in the wind, planes flying overhead, cars traveling on the streets.

One of the coolest environmental sounds I’ve heard recently was in “Medal of Honor: Frontline.” In one of the last missions you must fight your way through a steel foundry. The sound of the hot metal pouring into the moulds is amazing. It totally freaked me out when I first played the game because you can hear the sound coming from adjacent rooms — and it sounds like some huge monster!

• Normal Effects: The stuff that happens in-game. If you were doing a card playing game, the sound of the cards being dealt and flipped over by the player would be a Normal Effect.
• Special Effects: The big payoff or surprise sounds that add spice and reward to a game. In Blastorama the explosions are made as big sounding stereo files which reward the player for blasting the hell out of the level they’re playing. In BaseGolf I did a “Tadaaa” fanfare for a hole-in-one shot.
• Interface Effects: Sounds used in menus, for selection of items etc.

You’ll probably be spending most of your time getting the Normal and Special Effect sounds just right.

Sound FX Walkthrough 03

Resources/0b.gif

alt=“Part 1 — Preliminaries

Resources/0e.gif

Resources/0g.gif

What actions, events or locations need particular sounds? Selecting options and menus, key in-game events, repetitive events (like firing a gun, or hitting a baseball,) player footsteps, monsters, ambience — these can all play a part.

Resources/0h.gif

Since some of your normal effects have the potential to be repeated hundreds of times, it might pay to consider doing multiple versions of some sounds. Alternatively you can program small random pitch and volume changes to occur in-game for particular sounds. Either way, it’s good to get a rough idea as to how many sounds you will want because that will affect other areas of the game not least of which is the file size consideration for downloading.

Sound FX Walkthrough 04

Resources/0b.gif

alt=“Part 1 — Preliminaries

Resources/0i.gif

Space or file size restrictions play an important part in choosing how many sounds and the quality of sounds you use. Space restrictions for downloadable games. If you make games for download it seems 5MB is about the ‘magic’ file size for the total game. Usually people are using compressed formats to reduce audio file size.

Resources/0j.gif

Typically when a game uses uncompressed files they are 22kHz, 16-bit, Mono. Which type of compression used depends on the development and delivery platform. MP3 and OGG are promising, Microsoft ADPCM is ok, but all of these compressed formats have overheads in terms of the power required to decompress them on the fly and I have experienced problems with looping compressed sounds. It’s a good idea to try out a few formats and see which suits your style, audio engine, and project.

Sound FX Walkthrough 05

Resources/0k.gif

alt=“Part 1 — Sound Design Process

Resources/0l.gif

Resources/0m.gif

There are several ways to get beginning sounds for effects. From recordings you’ve done yourself, from sound libraries, from sound manipulation software on your computer, or from the web.

Note: I try to steer away from using sounds from the web as they are often ‘shonky’ ie. Stolen from a commercial sound library, from a movie, or some other copyrighted source. There are some great sites with free sounds however (eg: Flashkit) you just have to finds them. I generally start from a sound library sound and/or a sound I’ve recorded myself.

Resources/0n.gif

Sample rates and Bit rates.

You can think of sample rates and bit rates a bit like the quality of a JPEG picture. With a JPEG, the lower the quality (higher the compression) the worse it looks. With audio files, the lower the bit/sample rates the worse it sounds. [Note: sometimes low bit-rate sounds can work really well, like in the Matrix movie for example]

The key to getting a good image (or sound) is to start at a higher resolution/quality, edit your files at this resolution and then convert your files from to lower quality from there.I generally use 44.1kHz, 16 bit for my high-quality files (lately I’m using 48kHz, 24bit.).

A lot of the audio files from the internet are lower quality like 22kHz, 16 Bit or even 11kHz, 8bit. I’m not going to cover sample rates and bit rates in this article but needless to say, starting from highest quality is always best. Gather as many sounds as you think you might need to create a particular effect.

Sound FX Walkthrough 06

Resources/0k.gif

alt=“Part 1 — Sound Design Process

The general procedure I use for creating effects is pretty simple, and I’ll cover it more when I run through an example later on.

• Load the sound into the audio editor
• Edit the sounds with DSP functions, trim the file etc
• Layer sounds together for bigger, more interesting effects.
• Experiment!

Resources/0p.gif

Resources/0q.gif

• MP3 — iTunes. The most convenient method of converting to MP3.
• OGG — OGGDrop, Audacity, Amadeus all can do this format.
• WAV — most tools allow you to save as a WAV file
• AIF — any MAC audio editor can do this format

Some other tools that would be useful for audio conversion:

• SoundApp — I use this program a lot. It isn’t the best quality but it can convert between many formats and is a good way to audition lots of files.
• Sound Hack — I have no experience with it but it looks pretty good.
• Amadeus II — I love this program, lots of good features and great denoising, support for VST effects and it doesn’t cost the earth.

Sound FX Walkthrough 07

Resources/0r.gif

alt=“Part 1 — Sound Design Process

Resources/0s.gif

Once you start getting more than 20 sound files, it is a good idea to keep track of them. There is a document on the iDevGames.com site by Yogic Flyer which outlines a good standard for art asset file naming conventions:

XXX-YYY-RRRxRRR.ZZZ

Where XXX is the prefix, YYY is the description, RRRxRRR are the dimensions, and ZZZ is the suffix (extension.)

To expand on that for audio you could use:

LLL_XXX_YYYRRR.ZZZ

For example: a02_sfx_bubbles002.aif

• LLL is information specific to your game to help you identify where this audio belongs, in which level. For example: A01 — for Mission A, Level 1. It can also allow you to make the destinction between interface and game sounds (e.g.: I00 — for Interface sounds.)
• XXX is the identifier for the type of audio: (E.g. mus = Music Track, sfx = Sound Effect )
• YYY is the description of the audio file
• RRR is any particular extra info (e.g. Sample Rate, Version Number)
• ZZZ is the suffix.

Our example again: a02_sfx_bubbles002.aif

From the name we can tell that this item is used in Mission A, Level 01. It is a sound effect, it is a bubble sound effect and it’s version two. Finally it is an AIFF file.

Sound FX Walkthrough 08

Resources/0t.gif

alt=“Part 2 — Sound Design Example

Resources/0u.gif

Since I don’t have access to explosives I can’t really record my own real explosion sound. Most ‘real’ sounds don’t really sound big enough anyway so I like to layer sounds to create that ‘big’ sound. I’m using as the basis of the explosion a sound effect called “Classic Explosion” which is from the “Ear Shot sound effect archive” which I own.

ExplodeClassic:

When not using Sound Library stuff as a beginning I might also use original recordings from my MiniDisc, or sounds created from computer-based synth software. You could just use this sound by itself but that would be cheating, not to mention lazy….and lazy cheaters go to hell. So to avoid that I always try to give a base sound effect a bit of character that is my very own. This is where we begin the process of creating another layer or several layers to create the perfect sound. The original Classic Explosion sound has a sort of high-pitched shock wave sound that I really like so I’m going to try and emphasise that with another sound. I’ll start with a sound called “Mega Distort Battle” that I created from a PLUGGO plug-in called Feedback Network.

[PLUGGO is a set of over 100 Mac-only VST plug-ins for $100. Available from www.cycling74.com. There are other free plug-ins that can do this sort of thing like THONK which you can do a search for on Google if you want to find it.]

MegaDistort:

So remember that I’m editing this sound because I intend to layer it with the other explosion sound so first I need to prepare the bits I want to keep and get the file ready for work.

Sound FX Walkthrough 09

Resources/0t.gif

alt=“Part 2 — Sound Design Example

Resources/0v.gif

I’ve chosen to keep the first part of the sound because there is a nice high-pitched sort of sound going on there.

• In Amadeus select the first 5 seconds of the sound and use Edit — Crop to remove the rest of the file, leaving behind the first 5 seconds.

Resources/0w.gif

I want to fade in the beginning and fade out the end so that it sounds a bit smoother.

• Select from around 2 seconds to the end of the file and choose Effect — Fade Out.
• Select from the beginning of the file to around 1.5 seconds and apply Effect — Fade In
• We now have a nice chunk of audio to play with.

Resources/picstep0102.jpeg

alt=“PicStep0102

TIP: Save incremental backups of your audio file even if your audio editor supports multiple undo. You never know when you’ll want to go back to an earlier version.

Sound FX Walkthrough 10

Resources/0t.gif

alt=“Part 2 — Sound Design Example

I found a free plug-in on the net called MadShifta that is a dirty little pitch-shifting tool. I’m going to try pitch shifting the file to see if that makes it more interesting.

• Select the whole file (which makes sure the plug-in is acting on the whole file and not just a little portion of it.)
• Apply Effect — VST Plug-ins — MadShifta with the settings shown.
• The results sound nice.

Pic_Step03_Madshifta.jpg

Resources/picstep03madshif.jpeg

alt=“PicStep03Madshifta

Now I want to home in on the core sound a bit more.

• Select from around four seconds to the end of the file, use Edit — Clear to remove this part.
• Apply Effects — Fade Out to the last second or so of the file.

Sound FX Walkthrough 11

Resources/0t.gif

Part 2 — Sound Design Example

Resources/0z.gif

Lets make the volume of the file a bit louder

• use Effects — Normalize with a setting of 98%. This increases the ‘loudness’ of the file.

Pic_Step05_ShowingFile.jpg

“Resources/picstep05showing.jpeg

alt=“PicStep05ShowingFile

Resources/0-1.gif

To add some movement

• apply Effects — VST — mda Auto Pan which moves the sound between the left and right speakers.

MDA Auto Pan is a free VST effect that comes with Amadeus.

The resulting file is pretty cool.

Resources/picstep06showing.jpeg”

alt=“PicStep06ShowingFile

Resources/picstep0506autop.jpeg

alt=“Click here to see the AutoPan settings for Step 6”

Sound FX Walkthrough 12

Resources/0t.gif

alt=“Part 2 — Sound Design Example

Resources/0-2.gif

The sound needs a bit of a trim so we’ll trim the beginning and end off the Mega Distort file.

• Select from the beginning to around 0.5 seconds. Use Edit — Clear to get rid of that part. Now select from around 2.0 seconds till the end and use Effects — Generate Silence. This will clear the end of the fade but leave silence for us to add a little more spice to the sound.
• Fade out from about 1 seconds till a little after 2 seconds.
• Use Effects — VST — mda ThroughZero with the settings shown to get a choppy phased sort of sound.

Resources/picstep07thruzer.jpeg

alt=“PicStep07ThruZero

Resources/0-3.gif

That sounds good, but now it’s a little dry. So we are going to use a reverb to create a more open washy sound.

• Use Effects — VST — FreeVerb with the settings I have used. This produces a nice open wash.

Resources/picstep08freever.jpeg

alt=“PicStep08FreeVerb

Sound FX Walkthrough 13

Resources/0t.gif

alt=“Part 2 — Sound Design Example

Resources/0-4.gif

• First save a copy of the file as it is as another name- we’ll come back to it in step 10.
• Now to accentuate the end of the sound, and to make sure the sound doesn’t get in the way at the beginning of the explosion, lets Fade in from 0 to around 0.6 seconds. Do the Fade in on the same selection again twice more to make sure there is clear space for the other sound later on.
• Select from 1.8 seconds till the end and use Edit — Clear. Fade Out from 1 second to the end of the file.
• Now reduce the volume of the file again by using Effects — Normalize with a setting of 20-30%

Resources/0-5.gif

Still more is needed I think.

• Open the copy you saved in Step 9.
• Apply Effects — MadShifta with the settings shown.
• Apply the Effects — VST — DFX Skidder with the settings shown below. This produces a neat grungy skipping sort of a sound.
• Clear from around 2.4 seconds to the end.
• Fade in from the beginning to1 seconds.
• Fade out from 1.2 secs to end
• Normalize to 40%
• Save this file.

Resources/picstep10madshif.jpeg

alt=“PicStep10Madshifta

Resources/picstep10askidde.jpeg

alt=“PicStep10aSkidder

Sound FX Walkthrough 14

Resources/0t.gif

alt=“Part 2 — Sound Design Example

Resources/0-6.gif

Now to layer the sounds together. Make sure the three sounds we have created are now open.

• Edit — Select All of the file from step 9 and then click on the Classic Explode window. Now Select All there and choose Edit — Paste Over (See picture below.) The copied sound will be mixed in with the destination.
• Do the same with the file from Step 10 and have a listen to your results.

Resources/picstep11pasteov.jpeg

alt=“PicStep11PasteOver

Sound FX Walkthrough 16

Resources/0-8.gif

alt=“Download this Walkthrough

Resources/0-9.gif

Feel free to download this walkthrough. It’s compressed into an archive with a PDF document and the associated MP3 files in a folder for you to play with—enjoy.

CMP Sound FX Tutorial

Sound FX Walkthrough 15

Resources/0t.gi

alt=“Part 2 — Sound Design Example

Resources/0-7.gif

Not a bad effort really, a great original effect ready for exporting into our favorite format.

ExplodeClassic (Original File) :

New Explode (Our New File) :

And with a little tweaking of a few parameters here and there, I came up with some variations:

Variation 1 :

Variation 2 :

As you have seen, half of the process is experimentation, trying stuff out and seeing how it sounds. To sumarise the steps I take:

• Gather raw sounds
• Edit, experiment, twist and generally muck around with the files until you get something you like
• Layer sounds together to get a more interesting effect.

That’s it really, get to work!

“Resources/audio03b.gif

alt=“Audio03b

About the Author:

Simon ‘Himiona’ Castles heads Castles Music Productions, New Zealand’s premiere audio production house for computer games. For a full profile visit the Castles Music website at: http://www.castlesmusic.co.nz

basic,sound,effect,design

omnigraffle01.gif

OmniGraffle”

omnigraffle02.gif

Shape Info

I had been curious about The Omni Group’s OmniGraffle for quite some time when I won it as a prize in uDevGames 2002, iDevGames’ annual game creation contest. The reason I had been looking into it was that it is capable of doing Universal Modeling Language (UML) diagrams, something that I really enjoy using when programming.

For those who are unfamiliar with UML, it is a diagramming convention for planning and laying out object-oriented software. It works as a flow chart, showing the relationships between classes, as well as the members of each class. It’s a powerful tool for spotting problems in your program even before you begin to code. It’s also very useful in projects with multiple programmers, as it clearly defines the relationships and interactions between different parts of the code. If you often find yourself rewriting code because you hacked yourself into a corner, check into UML—it might be just what you need.

omnigraffle03.gif

Layout Info

In short, OmniGraffle is an application for drawing diagrams, flow charts, mind maps, and relational studies. At first glance, the concept seems simple: draw boxes and connect them with lines. You edit text in boxes, and move them around—nothing groundbreaking. However, after playing with the tools for some time, I was struck by two things. The first was that everything I had done, had been done without reading the manual. It was all so intuitive! I was surprised at how often pure guesses as to how the interface worked turned out to be just what I wanted. The second thought was that it all looked so good. It was absolutely beautiful. Arrows and lines curve graciously, boxes cast drop shadows, and the diagrams look clean and attractive. I then used OmniGraffle’s export options to turn my charts into a PDF file, and fell in love.

omnigraffle04.gif

Link Info

OmniGraffle is a program that is extremely well built and makes full use of the power of Mac OS X. There are, however, many flow chart editing programs out there. What sets OmniGraffle apart? One thing is the beautiful, if standard, Aqua look and a killer user interface (which I’ll get back to later). It does a great job at the basic box-and-lines diagrams. However, that’s where many flow chart editing packages stop, and where OmniGraffle takes off. It comes with palettes that show off what can be done with those shapes. You can make your own boxes and templates, and it becomes very powerful in a second. The UML charting, for instance, is just a side effect of these templates. Another example is network planning charts, with images of different Mac models and network peripherals, so now you can lay out that Ethernet you work on in no time, and save yourself a few meters of cabling.

omnigraffle05.gif

Magnets Info

The Office palette shows how you can arrange office furniture by providing a few tables and chairs that you can move around on the page.

So, what are the quirks? Well, I thought I had found a few unfinished touches in the interface. However, Omni Group pointed out to me how to accomplish them, and I was left without any criticism at all. I am truly in love with this piece of software. Even as I thought I had found some uncomfortable moves in the interface, I found cmd-key equivalents for them all. The only thing I can possibly complain about is the color selection tool, but that’s just one of my pet peeves with Aqua, and I really can’t blame Omni Group for that. So, that leaves me with no weak points to exploit, just a solid flow charting experience. Oh, and did I mention it does AppleScript? It does.

OmniGraffle is an outstanding application for game developers, as well as anyone wanting to do any kind of diagramming. The Omni Group has been involved with creating applications based on the Cocoa API, and OmniGraffle reflects their expertise in designing clear and powerful applications.

omnigraffle06.gif

omnigraffle07.gif

omnigraffle08.gif

Rated 9

Version: 2

Category: Diagram and Charting Tool

Developer: The Omni Group

MSRP: $59.95 (USD)

omnigraffle,2,omni,group

The Back Story

As Editor-in-Chief of iDevGames, my objective is to promote and evangelize game development for the Macintosh platform. Since 1998, iDevGames has grown from a small band of visitors to one of the largest sites devoted to Macintosh development. In fact, our uDevGames 2002 programming contest was such a success we had the privilege of being ‘Slashdotted’ when Slashdot.org reported on our support for Open Source code through the uDevGames Contest. Had we been serving the page on a virtual server, our host most likely would have quickly pulled the plug. Instead, our dedicated server, which was generously purchased through the support of our community, could sustain¹ the demands of the Slashdot horde. iDevGames moved from a virtual server to a dedicated server in 2001. For those of you that are not familiar with those terms, let me simplify by saying that on our dedicated server, the only site that is hosted is iDevGames. This is as opposed to a virtual server, which would contain iDevGames and many other sites, as many as 200 or more, all on one machine. Upgrading to a dedicated server is a big step for a small site in terms of larger hosting fees and management requirements. For the latter, the situation is becoming better as prices for dedicated servers have been falling for some time. In fact, the price may pleasantly surprise you if you are currently on a virtual server. That said, dedicated servers aren’t for everyone and my second point in upgrading should not be dismissed lightly. Proper management of a server is a must, and, outside the price, the most compelling reason to stay on a virtual server plan.

The Forbidden Fruit

Not long ago Apple set out to make a serious challenge to the traditional server solutions offered by the many PC vendors through their Xserve line. Apple had offered servers in the past, however, the Xserve models are Apple’s first real attempt to go toe-to-toe and provide a true alternative to networking needs beyond the publishing market, which Apple has always performed strongly in. With an OS that is based on standard and mature technologies, the Xserve’s advanced features made it the “apple of my eye.” Of course being the only site devoted completely to Macintosh game development, we could think of no better endorsement of the platform than having the ability to place the “Powered by Mac OS X Server” web badge on our front page. Our friends over at Inside Mac Games provided a great testament to the benefits of the Xserve when they switched over in 2002. Alas, an Xserve powered iDevGames site is still years away, as the costs of co-hosting combined with the initial costs of the Xserve are far beyond our budget and current needs. Back to reality and present day needs, our dedicated server is a simple Linux server running on an AMD Duron box. Surprisingly enough, this machine has proved to be a great value in providing content and in supporting our active forum of over 400 developers. As mentioned earlier, this little server did us proud when our traffic went sky-high due to the mentioning of uDevGames on Slashdot.org.

Dedicated to the Server

Hosting companies that offer dedicated servers offer various levels of support, ranging from managed to self-managed machines. While managed servers are wise for newbies and customers with little time or patience to learn what SSH is, the prices tend to reflect the extra hand-holding and support that is provided. In the case of our hosting company, they offer self-managed machines at great prices—unfortunately some of their customers expect ‘managed’ support at ‘self-managed’ prices. Operating a self-managed dedicated server requires knowledge in system administration, security, applications, and much more. With Mac OS X, Mac users have been getting exposed to many of these areas, such as running the Apache server. No doubt, a good many of you are serving web pages, files, and more from your desktop Macs running Mac OS X. I mentioned our own in-house guru webmaster, Griggs. He keeps a close eye on our server and does the standard system admin duties that are required to keep iDevGames running smoothly. However, even Griggs must sleep and perform his day job so the need for another set of eyes to watch the server has been very great since we took the step into the world of dedicated servers. Aside from monitoring the server, the need to maintain the latest security patches and software updates is crucial to our success. So with that in mind, I decided to start learning the various ins and outs of system administration. Since Mac OS X is based on Unix, and my current desktop machine was running Apache, PHP, MySQL and other applications, it seemed the logical solution would be to crack open the excellent book ‘Mac OS X Unleashed’ by John and William C. Ray. This textbook has enough pages to make almost any Mac user into a power user and system administrator. As I studied chapter after chapter a small voice in my head grew louder and louder, “If you build it…” Simple, but what should I build? And more important, what would be the benefit in building it? The answer finally came to me one morning when I looked at a flyer from a local computer store that specialized in DIY PC systems. The it that the voice was pushing me to build was a Linux box. Why, though, when I already had a Mac perfectly capable of teaching me what I needed to know? Or did I?

A Fool’s Errand

In reality, I could indeed learn most of what I needed to know from my desktop machine running Mac OS X. However three reasons came to mind that pushed me into this fool idea of trying to build my own machine. Foremost was the need to get away from the server. This point is hard to put into words but I needed to have a box that sat in the corner of my computer room, without a keyboard, or display, that I could envision as a dedicated machine thousands of miles away from my terminal client. In short, I need to build my confidence that I can effectively operate a machine that I cannot see. The second reason for building a Linux box was to create an exact copy of iDevGames’ server environment. From the hard drive, to the CPU, to the version of Linux and everything else. Now, I could safely use my clone as a development machine without fear of bringing down the entire iDevGames site. My Linux box won’t just be a development machine, but should also allow me to learn about security as I play both hacker and system administer. It should also serve as a good test bed for trying new packages before installing them on iDevGames’ server. The third reason for building the Linux box stemmed not from logic but from the simple thrill of exploring something I know nothing about—the PC world.

Choices, Choices, and Yet More Choices

My mind was now set on building a Linux machine. I had my three reasons, and just as importantly I had my wife’s OK after promising to install Windows on an extra hard drive so she could play the various “The Sims” expansion packs, which may never be localized to Japanese Mac versions. I thus began to visit several local stores that sold PC parts to educate myself. After every trip, I felt myself more and more confused. Which CPU, motherboard, graphic card, etc., should I get? Since I live in a small Japanese city of only 300,000 or so people, the chances of finding a Linux guru who spoke English were slim. So I spent several weeks reading articles on the Internet. Of the sites and articles I encountered, less than half had information that was clear and concise and that someone without knowledge of such things as chipsets, sockets, and BIOS could understand. The endless choices and combinations seem like a double-edged sword in some ways. If you have the time and knowledge to read countless reviews, you can quickly narrow your choice to a few components (e.g. graphic cards). However, Mac users have such limited choices in graphic cards. Sure, we have PCI and AGP slots, but you can count the number of Mac-ready cards on one hand. (I’m excluding cards which you can flash the BIOS.) It seems the PC and Mac world truly represent different extremes. Which side is better obviously comes down to the individual. My guess is that there are many Mac users who are like me in that we enjoy the stability that being a Mac owner brings, but we wouldn’t mind a few more choices, not to mention a break on the price for a product that in many ways seems identical to its PC counterpart!

The Art of PC Parts Buying

When you first start to shop for parts, you will feel in awe of the choices, as I mentioned above. I’m going to explain how I turned fruitless trips to the store into more productive time. I should first mention that the process I used may not be the best for every Mac user, and it will no doubt rely on how you can shop and with whom. In my case, living in Japan, the low cost of parts imported from America via the Internet would be offset by the shipping and duty taxes, so I was forced to buy local. I could have taken a trip to one of the two ‘meccas’ of electronics shopping in Japan, Akihabara in Tokyo or Den-Den Town in Osaka, but any savings in parts would be offset by traveling costs—very high in Japan! Shopping with a friend who knows Linux could help, but as I mentioned, this was not an option for me. I did have an idea of some brands that were a bit more Linux friendly. In fact, visiting the stores was useful as I could pick up a box, flip it around, and look for the Linux mascot, or in some cases check out the user manual. Since most of the parts are made in Taiwan and China, I was happy to see multilingual manuals. Sometimes the manuals were in Japanese only but with a brief visit to the website I could quickly download an English PDF manual. There are countless guides for buying and building PCs on the Internet, so I won’t go through each step in detail. However, I will outline my own process with some added commentary from the eyes of a Mac user. The first step was to examine the specs of iDevGames’ server; I needed a Duron, a 40GB hard drive and 512MB of RAM, and Red Hat 7.2. In looking at the hardware specs I listed, I expected the total system cost to be well within my budget of 60,000 yen, or about $500 USD.

The Operating System

I visited many sites with Linux distributions, and the choices again were mind-boggling. After asking questions, reading articles and reviews, as well as reading posts in various forums, I came back to my original mission: create a machine as similar to the iDevGames’ server as possible. We are running Red Hat 7.2, so I headed over to Red Hat’s site.

At the time of this article, the latest version is 8.0, but I chose version 7.2. My first test as a system admin will be to remotely upgrade 7.2 to 7.3. on my new box and then to do so on iDevGames’ server. Creating the Red Hat Installation CDs is a simple matter once you know where to look, what to get, and how to burn them to ISO format. Red Hat’s site contains plenty of documentation about these questions, but you won’t find much on burning the CDs on a Mac. My advice is to use Roxio’s Toast. I should mention that if you plan to study Linux, many books often come with the distribution to save you time.

Selecting Between AMD and Intel

I use to think that debates between Mac and PC users were extreme. Now, I know that within the PC camp there is a civil war, with each side claiming victories in various battles. I found it difficult to get unbiased opinions and often found articles that had comparisons of chips that were discontinued. This confusion almost made me throw in the towel and go with running Virtual PC or a modern PPC Linux distribution. In the end, three factors moved me to getting the AMD. Foremost was my desire to stick to my plan to clone iDevGames’ server, and the second reason, and no doubt one of the strongest cases that loyal AMD users give, was price. Since my machine wouldn’t be required to work 24/7, I felt comfortable in the savings and put aside any worries of overheating I had heard about. The third reason for choosing AMD was the old saying, “The enemy of my Enemy is my friend.”

As a Mac user, I can only hope that some type of relationship is built between AMD, IBM, Apple, and even Motorola at some point in the future, to combat Intel. Although I went the AMD route, I did deviate in the choice of CPU as I picked an Athlon over the Duron. The difference in price was marginal, and using the machine as a network-rendering machine for my 3D work at some point made it clear that the Duron simply wouldn’t do. The CPU I purchased was the Athlon XP 1700+ and it used the latest designs, which I’m told reduce heat. First, I was drawn to the pre-packaged AMD Athlon boxes that included a fan, because I was a tad afraid to buy a CPU in a simple plastic bag. However, every store I visited was sold out and so I was forced to learn about CPU coolers to go along with the XP 1700+ I bought. Any CPU will generate some level of heat during operation but you really come to appreciate the PowerPC line’s design when you look at some of those CPU coolers for AMD and Intel chips. They look as though they should be installed into rockets!

Motherboard

I had wasted a lot of time during my early shopping trips due to the fact that I was looking at ALL the various motherboards and writing down specs. The key here is choosing your CPU first! For many of you that seems obvious, but for newbies like me, that advice could have saved a lot of time. Once my CPU was determined, I could ignore half of the motherboards on display. Choosing the motherboard involved some homework on the Internet. In some cases, I could find the exact model reviewed, however, some models were off by a few letters from the reviewed models. Don’t assume they are the same model, and just made for another market. Often, the absent letters signify missing features such as RAID, audio, etc. Like the AMD vs. Intel debate, I often found PC users strongly defending various motherboard brands. My research showed me which companies had a consistent track record, and which makers were to be avoided. It is also very wise to visit the website of the motherboard maker and check their support section for manuals, BIOS updates, and FAQs. I admit that in shopping for the motherboard I was in a bit over my head. There were many terms that, as a Mac user, I had never come across. In the end, I looked for a motherboard that had the latest chipsets, but not so new that it didn’t have a chance to go through the PC world and raise red flags. The board I picked was made by GigaByte and was attractive in terms of price, board layout, features and matching my needs.

Case

Choosing a case for my Linux box should have been a simple ordeal. After all, it was to be placed in the corner of the room hidden from view and the eyes of any visiting Mac friends. Yet, as I stood in front of rows upon rows of empty cases with their innards showing, the Mac user in me wondered if all PC case designers had graduated from the same Soviet school of design. Even on the most expensive cases, it seemed that they all lacked character. There were many cases that made a weak attempt at style with cheap chrome buttons, as well as some with a bit of color to break away from the beige look. Actually, in my attempt to avoid the tacky cases that seemed the norm, I settled on a very basic beige box. However, what it lacked in Apple quality and layout it made up for in its ample room for storage devices. Purchasing a PC case, and then a day later opening my PowerMac G4 to remove a spare drive really brought home to me why exactly we Apple users must spend a bit more on our machines—the small details.

Storage Devices

Of all the devices I needed to acquire for my new machine, I felt most qualified in the selection of storage devices. No doubt because Mac users have come to embrace the low cost, high capacity benefit of IDE-based drives. My desktop PowerMac G4 had the original 10GB drive, as well as an IBM 60GB and Maxtor 40GB drive that I had added a year earlier. To save money, I decided to remove the 40GB and 10GB drives and place them in the machine I was building. The 40GB would meet my Linux needs, while the 10GB could hold Windows and the few games and applications that my wife was interested in. This approach kept me within my budget. However, two days later I found myself yearning for more storage in my Macintosh for a DV project. So back to the store I went to pick up a 80GB IBM drive for my Macintosh to compliment the remaining 60GB drive. As is often the case with males and their toys, I lingered around the hard drive display far too long, and talked myself into a third drive for my Linux machine—a 60GB model. As you may have guessed, my binge hard drive shopping drove me over my set budget of 60,000 yen. However, it was only by 11,000 yen, and I was able to sleep well at night knowing my Mac wouldn’t feel neglected with its shiny new 80GB drive. The decision of CD was made in haste due to the fact I was now over my budget and looking to save a little yen on the remaining components. Since my Mac’s writer could fill all my burning needs, I didn’t regret cutting corners here. I had Mac user written all over me as the sales clerk reminded me not to forget to pick up a floppy drive.

Video Graphic Card

My motherboard had many features on-board, such as sound, USB 2.0, and LAN, so additional cards weren’t required. This left my dwindling funds for a graphic card. I was convinced that since the machine would act as a server, with a monitor only occasionally connected, an under $30 card would be fine. But then I started to think of my wife using the machine under Windows, and I looked more closely at my options. I alluded to the fact that PC users have a tremendous number of choices in graphics cards earlier. Although I was familiar with the chipsets from ATI and nVidia, I was clueless as to the card makers, who all seemed to be Taiwan-based. More surprising was the graphic power that could be had for so little. Recently, I have started to think about updating my stock Rage 128 to take advantage of the Quartz Extreme. It seems as though the only affordable solution for my machine would be an ATI 9000 PRO at $169 MSRP. Yet here I was, in an aisle full of cards with equal if not better graphic power for less than $60. The lesson I learned here is that the forces that be want us to buy the latest Mac in order to improve graphic performance—not a new graphic card.

I had read that nVidia’s cards were more Linux friendly, although that may only concern Linux users who run some GUI. Not wanting to take a gamble, I focused only on cards based on nVidia’s chipset. Much to my surprise, the price difference between a GeForce2 and GeForce4 made it a no brainer, so I purchased a GeForce4 with 64MB DDR. Although my motherboard was capable of utilizing x8 AGP cards, I decided that going over an AGP x4 model would be overkill for my needs.

RAM

Memory can have the biggest impact on a server’s performance, and a general rule of thumb is the more the better. iDevGames’ server has only 512MB of RAM, and although I wanted to bring my development machine to a respectable 1GB or RAM, my wallet, and the line of thought that said to stick to the game plan, made me settle on a PC2100 512MB module. I had originally planned to use some of my Mac’s smaller memory modules to save money, however after being educated on PC memory, I learned that my Mac’s SDRAM would be useless in the project. Although I learned quite a bit about the latest memory technologies, I admit that there is still I a lot I don’t understand.

Building the Box

When I told my wife and Japanese friends that I would build the computer myself, they looked at me in awe. Perhaps two decades ago that would indeed have been a feat, with all those early computer kits. However in this modern age, it’s almost as easy as programming your VCR. I say ‘almost’ because some steps reminded me that I was very much a newbie and one slip would prove that it was indeed a fool’s errand.

Most of the components I purchased had Japanese manuals, so I downloaded English manuals. These were obviously translated from Chinese and contained some errors as well as phrases more head scratching then a Chinese proverb. So I searched the Internet for articles on building PCs and printed out some general guides. One site I strongly recommend is ExtremeTech as they cover many topics and contain good reviews.

The first step was clearing a work desk and insuring that my body was properly grounded. Removing the motherboard from its wrapping, I was glad I had chosen the GigaByte board, as it seemed well made, with parts clearly labeled, and even featured little touches like rounded corners. The AMD CPU was carefully removed from its packaging and placed in its socket on the board. A simple lever locked it in place, and I breathed a sigh of relief as step one was complete. Without a doubt, the next step was the most difficult part of the entire process—attaching the “mega-super-duper-extra” gigantic CPU cooler to the Athlon. My guide said to place some thermal grease over the CPU and install the heat sink-fan to the socket latches. Although the instructions were one sentence long, the whole process took me over an hour! Most likely it was due to the fact that this was my first time and I was afraid excessive force would break the CPU die and motherboard. In a nutshell, the heat sink (and the connected fan) has a “v shaped” bar that has latches at each end. You connect one side to the CPU’s socket latch and then force the other side under the opposite latch until it too catches. This will keep the cooler in place while providing contact between the heat sink and the CPU. Sounds simple, but the whole process was very nerve racking, and I was certain that I was destroying the CPU and motherboard with my terrible technique. In addition, if installed improperly, a CPU without proper cooling would reach the temperature inside a nuclear reactor and meltdown would occur.

Once step two was behind me, my confidence level rose tremendously, and I proceeded to install the RAM. Nothing special there, so it was on to the next step, which required mounting the motherboard inside the case. Actually, my guide mentioned case preparation but there wasn’t much to do except for marking were to place the spacers to secure the motherboard. I did have a bit of trouble understanding the plate that covered the I/O ports. The plate was made from a cheap aluminum and really drove home the difference between a medium priced case and one of higher quality. The case I had chosen, while ATX compatible, was a tad on the small side, so during the installation of the motherboard I found my fingers having a bit of a rough time. Again, another argument to spend a bit more and buy a large well-made case.

With motherboard in place, installation of the graphic card was a breeze. It did, however, give me pause as it dawned on me that I lost a PCI slot with the nVidia’s chipset fan hovering over it. Still, with four more PCI slots, I shouldn’t run into trouble if I ever feel the need to add a Firewire, RAID or 1GB LAN card. (In hindsight, it might have been wiser to purchase a motherboard with Firewire, 1GB LAN, and RAID on-board.)

The next major step was to install the various storage devices. This process went without incident; however, I noticed that the IDE cables were starting to clutter up the inside. As a newbie, I had purchased regular flat cables and so I had to do a lot of pushing of cables to insure that airflow would be good. (Note to self: Buy higher quality cables that take up less space.) CD-ROM and floppy drive installation also went smoothly. The box was starting to look like a real “PC” at this point, with installed components.

At this point I took a break to install the 80GB hard drive into my desktop Mac. A simple pull of the circle lever and the side of the machine smoothly came down to expose the inside. This was a good chance to compare the inside of a Macintosh and PC. It’s true that a “brand name” PC made by a company such as Sony would surely look better than what I had “slapped” together; still, to look at the inner design of my Mac was to marvel at Apple’s engineering. I’ve read far too many PC vs. Mac arguments and complaints about higher Mac costs by both camps, but not until you have a PC and Mac opened side by side can you truly understand why us Mac users are paying a premium for being Apple users. Unfortunately, I think most reviews of computers really fail to look beyond specs on a data sheet or the eye-candy we see on the screen.

Returning to my Linux machine, I was at the final stages of completing the job. The last remaining step was to connect the front LEDs, speakers, and switches to the motherboard. The case’s manual was very vague, and the motherboard’s manual was also not helpful. I finally thought I had it mastered and did one last check of all connections along with components. It was now time to see whether it would live or if my adventure would come to a sudden puff of smoke. Monitor connected, I crossed my fingers and powered up. Thoughts of the battle I had with the CPU cooler gave me feelings of doom and gloom, but the twenty odd fans (actually it has four) came on and soon I was greeted by the BIOS screen! I took a moment to reflect on the whole ordeal, from stumbling my way through buying the parts to the sometimes nerve-racking steps of connecting it all together. But, it was working, and I had built it. A Mac user had built a PC! I suppose for many Mac users who might have migrated from the Linux and Windows worlds, my story is trivial and something they have experienced. However, for me, it was like visiting a foreign country. I was able to learn many new things, like a new culture, while appreciating what makes my own culture, or in this case Mac, so unique, and wonderful.

Final Thoughts

I’ve just climbed my first peak, and now I see that there are many more to go, such as the installation of Linux. However, each time I climb a new mountain, I will be extra happy to come back to base camp—my Macintosh.

¹ Thanks to our webmaster, Griggs Domler, who created the excellent PHP/MySQL custom backbone system that runs iDevGames.

mac,user,builds,pc

Carlos Note: Someone confirm all LINKS are working as well as point to the best page that features the language in question. Also, is OSC’s list missing any languages? Or topics that could provide further insight? Perhaps a short list of books on “software development” might be good. I.e., not geared towards any language but the theory of good programming.

An oft-asked question by beginner programmers is, “What language should I use?”

The answers that are given vary, but usually involve heavy recommendations of C and C++. And that’s where it ends. The student learns the recommended language, and never stops to consider what else they might learn.

Time passes, the bright-eyed student becomes something of a guru herself, and when it comes her turn to answer the inevitable question for the next generation, she’s hemmed in by her own experience. “C or C++,” comes the stern reply, and another generation marches blinkered toward the same fate.

Why must this always be the case? Why is it so difficult to leave the beaten track?

When it comes time to start a new project, why is the question always “How can this be done in C++?” rather than “What language would make this project easier?”

Why Computers are Better than People, Reason #457

The point many people miss here is that computer languages aren’t like human languages. It might take you a lifetime to master Japanese. You’re looking at maybe a week for Python. One week to mastery. Not “good morning” and “My name is Ellie” clumsy beginnings, not even mere competent conversation; we’re talking complete, total and utter mastery.

Pick a difficult language, say Perl, and we might be in two-week territory. How about a completely different paradigm—a whole new way of thinking? It shouldn’t take a month to master Haskell.

There’s no reason to limit yourself by the languages you know—the effort to acquire a new one is miniscule, while the pay-offs can be tremendous.

On Round Pegs and Square Holes

Every new project gives the opportunity to start afresh, to reevaluate preconceptions, to apply knowledge gained during the execution of the last. The choice of a programming language is no different.

The decisions made now will have a profound impact on the outcome of this latest venture. The choice of language(s) will affect how easy it is to produce the program in the first place; it will affect how easy it is to modify the program later; it may even affect how easy it is for the program’s users to customize your program to their liking. Why ignore the choice given you?

People don’t like to ask the difficult questions. The questions like “Why are we using C (a language for writing high-performance code) to create a desktop office suite (where performance requirements are very low)?” The questions like “Why are we using Java (a language for writing high-level reusable code with low performance requirements) to write a software 3D renderer expected to run in real-time?” The questions like “Why are we using Haskell (a language good for complex mathematical computation, but poor at I/O) to write a file-format translator?” The questions like “Why are we using Perl (a language good for text-processing) to write an image-editing program?”

Would you fire your builder if she tried to drill a hole in your wall with a wrench?

Choosing the Right Tool for the Job

Every language has its strengths and weaknesses—it has areas where it particularly shines, and areas where you’ll only be fighting the language to try and accomplish anything.

When you start your next project, stop and think for a while. List the requirements you have for your programming language, and match them up against actual languages. Chances are you won’t find an exact match, but this should help focus your attention on a small group of languages that are more suited to your task than the others.

Color-Coordination (or When a Tracksuit isn’t Enough)

One problem you’ve likely encountered having followed the advice of the previous paragraph is that different parts of your program have different requirements. If you’re writing a game, for example, you’ll probably have a large portion of your program (containing AI, game logic, user interface, etc.) which needs to be easy to build and easy to change, but where performance isn’t critical. Unfortunately, you’ll also have a small, hard core of the functionality (probably graphics and physics routines) where performance is of the utmost importance.

As with clothing, not everything has to be the same color. As with food, you’re allowed to have more than one flavor in a meal. In programming, you don’t have to use the same language throughout the entire program. There are ways and means of embedding almost all languages in other languages, even if it involves going via C on the way. This way you can enjoy the benefits of each language in the areas suited to it, without succumbing to its weak areas.

Beware the fashion police, however—too many different languages in one project will quickly tie you up in the mess of integration, rather than letting you get on with using your chosen languages. I still have visions of my high school English teacher, whose favorite color combination was yellow, lime green, turquoise, and hot pink. You don’t have to be like her!

Forging a New Path

Take off your blinders! Look around you! Marvel at the vast array of possibilities!

Dare to find the language which makes your task easier! And when you, in turn, get asked “Which language should I learn?” do the right thing—ask a question in return: “What do you want to create today?”

Appendix: Languages to consider

To complement this piece, here’s a short list of some of the better-known languages. Support for all these languages is good, and the developer communities are of a fair size. They represent a reasonable cross-section of traditional languages.

Compiled and JIT-Compiled Imperative Languages

• C
• C++
• Java
• Objective C

Imperative Scripting and Extension Languages

• Lua
• Perl
• Python
• Ruby
• Tcl

Functional Languages

• Caml
• Haskell
• LISP
• Scheme

Logic Languages

• Prolog

…and of course, if you want an adventure, you can always try http://www.kraml.at/stupid/languages.html for some truly bizarre inventions.

Bio

Keith Bauer is a 22-year-old graphics programmer living in Wellington, New Zealand and working at the New Zealand Meteorological Service. He has university degrees in Computer Science and Mathematics.

choosing,programming,language