Back to the past. Part 3. Interview with Ken Silverman, creator of Build. From technical details and Duke Nukem 3D to Ion Fury.

[UnknDoomer]

New day. New interview. New 30 questions.

 

---

A quick summary of the main players:

 

Ken Silverman is the creator of Build, as well as a number of other solutions such as VOXLAP, which later became the basis for games ranging from Duke Nukem 3D (1996) and Blood (1997) to Ion Fury (2019), as well as Electric Highways (2015) and Voxelstein 3D (2008) individually. Home page - Ken Silverman's Official Home Page.

 

---

 

 

Q. Has anything inspired you to create the Build engine? And, regarding your participation in specific games development, perhaps you can mention a few interesting facts?

 

A. Sure - Doom. Id started releasing information and screenshots about their next game right around the time I finished Ken's Labyrinth, in early 1993. After spending almost a year copying Wolfenstein, this obviously caught my attention. Your second question is bit too general. Consider reading the rest of the interview? ;-)

 

---

Q. @taufan99 asking: "Ever since I played Ken's Labyrinth and your other programs, I've fallen in love with the KSM format. However, I'd like to know if you may release a converter to the General MIDI format, because even though I acknowledge that AdLib is a good sound card, I'm more of a General MIDI fan myself.".

 

A. If you're willing to do a little editing, you can use my KS2.EXE program to convert those music formats. Look for it on my utility page. You'll have to manually select the MIDI instruments, and completely redo the percussion track by using the lasso tool. With some persistence, you can get good results. And yes, KS2 hasn't been update in a while, and it flickers in modern versions of Windows. I could fix that, given sufficient motivation and time.

 

---

 

Q. @vyruss asking: "During the experimentation phase of the build engine, what led to the final design decision to use portals amongst other technologies of the time? I am aware of it's benefits compared to other rendering technologies at the time, as well as the constraints of mainstream user hardware - was there a significant analysis done on different approaches to measure their strengths and weaknesses, or did the idea start in one iteration as an engine unrelated to the Build engine and then grew organically from there? I ask this because of my (hazy) memory showing different levels of capability between something like Ken's Labyrinth going to Duke Nukem 3D and other big names of the day.".

 

A. When I came up with an idea, I would write a prototype in QuickBasic, as it was really easy to write code and test things in that environment. My earliest prototype for what was to become Build was called PICROT4.BAS, which simply raycasted into wall soup. Obviously that was going to be slow for a large map. My next idea was to use a grid, where each cell holds a list of every wall (line in 2D) that touches it. This solved 2 things: roughly sorting the walls in a front to back order, and eliminating any walls that fell outside the viewing frustum. This could have been made to work with some extra code to refine the sort, but at the time I didn't know how to do that. It was basically a dumb painter's algorithm, and it was full of visual glitches.

 

Then in December 1993, Apogee had me telephone John Carmack. As would be expected for such a cold call, he glossed over many topics without really explaining them in much detail. He didn't have to take the call after all. For example, I remember asking him about one of the trickiest things in the Build Engine at the time - how to rasterize or fill in the ceilings and floors. He described his method as simply "floodfilling" them, which didn't make much sense to me. Floodfilling to me was always a slow algorithm, like the paint tool in Microsoft Paint. Or in BASIC, you could see it actually doing its recursive search as you watched it across many frames. Obviously, that's not how it really worked. So clearly he had a different definition of what floodfilling meant, I guess.

 

The other thing I remember is him giving me the idea and the name for a "sector", which is a structure to hold ceiling and floor information for a list of common walls. This didn't solve my wall sorting issues, but it did make me realize how ridiculous my old grid-based engine was designed. I was storing ceiling and floor information along with each wall! Not only did this waste a lot of memory, but it opened up the engine to lots of visual glitches - such as when a wall's structure didn't match its neighbor in the same sector.

 

To fix the wall sorting, I needed to learn some new math: 2D dot and cross products. I learned about these during my first semester math class at Brown. I was surprised they didn't teach this stuff in high school. Now with my new sorting algorithm, I had a way to sort walls without glitches. I couldn't prove it, but I couldn't find any counterexamples in my test program .. unless the walls intersected, that is.. but that was not considered a valid case anyway.

 

