Interview:Daniel Auld

From Game Developer Research Institute

Jump to: navigation, search

< Interviews

Daniel Auld

We found Daniel Auld's résumé completely by accident, but we're glad we did. In the early 1990s, Auld worked at prolific contract developer Tose as a 3DO programmer. We asked him to share anything he could about his time there. Please do enjoy.

ABOUT THE COMPANY

Tose was a cut-out company, meaning they would be contracted by large game publishers to develop complete products, but would not put their name on it when released. The programmers would only get satisfaction by looking at the scrolling credits at the end of the game where they could watch their pseudonym names drift up the screen.

Tose was one of the first development houses to take on the task of writing software for the 3DO Multiplayer. At the time, there were concerns among investors that this device did not have a "killer app" that would catapult it past the established platforms from Nintendo, Sega, and Atari. Trip Hawkins, who came up with the idea for the product, repeatedly pointed to his reputation and said, "Trust me."

I was brought onboard with great excitement after responding to a classified ad the company had placed in the newspaper looking for American programmers. As a general rule, Japanese programmers are not known to be especially creative. If there is documentation, they are experts at applying and perfecting advanced techniques. But when it comes to "just winging it," they are typically paralyzed. Americans are known to be very creative, and a great deal of incredible titles were coming out of the gaming houses in California and elsewhere at the time. For this reason, they were ecstatic to have me join their team, and the managers were doubly interested in my Japanese ability to help translate what I read/discovered to the rest of the team. Interestingly, however, they would not give me credit for my work (possibly out of cultural pride). I would explain in detail some new feature that I had managed to figure out by trial and error (i.e., how to get sprites to behave in a 3D plane with appropriate clipping), but they would all stare at me with blank, confused looks, even though I spoke in Japanese. Then the manager would repeat my words EXACTLY (literally to the syllable), and they would all say, "Oh, NOW I get it!" Very interesting (and frustrating, as you can imagine). I stayed at the company from 1992 to 1994, making around 200,000 yen per month (roughly $1450 with the exchange rate at the time).

About a year after I got there, The 3DO Company was going to present at a large convention in Las Vegas (possibly the CES show?), and we would be able to ask direct questions to their engineers. This was a perfect opportunity for me to travel with my Japanese co-workers and get first-hand answers to our questions (I would act as translator). The managers indicated to the president that they REALLY wanted me to go with them -- but the president refused since I had only been at the company for a year at that point, and he "couldn't justify the expense for such a new employee." That didn't make sense to me, but [it] demonstrates how strict the adherence to rules was at the company, regardless of rational arguments to the contrary. In the end, it cost the company more in lost time as the managers who went could barely speak a word of English, and the video tapes they brought back of their trip had such terrible sound, I couldn't make out what was being said. Our questions remained unanswered.

There were at least three managers that I remember, one of which reported directly to the president of the company, who was probably in his early 30s at the time (though it is sometimes difficult to tell the age of Asians). This man was incredibly wealthy, which created a stark dichotomy with the rank-and-file workers (of which I was one). While the president was fussing over where to park his 10th boat, some of the programmers were paid so little, they actually had to stop eating near the end of the month when their money ran out. The managers were in the typical "salaryman" mode of work, where they would show up at 5:00a and stay until 1:00 or 2:00a. In Japan, it is said that "the company is your mother and takes care of you, so you owe it your full devotion." At one point, I asked one of the managers (who was married with two children), "Doesn't your wife mind that you are never home?" He replied simply, "She minds," and left it at that.

The floor I worked on was sparsely staffed -- about 20 people total. Half were working on cartridge games for the established platforms, the rest on 3DO. The cartridge programmers were on one side of the floor and worked with large desktop boxes that served as emulators for the final product and would compile/run machine code directly. The documentation for these systems was very detailed, and the engineers had no problem finding the information they needed (it was all in Japanese).

By contrast, the 3DO team were all on Macintosh desktops and had only skeletal documentation, all in English, that looked like it had been photocopied at Kinko's late at night. Large sections of this 3-ring binder simply said "TBD," and there were areas where the hardware was changing so fast that what was printed was already obsolete -- the documentation was definitely not keeping up with the hardware evolution. In a few cases, the text suggested some ideas on how to use a particular feature and encouraged us to "play around to see what you can accomplish" -- that was an alien concept to the Japanese programmers I worked with.

One interesting point of working at Tose was the attitude toward copyright and piracy. The company had no problem copying anything they could find, though they called it "borrowing the idea." There were elements of competitors' games that they couldn't figure out how to do (very advanced sprite animation, for example), so they would simply buy the game and without even playing it, put the cartridge in their hardware and pull the code apart.

