Come get some! - Interview mit Ken Silverman Englischer Originaltext
14.09.2005

KS: Ken Silverman  
CPPJH
:
Cpp Junky's Home (Robert Zimmermann)


CPPJH:  
Hi Ken! First of all, I would like to thank you for doing this interview! The way you are present to the community, always ready to answer questions from people all around the world interested in your work or general game programming makes you different from other pros who can be seen on tv during E3 and then disappear from planet earth until their next game is released =) 

KS:
 
Thanks, I guess. I can do it because I don't have a real job. I've been working for myself for the last 5 years. 

CPPJH:
 
As the legend says, you were born on the night of Halloween exactly on midnight =) How old are you now, and where do you live ? 

KS:
 
That's correct - Halloween 1975. I don't see much significance in things like this. As for my age, you do the math. As my website says, I still live in Rhode Island, USA. 

CPPJH:
 
Somewhere on the web, I read that you got your first PC in 1988 and got into programming just one month later. I guess this isn't the normal case. A teenager with a computer would start playing games or simply get frustrated (It was 1988 and computers weren't easy to use). So, where was interest coming from ? 

KS:
 
Your history is inaccurate. I started programming TI BASIC in 1983, along with my older brother. In the early days, it took us a lot of effort to convince our parents to buy us the games we wanted. So instead, we took the "easy" route (lol) and created our own games. In 1988, my family introduced me to C programming, although I didn't like it much at the time. QuickBasic was just so much easier to use. I didn't start using C seriously until 1991. I think the issue is not how I stayed interested, but how I managed to avoid frustration. I was good at math and enjoyed thinking about it all day - even when it seemed like I wasn't getting anywhere. 

CPPJH:
 
In 1992, the first version of "Wolfenstein 3D" was released. There were 3D games before Wolf 3D, but it was the significant start of the 3D era. How did this affect your interest in engine programming ? 

KS:
 
How could it not? At the time, I already had some experience experimenting with 3D graphics and assembler programming. When I saw Wolf 3D, it was like the perfect challenge for me. Like most people, I was impressed that a 386 could render texture-mapped graphics at real-time speeds. 

CPPJH:
 
Was "Ken's Labyrinth" your first step into programming 3D graphics ? Where did you learn all the math and technical stuff ? (We have to mention, there were no open ready-to-use libraries like OpenGL or DirectX in 1992). 

KS:
 
Ken's Labyrinth was my first 3D demo to feature texture-mapping. Before then, I had written 3D demos with wire-frame graphics or solid-filled polygons (such as rotating "KEN" sign in Kentris, 1991). I learned the math either from school or by asking my parents. When I couldn't figure things out on paper, and my parents were no help, I would spend all day hacking around in code until I succeeded. I am very good at trial & error work : ) If I was really stuck, I would try to break the problem into smaller parts, and write test programs for each part of the algorithm. 

CPPJH:
 
Ken's Labyrinth was published by a big label (Epic MegaGames). Was it your  first game to be published ? How did you get into contact ? 

KS:
 
Yes. Epic contacted me about a week after I released my original "Advanced  Systems" version of Ken's Labyrinth. They weren't so big back then. I  believe their big game at the time was Jill of the Jungle. 

CPPJH:
 
When Ken's Labyrinth was released, Wolfenstein was state-of-the-art. Did you  ever get any response from ID software? Something like: "OMG! We are afraid  because Ken's engine is better than ours" ? =) 

KS:
 
No. I didn't get in contact with Id software until I signed on with Apogee.  When I visited the Id offices in 1994, I remember John Carmack mentioning  something about the ability to stand high / stand low as being innovative...  although he was probably just being nice. Remember, they had already  released Doom at the time. 

CPPJH:
 
When did you start working on the Build-engine ? What were the main features  you wanted to get real in Build ? 

KS:
 
I started work on Build in March 1993, right about the time when I finished  the registered version of Ken's Labyrinth for Epic. 

CPPJH:
 