As an interesting aside, many years later, I thought I could extend this idea, of perfect wall (now polygon) sorting to full 3D. I called it KENVEX - my name + convex. It turns out I was wrong - or at least it was much more difficult than I had imagined. The engine had a lot of other problems as well. I had no idea how to make a proper editor.

 

---

 

 

Q. @DNSKILL5 asking: "Build during development of first Blood times. There is some controversial information about this period available around the web. Long story short - things seem to have gone rough with this one. Could you tell us a little about the specifics of the work at that project?".

 

A. You're talking about GEORGE.TXT, a rant by Peter Freese that was written in June 1995. The Blood programmers were overriding my internal (intentionally undocumented) Build Engine functions with their own versions. I suppose they couldn't wait for new features. The problem with this is: whenever I changed something in the engine, it would break their code, and then they'd have to reverse engineer their hacks all over again. It's almost like hex-editing an executable. The practice of function overriding can be very counterproductive. Obviously, I needed to change stuff in the engine in order to improve it and fix bugs.

 

I'm sure their cache system was better at the time. The problem is: I was being bombarded with lots of other high priority tasks from the other teams. You don't need a perfect, or even a good cache system to test a game during its development. If you don't have enough memory, then your hard drive runs a bit more. It's annoying, but so what. I had a rudimetary cache system at the time which simply removed the oldest thing, which could be implemented with a simple FIFO. It wasn't efficient at picking the best things to remove. Later on in 1995, I did get around to writing a better cache system.

 

Oh, and I totally agree with Peter's comments about sprite centering - that was a mistake.

 

As for my conversational skills on the phone - yeah. I'm not going to tell white lies and promise to do something when I've never even heard of the concept before. I should have said, "Sure, I'll look into that". But I was a shy 19 year old with not much conversational experience. I wasn't good at thinking of what to say in these instances. To this day, I still prefer doing interviews in text format ;-) BTW, when Peter and I met in person a few months later, we got along fine.

 

---

 

 

Q. "The Legend of the Seven 3D" (1994) counts as the first commercial, Build based project. Also, in contrast to further one, it's based on an early version of the build. Still, its story itself rather remains in fog. Can you, perhaps, shed some light on this unusual project?

 

 

A. All I know is the very little that Apogee told me, which is the game was released illegally. That is until 2020, when I got a random email from some guy named Mr. Lin. Apparently, he and a group of 2 other guys from Taiwan visited Scott Miller just before Christmas of 1993. He said things ended a few months later due to language difficulties. As for why they continued working without a proper contract in place, I can't tell you.

 

 

---

 

 

Q. On your site I've noticed a title called "Fate" (1996), from Capstone, which is interesting, because I've never heard that they have made a bet on Build much specifically. "Corridor 8: Galactic Wars", which is supposed to be a sequel to "Corridor 7: Alien Invasion' ' (1994) uses the Doom engine at the end point. Can you tell me a bit about this title?

 

A. All I know is this was the name of Capstone's 3rd game, after Witchaven and Tekwar, and JonoF's games site has a demo of it.

 

---

 

