Man, where does the time go?

Miss Maggie turned two years old on Monday.

Man the time flies by. It really doesn't seem like two years since I was sound asleep in the delivery room. . .

Okay, might as well tell you that story.

About 24 hours before Maggie got borned, Shelly went into labor (as women tend to do before their kids get borned). I drove Shelly to the hospital late in the afternoon where they took us to a "pre-labor" room, which is a tiny uncomfortable room where they determine if you're really about to make a baby or if you've still got some time left. A doctor checked Shelly out and said that she was at least 24-36 hours from babytime. They gave us the option to stay in the tiny uncomfortable pre-labor room or to go home and return when babytime was closer. Shelly opted to head back home. Since the doc wanted Shelly to get a good night's sleep, they gave us a couple of Ambien sleeping pills, which are apparently fetus-friendly.

We got home but Shelly didn't wanna take the pills "just in case". Since I'm a lousy sleeper and knew I was gonna have a busy day the next day, I took the sleeping pills in the hopes that it would let me get some rest for the drama that was to come.

Fast forward to 4:00 the next morning, and Shelly decides that IT IS NOW TIME. Problem is that I, otherwise known as "the guy who's capable of driving a car" am now deep in drug-induced sleep. Shelly tried to wake me up a couple of times with little success, so she busied herself as best she could packing clothes and putting 'em in the car. Around 6:00, she could wait no longer. She then bounced me up and down on the bed shouting "GET UP DAMMIT!" until I finally stirred. I drove her to the hospital, which was probably not the safest thing given that I, to use "Dragnet" terminology, was wacky on the goofballs, but having a 9-month pregnant woman next to you giving you lurid descriptions of her pain tends to keep you awake.

We made it to the hospital where Shelly was re-admitted into the pre-labor room and was pronounced "ready to go". We were taken to the labor room where I promptly fell asleep on the couch for about another four hours while Shelly got hooked up to all kinds of fetus-watching machines. About 1:00 that afternoon we had ourselves a cute, but extremely loud, new addition to the family.

The moral of the story is "Ambien is good stuff!"

Here's my favorite picture of her at one day old. It looks like she's getting her first look at the world, and she just ain't buyin' it :)



And here's a picture from a couple of days ago, immediately after discovering that eating a blue sucker tends to turn one's tongue blue.



At her 2-year checkup she was once again pronounced "exceedingly tall" at 37.5 inches and 33 pounds. She's a big girl and a big joy in my life. Can't ya tell?

I have GOT to see this

Yeah, it could end up being one of those bad "intentional cheese" films, like Straight To Hell, but the trailer for this one is pure genius. The guy who wrote this strikes me as someone who has genuine affection for low budget 1950's monster movies.

http://www.apple.com/trailers/sony_pictures/lost_skeleton/

I especially liked THE TITANIC BATTLE FOR WORLD SUPREMACY. It had me on the edge of my seat :)



Quicktime Hint: If you don't want the Quicktime player pestering you to buy the Pro version every other time you use it, do the following:

1. Set your system clock forward quite a ways, like to the year 2014.

2. Run the Quicktime player. It'll pester you to buy the pro version.

3. Close the player.

4. Set your clock back to the present. It now won't bug you again until 2014.

Just remember to shut off MS Outlook before doing this. Otherwise Outlook's calendar will immediately remind you of ten years of appointments that you missed.

The Ultimate Date Class

Just saw John Munsch's entry on date classes, and I too am puzzled by why date and time classes are inevitably so unworkable. For my own edification, I now present my own date class that's simple, elegant, and probably completely unusable.

First off, let's dispense with making "date" and "time" two separate things. A date is just a way to express longer times, so there's no need for it. Let's just call it "time". After all, the year 1532 is a "time", but 8:00 this morning is not a "date", so "time" is the better descriptor.

Now let's think of a data structure. An unsigned 64-bit integer is capable of holding millionths of a second for about 585,000 years, so let's go with that. That'll satisfy the game-geeks who need millisecond timing along with the epoch counters who want to know what day of the week was July 4, 1776. We can even extend the calendar back a few thousand years. Let's make our pivot-point the date of the moon-landing (certainly a significant date, and much closer and easier to pinpoint than any ancient religious events), so our date object will be able to cover millionths of a second from approx 290,502 BCE to 294,440 CE. So you'll be able to use this time-object to track the journey of early protohumans across the Siberian landbridge, but you won't be able to track the progress of the Eloi and the Morlocks. Still, it's a good range and resolution.

