Volume Number: 19 (2003)
Issue Number: 12
Column Tag: Interview

Getting Started

Meet Andrew Welch

by Dave Mark

This month's column is a bit of a departure from our normal Mac dev exploration. As long-time readers know, I am a big gaming fan. I recently had the chance to hook up with one of the originators of shareware gaming on the Mac and I wanted to share this conversation with you.

Andrew Welch, aka Ambrosia Software, Inc's el Presidente, started developing software in high school because frankly, it was better than flipping burgers (though he did have a stint as drive-thru guy at Roy Rogers). He went on to study Photojournalism in college, but decided to pursue software development for a living rather than carry someone else's camera bags. He currently lives in Rochester, NY, and has the oddly polar hobbies of origami and weight lifting.

Dave: Can I call you Andrew, or would you prefer el Presidente?

Andrew: If you call me "el Presidente" I might end up the target of some sort of "regime change", so let's keep it safe; "Andrew" is fine.

Dave: I first became aware of Ambrosia in 1992 with the release of Maelstrom. Can you give me a bit of history here? What led up to Maelstrom?

Andrew: I was actually in college at the time, working on a degree in Photojournalism. Maelstrom was developed over the summer, primarily because I heard someone state that good color animation wasn't possible on the technologic tour de force at the time, a Mac IIsi.

It served as a fun little project for me to hone my 68K asm coding skills; almost all of Maelstrom is written in assembler, with a few non-critical interface routines done in C. I wrote the game myself, but I had a number of people who assisted me, creating the graphics for the game, and all of my friends pitched in play testing it and helping me record sound effects for it.

I polished it up, put it online on AOL, and was surprised at how popular it became.

Dave: What was the state of shareware back then? Was there any kind of movement to organize shareware? Did you get a lot of payments, as compared to the number of game downloads? Where did people get most shareware? CompuServe? AOL?

Andrew: At the time, at least in my world, AOL and CompuServe were the major places to put software. The web hadn't taken off yet, and the Internet was something that only people with few social skills muttered about.

Shareware back then was fairly unorganized, in the sense that there were few products that required license codes to operate, payment was optional, and you had to send in checks or cash to pay for something. One of my favorite things was receiving money in various currencies I'd never seen before, from all over the world.

There was something distinctly cool about writing something in my dorm room in Upstate New York, and having people all over the world writing to me about it.

As for payments received vs. downloads, it's never a metric I've considered important. Many people download something, then forget about it, trash it, or whatever. I really didn't pay too much attention to the money it was making, because I was busy in college, doing things college kids do.

Dave: 1992 saw the introduction of System 7.1, as well as the Mac LC II, the Quadra 950, the 25 Mhz 68030-based PowerBook 145, the Mac IIvx and Mac Iivi, and the PowerBook Duo 210 and 230. Microsoft introduced Windows 3.1 and NeXT released NeXTSTEP 3.0 and NeXTSTEP 486. What was your dev environment back then?

Andrew: I actually had the original NeXT documentation, too -- I was a NeXT developer, even though I actually didn't own a machine (I couldn't afford one). On the Mac, my development environment was originally THINK Pascal, but I transitioned to using THINK C (this is before Symantec bought them out). My main development machine was a Mac Iisi at the time, with a whopping (for the time!) 17mb of RAM!

I actually started coding originally on a 512K "Fat Mac" -- yes, younguns, this was the technology of the day, and it had only 512K of memory. I used a 1200baud modem, and my life changed utterly when I was able to buy a 20mb hard drive for the machine. Prior to that, I booted from a 400K floppy drive, and did all of my development on an external 400K floppy disk.

You young whipper-snappers have no idea how good you have it! God, I feel old now...

Anyway, back to the question at hand. THINK C was a very cool development environment for the time, though it wasn't as friendly as THINK Pascal, the environment I started out programming with. I taught myself both languages, and the "bible" at the time was a phone-book style volume called "Inside Macintosh." It was mostly an exercise in curiosity for me; I wanted to figure out how these computers worked, and I truly enjoyed creating things.