Q. Zdoom-derived ports support the .kvx voxel format (and only that), making this ancient format from the Blood era the single, uncontested voxel standard for the doom community, which is known to be the most alive (there is, of course, DelphiDoom, which can eat .vox, but it’s exotic with a bunch of its own limitations. There are a lot of voxel formats and editors. But in order to put voxels into Doom, you need to run them through a converter editor into .kvx. There you can optionally tint and center them. Such an editor is the yours editor of SLAB6, a software from 2011, which has long been lying around. SLAB6 has a limit on voxel model sizes of 256x256x255 pixels.

 

Mastermind, for example, could fit in. But if you upscale it, it won’t anymore, or, at least, it seems so. There are no more modern alternatives on the horizon and are not expected and in general this creates a bad syndrome when something modern is tied to ancient abandoned infrastructure.

 

Generally speaking. It is possible to bypass the limitation through your utility, POLY2VOX. But this requires a schizophrenic voxel-model-voxel conversion scheme with dirty hacks in the 3D editor for centering. Which is also not good.

 

Long introduction ends and this raises the question. Do you have any plans to release a more modern version of SLAB6?

 

A. You should look at PND3D as a successor to both SLAB6 and VOXLAP. The editor is less featured since nobody really used it, but it works well as a fast viewer and format converter. Unfortunately, PND3D doesn't currently save to KVX format. I could add that, but there would be some problems, such as color quantization and size limitations.

 

KVX was designed for the Build Engine, which used 8-bit paletted color, didn't need to support huge models, and always rendered upright (where vertical RLE makes sense). KVX has some strange things in its design, such as visibility flags that are only defined per slab, and offsets that are relative to absolute file position. Also, KVX is limited to 256 voxels high, and while you could extend the x and y beyond 256, you could run into trouble when you do so. If the sprite isn't sufficiently compressible, then various things can overflow, and so it's not a good idea. If you want large models, you should consider using KV6 instead. The only downside to KV6 is it won't compress an 8-bit paletted sprite nearly as well as KVX.

 

Also, with POLY2VOX, have you tried the /s# option? This is intended to fix both consistent scale - and centering - in animations.

 

---

 

 

Q. ck3D asking: "To this day Build is an oddity in the landscape of game engines that, most often, are designed with rather imminent concerns of practical application in mind. Especially modern games tend to rely on photorealism a lot more than in the general 90's for user immersion and relatability, sometimes at the expense of more creative alternative approaches to complement. Games such as Duke Nukem 3D didn't miss any of those marks and somehow managed to push credible environments all the while technically introducing reality-bending tricks: sector-over-sector (allowing for the potentially endless stacking impossible spaces on top of shared coords), and walls possibly rewriting their position at runtime are features that make it that, in addition to being a tool that was destined to serve production, Build also can be approached as its own mini-medium and generally is as such by most longtimers in the mapping communities.

 

How much of this creative freedom was deliberate and maybe important to you when designing the engine, were you hoping (or did you even expect) those uncommon and relatively experimental features would be embraced by its users, were you aware of the punch they would eventually pack to the point where they still are influencing some niche schools of level design, or were you just having mindless fun while it lasted and still unaware of how more rigid gaming was just about to become as soon as the next couple of trends came up?

 

Subquestion that are also related to intent. While it is common popular canon to retain "realism" as a forte of the engine, I would tend to disagree and argue it really is suggestion-based, and the apparent relatability of most Build environments really is just a surface level hook towards more abstract level designs and creative layout ideas. It relies on disguising a lot in order to put players in situations they normally wouldn't be drawn to because said situations usually are quite technical (and so, paradoxically, a lot of fun for mappers to compose). What do you think?".

 

A. Clearly, I think on a lower level than you. I concern myself with algorithms and assembly language optimizations. I didn't worry about how the general public would see things. Many things I do are the result of evolution. I try something. If it's good, I keep it. If not, goodbye. This works well for optimizations. It also works for design changes. The problem is there are always more ideas than time. In order to decide what to work on, I would use this simple formula: coolness divided by the difficulty of implementation. Of course, I would usually end up doing what I felt like working on at the time - which was unnecessary optimization ;-).

 

The key to the Build Engine games having this supposed "photorealism" was by having large parts of the editor working in 3D mode. AFAIK, Build was the first to do it. Being able to preview and modify the game environment directly, without having to waste time building a BSP or whatever, saved a ton of time (for the same reason, I would use QuickBasic for prototyping instead of C and today, that would be EVALDRAW instead of C).

 

I came up with the idea of a 3D editor while working on the grid-based engine in mid to late 1993. At that time, the editor was called EDITBORD.BAS - written in QuickBasic. The 3D preview started out as a quick hack. I added a command line parameter to the 3D viewer I had in C, which would override the starting position. My QuickBasic editor could then spawn this executable from wherever the mouse cursor was hovering.

 

