A Conversation With Bill Budge

[Pinball Construction Set creator Bill Budge is working at Google and trying to solve problems relevant to today's programmers -- and in this interview, he reflects on the past, present and future of development.]

Bill Budge likes to code. Games, per se, aren’t his passion -- it’s the software. He’s known for his influential Raster Blaster and Pinball Construction Set, early software tools that blazed trails for user-generated content in later years. He was an early EA designer, and is the gentleman wearing the glove in the classic “designers” photo from that classic era.

Budge left the traditional game industry for most of the late '80s and early '90s, toiling away in solitude without much outside influence. But he realized the world of code and tools was changing around him, so he returned to the scene with EA, then 3DO, then Sony, and now Google, continuing to build tools that enable other developers to do their jobs better. He’s now in the Native Code division of Google, working to make raw code viable in a browser.

Budge likes talking code almost as much as he likes coding. So that’s what we did.

It seems like you’ve always loved software tools. Where does that come from?

Bill Budge: I don't know how well I can explain it. I've just always liked the idea of taking what you have -- the pieces -- and putting them together to build something that didn't exist before.

That just goes all the way back to being a little kid, playing with blocks and construction sets. Those were always the kinds of things I liked. We scrounged around for stuff and made go-karts. That was always really fun and exciting. Programming just feels, to me, like that, really.

What made you want to construct in the virtual world versus the physical world?

BB: You could build things in the virtual world that can't really exist. You could make a pinball construction set out of real parts with pinball pieces, but it would cost thousands of dollars. But, yeah, in a computer, you can make something that costs $20.

After the break from making games that you took, you’ve talked about how it can be difficult to get back into the swing of things. That gap was in the earlier days, so maybe it wasn't so difficult?

BB: I kind of tapered off. I didn't leave suddenly. I did that MousePaint program for Apple, and it was a really good deal for me. Part of the deal was a little open-ended. They didn't want just the MousePaint program. They wanted a whole framework, so that it would be like the Mac ROMs really, so that you could render text and build apps. I think only one app was ever built with it.

It's amazing, Think Pascal. It's like an IDE that runs on an Apple II maxed out with a language card and bank switching. It was wild, pushing that things way beyond its limits. So, I had to spend a lot of time finishing all the details on that. And then after that, I had a Mac... Actually, I had one of the first plexiglas prototype Macs.

Oh yeah?

BB: Yeah. I had an Apple II floppy, which included a disk controller, and it had the circuit board, one of the first Burrell Smith circuit boards, and the screen, and analog electronics. But it didn't have a case yet, so I had a beautiful plexiglas case. They gave eight of those out. Microsoft got one, and I got one. I was trying to build some games, but it was black and white. And the mouse, it wasn't really clear how to use it as a controller. I got some pretty fast-speed graphics going on it, but I just didn't have much enthusiasm for continuing with that.

I made a game years later on the Mac, which was just a port of Pinball Construction Set, but then I started working on this idea, which was the Construction Set, which was kind of a stage machine editor and a visual programming environment. And I was writing that in C, which I used in college, so it wasn't all assembler.

I was building this program but didn't really have any customers, and I was just off by myself, sort of getting more rarified and abstracted and trying to do this amazing thing. It didn't work out, so... Really, I left it at that.

I just kind of, at that point, stopped doing much programming at all. And windsurfing mostly. Yeah, just working pretty slowly on this project. And that was bad. So, I think when I got married, which is like in the early '90s, I realized I needed to get back. I did a deal with Electronic Arts doing a Sega Genesis game, and that started with assembler. Game development was turning to C++.

So, I really had to learn C++ on the job at 3DO. They hired me because I had a really good assembly language ARM engine for 3DO, so I was doing that. At that point, I learned Maya, I learned .NET, I learned a whole bunch of tech. And then at Sony, I really learned .NET and became an expert on that. So, yeah, I guess maybe I exaggerated. It didn't take that long to catch up.

Were you at 3DO when they were making the M2? (Ed. note: The abandoned successor to the original 3DO hardware)

BB: Yeah, they ran into problems because of the software. I don't know if you know this story, but Mark Cerny was consulting. He came in one day, and they had all these SGI guys, and they built this bloated retained mode scene graph renderer, and the games were running it at like two frames a second. It was terrible. Because they were used to much more powerful systems.

And Mark Cerny came in with this very tight little piece he had written in assembly language -- he's an awesome assembly coder -- and a very well-designed process data, taking into consideration how big the caches and the memory were on the system. It was really fast. He saved that whole project. So, yeah, I've got a ton of respect for Mark after witnessing that and [how] he rebuilt that whole project. I guess in the end they had to sell it and close that down, but it would have been nothing without that. That was cool.

Do you still have that old plexiglas Mac?

BB: No, they asked for it. They took it back. Yeah, they were always very nice to me. Steve Jobs was always really nice. He treated me well. And, yeah, I was very privileged. It was really amazing being able to hang out with those guys.

You've worked in several programming languages. What do you think was best in its time?

BB: The early, early days when everything was in assembler, I think the Pentium architecture was really beautiful. The first Pentium. It was probably the most fun assembler language to do, because it had two pipelines, and you could schedule instructions so that they were both busy. There's some amazing beautiful code.

Quake has a little segment of code that's unbelievably beautiful. It uses every register and every cycle. The floating point unit, too. And it's all kind of choreographed so that everything is busy and it's pumping out the maximum number of pixels. Beautiful, beautiful code by Michael Abrash.

Like early multi-threading.

BB: Yeah. It's at the very lowest level. You're keeping all the hardware busy. I really like C# for building big apps fast with big teams. I think it's awesome. A lot of people don't like Java or C# because they're kind of verbose, I think they sort of strike a balance between -- I don't know how technical you want to be --

Go ahead!

BB: I like C# and Java because they're very readable. It's a great language where people can communicate. They're not the most powerful languages, but really powerful languages have this problem that as you get more abstract, as the expression gets more powerful, it's harder for other people to understand. So, I think it's kind of a balance.

Maybe to have a little bit of verbosity, you have to say things multiple times, more boilerplate, but large teams can collaborate. C++, if it’s kept to a nice subset, is very powerful. Tools are unfortunately kind of crippled, but it's a reasonable language if you restrict yourself.

The problem with C++ and all the old C languages is a couple of things. Preprocessor just makes it impossible for the tools to really understand the code reliably. There are very few environments that actually can deal with C++, where you can find every reference a symbol would say. In large programs, it's really important to be able to navigate and browse code powerfully, to be able to say, "I want to find every place that this symbol is used." When Chrome is loaded into Visual Studio, which is a fine tool, it does a terrible job. It just doesn't find all the things, so it really slows you down.

Kenta Cho, he's an indie guy, he programs everything in D. That's curious.

BB: Yeah. I'm intrigued. The problem with D is it’s just not adopted as C++, which, you know, has got a lot of problems. A lot of people like D. I certainly would be rooting for it to be catch on. Another language that's even more different -- and this is going to sound like marketing speak, but I'm intrigued by Go -- because in a way they're ejecting a lot of problematic old things that are in object oriented programming, like inheritance for instance. And I like the treatment of interfaces. It's kind of intriguing.

If they can get their performance story to where they are equivalent to C or C++, because I think right now in a lot of benchmarks they are at maybe half the speed... They'll claim that benchmarks are tweaked, you know, for the language... So, when they get that performance story, which I think they will, even though it's a garbage-collected language, that will be a very compelling language.

I have this fantasy of writing a browser in Go because it's a really great language for concurrency. And it's clean like C#. There's no preprocessor, no header files, so it compiles really fast. I mean, those guys are insane about making a compiler fast, and that’s very important also, reducing friction.

When it takes a couple seconds to build, that's a huge difference from when Chrome takes like three minutes, and I go grab a snack. And that's on a special machine with 16 cores. That's really not bad for a C++ program on the scale of Chrome, but still, it's a big difference.

Why is Chrome built in C++ as opposed to something else?

BB: Performance. Webkit was built in C++. You just have so much control over memory and how things are laid out. Webkit, I wouldn't criticize it. It's the fastest rendering engine for HTML on the web, and Chrome is built on that.

Yeah, control. It's a pain to debug. A point of view reference takes you to another file because it's a template. Whereas you have references just built into Java like C#. Nothing is as pleasant as building in C#. C# and Visual Studio, it just works great.

There's a large crop of web 3D things now. What do you think about all of these?

BB: Yeah. It's amazing how long it's taken for 3D to come to the web, and now there's WebGL. I think WebGL will be the thing that people will standardize on if they want to do 3D using JavaScript in the browser, which for certain things is very compelling. You wouldn't want to build a triple-A game that way because JavaScript is slow, and WebGL is just OpenGL ES. It's not really full OpenGL. It's restricted. You probably can do pretty good games in JavaScript, but it would not be a Call of Duty-style thing.

Unity, they've got a great engine, but I think that they... There's a lot more to an engine than just graphics. And with integration with the tools, then you can have more code that would be compelling in the engine, too. And they have great tools. I'm not all that knowledgeable on what is in their plug-ins, so I wouldn't say that they're out of business because of WebGL.

But I think what they're interested in is... They don't want to have a plug-in. They want to reduce friction, so they would like to use something like Native Client, which is actually the group I'm in, to write the functionality they want to write. They just want to run native code for their engine. So, they'll have to have the 3D interface. And I know that they're working with the Native Client people, but it's still a classic web thing. It's very fragmented. Nobody knows yet. And we're only talking about Chrome. So they've still got to have plug-ins...

Going back to that drive to create... When making Pinball Construction Set, I was getting the impression making that was for you a similar drive just creating software tools in general, because it's making an enabler, more than really making a game.

BB: Yeah. A really perfect thing for me to do, since I'm not a really good game designer. I don't really think of myself as a game designer at all. In fact, I don't think I've ever designed a game. Maybe Raster Blaster was a pinball table. So, yeah, I mean, the only thing I've ever been able to design are tools.

People ask you the question, you know, "How did you come up with the idea of user-created content in games?" But I was sort of getting the feeling that maybe it wasn't so much “let's change the industry right now.” It was making a tool with a game interface.

BB: I think a really good game designer has to love games, and they know what they love about games. They want to create that experience. I couldn't do that. I like building stuff, and that I can understand. So, I guess I built a game or program -- a software toy -- that I would want to play with.

It's kind of hard to think of building a pinball game now because I got really sick of it, but I built a lot of games, and I played it quite a bit. It was very exciting. There's a certain amount of excitement because you're seeing something for the first time, and you're building it. And you want to see it work in addition to using it. There's that extra thrill.

The best games or software products are people making things because it doesn't exist, and it's the kind of thing that they are looking for.

BB: That’s the secret. You know, Steve Jobs totally understands that; he builds what he wants. And then you refine it. I think a part of it is you've got to give it time. You build it, you love it, then you realize it sucks and you want to make it better. Then you go through about five or 10 iterations of that. In the end, you're kind of tired of it, but for the rest of the world it’s amazing.

It's interesting to see how that mentality does not filter up so well in certain companies. Like we've got a group of guys whose core competence is making big games, but Facebook games are the big thing, so we've got to try to get these guys to make some Facebook stuff, right? But they aren't going to be interested in making them, necessarily.

BB: Yeah, that would be a disaster if they're AAA guys.

It's interesting to see some of these companies try to wrestle with the idea of “how do we make games that people want to play, but that we don't want to make.” But of course, that's changed a lot, recently.

BB: You gotta have people who really get it and love it, and know what's great. Yeah, it's more than that. I guess what we're talking about is a vision. You need a visionary. Steve Jobs, he's a visionary. And he knows what he wants, and he's usually pretty right on.

Do you think it would be possible to create a game-oriented interface of some kind that could actually teach people programming, and teach people to be able to create, more than just pulling things together and assembling things?

BB: A full-power programming? That's kind of a holy grail, really. I don't think anyone's really come very close. There are specialized languages. Logo is the really interesting one for drawing. You can buy software to essentially program by building state machines and transitions, or defining actions and events, timelines with repeats, like Excel. There are little ways to do that, but really full-on programming where you're creating abstraction layers with data structures just seems very far away.

I mean, programmers think in a certain way. The computer is going to have to do a lot of translating at the very least. You know, for specialized domains... There are programs where you can take business entities that programmers have built and defined like connections or processes. But it does seem like it's far away. That would be wonderful, but I think programmers are just a group that think very differently.

Machines at the low level are still the same. They have registers and memory, and they're fairly complicated. And software is complicated. There are a lot of possible ways to structure stuff, and the ability to simulate what's going on in a computer like that is something that a small number of people percentage-wise have.

It really is like learning a language, though, as well. Certainly there are languages that people have affinities toward. I feel like games don't do a great job of teaching people language on a deeper level. But on a higher, Dora the Explorer-type level, they can teach you a bit of Spanish and how to string words together, or something like that.

BB: Really, if you wanted to teach in a certain domain, I mean, you can certainly create very interesting physics labs, for instance. I don't think that the possibilities for those kinds of programs have even be scratched. There can be some amazing stuff.

I mean, somebody built a 6502 emulator. They actually went and got a 6502 chip under an electron microscope and sort of extracted the masks from just the images, and then they run a circuit simulation. You can run this in a browser. It's an amazing little tool. If you're interested in microprocessor design, this is a microprocessor with 3,000 transistors that, you know, would be very understandable by a person.

It seems like everyone is kind of trying to go the other direction where they're just making it so you don't have to program sometimes. Unity and Unreal Engine, they both feel like they're moving in the direction to where you can get a lot more done with a lot less knowledge.

BB: It's definitely easier with tools like that, I guess, if you can afford it. Unreal Engine is another one, for sure. But yeah, Unity is great. I'm actually a huge fan of them. I mean, this was exactly what I was doing at Sony. We built kind of a more one-level meta up, which is we built a bunch of C# components and samples that showed how to build tools. And the teams could take this stuff and very quickly make an animation blend tree editor or level editor. We had prototype samples that they could very quickly just start modifying, grow, and make their own. So, it was kind of a construction set.

The technology is always getting better. Languages are better. Computers are faster. And, you know, there are tools like Unity. It's a little chaotic. There are a lot of open source editing tools. It takes a while, I guess.

There's nothing really compelling like a Maya where you can build your own like modeler. Because I think that's something that's missing. There's the modelers, and they can have plug-ins, but if you wanted to make a very different kind of game engine that did procedural geometry and you wanted to define procedures, it's more difficult, and you're sort of limited to what's out there already. Or you have to write plug-ins, which is demanding.

The Finnish company Housemarque, they actually use Maya as their level editor.

BB: There are two schools of thought in the game industry. Use Maya and write plug-ins, or build a level editor. Everyone uses Maya to model, or some modeling tool. I don't think anybody, or very few people... Even the Quake-style games, they have level editors, actual Doom-model geometry. They have a very different way of creating geometry.

But everybody uses Maya. Some people will do level editors, and some people will try to build a level editor in Maya. Both approaches have their strengths and weaknesses. And I've gotten caught in that battle a couple of times at a couple of companies. Yeah, it's just kind of never-ending.

As all these things get more robust, I think it will be interesting to see what happens. The flavor of an engine, that was never something that people would be able to identify before, but it's becoming identifiable.

BB: Well, it's funny, in a way... I don't want to sound like I'm criticizing Unreal or any engine, but they target a certain kind of game. It's really rare that you can do a first-person shooter and a racing game with the same engine and toolset. That's kind of a shame. It seems like it would be great if at least there were a framework that could build tools for different kinds of games.

And I think that’s the goal for everybody. They're all trying to get there. Since many of them do come from game creators, it will service what they want first.

BB: Yeah. Of course. And because game teams are always under a lot of pressure, they tend to just build what they need without thinking. And there's a lot of criticism for people who abstract too early and over-engineer, but in a way, for a framework, you do need to think more carefully and have that experience in multiple directions. "We don't want three separate things. How can we unify some of it?" And then customize it just because you've got code... Too much code is bad. It's what we do, but it's bad.

Code bloat.

BB: Yeah. There's a great quote, "Functionality is an asset. Code is a liability."

I don't know how long your current project is going to be -- maybe it's a forever-ongoing thing. But what do you see as your next steps for yourself?

BB: Well, my passion really is building tools and frameworks, and what I'm looking at are ways to deliver that, learn more about web programming, and ways more to build that. I've always built desktop apps, but it just feels like that's the past, and that web apps -- apps that are delivered in the browser -- really are a good idea. So, I wanted to see if that’s really true, because there's an opposite current of phones. Apps are back. Yay, apps are good again! And web apps on the phone can be kind of painful.

So, it's got ways to go. I guess I haven't totally made up my mind, but I wanted to learn about this and see how Google builds software. They must know something. They seem to do a pretty good job. It's been eye-opening. Nobody's perfect, of course.

Have you felt specifically like you learned anything from your time so far at Google? Or were you schooling everybody?

BB: No, everybody's really smart there. I wanted to be challenged. Everybody's really smart, at least in my build group, I think, just from conversations. It can become a little overwhelming. Everybody is trying so damn hard to be the smartest guy in the room, and you're just trying to keep your head above water. And, you know, you don't need to always be trying to impress everybody. But I've been impressed. Everybody is really competent.

I was on Windows, so I wasn't really up to date on Linux and Mac OSX. I was programming a pretty high-level language and was not doing any low-level systems. Our group does much more system-level stuff. Native Client has got a lot of system level kind of coding in it.

Chrome and C++, I haven't done much C++ because I was able to avoid it. And there are a lot of considerations to working with hundreds of people, the collaboration. I've learned a lot of nuts and bolts. I've done very little just coding away like I used to, which I do miss. There's a certain discipline that you do need on really big projects. They have an excellent code-reviewing process. There are a lot of great people. I've learning from people who are the top browser writers in the world. That part I love.

It seems the only person you can really try to impress is yourself. And that's impossible.

BB: At the end of the day, I think all that matters is what have you done. It doesn't matter how smart you are, or how brilliant do you sound, or whether you sound like an academic paper when you talk. What really impresses me is people who have built things, who made things that really worked, who did something that nobody else thought would work, or followed their vision and made it real. That, to me, is very admirable; the only thing that counts.