Dave: More than ten years after Maelstrom, how has your development environment changed?

Andrew: For my personal development these days, I use Project Builder. It used to be Code Warrior, but to do some of the projects I've needed to do for Mac OS X, Project Builder was a better, if less refined, choice. But now it isn't just me; we also have an ace coder named Matt Slot working for us (we affectionately call him our "Code Whore"), as well as developers all over the world we partner with.

I don't do as much coding as I used to. I do some work on our supporting libraries, and there are some major projects that are all mine (such as Snapz Pro X), but I spent a lot of time running the company and managing projects these days.

I've dabbled a bit with Cocoa, such as our free WireTap product for recording system audio, but I'm not comfortable enough with it to say I'm any good at it. I wish that I had the time to invest to dive into it deeper, but so it goes...

Other things have changed a bit. The development cycle is no longer code, run, crash, poke around in MacsBug, then reboot your computer while you slam your head into the monitor. Lather, rinse, repeat. In that sense, my sanity is significantly improved these days.

Dave: You used to do all of your development in house. How has this changed?

Andrew: We try to stay very involved in the design and development of all of the products we work on, because we collectively have a lot of experience in terms of making a polished product that people will be interested in. We are involved on many levels: helping to design the feature set/game play, offering technical assistance in the form of libraries we've written that do very useful (and hard) things, as well as debugging support, and then of course things publishers do, such as marketing, support, etc.

We do both in-house and external beta testing, phased in so that it fits with where the program is in terms of development, and we manage the beta tests. External testing is a must, because there is no other way you can get an idea how your product will perform in the wild. If I had a dollar for every time something I wrote crashed on someone else's machine, but "worked for me", I'd be rich indeed.

Dave: Clearly, games are one area where you really need to be able to move pixels quickly. Can you talk about the kinds of approaches to blitting you use in house? How about outside developers that you work with?

Andrew: We used to do all sorts of very tricky things to blit pixels to the screen quickly, such as using custom assembler for critical portions. Now it's mostly just of historical interest. Computers are fast enough now that you can safely just use the provided OS routines such as CopyBits() or even better, just use OpenGL (for both 3D and 2D).

Dave: How has your net gaming strategy evolved over the years? Is there a standard protocol for finding opponents over the net, for example? Do you roll your own net gaming libs?

Andrew: Obviously, net gaming is important, and has been for years. It's important to the point of designing your game around the physical limitations that things such as latency introduce, as well as designing your game to be a fun multiplayer game.

We looked at available solutions out there, and decided to roll our own. We use something Matt Slot wrote called Network_Tool (hey, no one said his forte was coming up with creative names), which handles TCP/IP as well as UDP networking. It performs quite well, using proprietary algorithms of concatenating and retrying transactions. This is an example of a library we develop and provide for the partners we work with to use. It takes care of the dirty, tough to write stuff, so people can get on with making their game.

Similarly, we have a library called Reggie that handles allowing people to find others on the net. It works in a very general manner, allowing for data to be stored in any format the client application wants, and it's all stored on the back end in an SQL database.

Dave: I know you recently implemented your own order processing system. How did you used to do fulfillment? How does the new system work? Is it something you wrote yourself?

Andrew: We have long had our own merchant account for credit card processing, but we decided it was long overdue that we take it to the next level and automate and enhance our order processing system. We came up with a set of design specs, and handed them off to a third party developer to implement them.

Alas, in the end, we had to do quite a bit of work ourselves to make it work the way we wanted it to. On the upside, though, our customers get their license codes instantly, they can get lost/renewed license codes sent to them any time they wish, and it all integrates seamlessly with our FileMaker Pro Server back end.

Dave: What are the technical details behind your web site? Do you use a DBMS? Is it straight HTML? Do you update it by hand? FTP? Use a management package? BBEdit?