Of course, spawning a program every time you want a preview was not the fastest way to run it. I knew I would have to port the editor from QuickBasic into C. Once I had a 2D mode working in C program, I realized it would be cool to be able to do some editing directly in the 3D mode. The problem was I needed a way to determine what wall/ceiling/floor/sprite the mouse cursor was hovering over. I didn't yet have a hitscan function at the time. (At that time, nobody was making games yet. They were just playing around in the early map and art editors I had.) I came up with a way to do hit detection during the rendering process - by comparing each horizontal or vertical span with the mouse cursor location as it rendered. It was ugly, but it was easy enough to implement. Once that was ready, I started moving as much stuff as I could to the 3D editor. Everything related to texture mapping worked best in 3D mode. Raising / lowering ceilings / floors worked great in the 3D editor.

 

 

--

 

Q. How was your experience working with 3DR on Duke Nukem 3D regarding the feedback you got directly from level designers? Did you approach your task of creating the game engine purely from a coding / mathematical perspective according to what the developers needed, or did you actively look at it in a way that a level designer / player would? Did the level designers catch on quickly with how to use the editor or did you struggle to find a common ground / show them your perspective?

 

 

A. The level designers from Duke that I knew best were Allen Blum and Richard Gray. A few map designers were added to complete the Atomic edition, but by that time I was spending most of my time with Frank Maddin - helping to finish Shadow Warrior. Sure, it was cool watching the map designers do their work. I don't remember specifically who asked for what, but some of the features in Build that came from the map designers were things like: Alt+S to turn a loop red, pressing 'V' once for current textures or twice for all of them (a feature which I hated BTW), tagging system, multiple kinds of copy & paste, and various rendering glitches. It didn't take long for someone to learn the Build Editor. Back then, people didn't need fancy menus or buttons. You could write a text file and more often than not, people would actually read it. If you couldn't remember everything in the text file, you would print it out. Learning the tricks of Build took longer, such as how to combine or separate sectors without redrawing them from scratch.

 

 

---

 

Q. The flagship Build engine games had relatively protracted development cycles, with Shadow Warrior dating back to 1993-1994, and the Build engine actively evolved throughout all those years. Did you play every build of Shadow Warrior and Duke Nukem 3D, or was it up to the playtesting team?

 

A. Actually, the first team to use Build was the Blood team, which started work in September 1993. Back then, they were known as the "Horror" team. Sure, I would play many versions of the games. Sometimes when someone needed to show me a bug, they would send me a copy by modem and I would look at it. If I was on-site, we could test over IPX or null modem. Often, we would play for fun at night. I wish I had kept copies of every version I had access to. Of course, that would have required a rather large box of floppies!

 

---

 

 

Q. Powerslave never uses sloped surfaces in any of the official maps, and it had been thought for a long time that the Build engine version it runs on does not have this feature implemented yet. However, recently it was discovered that Powerslave actually does have full support for slopes, and a custom map pack was created to take full advantage of this feature. Since sloped surfaces would seem like a logical element in an Ancient Egypt-themed game (e.g. to create pyramids), it was speculated by the community that 3D Realms might have withheld information about certain tech specs when it sub-licensed the Build engine, to retain the competitive edge with its own products. Can you comment on this in any way?

 

A. 3D Realms hid a lot about their dealings with minor game teams. I never saw whatever contracts they made, unless I specifically asked about them. Engine sub-licensing was not mentioned in my original contract, and they would use this fact to their advantage. Regarding features, I know that 3D Realms held back slopes from Capstone. As far as what happened with Lobotomy, I can't say. I remember Lobotomy being upset when they found out the engine supported slopes. I found that very confusing. So maybe you're right - and slopes were held back from them as well.

 

---

 

Q. If you were to recreate something equivalent to the Build Engine using the knowledge you have now, would you make any design changes?

 

A. Sure. I would with cleaning up the code. For example, more structures, fewer global variables, giving functions a return type, and not using 'long' types for nearly everything. As for optimization, I don't think I left much room for improvement. Most of my newly acquired knowledge is for modern machines, such as AVX2, multi-thread, and 64-bit assembly. These things don't exist on a 486-DX or Pentium. ;-) See the list of regrets I have in my answer to twentieth question.

 

