StrifeStrips.com - Still built with build

Back in the days when 3D games were the new frontier in gaming, it was a teenager called Ken that pushed things forwards.

I conducted this interview using MoonEdit, a real time text editing system. Which was certainly a new experience, try it out for yourself.

Well, there's all the latest stuff on my website - things I did after Build. Some of my more recent and popular projects are:
* JFBuild/JFDuke/JFSW: Jonathon Fowler's Build port to Windows/Linux/(Mac..coming soon!)
* Voxlap Cave Demo
* PNGOUT: PNG compressor
* Evaldraw: C-like compiler environment with real-time compile/display.

I must admit, I'm still puzzled by your reluctance to re-entering the more mainstream realms of game programming.

This picture was taken by James Storey (Duke3D pixel artist). Ken drew that map of the USA from memory. The photo was taken at Billy Zelsnack's cubicle.

I don't see what benefit it could provide to me - working for someone else, that is. I'm already doing what I enjoy.. I just don't get paid for it.

As a fellow programmer, I too love to code and solve problems. But I find it much easier to push myself and develop better system at work, when I'm not able to walk away from a problem. Do you find not *having* to solve a problem to produce the goods, something that makes things harder for you?

I've never been motivated by money. I do things to impress people and gain their respect. I'm always being challenged by myself and others. When a problem is interesting enough, nothing gets in my way from finding a solution.

I'm currently volunteering my time at Brown University, helping a class on embedded systems. They're building a new kind of input device that plugs into the USB port.

So someone else is teaching the class and you're there as a, teaching assistant? For want of a better term.

I'm not teaching the class. I'm spending more time doing research to motivate the class on the project.

After I graduated college (May 2000), my dad invited me to visit his lab.. he's a professor of electrical engineering at Brown. So I help out with projects there once a week. He always has students working on projects.. often the engineering students don't know as much about programming as they need to.

That sounds pretty cool :) I wouldn't mind doing that! Programming is an interesting field. What qualities does the best programmer need, knowledge of the language, a logical mind, an artistic mind. What do you think?

I like to think of programming in 3 parts:
* syntax
* math/algorithms
* creativity (knowing how/when to use math/algorithms)
I find that most people are able to learn syntax if
they stick to it. You can even study random math/algorithms
if you wanted to - but that's not enough. It's the creativity,
I think, that makes for the best programmer -
such as the ability to visualize a problem.

I have no idea. Probably mechanical stuff like building cars with solar panels (or at least thinking about it).

Indeed, but to steer the topic back towards Build, you proved that the Build engine could be made to support a polygon based renderer.

This is one of the very few pictures ever taken with both Todd Replogle and Ken in it (and this one's not modified!). The guy on the left is Ken's brother. Ken still regrets the fact that 3DR took the Duke3D team photo when he was out of town! (Photo taken September 1995)

As I said on the forum, I would rather start a new engine from scratch. Extending Build would be very difficult since I would have to modify the map format significantly - and in the process change all the functions in the engine that would go along with it. What I meant was: it is possible to write a full polygon based renderer using the sector idea.

When you look back at your original code, is there anything there that makes you think "What was I thinking, why did I do it that way"?

I have reasons for everything in the code. Some things were certainly designed in a bad way, such as statically allocated arrays.

I've always believed, if I can't look back at my code in a years time and not improve on it, then I need to.. retire maybe! :)

Perhaps so, but then it depends on how wide your scope as a programmer is. Such as which languages, platforms and technologies a person chooses to use.

I try not to spend much time learning new languages. Sure, I could learn Java and all the web-oriented languages, but they don't offer much different from what I can do in C, other than web applets I guess. I find it much more enjoyable to learn new math/algorithms.

I prefer C because it's at the lowest level possible, while still being portable. I like to see all the calculations being done. The code is more readable to me.

The main advantage, I suppose, is the namespace issues - being able to declare multiple instances of a library. It doesn't usually help for math/algorithm/engine work. Then again, I haven't used it enough to be sufficiently enlightened.