The societal attitude towards gender roles also came through in the company environment: On our floor was a small area where we could prepare coffee or tea. There were cups, hot water, etc. as well as a sink to clean the dishes once you were finished. At one point, I had finished my drink and began washing my cup to put back on the rack. The president of the company tapped me on the shoulder and said, "Don't worry, the women will take care of that."

HARDWARE AND SOFTWARE

While I was at Tose, the 3DO hardware was still in the development stage and comprised simply of a motherboard in an open box with various IC chips plugged in. It was named with colors to indicate the revision level. For the majority of the time I was there, we were on the "brown" release, which was significantly developed to where it would interface with the Macintosh host through a special interface card plugged into one of the expansion slots. A ribbon cable ran from the output of the expansion card into a port on the 3DO dev hardware, which would allow us to load programming directly into the memory of the unit and simulate CD access (using special Mac software supplied by 3DO). Once a suitable software release candidate had been finalized, we could burn a specially-encoded CD and actually play it on the device directly.

We would write software in MPW C (Macintosh Programmers Workbench), compile it into binaries, send them over the connecting link into the memory of the skeletal 3DO Multiplayer, and test it out. Since we only had a single unit at the current revision level, we had to schedule time. If I remember correctly, there were simulators on the expansion cards that would allow us to approximate the execution of our software on the Macintosh itself, prior to testing on the actual 3DO unit. The Mac simulator did not have a game controller, so the keyboard was mapped to functions on the unit.

Disk access on the 3DO Multiplayer was incredibly slow compared to the Nintendo and Sega hardware of the time, as it used CDs instead of cartridges. Character animations are comprised of multiple single images that are played back in various sequences in response to the game controller. We had to come up with creative ways to pack multiple images into a single disc access as the "traditional" way of loading them one at the time was far too slow (cartridges are better for that as memory reads are nearly instantaneous).

Tose had been contracted to develop two titles for the Multiplayer, Ultraman Powered and a first-person interactive murder mystery product based on a book by one of the more famous Japanese authors of the time.

  • Ultraman Powered (developed for/distributed by Bandai)

This was an action game where the Ultraman character would battle with monsters using special powers and weapons. Very similar to many other fighting games that were being developed at the time on other platforms -- two characters seen in side view that fight in increasingly difficult match-ups. I did not work on this title very much other than doing some clean-up and color reduction on the individual animation images to help compress their file size (reduced the colors from 256 down to 16 or 32 depending on how they looked afterwards). The player had VERY limited memory, though I don't remember the exact amount off-hand.

  • Yamamura Misa Suspense: Miyako Kurama Sansou Satsujin Jiken (developed for/distributed by Matsushita)

This was an interactive story where the player would go through various locations (the garden, the den, the train station, etc.) and piece together the clues to solve a murder mystery. Rather than an action game, this title was more of a graphic adventure (think Myst) with lots of text and video clips that presented many choices for the player to make.

I developed two of the core elements of this title: a 3D walkthrough of the house in the story and an algorithm to allow the player to use a magnifying glass on a seemingly innocent scene to look for clues that would be revealed when enlarged.

For the magnifying glass, I used some of the special features of the 3DO player, one of which was not clearly documented anywhere. There were a number of hidden rendering buffers that could be used for fast animation. What I did was to put a large version of a scene (in this case, the room of a house) in a hidden buffer, then displayed a smaller version to the player. I then created a magnifying glass sprite which would move in response to the game controller. Inside the lens portion of the magnifying glass, I would copy a piece of the larger image, creating the illusion of magnification. It was very believable. There were pieces of the display image that were too small to discern, but looked suspicious. By running the magnifying glass over them, the "clues" would become clear (since they were now bigger and easier to see). The undocumented trick I figured out was the ability to create a round mask for the lens portion, so the magnified piece was circular (the base command would only copy rectangular shapes). Here's the technique in a nutshell: the high-order bit of a 8-bit image was used as a mask (leaving the remaining 7 for color), but there were not any commands to manipulate them easily as a whole. What I ended up having to do was create a 32x32 grid on paper that represented my high-order bit plane for the lens portion (the magnifying glass was a small sprite). I drew a circle and manually colored in the squares that were outside of it. Using 1s and 0s, I then built a simple two-dimensional array to use in my program. With the array as a guide, I would perform logical OR operations on the appropriate pixels of my image to set those bits before displaying to the player. The end result was that the 3DO sprite engine would ignore any pixels that had that bit set and display a circular image.