---

 

Q. At the turn of 1997-1998, computer game developers would inevitably have to switch to full-fledged 3D graphics. Were you, perhaps, planning a completely new and truly 3D engine instead of Build at that time, i.e. before 00's? Later on, it seems, Voxlap took that niche. A14. Sure. POLYTEX (1995) was my first attempt at competing with Quake. POLYTEX used a BSP to sort polygons in back to front order. The rendering was simple but it had a lot of overdraw. Then in 1998, I started KENVEX, which was to be a portal engine. I wanted it to work like Build, with its perfect hidden surface removal, but it turns out trying to achieve this holy grail of polygon rendering was never going to work. Unfortunately, both projects failed to get past the test phase. I had no idea how to make an easy-to-use editor that worked in a full 3D environment.

 

A. Sure. POLYTEX (1995) was my first attempt at competing with Quake. POLYTEX used a BSP to sort polygons in back to front order. The rendering was simple but it had a lot of overdraw. Then in 1998, I started KENVEX, which was to be a portal engine. I wanted it to work like Build, with its perfect hidden surface removal, but it turns out trying to achieve this holy grail of polygon rendering was never going to work. Unfortunately, both projects failed to get past the test phase. I had no idea how to make an easy-to-use editor that worked in a full 3D environment. Q15. In continuation of the previous one. Looks like you are a fan of voxels, were you tempted to work more with traditional full 3D in overall, except for the POLYMOST renderer for Build? A15. Well, there's BUILD2, but that's hardly traditional and it came many years too late. No, my ambitions at trying to compete with Quake died after my attempt with KENVEX. By then it was too late - there was too much competition.

 

---

 

Q. In continuation of the previous one. Looks like you are a fan of voxels, were you tempted to work more with traditional full 3D in overall, except for the POLYMOST renderer for Build?

 

A. Well, there's BUILD2, but that's hardly traditional and it came many years too late. No, my ambitions at trying to compete with Quake died after my attempt with KENVEX. By then it was too late - there was too much competition.

---

 

 

Q. drugon asking: "In the second half of the 90's, 3D graphics were actively developing and at some point it seemed that shooters using sprite monsters would sink into oblivion, giving way to shooters with 3D models. Sprite monsters themselves were obviously a technical compromise at the time, allowing the hardware of that time to somehow adequately pull out the game without sacrificing the detail of the environment, like early simulators, where simple 3D models without sprites were used. But as often happens with popular games, constrained by technical limitations, these limitations then become a stylistic guideline for future developers. Sprite objects in first-person shooters are a clear example of this and are often used in modern retro shooters (Mullet Madjack, Warhammer 40,000: Boltgun, Supplice, so on). Did Ken imagine at the turn of the 90's and 00's that such a technique would generate so many followers and would be relevant to this day?".

 

A. Well, I'm not a fan of cardboard cutout sprites. They take a long time for an artist to draw, and if you render them from 3D models, that's a lot of extra work and unnecessary quantization. When I heard about Quake using 3D polygon models, I tried to come up with my own solution. I had never used a polygon modeling program before, and it seemed like writing my own wouldn't be easy. So I resurrected an old idea that I had - voxel sprites. I was glad to see these make it into the games, even in their limited forms. It would have been nicer to see them being used for enemies.. but I guess it wasn't fast enough for that.

 

---

 

 

Q. drugon asking: "Well, one more specific question, if I may. Did Ken think that the Duke engine would be used to some extent decades later? And not only in the many really worthy fan free works (WG Realms, Duke Nukem Forever 2013, so on), but also in the commercial release?".

 

A. 30 years ago, I would have been more worried about finishing games than thinking about legacy. We knew if we waited too long, something would come along (perhaps Quake) that would make our games look obsolete.

 

 

---

 

Q. What is your opinion of ray tracing as an option? It gets a lot of attention in recent years, which also took a place in classic titles, Doom including. It's just another temporary "noise of the modern" or it's something like the "real deal" thing?

 