. . .and Eloi and Morlocks weren't real anyway.

I mentioned before that this Ultimate Time Class of the Universe is probably entirely unworkable, and now's where it gets hairy. While it's got excellent resolution and range and not-unreasonable size (8 bytes ain't bad for computers today), the math necessary to calculate anything would be frighteningly ugly. To convert a 64-bit integer of microseconds into a "Tuesday February 24, 2004, 3:51 PM CST" would require some seriously ugly math, especially taking into account the little games that mankind's been playing with time ever since. . .well. . .time began. Things like adding or subtracting "leap seconds" now and then, and the Gregorian Calendar Reformations (when Pope Gregory III in 1582 declared that the day after October 4 would be October 15 to get the calendar back in sync with astronomy).

Maybe it won't be too ugly. Here's the code from my original date class that converts a month, day, and year into a Julian date (number of days since Jan 1, 5713 BCE). You'd think it'd be pretty hairy too, but it's not bad.

void Date::DMY(const ui8 &rDay, const ui8 &rMonth, const ui16 &rYear)
{
   ui8 MonthToUse(rMonth);
   ui16 YearToUse(rYear);

   if (MonthToUse <= 2)

   {

       YearToUse--;

       MonthToUse += 12;

   }

   i16 a = YearToUse/100;

   nDate = (ui16)((i32)(365.25*YearToUse) + (i32)(30.6001*(MonthToUse+1)) + rDay + 1720994L + (2 - a + a/4));

}

Oh, and for those who don't care about any of this, July 4, 1776 was a Thursday. Now you know something new.

Betcha didn't even know I was gone

Just got back yesterday from fabulous Las Vegas where the wife and I took a short vacation from the critter (who was staying with Shelly's sister) to enjoy eating, drinking, and gambling. We stayed at the Las Vegas Club, which has been one of our mainstays in Vegas. It ain't Caesar's Palace, but it's clean, has low-limit table games, and cost us about $35 a night.

We had plenty of good fun, despite our initial fright of waking up to four inches of snow on the ground that morning --in Fort Worth of all places. Our flight ended up leaving on-time, but spent three hours on the runway getting de-iced. We didn't have any pressing engagements on the other side, so we took the opportunity to catch up on our reading.

Once in Vegas, we had ourselves a good ole' gambling time. We played blackjack, craps, and three-card poker (a new table-game version of poker that's fun and dirt-simple to play). We played a couple of slot machines, which was basically a waste of time.

(Remind me never to play a slot machine again.)

The next night we did the Great Moments Room, which is a tiny dark little steakhouse in the hotel that happens to serve the best prime rib in town. Although next time I'll probably try their filet. The folks at the table next to us had one of those, and they were beautiful.

We also managed to check out a quite-nice art exhibit at the Venetian (much too high-class of a place for the likes of us). On the way out of the place, I managed to pick up a couple of 4-of-a-kinds on a video poker machine, which paid for admission to the art exhibit, bus fare to the hotel, and left me with a few bucks to spare.

Of course we also did the obligatory 99-cent shrimp cocktail at the Golden Gate, which is a Vegas tradition if there ever was one.

One thing that seems to have made a comeback in Vegas is the 1-cent slot machine. Of course, they're now quite a bit more sophisticated and are far more effective at draining your wallet than the old mechanical penny machines that you'll find at the biggest dives in town. The machine I played had up to fifteen paylines, and you could bet up to ten pennies per payline, which means that you can bet $1.50 per spin on a penny machine.

Of course, you don't have to bet that much on a spin, which brings me to. . .

How to get really drunk in Vegas really cheap

1. Go to one of those smaller, older downtown casinos (like the aforementioned Las Vegas Club or Golden Gate). The cocktail waitresses at those fancy new megaresorts are far too busy serving Gray Goose Cosmopolitans to $500 baccarat players to pay attention to the likes of you.

2. Stake out a penny machine in the main room of the casino. A lot of those old casinos have been expanded a half-dozen times, and they're a maze of side-rooms and hallways and such. Sitting near the bar is also a good idea.

3. Insert ten bucks (otherwise known as 1,000 pennies) into the machine. Play one penny per spin. You should be able to play for several hours without adding more cash. Resist the temptation to bet more.

4. When you hear the cocktail lady, flag her down, order your drink, and give her a healthy tip IN ADVANCE! Tipping in advance will ensure that your drink arrives posthaste. If you're worried about getting a watered-down drink, order a beer.

5. Repeat step 4 as many times as necessary, but without the tip. You're not really expected to tip more than once, especially if you're at a penny machine. If you're polite, she'll be by often. When Shelly and I played, our waitress was making the rounds faster than I could finish my drink.

6. Cash out once you've had enough to drink.

. . .Well, I guess there really is a purpose to those penny slots. They're good for getting pickled cheaply :)

Computerless no more

Yep, got the machine back only a scant week after sending it to the repair place.

I was getting impatient with 'em when they kept giving me the same diagnosis. They told me on the phone that they were getting ready to format the drives and reinstall Windows when I told 'em not to lay another finger on the machine and that I'd be there right away.

They gave me a clue when they said that it only restarted when IE was running. I got it home and everything seemed to be working, loading email, Trillian connecting, etc. It was only blowing up sporadically on IE, too. If I loaded a text-only piece of HTML, it was rock-steady, but when I want to my homepage (www.iwon.com), it'd blow up. Figuring it was a plugin, I uninstalled every plugin I could find, but to no avail. I then thought it might be one of the two plugins that seem to be impossible to uninstall, Flash Player or Java. On a lark, I went to the one website that I knew would not contain any flash content, and it loaded just fine. I then went to the one site that I was certain would contain Flash content, and it immediately rebooted.

I searched Google for a way to uninstall the Flash player and found this. After downloading the utility and uninstalling, everything worked wonderfully. I then re-installed the Flash player, and everything was fine.

I can only assume that something odd got written to the disk when we got the "power event" last week, and my Flash player was left in an odd state that would reboot the machine whenever it was run.

Computer-less

Sorry about the lack of updates. My computer is having some odd problems following a "power event" over the weekend. It appears that doing any kind of communication over the ethernet port now causes the machine to reboot, so it's in the shop. Hence I'm on the laptop in Shelly's office until further notice.

Or, to use Lord of the Rings terminology, STUPID FAT HOBBIT!!!

Anyway, go read Ernest's diary until I'm back up again. He'll eventually lose interest and it'll be another piece of flotsam on the information superhighway, but until then he's updating it regularly.

Game Development Common Sense

I'm getting ready to do a big redesign of the tired old Code Zone website. One of the things that's gonna be retired is the old Game Development Common Sense page. Since I think it still has a buncha valuable advice, I'm not in a hurry to let it disappear completely. Hence, I'm gonna post the entire contents here. That way it'll still have a URL if I want to refer to it again. If you've never read, enjoy!

---

Introduction

This work is a collection and expansion of various bits of wisdom from The Code Zone Developer Diary. It is meant to be a useful and interesting, but not in any way comprehensive, collection of advice for game developers. While aimed primarily at people starting in the industry, hopefully it will have a couple of useful ideas for professionals.

---

Design

Don't think that having a great idea is enough.

People who fancy themselves to be game designers because they play tons of games and have hot ideas aren't really sought-out commodities in this industry. Like it or not, the game industry is in the middle of a well-deserved 'correction', to use the stock-market vernacular. Literally thousands of titles are appearing every year, and only a few dozen are making money. To use a movie metaphor, for every Titanic, there are approximately ten Heaven's Gate's.If you plan to get a job in this industry, you'd better be able to do the following, and do it well, because publishers will expect it. . .

• Design a game, and write up a detailed design document that isn't abandoned immediately
• Write the code for the game
• Draw up the bits of art that you didn't/can't hand off to the artist.
• Work with a quality-assurance team to get your game bug-free
• Fix the bugs in the game
• Make changes in the game to match the market and your boss/publisher
• Write the manual for the game
• Submit your game to the proper legal authorities (lawyers, 'Made for MS Windows' seal, etc.)
• Communicate with the artists, so you don't end up with art/box/manual that doesn't fit the 'vision'
• Write an install program
• Drop a completed game on the boss's/publisher's desk that's ready to put on the shelf

If you're deficient in any of these skills, you'd better start working on it. Companies are far more interested in how well you can PUT A PRODUCT ON THE SHELF than how well you can code for DirectX, ModeX, WhateverX.Notice that, of the 11 skills mentioned above, exactly ONE fits the 'have a great idea' category. Sorry, but having a great idea is not enough!

One-man games can still be done, but not huge stuff. Know the limits (not just your limits).

This is something you can see in game development fora. Every other thread is something akin to 'I'm wanting to start writing games. I was planning to start out with'. . .followed by a description of a StarCraft or Quake clone, only bigger in scope.As an analogy, imagine for a second that you are a builder who wants to build something that's uniquely yours, so you decide to build the entire project yourself. No matter how talented and hardworking you are, you cannot build a shopping mall --it's simply too much for a single person. If you're good enough, however, you might be able to build a house. If you do manage to build a house by yourself, that's a feat which deserves respect, even if it's not a shopping mall.If you're planning to do a game by yourself, keep your sights lower than the top-shelf stuff. There can still be plenty of market for your product if you plan well. Large-scale stuff requires the effort of dozens, if not hundreds of people. You can't do all that yourself.

Look outside your genre.

If you're reading this, you're probably an 18-40 year old male, as that's the general profile of game programmers. Interestingly, it's also the intended audience for most of the top-shelf game titles. Computers owners, however, are not all 18-40 year old males. Computers are being used by 12 year-old girls, 60 year-old grandfathers, 30 year-old housewives, and toddlers. If you decide to write only games that you like to play, you might be missing a very good opportunity to sell some games in a more receptive market.Imagine for a second that there was very little variety in available cars --all cars are 4-door sedans. Everybody could drive them, but not everybody would be happy with such a limited choice. Parents with several children would rather have something with more seats. A student might want something smaller with better mileage. A builder might want something that could haul a load of lumber. Unfortunately, there aren't many cars like that, because the engineers design 4-door sedans. After all, that's the kind of car they like.Of course, that's not how things work in the auto industry. Engineers design cars that aren't necessarily made with them in mind.

Take an honest assessment of your skills. Know where you suck and where you're good.

If you can't draw your way out of a paper bag, hire out your art. If you have the grammar skills of a chimp, hire out the documentation or get a proofreader. If you don't have any QA skills, hire someone with QA skills to break your games. Cheesy art, bad grammar, or bugs will make an otherwise professional-looking title look like bad shareware.Conversely, if you're a terrific artist, make your game graphics heavy. If your language skills are top-notch, go for something with a lot of story. If you have a knack for writing stuff with zero bugs, consider writing libraries for other people.

You must follow a strict development methodology.

The computer gaming industry (yea, the entire computer industry in general) is very young, and is dotted with tons of rags-to-riches stories. There are garage startups that made it big (that 'Gates' company that's name escapes me), and there are ones that disappeared (too damn many to mention). One thing that's an absolute necessity if you intend to grow is to abandon the garage mentality. That means adopting formal development methodologies, project management techniques, and accountability for time. You've gotta lose the attitude that following a formal method is betraying your garage-programmer roots in favor of Dilbert-world.Yep, that also means that college is necessary. Kids in the game development fora will insist that college is not necessary to succeed in the computer games industry. Sorry to tell you this, but you're gonna need to know more than good ModeX techniques if you wanna succeed in this business.

Game development is not different!

That's right. Game development is not different from developing financial, database, or text-handling applications. Anyone who tells you otherwise is being too lazy to learn or is being dishonest with himself. Game development requires development plans, design documents, project management, schedules, resource management, design reviews, and all that other stodgy suit-stuff that you thought was irrelevant because you're gonna write games.Once again, the problem is that developing games is the most seductive part of programming. No high-schooler has grand visions of writing the next great financial report generator, and the industry is plagued by folks who think that because they know how to optimize fill-rate, that they're ready to release the Next Big Game. Trivial things like how to write a coherent development plan, how to manage a project, how to write a design document that doesn't become obsolete immediately, and how to schedule are viewed as being much less important than the ability to write code and pitch your grand vision to a publisher.Game development is only art if you don't plan to make any money. If you've got a publisher funding your product or you plan to pitch your product to a publisher, then you're not an artist. The era of 'Hey Mr. Publisher. Gimme a million dollars and I'll give you a great game sometime next year!' died in 1999. Learn to live without it.

---

Programming

Use mature code libraries for as much stuff as possible.

No game developer starts off a game development project planning to write their own operating system, memory manager, window manager, input manager, multitasker, and graphics subsystem for their game. For virtually all of those pieces, programmers choose base OS services that are already written. These services are, for the most part, very well tested, mature, and better than anything you could write. There is, however, no reason why you need to stop your search for services with the ones that the operating system provides. There are lots of good libraries out there to handle high-level graphics, sound, database, and video services. If you can cost-justify buying a library (and you probably can if you budget your time at more than $2 an hour), you probably should.There are several arguments people usually have against purchasing libraries. . .

Using somebody else's library will just make my game look like everyone else's

This is the old 'stock footage' argument. People feel that using libraries for look and feel will drain the 'soul' from their game, just like using stock footage in cheap movies can cause weird lapses in continuity. Remember, though, that computer games are not movies. Consistency between applications make users more comfortable with your product and means that they'll need less time with the manual or the tech-support line.I can probably write something better
Maybe, but can you write something in the time required to justify the cost? For example, you can get a decent 3D scene/graph library for $200 nowadays. If you budgeted your time at an entry-level salary of $15 per hour, that comes to 13 hours of your time. I guarantee that you can't write a decent scene-graph library in 13 hours. Budget your time and figure out the library's worth in hours rather than dollars.

Why should I pay for a library if there are free equivalents out there?

There are several excellent free libraries out there. There are also some group projects that are as stable as a house of cards. If the tech support for your graphics library consists of a mailing list or a group of kids who are supporting the library in their spare time, you probably shouldn't base a mission-critical project on it. If paying for a library obliges the programmer to help you out when your game is crashing, it's easily worth the money.

In short, find a mature library that's got the bugs fixed, and use the heck out of it!

Comment your code as you write it!

You certainly don't have to make your code-weight 50% comments, as is common in college courses, but it is important that you comment the tough spots and interesting bits. Much as you won't want to, you will have to revisit your code later during the coding or debugging process. If you're smart and you comment the trouble spots well, your life will be made much easier later. When I'm in the process of writing something really hairy (like a recursive search routine or a loop several levels deep), I like to pseudocode the whole thing in comments first like this. . .

// loop through every enemy
// first, check to see if a player's bullet has hit the enemy
// if the enemy is hit, remove him from the list
// otherwise, see if he has a bullet available and can see the tank
// if he can, fire the bullet
// check to see if the enemy is at an intersection
// if so, turn or go straight
// finally, update the enemy's position
// and move to the next enemy

Then, write the code to perform each step under the comment. For example, the code above is pseudocode for the enemy-update loop in the game Think Tank. It took about 150 lines of code to actually do all of the stuff mentioned. If the code was written top-to-bottom without a plan, it probably would've been more code and time to do it.Comments not only provide a way to see what you were doing later, they can be used as a planning aid for getting stuff done. They don't increase the ultimate size of the compiled code, so take the time to document your code as you go.

As far as user-interfaces go, just because you can do something doesn't mean you should

Just because you figured out how to write to the title-bar of your window does not mean that you should. Just because you figured out how to launch a URL from your app doesn't mean that you should add your own hotlist-bar. Just because you thought up a really cute control doesn't mean you should use it.If you need a scroll-able field in your game, use a plain old scrollbar rather than an esoteric slider that mimics the look of your game. If you need the user to click something to continue, use a plain old rectangular button. Forcing the user to learn an entirely new user interface right after he's figured out the user-interface of his computer is just rude.As far as interface goes, here are some rules of thumb. . .

• Whenever possible, use native controls (button, scrollbar, checkbox, etc) or controls that mimic the function of the native controls. Users already know how to use 'em, and that'll make it easy.
• If you've got a particular function that doesn't fit with native controls, try to make it as simple as possible. Don't automatically mimic a real-world control (like a round volume knob) thinking it'll be easier. People don't interact with the real world with a keyboard and mouse.
• If you've got an idea for a terrifically cute, yet useless, interface element, and you feel like you're gonna pop if you don't add it, at least give the user the ability to shut it off.
• If it slows things down or is going to cause tech support problems, dump it. It's just not worth it, no matter how cool it is.
• Don't add gratuitous colors and bitmaps to buttons, thinking that it'll make things easier.
• Finally, use words! Your users know how to read. The old adage 'a picture is worth a thousand words' works in some cases, but not all.

Examples of good and bad interface are available at the Interface Hall of Shame.

---

Publishing

Get on the phone!

Programmers, on the whole, are phone-phobic. They'd much rather do all their correspondence by email or by a mailed submission to the publisher. Unfortunately, though, that's not how most buyers work. If at all possible, try to get a phone-relationship with a buyer before you send in your submission. At best, the buyer will be eagerly expecting your product. At worst, you'll know the legal guidelines for product submission. There is no downside to talking to buyers on the phone.

Don't feel that publishers owe you something

They don't. Just because you made a game that you feel deserves to be on the shelves doesn't mean that publishers are gonna buy it. Publishers use lots of factors in evaluating your game, including timing for the market, requests from the retailers, and requirements for packaging, shelving, and tech-support.Ask the publishers what they're looking for. If you've got grand plans to get your game on the shelves, you must either already have a deal with a publisher, or you must have a game that they want. Never assume that you know what publishers want.

Don't think that just because you sent your product to the parent company that the sub-companies will see it

For example, if you want Origin to look at your game, don't just send it to Electronic Arts and hope it'll filter down to 'em. Many of these companies are merged in name only, and their business units are completely independent. That might require sending multiple product submissions to a company, but it's worth it if it ensures that the right people get your product.

---

Business

The object of a small business is not necessarily to become a large business

A fine example of this would be my father, who's been working as a manufacturer's rep for about 25 years now. In that time, he's gone from one employee to two employees (around 1980 he added my mom, who handles the orders). He's never gonna be on the cover of Forbes, but he does quite well and enjoys what he does. If you intend to grow, work towards it. If you wanna stay small, work towards that end. Don't assume that you've gotta be big to succeed.

Products are cheap, time is expensive

This is a plague for garage developers, that they budget their time at zero. There have been many times that people have ignored potentially useful hardware or software because they can 'get around' needing to use it. If 'getting around' a useful utility requires that you spend a lot of extra time that is better spent elsewhere, then you probably made a bad decision.The same can be said for computers. If it can justify your time to get a better piece of hardware, get it. A good piece of hardware might look expensive, but if it's reliable and doesn't need to be replaced immediately, it's probably worth getting.On the other hand. . .

Don't go hog-wild just because you got some cash, and don't fall in love with stuff

This is a problem for several high-profile shelf developers. Many companies, often with no successful products on the shelves, decide that they're stars and deserve some great digs and a truckload or chrome and glass. While penthouse offices are cool and look good in magazine articles, they probably aren't the best idea for startups, no matter how well-funded they are. Low-cost office space can be just as productive as high-cost office space if you make things comfortable for the developer.The same can be said for computers. Reliable machines with respectable, but not top-notch, speed are available for very low prices nowadays. Many, if not most of these machines will be quite capable for developing and testing your games. Before you decide to drop $3000 for the best box on the market, consider purchasing some much-needed utilities or books, or spreading the money out over two or three machines. You could then use one machine for graphics/email/documentation and another machine for testing under various OS's and graphic/sound cards.In short, before you decide to drop a pile of cash a chrome and glass penthouse office or the Ultimate Computer of the Universe, figure out if it's really worth the extra cash. If the extra money could be better spent on the purchase of some useful graphics tools, a compiler upgrade, or some books, it might be better to spend the money there.

Don't be unprofessional

Yeah, it's fun to sneak little personal digs, videos, and easter eggs into your code, but it's not professional. The game industry has a well-deserved reputation of being staffed by immature programmers, and that reputation hurts everyone. Developers will be kept on a short leash by publishers and bosses if they're not viewed as trustworthy.Despite appearing to defeat the ad-hoc spirit of hidden tricks, it is important for you to document all of your little undocumented tricks, cheats, and double-entendres for your publisher. If you've got your initials in a texture somewhere, or the 'about' box shows a picture of your girlfriend if you click in a certain spot, let the management know about it. They probably won't mind, but if they do, it's better that you know now before the CD hits the shelves.Needless to say, putting little extras in your game that can get you in legal trouble (like a defamatory image of a person or a picture or sound that's a copyright violation) is just plain stupid and will probably get you or your parent company sued.

Misplaced product loyalty

Saw a weird story over at http://overclockers.com/tips1133/ that's been circulating around. Basically a guy ended up with the case and power supply from a dead Mac G5 (the new dual-processor high-end Macintosh machine). He decided it'd be cute to put an Athlon motherboard in it.

Nothing interesting yet.

After that, though, he decided to make the whole thing into a not-all-that-clever prank. He made up a story that he was a kid who's parents got him a G5 for Christmas. Since he wanted an Athlon and since his parents knew nothing about computers, he decided to throw out the insides and install an Athlon motherboard in it.

When I first saw the story and didn't know it was a prank, my response was "The dumb kid should've convinced his parents to return the machine, because you can buy two nice Athlon machines for the price of a G5." That wasn't the response from some of the Mac-zealot community, though. He apparently got over a thousand emails (shutting down his mailbox) crying out in horror and hatred about what a horrible thing he'd done.

Some people even cried.

I wonder how many of those same people who cried for the death of a Mac G5 are crying right now for the several dozen people killed by suicide bombers yesterday?