About the time I was building this element, I think they were trying to reduce my salary and have me come in more often. I don't remember exactly why, but for some reason, I decided to quit. They asked for the magnifying glass code, but I had already deleted it and was not about to recreate it given the current relationship.

The manager of the development team was not happy with that response and proclaimed they would reproduce it without me. He walked defiantly to his lead engineer and asked him how I had produced the round sprite; the guy just shrugged -- it wasn't documented anywhere. The final version of the game had a square magnifying feature, so they never did figure it out.

The 3D walkthrough would start by presenting the player with a hallway that they would use the game controller to navigate. They could move forward, backward, turn, go upstairs/downstairs, and open various doors to enter rooms in the house. This was all rendered in real-time 3D, using grid transforms, clipping, and z-buffer ordering to produce the illusion of moving through a real house. Two special pieces of hardware were utilized in producing this result -- a sprite rendering engine and built-in matrix multiplication, both of which were unique to the 3DO unit. Together, these were the "claim to fame" of the Multiplayer and had EA believing it was the "ultimate platform for next-generation gaming." The sprite engine would perform real-time pixel transforms on images, mapping them into bounding shapes to simulate perspective. If you started with a square image, you could "tilt it sideways" by shrinking the bounding box along one edge to simulate distance. The sprite engine would do the appropriate interpolations of pixels to compress the "far" edge of the image and create the illusion that it was in perspective.

The theory was that you could take a grid of points representing a complex shape, use the hardware matrix multiplication to transform it (rotate, scale), and map images to the various faces, which would be manipulated by the sprite engine to create fast, simulated 3D. Great theory, but at the time I was developing, there were wiring issues in the 4x4 matrix functions to where it always produced the wrong answer. Ultimately, I had to use 3x3 grids instead to do my rotation transforms, which were less desirable than a 4x4, and [that] meant I had to fill in the gaps separately. This slowed the overall execution somewhat, but [it] could be overcome to some extent by pre-calculating certain values and using lookup tables.

GDRI: Did you go by a pseudonym on the games you worked on?

DA: I don't recall what pseudonym I used, but it was probably something like "Elvis" in homage to "The King."

GDRI: Do you remember any other games being developed at Tose besides those you worked on?

DA: I remember Tose working on the Dragon Ball Z series while I was there, but I don't recall specifically which one.

GDRI: Was Tose contracted with the "main" development of the games you mentioned or just small parts?

DA: The 3DO games were being mainly developed by Tose (I think they may have outsourced some video production on the mystery title). For the console titles, I don't know the company's level of involvement -- I don't remember any specific conversations regarding that topic. In fact, I don't think I ever spoke to the machine language developers at all.

GDRI: Were employees assigned games to work on? Considering Tose's supposed output, might an employee work on multiple games at the same time?

DA: Employees were definitely assigned to more than one game at a time. While I was there, I contributed to both of the titles I've mentioned, and I know some of the other programmers had been splitting their time between 3DO and console programming (most of our guys came from that side of the house originally).

GDRI: How long did it take to develop a game? Do you know how long it took between the end of development and release?

DA: As far as the time frame to complete a title and then bring it to market, I didn't have any visibility into that realm. I know for the entire two years I was there, we were heads-down on 3DO, and neither game was quite ready for prime time when I left, but they did come out eventually (come to think of it, I don't believe I've ever heard anyone else mention Ultraman anywhere except me, so that product may have died on the vine[1] -- the action on the 3DO console was not as fluid and crisp as what was available on Nintendo/Atari/Sega, so it may not have been able to compete. What made the Multiplayer unique at the time was the ability to play video and some of the specialized hardware).

GDRI: Were there any other non-Japanese working at Tose?

DA: I remember there being one attorney who was white, American, and far more proficient at Japanese than I was. I don't remember his name as I only met him once while in a large board meeting. It is very possible there were others as well, as I did not meet everyone in the building.

GDRI: What brought you to Japan to begin with?

DA: Originally, I went to Japan with an exchange program from Antioch College in Ohio. We went over for six months to perform around the country in a traveling theater troupe. When the program ended, everyone went home except me, who had already found work as a programmer (not with Tose yet). I ended up staying another 3 1/2 years until coming back to the U.S. in 1995.

Thanks go out to Mr. Auld for taking the time to write such a detailed initial response and answering our follow-up questions. He works as a technologist available for contract or part-time technical consulting and development. Find out more here. He is currently the CTO of Global Fitness Media.

Interview conducted via e-mail by CRV in June 2008.

Footnotes
1. Ultraman Powered was released. [1]