A. Ray tracing works best when you have a highly parallel processor, such as on a modern GPU. Sadly, I never got much into GPU programming. Theoretically, there should be no difference in the output between the two. It comes down to a choice between using a pixel or a primitive as your outermost 'for' loop. In practice, some things are easier in one method versus the other. For example, reflections are easier with ray tracing. Rasterization is usually faster due to the primitive count being lower than the number of pixels on screen. But that can change when you have more detail, or different hardware. Beyond that, I don't have much else to say about the topic, other than to say that I've not tried general ray tracing.

 

---

Q. If in '24 it would be required to make another engine from scratch, with software rendering, for a new 3D shooter, what would be the main differences in comparison to Build?

 

A. A better question is: who would be crazy enough to "require" this insanity? To answer your question, my first task would be to choose between voxel, polygon, or a hybrid engine. A polygon engine could work well if there was an elegant bug-free way to do CSG operations on the fly. A voxel engine could work well if there was a way to animate sprites fluidly without having to make separate frames of animation. Obviously, I would design any new project for the PC using 64-bit mode, AVX2, and multi-threading in mind from the start.

 

---

 

Q. Do you have any regrets working on Build or stuff youd wish youd have differently or no? This includes technical related aspects of Build.

 

A. Sure. Here's a list:

 

* Slope texture-mapping. I shouldn't have resorted to using FPU instructions to get an extra integer register. This killed frame rate on the 486-SX when a slope was on screen.

 

* Texture-mapped slopes. It could have been a little faster if I had the time to make it do texture-mapping in the horizontal direction.

 

* Real-centered centering: This flag in the sprite structure should have never existed. Instead, it should have been provided as a macro to the game programmer.

 