Andrew: Our web site is for the most part nothing too exciting. We have a number of custom written or modified Perl scripts that handle the drudgery of most of it. We set up systems so we generally don't have to edit HTML, just work with custom scripts we've written to do various things to it.

We update it by hand over sftp, and BBEdit is of course the tool of choice to do any kind of serious editing. It's true, it really doesn't suck.

Dave: You've got some fascinating utilities that have pushed the envelope beyond traditional application development. Snapz Pro is a perfect example. Can you take us behind the curtain on some of this technology, tell us a bit about how they work?

Andrew: Snapz Pro X is something I've been working on heavily lately. We've done a major interface reorganization, and an even more major boost in performance of the video capture engine. When 2.0 is released, we'll have made video capture as easy to do as static screen captures (something Snapz Pro X excels at already), and I'm betting that many people will opt to put a short video of their product in action up on their web site to show it off, rather than a static screen shot.

Making something like Snapz Pro X work involved very long sessions probing the various MacOS X system frameworks with nm (a command line tool) to ferret out the functionality we needed. Many times the APIs we needed didn't exist, and waiting for Apple to make them available just wasn't a viable option. Remember folks, it's software - anything is possible, it just depends on how much effort you're willing to go through to make it happen.

Dave: What advice would you give today's shareware developers?

Andrew: My main piece of advice is not to set the bar low just because they are writing shareware, or they are pricing it cheaper than commercial counterparts. People tend to judge things by why they offer them, not by how inexpensive they are. For instance, let's take games. Games are entertainment. If you go to the video store looking for a movie, you don't bypass the better movies for a budget $2 college film. Sure, it's cheaper, but it doesn't matter, you want to be entertained.

Don't kid yourself that you can offer an inferior product just because it is cheaper, and expect it to do well.

My other main piece of advice would be to figure out what you want to do. Many people who go into think they want to do the whole shebang: development, testing, marketing, support, order processing, etc., etc. This is a quick way to lose your sanity if what you really want to do is just develop cool software. Figure out what you really want to do, and partner with someone if it is appropriate.

Dave: One of my favorite things about being part of the Macintosh developer community is what an incredibly small world we live in. Whenever I travel I always seem to run into someone I know from this universe. Don't you have a story - something about beer?

Andrew: I recently went to Germany for Oktoberfest, which is a wild time, with some great German beers in mugs you need two hands to lift up. While sitting in an old brew house having some beers with friends, I was a little surprised to see a guy walking by with a Metrowerks t-shirt on.

So I pulled him aside, and decided to clink mugs with him, and see what he used CodeWarrior for. As it turned out, he was a Metrowerks employee... and all 20 or so people at his table were as well. So if the next version of CodeWarrior is a bit delayed, I think we may know why... the coders are all off boozing it up somewhere.

Dave: What's on the horizon for Ambrosia?

Andrew: We're always working on plenty of new projects. We just released our Internet search tool, iSeek <http://www.AmbrosiaSW.com/utilities/iseek/> that's going over quite well, and as I mentioned, I've had my head buried in Snapz Pro X 2.0. That's going to be a huge product when it comes out, the video capture performance is just amazing now.

Additionally, we're always working on cool new games, some of which we've announced, like our 3D racing game Redline, and others we haven't. And you can't make me talk either. :)

I hope you enjoyed this little respite from coding. I know I did. Part of this was getting to know someone who has really been a part of the Mac gaming story. But another part of this month's column was a bit of a stroll down memory lane. I mean, c'mon, Think Pascal before it was bought by Symantec. I love it!!!

Dave Mark is a long-time Mac developer and author and has written a number of books on Macintosh development, including Learn C on the Macintosh, Learn C++ on the Macintosh, and The Macintosh Programming Primer series. Be sure to check out Dave's web site at http://www.spiderworks.com.