We all know, the Build engine was used for Duke Nukem 3D, one of the most  popular games ever. How did you get into contact with 3D Realms ? Were you  actively involved in development at 3D Realms, or did you just leave them  the code and the docs ? 

KS:
 
I contacted them in 1992, when they were known as Apogee Software. At the  time, I was sending beta versions of Ken's Labyrinth to several companies  for evaluation. Not being satisfied with any of the offers, I eventually  released the game on my own. I think what caught Apogee's attention was the  fact that Epic took on my game. Apogee and Epic were the 2 biggest shareware  companies at the time and so they followed each other closely. A few months  after the release of Ken's Labyrinth, I must have sent the guys at Apogee a  beta demo of Build, because soon after, they sent me an offer I couldn't  refuse. 

I was most actively involved when I was on site. When I wasn't adding  features to Build, I was usually helping the programmers debug their code or  showing the map designers and artists how to best use my tools. When in  Rhode Island, it was like you say - I was leaving them code and docs, along  with plenty of phone support. 

CPPJH:
 
It must have been cool, to be (I guess) the youngest member of the team, but  having developed the core technology to work with =) Build has been used for  many games. Maybe it's the most used engine of the nineties. Were you  involved in development on each game like you did at 3D Realms during  development of DN 3D ? 

KS:
 
I was involved with all teams in the same way. I spent the most time with  the Duke team, simply because they were in-house throughout the project,  meaning I saw them every time I visited Garland, Texas. The Shadow Warrior  team didn't re-locate to the Garland office until the last year of the  project. And the Blood team was in Seattle, WA, except for a few weeks in  the middle of the project. I had to make special trips to see them. 

CPPJH:
 
Ok, let's get a bit deeper into Build technology. One of the best advantages  I think, was the ability to move walls. It sounds simple, but this enables  tons of features like doors, elevators, destructible walls, etc.. I can  remember having played a cool level where somebody built a subway in a big  city - you could just step into und drive to the next station. That was just  awesome, because I never saw something like that before at the time. In  episode 3 of the main game, we could see floating water. I guess, this is  just another effect of (really clever) moved walls. What kind of data  organization was used in Build ? I guess, it wasn't any kind of BSP tree,  because the levels were simply too dynamic. What kind of culling /  visibility check algorithm was used ? 

KS:
 
Build does not use a BSP. I talk about the technology in this thread at  JonoF's forums: (http://jonof.edgenetwork.org/forum/viewtopic.php?t=137&highlight=visibility
(This part taken from the thread mentioned above is very interesting:)
 
Build works like a portal engine in the way that it follows invisible walls into  neighboring sectors. My method for hidden surface removal is probably very  different than most portal engines though. The classic Build engine uses a simple  vertical span buffer. Every vertical column of the screen has 2 heights: a top and a  bottom point. Any future pixels drawn to that column (or x-coordinate) must fall  inside this range to be drawn. At the beginning of each frame, I set these two  heights to 0 and yres (the height of the screen in pixels). Build draws walls in  front-to-back order, 1 wall at a time. I have a nice way of guaranteeing proper order,  but I won't get into that now. Anyway, as I draw walls, I clip to the current height  values for each column, and I update them after drawing the wall piece. The height  values always creep towards the middle of the screen (or horizon). When they meet  or cross, that column is done - meaning nothing else can be drawn to that column.  A portal (or wall connecting to a neighboring sector) is visible if any part of the invisible  part of the wall happens to fall inside the visible range of any column.) 

CPPJH:
 
Build wasn't actually a "real" 3D engine at all. As far as I can remember, it wasn't able  to build rooms over rooms. (BTW: On later versions it seemed to work - I can remember  having seen this feature in the game "Blood"). As well, if you looked up and down you  could notice some kind of "perspective shifting". I guess, you were able to develop a  full "real" 3D engine back then, so what's the reason Build isn't like this ? 

KS:
 
I thought a lot about looking up/down with correct perspective. I tried some  experiments back in the day, but nothing came close to quality and speed of  the renderer you see today. That's why it never happened. 