* Height-mapped floors (aka "groudraw"'s). I never got around to fixing the divide by zero bugs. Later on, slopes made these obsolete.

 

* Network code. I could saved everyone a lot of time if I had just gotten it right the first time. This was done in game land, not the engine, so I had to spend a lot of time coaching each game programmer how to make every little change I came up with.

 

* Red-Blue mode. This should have been Red-Cyan mode. The green channel was wasted! Yes, very minor.

 

* Archives. While I saved a lot of stuff from back then, I wish I had kept even more. In particular, more copies of each commercial game. Also, it would have been nice if the tape backup of my hard drive from 1995 didn't get destroyed upon rewinding.

 

---

 

Q. What do you think of the potential of voxel engines like VOXLAP today? Voxelstein 3D was more of a tech demo, but it is still quite an interesting experience. Do you think games like it have a future?

 

A. When you say "like VOXLAP", I assume you mean the goal of small voxels and not the large ones you see in Minecraft/Roblox. Voxel objects work well on a 3D display, and they're easy to generate from code (such as in EVALDRAW). They don't make much sense if you're looking for realistic scenery. Voxels scale poorly when you increase the resolution. It doesn't matter how many bits you throw at it - you still see the blocks. Sure, you could hide this using interpolation, but that can be expensive unless you use a GPU, I suppose.

 

---

 

 

Q. @Cheello is currently working on his his massive Voxel Duke Nukem 3D project, which aims to recreate every sprite in the game. Have you seen Cheello's other work: Voxel Doom, Voxel Blood?

 

A. Yes. It's really cool to see 2D sprites converted to voxels and manually edited to that level of accuracy. It really looks authentic to the original games.

 

---

 

Q. Is there any feature that Build engine (prior to open sourcing) didn't have that you wish you had implemented?

 

A. Sure. You should check out BUILD2. Here's a few of the biggest features I would have liked to see in Build:

 

* True look up/down.

* Native room-over-room.

* Fancy lighting.

* Drop-in networking.

---

 

 

Q. If not a secret. Why did you decide to leave the major game industry? Commercial one kind i.e. Is there any chance of you returning to it, maybe even a Duke related thing or a Build based title, as unlikely as it is, if someone asks?

 

A. In 1997, I could see my role as a 1-person engine team quickly being squeezed out. There was a lot of new competition. Even then, I knew that a new engine would take many years to develop.. probably not 14 years though. ;-P I didn't want to move to Texas full time, and I wasn't looking at other companies. In 2015, Gearbox asked if I could contribute in some way to a Duke 3D remake, which later became the DN3D 20th Anniversary edition. I didn't know how I could contribute in a way that would have been fair to my time. Recording sound effects may take days. Making maps or songs may takes weeks. But writing a new engine can take years. Later on, I realized what they really wanted, which was a port to a few consoles, along with a few tweaks. I've never done programming for a console, so I guess it worked out for the best. As far as a return to the game industry, I don't see that happening. Besides, making 3D displays is more fun ;-).

---

 

Q. Did you ever envision Build 2 as anything beyond a summer camp learning project? What kind of game do you think it could work better with than, say, EDuke32? What prompted you to release Build 2 in 2018, almost 10 years after you stopped working on it?

 

A. Well, since I put a lot of effort into it, it would have been nice to see a proper game made with it. I suppose nobody wants to use an incomplete engine that's full of unmanageable assembly code. I released it because why not. It was something cool that had no value to me anymore. I should have released it years earlier.

 

---

 

Q. What's the story with the mysterious Ken's Labyrinth II? It appears that the project has been in the works since around 2007, but it has almost no publicity. Are / were you involved in any way apart from licensing the characters? Isn't it a bit disappointing that the game is using GZDoom and not Build or another engine of yours?

 

A. I never licensed anything. All I did was say something like, "Sure, that's fine." in an email response. Ken's Labyrinth was basically a bunch of random nonsense packaged in the form of an engine demo. I find it flattering that anyone would want to make a game based on it. A while ago, the guys asked me to record a few sound effects for their game, which I did. I have no idea whether they'll actually use it. Besides that, I have nothing to do with the project.

 

---

 

Q. Ken, you mention your love for cartography and maps, and there are images of the US map among the wall textures in Ken's Labyrinth. Has this hobby of yours been useful for designing maps for Ken's Labyrinth, or for any other aspects of game / engine design?

 

A. Not really. As a child, I enjoyed drawing and transcribing (but never tracing) maps. I can still draw a pretty good map of the 50 states from memory. I don't think this has much to do with engine design, but I can say they both involve a lot of visualization, which I've always been good at (BTW, Andy Cotter designed most of the maps for Ken's Labyrinth).

---

Q. Can you tell us what you are doing now, what projects you are interested in. Do you currently make any software for creating games?

 

A. I've been with Voxon Photonics for over 10 years now. We make 3D displays. My job is mostly the low-level software, but I also do some circuit board design. I wrote the SDK which includes a bunch of simple example games. Sadly, I haven't updated my website in a while because I've been quite busy with my work at Voxon.

 

---

 

 

Q. Have you played Ion Fury and if so what do you think of the game? Do you think it is a worthy spiritual successor to Duke Nukem 3D? Do you believe more games like Ion Fury should be coming out?

 

A. Sure. I thought the game was great. I loved seeing all the new and very detailed maps. The voxel objects were well done. It's nice seeing my work with POLYMOST being put to use. Also, shotgun trains are fun ;-).

 

---

 

Q. Any final words you would like to say to our readers?

A. Sure. Game over.

 

---

 

 

Edited September 1 by UnknDoomer

[taufan99]

Nice interview! I always enjoy hearing more from people about software engineering and game development back in the 1990's. Clearly it's not all fun and games (heh), but otherwise it really gives an insight of what it was really like back then. Still, it sucks to hear about the "secret" (?) fiasco between the Blood development team and Silverman.

 

Also, this answer doesn't have the question attached on the OP.

52 minutes ago, UnknDoomer said:

A. In 1997, I could see my role as a 1-person engine team [...]

And I like how he finished the interview with a "Sure. Game over." It just feels nice to me.

[UnknDoomer]

Quote

Also, this answer doesn't have the question attached on the OP.

 

@taufan99, fixed.

[vyruss]

This is fantastic on all of the questions being answered with the detail given.  Thanks for conducting this one @UnknDoomer

[GibFrag]

Even with your rewording of my question, he knew I was referring to GEORGE.TXT. Really glad he went into detail with that one. His responses in general were great here! Good work!