I wouldn't do it for Build. As far as I'm concerned, JonoF's port is the end of my work on Build. I would consider doing physics for a future engine, however.

Ken pressed F12 at the very instant he turned 18 years old. He selected the most impressive thing that he could show. That scene is from the old Build engine (See the link to BUILGRID.ZIP from Ken's Build page)

Have you heard about the work of the developers of the Havok physics middleware engine, using the GPU on a graphic card to perform the parallel processing for the physics.

No. I really don't keep up on video game news. It just makes me jealous / feel bad about myself for not having done these things.

It's not too late if I want a lousy job, where I would basically be implementing somebody else's idea. That doesn't excite me. I realize that my role at 3DRealms will never happen again.

I couldn't see them hiring me in my old role. If anything, they would probably have me hack up the Unreal/Meqon code in some way - or maybe help fix bugs in their current DNF codebase. They're not interested in an engine from a single person anymore.

Do you believe that in today's market, a single programmer can make a commerical level engine, as you did?

Sure, if somebody's naive enough to license it : P There's no way a single programmer will ever compete with Unreal - unless they borrow a lot of free code, in which case it wouldn't really be a single programmer.

My dad did all the business talk for me then. I think I talked more about bugs & features more than algorithms with Tim. I remember him being impressed with some of my features... like the rotating globe at the end.

Apart from voxels, what other features would you have liked to get in the Build engine for the release of Duke3D?

It was false perspective, but yeah. Most people would say it was ROTT, although they didn't add it until 3 days after seeing the hack working in Build.

It was probably from Scott & George nagging me that they needed the ability to look up/down to compete with Quake.

Was the fact Quake was being developed at the same time, something which worried you?

Of course it was. That's what inspired Todd to write his CON system - to compete with Quake C.

Ken took this snapshot at the instant he turned 28 years old. That is what his current office looks like. Notice the familiar image on the monitor.

Hmm... a certain room on E1L6 with slopes and shading looks like a certain Quake screenshot. We added auto look up/down when you're on slopes - that was inspired from Quake.

Not really because adding multi-texturing to my inner loops (especially with a bilinear filter on the shading) would have slowed down the rendering speed of Build a lot.

3D accelerator cards were just emerging back in those days, were you ever interested in using them for Build?

3DFX and ATI sent me demo cards in 1996-7 (I think). They all turned out to be decelerators. Was I ever interested? Of course. In 2003 :) See Jonof's site (http://jonof.edgenetwork.org)

I didn't work on that. All I remember was one tech support call, where I think we we talking about rendering the scene in horizontal / vertical strips - the same way the classic engine does it. This is certainly not the fastest way to render a Build scene. Polymost has much lower polygon count than that.

Good question. Slopes perhaps? I wasn't keen on them before I implemented them.
As a programmer, I see not only the benefit, but the labor that must go into it. Slopes were a lot of work!

Did they require as much re-working of the engine as you feared, when you actually implemented them?

I think not. I remember some things working automatically without having to do much. I think I was worried about collision code. Slopes didn't affect it too much - just an extra function call here and there.

Is there one stand out feature, that worked out to bring a big benefit without taxing the engine?

That would have to be fake look up/down. And I laugh when people say that one of Build's best features is flying and ducking... that required no effort on my part.

Did you ever need to re-write any routines from scratch as the engine grew, because they were causing problems?

The one that comes to mind is rotatesprite() - for drawing HUD tiles, menus, guns, etc.. Originally, it was split into 2 functions, one that was for status bar items and menus only, and another for the guns. When I combined the 2 functions, I chose "rotatesprite"... I always thought that was a weird name. I probably used my version that supported rotation because it was more complex (and therefore less work to modify).

Network code. I must have had at least 5 versions of it - simply because I was learning as I was writing it. First, I realized the power of a synchronous protocol. Then I threw in interpolation. Then there was peer-peer vs. master/slave mode. Finally, there was local prediction. The teams were always struggling to implement my latest ideas, and especially in getting the game to stay in sync.

I remember the horror of seeing the out of sync message from my youth playing Duke3D!