CPPJH:
 
Let's talk about your newest project, "Voxlap". It's a 3D voxel engine. (A  voxel-engine displays geometry by using three-dimensional pixels - you could  call them cubes as well - instead of using polygons). We already saw voxels  in Build. I can remember, the goodies in Blood were displayed this way. Why  exactly did you focus on writing a pure voxel engine ? When did you first think about it ? 

KS:
 
Around the time I released Ken's Labyrinth, I stumbled into 2 engine  technologies that really excited me: 

* Id Software's press release about Doom on January 1, 1993 (which led to Build) 
* NovaLogic's Comanche Maximum Overkill (which eventually led to Voxlap) 

Obviously, I had more success with Build early on. I played around with  voxels a lot too though - including during the Build project. I didn't start  thinking seriously about a 6 degree of freedom voxel engine until 1999. I  thought it could be the engine that would end all engines. After all, in  theory, you could make anything with it by just increasing the voxel  resolution. Unfortunately, theory doesn't always work well in practice. My  fault, I suppose, was in thinking too highly of my optimization abilities.  At the time, 3D hardware accelerators were just starting to catch on. By  2002, I realized the advantages of a voxel engine just weren't worth it  anymore. I had already lost interest by the time Tom started his work on the  Voxlap Cave Demo. 

CPPJH:
 
I guess, it requires very high optimization work when developing a voxel engine  because voxels aren't actually accelerated by any graphics card. What's the  "magic" behind Voxlap ? What were the major problems ? 

KS:
 
Where to begin? First, there's the world memory format, where I store  "slabs" of voxels along columns using a type of run-length encoding, along  with a custom memory allocator to allow for fast dynamic terrain. Then  there's my recursive raycasting loop, which is a mixture of many complex  techniques. Then there's my fancy projection technique which I do in a  separate pass ... which basically extends the engine from a standard  (x,y,z,ang) view to the full 6 degrees of freedom. The problems? Pretty much all of them are related to not having enough  speed, memory, or both. Doing things brute force on a 3-dimensional array is  never going to be practical. So to get things running at decent speed, I had  to devise a trick for basically everything - which usually meant working  directly with the run-length encoded data. I guess I just got tired of  adding to  the mess after a while. I designed the engine to have total freedom, and what  I ended up with was a fast demo with very little flexibility. 

CPPJH:
 
The official source code was released just a few days ago, but there was some  kind of pre-version in 2004. Are there already some projects in progress that will  use Voxlap ? 

KS:
 
I don't know of any real projects using Voxlap. I've only heard from a few people  saying things like "hi, I'm thinking of using Voxlap for so-and-so" and then never  hearing from them again. I know many people were excited after seeing the  Voxlap Cave Demo. Sadly, I don't see much potential beyond that, since just about  every feature that people would want requires serious engine work. I released the  Voxlap source code because I didn't want to see this effort rot on my hard drive forever. 

CPPJH:
 
Have you completely stopped development on Voxlap ? What are your future plans ? Is there a new project you're on ? 

KS:
 
I stopped doing serious work on Voxlap in 2002. That's when I realized it would never compete with polygon engines. In my future, I see death and taxes. Seriously though, I don't work on big projects anymore. I've been playing around with small test programs - mostly useless things to satisfy my own curiosity. 

CPPJH:
 
What do you think about today's game industry? Which upcoming games are you waiting for and which games in the time from 2000 till today do you like most (technically and gameplay). 

KS:
 
I've been out of the industry for nearly 10 years. At 3D Realms, I focused on programming, not business. For these reasons, I find my thoughts on the industry to be obsolete and irrelevant. I'm not a gamer. I think the only games I've installed and tried since 2000 are some ancient Unreal demo, Red Faction, and Doom3. I probably enjoyed Red Faction the most out of that bunch. The only future games I find interesting at this point are DNF and Prey. 

CPPJH:
 
Ok Ken, that's it. Thank you, for this very interesting interview! I hope, we will hear from you again soon.