Did you ever consider implementing some type of 'Re-sync' operation for such cases?

Doing that would have been very difficult, mostly because each team implemented things in different ways. There was no standard black box formula that could simply "re-sync" things. If I was writing it from scratch today, I would put all game state variables in their own self-contained structure and do re-syncing by sending CRC32's periodically.

That's Ken working in his Rhode Island office, taken sometime between March and May of 1994. If you can actually see the monitor, you'll see that he was testing KenBuild.

The most common error would be the way we used random seeds. The theory behind the synchronous protocol is that all computers must execute all movements in exactly the same order, at the same rate, using all of the same inputs. The only thing sent over the network is keyboard changes and relative mouse movements. Because the movement code is locked to a certain framerate, it is essentially executing in a separate thread from the rendering code. Now imagine what happens when you use the rand() function in the CON system (which is part of the movement code), and rand() for displaying the weapon shaking. Instant out of sync. Here's another example: the movement code reading any variable from the rendering code. Out of sync. The worst part is: there's no easy way to detect where it happens. And when it does, my typical method of binary search on the code using printf's doesn't work. Sometimes you just can't reproduce a network game exactly.

I do a CRC of selected game state variables, such as player position and weapon ammo amounts. I send these over every 5 movement frames. If they don't match, "Out of sync" is displayed. The purpose of this was to help us find sync bugs as soon as they happened. It wasn't always that helpful.

Was the out of sync problem, something you wanted to solve, but didn't have the time?

Of course. Working on sync issues can be very frustrating though. I wasn't exactly begging for the opportunity to work on this problem. It's one of those things where you just hope it goes away after time.

Apart from the out of sync issues, are there any other parts of the Engine that you'd like to go back and improve upon?

I was never proud of the way I implemented the texture-mapping inner loop for slopes. It could have been a bit faster if I had rendered them as horizontal lines instead of vertical. I think something more urgent came along and I never had a chance to debug it.

3DRealms doesn't really have time constraints. The way it works is: if you take too long, and some other company comes out with a game with new features, then you must suffer the delaying of your own game for several more months while you add those features...

As you know, I use Build to create the comics on my website. The main reason is because it's so easy to import art and create environments. How do you feel about the Build editor?

I think Build was the first 3D game editor to have a WYSIWYG mode? I always thought that was the reason why it was so fast and easy to use.

A picture of Ken's 1990 high school computer team. Top row (L-R): Mahesh Jayaraman (12th grade), Greg Coppa (advisor). Bottom row (L-R): Andrew Shearer (11th grade), Alan Silverman (12th grade, Ken's older brother), Ken Silverman (9th grade). Some called them the "dream team" as they won first place in the biggest programming contest of the land (New England area).

Absolutely! I had written many game editors before and it was frustrating not knowing what the environment looked like as you modified it. This was just a natural next step. Maybe you noticed MoonEdit has a typing sound? No sane editor needs that... but it really is useful to know when someone else is typing! (That was my idea BTW :) It's the same kind of mentality.

Yes, I do like that additional feedback.
Are there any other things you put into Build or Duke3D as a result of beliefs or ideas you had, that other games or engines weren't doing?

A lot of things: 2D textured map mode, rotating wireframe map mode, slopes, voxels (not quite Duke, but you know), overlapping sectors, moveable sectors (swinging doors)

Yes, but I'm afraid this piece is fading away. I feel like my talents aren't as valuable as they used to be - especially when you can find free engines online (partly my fault I guess :). When before, I was an innovator for writing my own engine, I am now made to feel silly for not using someone else's.

You know I'm a big contributor to that project. I think it's great to have the source code out there and have the ability to play the old Build games in their full glory (again).

What advice would you give to teenage coders, based on your experience at that age and now?

Probably the best advice I can give would be to make time for yourself to work on your own projects. Show the projects to your friends and listen to their suggestions. You will learn the most this way, and it's sure to impress potential employers more than any report card could ever do. It shows you're really interested. As for developing skills, I would suggest studying math & physics in addition to the basics of programming - maybe even things like music or art. They're all important for this industry.