[Интервью] Назад в прошлое. Часть 3. Интервью с Кеном Сильверманом, создателем Build. От технических деталей и Duke Nukem 3D до Ion Fury.

Назад в прошлое. Часть 3. Интервью с Кеном Сильверманом, создателем Build. От технических деталей и Duke Nukem 3D до Ion Fury.

​

Новый день. Новое интервью. Новые 30 вопросов.

---

Краткая справка об основных действующих лицах:

Фото взято с домашней странички интервьюируемого.​

Кен Сильверман (Ken Silverman) – создатель игрового движка Build, а также ряда других технических решений вроде VOXLAP, на основе которых были созданы игры в диапазоне от Duke Nukem 3D (1996, DOS) и Blood (1997, DOS) до Ion Fury (2019), а также Electric Highways (2015) и Voxelstein 3D (2008, Windows). Домашняя страничка Кена – Ken Silverman's Official Home Page.

Над улучшенной версией перевода работали:

@WERTA - помогал в вопросе стилистической составляющей материала.

Вносили различные корректировки и обновления @Dimouse, @A National Acrobat, @Virgil и @kreol.

---
English text of the interview.

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. @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. 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: "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. Chello 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.

---

Вопрос. Что вдохновило вас на создание игрового движка Build? И касательно вашего участия в разработке игр - возможно, вы могли бы упомянуть несколько интересных фактов?

Ответ. Конечно – DOOM (1993, DOS). Doom определённо не мог не привлечь внимания человека, потратившего целый год на копирование [кода] Ken's Labyrinth (1993, DOS) в начале 1993 года. После того как я потратил почти год на копирование [кода] Wolfenstein 3D (1992, DOS). Ваш второй вопрос слишком обобщённый. У нас же целое интервью, может быть, почитаем его?

---

taufan99 спрашивает: "С тех пор как я сыграл в Ken's Labyrinth и другие ваши шутеры, я влюбился в формат KSM. Однако я хотел бы узнать: можете ли вы выпустить конвертер для формата General MIDI, поскольку, хоть я и понимаю, что AdLib – хорошая звуковая карта, я сам больше являюсь поклонником General MIDI".

Ответ. Если вы хотите что-то немного отредактировать, вы можете использовать мою программу KS2.EXE для преобразования этих музыкальных форматов. Ищите её на моей домашней страничке в разделе утилит. Вам придётся вручную выбрать MIDI-инструменты и полностью переделать трек с перкуссией при помощи инструмента "Лассо". При некоторой настойчивости можно будет добиться хороших результатов. Да, КС2 давно не обновлялся и в современных версиях Windows имеет свойство мерцать. Я мог бы это исправить, если бы у меня было достаточно желания и времени.

---

vyruss спрашивает: "Что во время экспериментального этапа разработки движка Build привело вас к окончательному решению использовать именно порталы, а не другие технологии того времени? Я знаю о преимуществах порталов по сравнению с другими технологиями рендеринга того периода, а также знаю об ограничениях распространённого в то время оборудования у пользователей; был ли проведён расширенный анализ различных подходов для оценки их сильных и слабых сторон или идея зародилась сразу же в виде движка, не связанного конкретно с Build, а затем уже всё органично развилось из подобного решения? Я спрашиваю об этом лишь потому, что, согласно моим (смутным) воспоминаниям, чувствовался разный уровень возможностей у чего-то вроде Ken's Labyrinth, плавно переходящего в Duke Nukem 3D, и других громких тайтлов того времени".

Ответ. Когда у меня возникала идея, я создавал прототип на QuickBasic, так как в этой среде было очень легко писать код и проводить отладку. Мой самый ранний прототип того, что должно было стать движком Build, назывался PICROT4.BAS, который просто "выпускал" луч во множество стен. Очевидно, что это был слишком медленный подход для карт с открытыми пространствами. Моей следующей идеей было использовать регулярную сетку, где каждая ячейка содержит список всех стен (они будут линиями в 2D), которые её составляют. Это решало две проблемы: грубую сортировку стен в порядке от начала к концу и исключение всех стен, которые выходили за пределы пирамиды видимости. Можно было бы обойти эту проблему с помощью дополнительного кода для улучшения сортировки, но в то время я не знал, как это сделать. Это был слишком примитивный алгоритм со множеством визуальных "глюков".

Затем в декабре 1993 года Apogee позволили мне позвонить Джону Кармаку. Как и ожидалось, его ответ был сдержанный; он умолчал о многих моментах, не объясняя ничего подробно. Он вообще не обязан был отвечать на мой звонок, в конце концов. Например, я помню, как спрашивал его об одной из самых сложных вещей в Build Engine того времени: как растеризовать или заполнить пикселями потолки и полы. Он описал свой метод как обычную "заливку" (прим. пер.: в оригинале "flood-filling"), что не имело для меня особого смысла. В моём понимании термин «заливка» всегда был медленным алгоритмом, как у инструмента для рисования в Microsoft Paint. Ведь в BASIC можно было реально видеть, как программа выполняет рекурсивный поиск, наблюдая за этим на многих кадрах. Очевидно, что это работало не так. Так что у него было какое-то другое, своё определение того, что значит «заливка», насколько я могу судить.

Ещё я помню, как он дал мне идею и название для объекта – "сектор", который представляет собой структуру для хранения информации о стенах, являющихся общими для потолка и пола. Это не решило моих проблем с сортировкой стен, но заставило меня понять, насколько нелепо был спроектирован мой старый движок на основе регулярной сетки. Я хранил информацию о потолке и поле вместе с каждой стеной! Это не только расходовало существенное количество памяти, но и дополняло движок множеством визуальных сбоев: например, когда структура стены не соответствовала соседней стене в том же секторе.

Чтобы исправить сортировку стен, мне необходимо было немного подтянуть знания по математике: скалярные и векторные произведения. Я узнал о них в первом семестре в Брауне. Я был удивлён, что это не преподают в старшей школе. Теперь, с моим новым алгоритмом сортировки, у меня был способ сортировать стены без сбоев. Я не мог это обосновать, но не мог и найти никаких отклонений в моей тестовой программе... если только стены не пересекались, то есть... но это в любом случае считалось нереализуемой ситуацией.

Интересное отступление: много лет спустя я подумал, что смогу расширить идею сортировки "идеальной стены" (теперь это называется "полигон") до полного 3D. Я назвал её KENVEX – мое имя + выпуклость. Оказалось, что я ошибался, - или, по крайней мере, реализовать это было намного сложнее, чем я себе представлял ранее. У движка было и множество других проблем. И я понятия не имел, как сделать нормальный редактор.

---

DNSKILL5 спрашивает: "Движок Build на этапе разработки первого Blood. В сети имеется несколько противоречивая информация об этом периоде. Иначе говоря, похоже, дела с этим тайтлом шли не так, как ожидалось. Не могли бы вы немного рассказать нам о специфике работы над этим проектом?"

Ответ. Вы говорите о GEORGE.TXT и тираде Питера Фриза, написанной в июне 1995 года. Программисты Blood переопределяли мои внутренние (намеренно недокументированные) функции Build Engine своими собственными версиями. Полагаю, им некогда было ждать появления новых функций. Проблема была в том, что всякий раз, когда я что-то менял в движке, это ломало их код, и тогда им приходилось заново переписывать собственные "хаки". По сути, это почти как редактирование исполняемого файла в шестнадцатеричном формате. Практика переопределения функций может быть очень контрпродуктивной. Понятное дело, что мне нужно было что-то изменять в движке, для того чтобы улучшать его работу и исправлять ошибки.

Я уверен, что их система кэширования была лучше в то время. Проблема в том, что меня заваливали множеством более важных задач от других команд. Вам не нужна идеальная или даже хорошая система кэширования, чтобы тестировать игру во время её разработки. Если у вас недостаточно памяти, то ваш жёсткий диск работает немного дольше. Это раздражает, но что с того? У меня в то время была примитивная система кэширования, которая просто удаляла самые старые объекты, что можно было бы реализовать с помощью простого FIFO. Она была неэффективна в выборе наиболее подходящих объектов для последующего удаления. Позже, в 1995 году, я всё-таки написал улучшенную систему кэширования.

О, я полностью согласен с комментариями Питера о центрировании спрайтов, – это было ошибкой.

Что касается моих навыков разговора по телефону – да. Я не собираюсь «лгать во спасение» или обещать «что-то там сделать», если я никогда раньше не слышал о такой концепции. Мне следовало бы отвечать: «Конечно, я подумаю над этим». Но я был застенчивым 19-летним парнем с небольшим опытом ведения подобных разговоров. Я не очень хорошо соображал, что говорить в таких случаях. По сей день я предпочитаю давать интервью в текстовом формате. ;-) Кстати, когда мы с Питером встретились лично несколько месяцев спустя, мы прекрасно поладили.

---

Вопрос. The Legend of the Seven Paladins 3D (1994, DOS) считается первым коммерческим проектом, основанным на движке Build. Кроме того, в отличие от последующих работ, он основан на его ранней версии. Тем не менее сама история с игрой остается в тумане. Можете ли вы пролить свет на тот необычный проект?

​

Ответ. Всё, что я знаю, - это то немногое, что мне рассказали в Apogee, а именно – игра была выпущена нелегально. Это было до 2020 года, когда я неожиданно получил электронное письмо от какого-то парня по имени мистер Лин. Судя по всему, он и группа, состоящая из двух человек с Тайваня, приехали к Скотту Миллеру как раз перед Рождеством 1993 года. Лин поведал, что всё закончилось через несколько месяцев из-за проблемы языкового барьера. Что касается вопроса, почему они продолжали работать без надлежащего контракта, – тут ответа я не знаю.

​

---​

Вопрос. На вашем сайте я заметил название Fate Fate (не издана, DOS) от Capstone, что довольно интересно, поскольку я никогда не слышал, чтобы там делали ставку именно на движок Build. Ведь в игре Corridor 8: Galactic Wars (не издана, DOS), которая является продолжением Corridor 7: Alien Invasion (1994, DOS), в конечном итоге использовался движок от Doom. Можете ли вы немного рассказать нам об игре Fate?

Ответ. Я всего лишь знаю, что так называлась третья игра от Capstone, планировавшаяся после Witchaven (1995, DOS) и William Shatner's TekWar (1995, DOS); на сайте игр JonoF есть её демоверсия.

---

Вопрос. Порты, являющиеся производными от ZDoom, поддерживают формат вокселей .kvx (и только его), делая этот древний формат из эпохи Blood единственным неоспоримым стандартом вокселей для сообщества Doom, которое, как известно, является наиболее активным из ему подобных (есть, конечно, DelphiDoom, который может "переваривать" .vox, но он экзотичен и имеет кучу своих ограничений). Существует множество форматов и редакторов вокселей. Но для того, чтобы поместить воксели в Doom, вам нужно преобразовать их с помощью редактора-конвертера в формат .kvx. Там вы можете выборочно подкрасить и отцентрировать их. Подобная программа – это ваш редактор SLAB6, разработанный в 2011 году, который давно уже доступен повсеместно. У SLAB6 есть ограничение на размеры моделей – 256x256x255 вокселей.

Mastermind, к примеру, мог бы вписаться в вышеозначенные ограничения. Но если его масштаб растянуть, то это, судя по всему, уже не будет соответствовать действительности. Более современных альтернатив на горизонте нет и, похоже, не предвидится – получается плохой прецедент, когда что-то современное привязано к древней, заброшенной программной основе.

К слову говоря, обойти подобное ограничение можно обойти через вашу утилиту POLY2VOX. Но для этого нужна шизофреническая схема преобразования воксель-модель-воксель c использованием недокументированных возможностей 3D-редактора, необходимых для центрирования. Что тоже плохо.

Тут длинное вступление заканчивается и начинается вопрос. Планируете ли вы выпустить более современную версию SLAB6?

Ответ. Вам следует рассмотреть PND3D как преемника SLAB6 и VOXLAP. Редактор менее функционален, поскольку им никто не пользовался, но он хорошо работает в качестве быстрого просмотрщика и конвертера форматов. К сожалению, PND3D в настоящее время не сохраняет в формате .KVX. Я мог бы добавить эту опцию, но возникнут некоторые проблемы, такие как квантование цвета и ограничения по размеру.

Формат KVX был разработан для Build Engine, который использовал 8-битную палитру цветов. Формат не нуждался в поддержке огромных моделей и всегда отображался вертикально (где вертикальный алгоритм RLE имеет смысл). В дизайне KVX есть некоторые странные вещи, такие как флаги видимости, которые определяются только для каждого слэба, и смещения, относящиеся к абсолютному положению файла. Кроме того, формат KVX ограничен 256 вокселями в высоту, и, хотя вы и можете расширить координаты x и y за пределы 256, при этом есть риск столкнуться с проблемами. Если спрайт недостаточно сжимаем, то в отношении различных объектов может возникать переполнение, поэтому это не очень хорошая идея. Если вам нужны большие модели, вам следует рассмотреть возможность использования формата KV6. Единственный недостаток KV6 в том, что он не сжимает 8-битную палитру спрайтов так же хорошо, как это делает KVX.

Кроме того, относительно POLY2VOX - не пробовали ли вы опцию /s#? Она предназначена для исправления как постоянного масштаба, так и центрирования в анимациях.

---

​

ck3D спрашивает: "По сей день Build выделяется своей необычностью на общем фоне игровых движков, которые чаще всего разрабатываются с учетом весьма узких задач практического применения. В особенности современные игры, как правило, полагаются на фотореализм гораздо больше, чем игры 1990-х годов, что необходимо для вовлечения пользователя в геймплей и улучшения восприятия, иногда даже в ущерб более творческим альтернативным подходам. В таких продуктах, как Duke Nukem 3D, не упущен ни один из этих параметров; каким-то образом в них сумели развить правдоподобное игровое окружение, при этом внедряя технические приёмы, искажающие реальность: «сектор на секторе» (это позволяет потенциально бесконечно накладывать невозможные пространства поверх общих координат) и стены, переписывающие своё положение во время исполнения, – всё это те особенности, благодаря которым движок Build также можно рассматривать не только как инструмент, предназначенный для создания уровней, но и как актуальную мини-среду разработки, и чаще всего для большинства устоявшихся мапперских сообществ он таковым и является.

Насколько эта творческая свобода была запланированной и, возможно, важной для вас при проектировании движка? Вы надеялись (или даже ожидали), что эти необычные и относительно экспериментальные функции будут приняты его пользователями? Знали ли вы, что они в конце концов будут настолько эффективны, что это до сих пор оказывает влияние на некоторые нишевые школы дизайна уровней? Или вы, не задумываясь, развлекались, пока это происходило, и всё ещё не знали, насколько негибкими станут компьютерные игры, как только возникнут новые тенденции в их развитии?

Вот ещё один связанный с этим вопрос. Хотя общепринятым каноном в качестве сильной стороны движка является «реализм», я склонен не согласиться с этим и утверждаю, что в действительности это базируется на тех или иных предположениях, а очевидная привлекательность большинства уровней в Build на самом деле достигается за счет методов работы с поверхностями, что приводит к более абстрактному их дизайну и творческим идеям в размещении объектов. Это во многом основано на эффектах маскировки, чтобы привести игроков в такие ситуации, в которые они обычно не попали бы, потому что подобные ситуации довольно искусственные в реализации (и поэтому, как ни парадоксально, для мапперов их очень весело придумывать). Что вы думаете насчёт всего этого?".

Ответ. Очевидно, я мыслю на более низком уровне, чем вы. Я занимаюсь алгоритмами и оптимизацией языка ассемблер. Я не беспокоился о том, как широкая публика воспримет те или иные решения. Многие вещи, которые я делаю, являются результатом развития и улучшения. Я пробую что-то. Если это хорошо, то я это сохраняю. Если нет, то – до свидания. Это хорошо работает, когда дело касается оптимизации. Это также обеспечивает гибкость проектирования. Проблема в том, что идей всегда больше, чем времени. Чтобы решить, над чем поработать, я бы использовал такую простую формулу: крутость, делённая на сложность реализации. Конечно, в итоге я всегда приходил к своему любимому занятию – необязательной оптимизации. ;-)

Ключ к успеху игр на Build Engine, имеющих этот самый "фотореализм", заключался в том, что многие части редактора работали в 3D-режиме. Насколько мне известно, движок Build был первым, где имелась подобная составляющая. Возможность просматривать и изменять игровую среду напрямую, не тратя время на создание BSP или чего-то ещё в этом роде, экономила массу времени (по той же причине я бы использовал QuickBasic для прототипирования вместо Cи, а сегодня это был бы EVALDRAW вместо Cи).

Идея трёхмерного редактора пришла мне в голову во время работы над движком на основе регулярной сетки в середине-конце 1993 года. В то время редактор назывался EDITBORD.BAS и был написан на QuickBasic. Предварительный просмотр в 3D исходно начинался как наспех сделанный хак. Я добавил параметр командной строки в трёхмерный просмотрщик, который у меня был на Cи; он переопределял начальную позицию. Мой редактор QuickBasic мог затем создавать исполняемый файл из любого места, где находился курсор мыши.

Конечно, запуск отдельной программы, когда вам нужен предварительный просмотр, - не лучший вариант для работы. Я знал, что мне придётся портировать редактор из QuickBasic на Cи. Как только у меня появился 2D-режим, работающий в программе на Cи, я понял, что было бы круто иметь возможность редактировать что-то прямо в 3D. Проблема была в том, что мне нужен был способ определить, над какой стеной / потолком / полом / спрайтом находится курсор мыши. В то время у меня ещё не было функции сканирования попаданий луча (в то время никто ещё не делал игр; они просто игрались в моих ранних редакторах для карт и графики). Я придумал способ обнаружения попаданий во время процесса рендеринга: сравнивая каждый горизонтальный или вертикальный промежуток с местоположением курсора мыши. Неказисто, но достаточно легко в плане реализации. Как только эта часть была готова, я начал перемещать как можно больше объектов в трёхмерный редактор. Всё, что связано с отображением текстур, лучше всего работало в режиме 3D. Поднятие/опускание для потолков/полов отлично функционировало в трёхмерном редакторе.

---

Вопрос. Каков был ваш опыт работы с 3D Realms над проектом Duke Nukem 3D (1996, DOS) касательно отзывов, которые вы получали напрямую от дизайнеров уровней? Вы подходили к своей задаче создания игрового движка исключительно с точки зрения кодирования/математики в соответствии с тем, что было нужно разработчикам, или активно смотрели на это так, как сделал бы дизайнер уровней/игрок? Дизайнеры уровней быстро поняли, как использовать редактор, или вам было трудно найти с ними общий язык либо доказать им свою точку зрения?

Ответ. Лучше всего я знал дизайнеров уровней из Duke Аллена Блума (Allen Blum) и Ричарда Грея (Richard Gray). Несколько дизайнеров карт были дополнительно привлечены для завершения издания Duke Nukem 3D: Atomic Edition (1996, DOS), но к тому времени я проводил бóльшую часть своего времени с Фрэнком Мэддином (Frank Maddin), помогая ему закончить Shadow Warrior (1997, DOS). Конечно, было круто наблюдать за тем, как дизайнеры карт делают свою работу. Я не помню, кто конкретно просил, но некоторые из функций в Build, которые появились именно благодаря дизайнерам карт, были такими: Alt+S – чтобы провернуть цикл; нажатие "V" один раз для текущих текстур или два раза для всех текстур (функция, которую я ненавидел); система тегов, несколько видов копирования и вставки; различные "глюки" рендеринга.

Не требовалось много времени, чтобы освоиться с редактором Build. Тогда людям не нужны были красивые меню или кнопки. Вы могли написать текстовый файл, и чаще всего люди его читали. Если вы не могли запомнить всю информацию, вы её распечатывали. Изучение приёмов в Build занимало больше времени, например объединение и разделение секторов без перерисовывания их с нуля.

---

Вопрос. Флагманские игры движка Build имели относительно длительные циклы разработки: начало проекта Shadow Warrior датируется 1993–1994 годами, а движок Build активно развивался все эти годы. Вы вообще играли в каждую из сборок Shadow Warrior и Duke Nukem 3D или это было задачей команды тестеров?

Ответ. На самом деле первым коллективом, использовавшим Build, была команда Blood (1997, DOS), которая начала работу в сентябре 1993 года. Тогда они были известны как "Horror". Конечно, я играл во многие версии игр. Иногда, когда кому-то нужно было показать мне ошибку, они отправляли мне копию по модему и я её просматривал. Если я был на месте, мы могли вести тестирование по IPX или нуль-модему. Часто мы играли ради развлечения по ночам. Хотел бы я сохранить копии каждой из версий игр, к которым у меня был доступ. Конечно, для этого потребовалась бы довольно большая пачка дискет!

---

Вопрос. Вы играли в Shaw's Nightmare (2013)? И если да, то что вы о ней думаете? Кажется, ей нужна некоторая оптимизация производительности.

Ответ. Нет. Видео на YouTube выглядит как уникальное ретро. Возможно, низкая частота кадров была задумана изначально?

---

Вопрос. В Powerslave (1996, DOS) не используются наклонные поверхности ни в одной из официальных карт, и долгое время считалось, что версия движка Build, на которой игра создана, ещё не имела этой функции. Однако недавно было обнаружено, что Powerslave на самом деле полностью поддерживает наклоны, и был создан специальный пакет карт, в полной мере использующий эту функцию. Поскольку наклонные поверхности кажутся логичным элементом в игре в сеттинге Древнего Египта (к примеру, для создания пирамид), сообщество предположило, что 3D Realms могли скрыть информацию о некоторых технических характеристиках, когда они сублицензировали движок Build, чтобы сохранить конкурентное преимущество за своими собственными продуктами. Можете ли вы как-то это прокомментировать?

Ответ. 3D Realms многое скрывали о своих отношениях с небольшими командами разработчиков. Я никогда не видел никаких контрактов, которые они заключали, если только специально не спрашивал об этом у них. Сублицензирование движка не упоминалось в моём первоначальном контракте, и они использовали этот момент в своих интересах. Что касается особенностей, то я знаю, что 3D Realms утаили программную поддержку наклонных поверхностей от Capstone. Что касается того, что случилось с Lobotomy, то я не могу сказать. Я помню, как в Lobotomy расстроились, когда узнали, что движок поддерживает наклонные поверхности. Это выглядит очень странно. Так что, возможно, вы правы – поддержку наклонных поверхностей от них утаили.

---

Вопрос. Если бы вы воссоздали что-то эквивалентное Build Engine, используя имеющиеся у вас на сегодня знания, вы бы внесли какие-либо изменения в дизайн?

Ответ. Конечно. Я бы это сделал, очистив код. Например, больше структур, меньше глобальных переменных, присвоение функциям возвращаемого типа и никаких типов "long" почти для всего. Что касается оптимизации, то я не думаю, что оставил много места для улучшения. Большáя часть моих новых знаний касается современных машин, таких как AVX2, многопоточности и 64-битных сборок. Этих вещей нет на 486-DX или Pentium. ;-) См. дальше список моих сожалений в ответе на двадцатый вопрос.

---

Вопрос. На рубеже 1997–1998 годов разработчикам компьютерных игр неизбежно пришлось переходить на полноценную 3D-графику. Возможно, вы планировали совершенно новый и по-настоящему трёхмерный движок вместо Build в то время, т. е. до наступления 2000-х? Кажется, что чуть позже Voxlap занял эту нишу.

Ответ. Конечно. POLYTEX (1995) был моей первой попыткой конкурировать с Quake. POLYTEX использовал BSP для сортировки полигонов в порядке от конца к началу. Рендеринг был простым, но в нём было много перерисовки. Затем в 1998 году я начал KENVEX, который должен был стать портальным движком. Я хотел, чтобы он работал как Build, с его идеальным удалением скрытых поверхностей, но оказалось, что попытка достичь этого "святого Грааля" для рендеринга полигонов так и не сработала. К сожалению, оба проекта не прошли стадию тестирования. Я понятия не имел, как сделать простой в использовании редактор, работающий в полностью трёхмерной среде.

---

Вопрос. В продолжение предыдущего вопроса. Похоже, вы поклонник вокселей; не было ли у вас соблазна больше работать с традиционным, полным 3D в целом, за исключением рендерера POLYMOST для Build?

Ответ. Есть BUILD2, но это едва ли традиционный вариант, и он появился на много лет позже. Нет, мои амбиции в попытке конкурировать с Quake умерли после моей попытки с KENVEX. К тому же не оставалось времени что-то предпринимать – было слишком поздно: повсюду была очень сильная конкуренция.

---

@drugon спрашивает: "Во второй половине 1990-х активно развивалась 3D-графика, и в какой-то момент показалось, что шутеры, использующие спрайтовых монстров, канут в лету, уступив место шутерам с 3D-моделями. Сами спрайтовые монстры, очевидно, были техническим компромиссом в то время, позволяя железу хоть как-то адекватно вытягивать игру, не жертвуя детализацией окружения, как и те ранние симуляторы, где использовались простые 3D-модели без спрайтов. Но, как это часто бывает с популярными играми, стеснёнными техническими ограничениями, подобные ограничения затем становятся образцом стиля для будущих разработчиков. Спрайтовые объекты в шутерах от первого лица являются ярким примером этого и часто используются в современных ретрошутерах: Mullet Madjack (2024), Warhammer 40,000: Boltgun (2023), Supplice (2023) и т. д. Представляли ли вы, Кен, на рубеже 1990-х и 2000-х годов, что подобное решение породит столько последователей и будет актуально по сей день?"

Ответ. Я не фанат "картонных" спрайтов. Художнику нужно много времени, чтобы их нарисовать, а если вы визуализируете их из 3D-моделей, то это занимает много дополнительной работы и ненужной квантизации. Когда я услышал о Quake, использующем 3D-полигональные модели, я попытался придумать своё собственное решение. Я никогда раньше не пользовался программой для моделирования полигонов, и мне казалось, что написать свою собственную будет непросто. Поэтому я воскресил старую идею, которая у меня была, – воксельные спрайты. Я был рад видеть, как они появляются в играх, пусть даже и в ограниченной форме. Было бы ещё более приятно увидеть тогда, как их используют для монстров... но, думаю, для этого всё было недостаточно быстрым.

---

@drugon спрашивает: "Ещё один конкретный вопрос, если можно. Думали ли вы, Кен, что движок Duke будет использоваться в какой-то степени десятилетия спустя? И не только во многих действительно достойных бесплатных работах фанатов - WG Realms, Duke Nukem Forever 2013 и т.д., - но и в коммерческих релизах?"

Ответ. 30 лет назад я больше бы беспокоился о завершении проектов игр, чем об их наследии. Мы знали, что если будем ждать слишком долго, то появится что-то (возможно, Quake), из-за чего наши игры будут выглядеть устаревшими.

---

Вопрос. Что вы думаете о трассировке лучей как об опции? В последние годы ей уделяется много внимания, что также имело место и в классических играх, включая Doom. Это просто очередная "дань моде" или действительно "стоящая вещь"?

Ответ. Трассировка лучей лучше всего работает, когда у вас есть высокопараллельный процессор, например на современном GPU. К сожалению, я никогда не углублялся в программирование для GPU. Теоретически не должно быть никакой разницы между двумя вариантами вывода. Всё сводится к выбору между использованием пикселя или графического примитива в качестве объекта для вашего внешнего цикла "for". На практике что-то проще в одном методе, а что-то в другом. Например, отражения реализовать проще с трассировкой лучей. Растеризация обычно происходит быстрее из-за того, что количество примитивов меньше количества пикселей на экране. Этот аспект может измениться, когда у вас больше деталей или установлено другое оборудование. Помимо этого, мне нечего больше сказать по этой теме - кроме того, что я так и не попробовал сделать общую трассировку лучей.

---

Вопрос. Если бы в 2024 году потребовалось сделать другой движок с программным рендерингом для нового 3D-шутера с нуля, в чём были бы основные отличия по сравнению с Build?

Ответ. Лучше спросить: кто был бы настолько сумасшедшим, чтобы "потребовать" подобного безумия? Чтобы ответить на ваш вопрос, моей первой задачей была бы необходимость выбирать между воксельным, полигональным или гибридным движками. Полигональный движок мог бы хорошо работать, если бы был элегантный, безошибочный способ выполнять операции CSG на лету. Воксельный движок мог бы хорошо работать, если бы был способ анимировать спрайты плавно, без необходимости делать отдельные кадры анимации. Очевидно, что я бы с самого начала разработал любой новый проект для компьютеров, используя 64-битный режим, AVX2 и многопоточность.

---

Вопрос. Есть ли у вас какие-либо сожаления относительно работы над Build - или, может быть, есть то, что вы хотели бы сделать по-другому? Этот вопрос включает в себя технические аспекты, связанные с движком Build.

Ответ. Конечно, вот список:

* Наложение текстур на наклонные поверхности. Мне не следовало прибегать к использованию инструкций FPU для получения дополнительного целочисленного регистра. Это убивало частоту кадров на 486-SX, когда на экране была наклонная поверхность.

* Наклонные поверхности с наложенными текстурами. Могло бы работать немного быстрее, если бы у меня было время, чтобы воплотить реализацию наложения текстур в горизонтальном направлении.

* Истинно-центральное центрирование: этот флаг не должен был оказаться в структуре спрайтов. Вместо этого его следовало предоставить в качестве макроса программисту игры.

* Полы с наложением высот (они же "groundraw"). Я так и не дошёл до исправления ошибок деления на ноль. Позже наклонные поверхности сделали этот компонент устаревшим.

* Сетевой код. Я мог бы сэкономить всем много времени, если бы всё сделал правильно с первого раза. Это было сделано уже в процессе проектирования игр, а не движка, поэтому мне пришлось потратить много времени на обучение программистов тому, как вносить каждое небольшое изменение, которое я придумывал.

* Режим «красный-синий». Должен был бы быть режим «красный-голубой». Зелёный канал в ауте! Хотя это же мелочь.

* Архивы. Я сохранил много вещей с тех времён, но хотел бы сохранить ещё больше. В частности, больше копий каждой коммерческой игры. Кроме того, было бы неплохо, если бы резервная копия моего жёсткого диска с 1995 года не погибла.

---

Вопрос. Что вы думаете о потенциале воксельных движков, таких как VOXLAP, сегодня? Voxelstein 3D был скорее технической демонстрацией, но всё равно довольно интересным экспериментом. Как вы думаете, у таких игр есть будущее?

Ответ. Когда вы говорите «как VOXLAP», я предполагаю, что вы имеете в виду маленькие воксели, а не большие, которые вы могли видеть в Minecraft / Roblox. Воксельные объекты хорошо работают на 3D-дисплее, и их легко генерировать из кода (например, в EVALDRAW). Они не имеют особого смысла, если вы ищете возможность отображать реалистичные пейзажи. Воксели плохо масштабируются при увеличении разрешения. Неважно, сколько бит [цвета] вы в них помещаете, – вы всё равно видите кубики. Конечно, вы можете скрыть это с помощью интерполяции, но это дорого вам обойдётся - во всяком случае, если вы не используете GPU.

---

Вопрос. В настоящее время Cheello работает над своим масштабным проектом Voxel Duke Nukem 3D, целью которого является воссоздание каждого спрайта (монстра) в игре. Вы видели другие работы Cheello: Voxel Doom, Voxel Blood?

Ответ. Да. Очень здорово видеть, как 2D-спрайты преобразуются в воксели и вручную редактируются до такого уровня точности. Это действительно выглядит аутентично по отношению к оригинальным играм.

---

Вопрос. Есть ли какая-то функция, которой не было в движке Build (до перехода проекта в открытый доступ) и которую вы хотели бы реализовать?

Ответ. Конечно. Вам стоит посмотреть Build 2. Вот несколько самых важных функций, которые я бы хотел видеть в Build:

* Полноценный взгляд вверх / вниз.

* Нативная поддержка комнаты поверх комнаты.

* Красивое освещение.

* Drop-in networking (прим. пер.: термин, определяющий взаимодействие различных беспроводных и проводных сетей связи с целью передачи данных между устройствами).

---

Вопрос. Если не секрет, почему вы решили уйти из крупной игровой индустрии? Из коммерческой, я имею в виду. Есть ли шанс, что вы вернётесь в неё, - может быть, даже к чему-то, связанному с Duke, или к новой игре на основе движка Build, как бы маловероятно это ни было, если кто-то попросит?

Ответ. В 1997 году я заметил, что спецу-одиночке по разработке движков уже нечего ловить. Конкуренция возросла многократно. Даже тогда я знал, что разработка нового движка займёт много лет... но всё же не 14 лет. ;-P. Я не хотел переезжать в Техас на постоянное место жительства и не рассматривал другие компании. В 2015 году Gearbox спросили, могу ли я как-то поучаствовать в ремейке Duke 3D, который позже стал изданием DN3D 20th Anniversary. Я не знал, каким образом мог бы внести в это дело свой вклад и при этом не слишком навредить своему графику. Запись звуковых эффектов может занять несколько дней. Создание карт или песен может занять несколько недель. Но написание нового движка может занять годы. Позже я понял, чего они на самом деле хотели, а именно порт на несколько консолей вместе с несколькими настройками. Я никогда не занимался программированием для консолей, так что, полагаю, ситуация сложилась к лучшему. Что касается возвращения в игровую индустрию, то я не вижу к тому предпосылок. К тому же делать трёхмерные дисплеи - это намного веселее. ;-)

---

Вопрос. Вы когда-нибудь представляли себе Build 2 как что-то большее, чем просто учебный проект для летнего лагеря? С какой игрой, по вашему мнению, он мог бы работать лучше, чем, скажем, с EDuke32? Что побудило вас выпустить Build 2 в 2018 году, почти через 10 лет после того, как вы перестали над ним работать?

Ответ. Поскольку я вложил в него много усилий, было бы неплохо увидеть полноценную игру, созданную с его помощью. Я полагаю, что никто не хочет использовать недоделанный движок, полный нечитаемого ассемблерного кода. Я выпустил его, потому что… а почему бы и нет. Это была клёвая штука, но сейчас он не имеет для меня никакой ценности. Мне следовало выпустить его на несколько лет раньше.

---

Вопрос. Что за история скрывается за таинственным Ken's Labyrinth II? Похоже, что проект находится в разработке с 2007 года, но у него почти не было рекламы. Вы участвуете / участвовали в нём каким-либо образом, кроме лицензирования персонажей? Разве не разочаровывает, что игра использует GZDoom, а не Build или другой ваш движок?

Ответ. Я никогда ничего не лицензировал. Всё, что я делал, это говорил что-то вроде "Да, конечно" в ответе по электронной почте. Ken's Labyrinth был демоверсией движка с кучей спонтанной ерунды внутри. Мне лестно, что кто-то хочет сделать шутер на основе первого "Лабиринта Кена". Некоторое время назад ребята попросили меня записать несколько звуковых эффектов для их игры, что я и сделал. Я понятия не имею, будут ли они на самом деле это использовать. Кроме этого, я не имею никакого отношения к проекту.

---

Вопрос. Кен, вы упоминаете свою любовь к картографии и картам, и среди текстур стен в Ken's Labyrinth есть изображения карты США. Было ли это ваше хобби полезным для проектирования карт в Ken's Labyrinth или для каких-либо других аспектов разработки игры/движка?

Ответ. Не совсем. В детстве мне нравилось рисовать и переписывать (но никогда не калькировать) карты. Я до сих пор могу нарисовать довольно хорошую карту пятидесяти штатов по памяти. Я не думаю, что это имеет большое отношение к дизайну движка, но могу сказать, что всё это подразумевает наличие развитого образного мышления, что всегда было моей сильной стороной (кстати, большинство карт для Ken's Labyrinth разработал Энди Коттер (Andy Cotter)).

---

Вопрос. Можете ли вы рассказать, чем сейчас занимаетесь, какие проекты вас интересуют? Разрабатываете ли вы сейчас какое-либо программное обеспечение для создания игр?

Ответ. Я работаю в Voxon Photonics уже более 10 лет. Мы делаем трёхмерные [объёмные] дисплеи. Моя работа в основном заключается в низкоуровневом программном обеспечении, но я также занимаюсь проектированием печатных плат. Я написал SDK, который включает в себя несколько простых демоигр. К сожалению, я давно не обновлял свой сайт, потому что был очень занят своей работой в Voxon.

---

Вопрос. Вы играли в Ion Fury? И если да, то что вы думаете об этой игре? Считаете ли вы её достойным духовным преемником Duke Nukem 3D? Считаете ли вы, что должно выйти больше игр, подобных Ion Fury?

Ответ. Конечно. Я считаю, что игра отличная. Мне понравились новые и очень детализированные карты. Воксельные объекты были хорошо сделаны. Приятно видеть, как моя работа с POLYMOST находит практическое применение. Кроме того, поезда с дробовиками – это весело. ;-)

---

Вопрос. Какие-нибудь слова напоследок для наших читателей?

Ответ. Конечно. Game over – Игра окончена.

---

 

Про "Game over"?

На момент публикации на других ресурсах, это 12.06.24, ссылка работала. Адрес конкретно почты впрочем изначально был взят не с этой страницы, его подсказал один товарищ.

Может в связи с публикацией в целом нахлынул общий интерес / последовали вопросы, но думаю это в целом маловероятно. Скорее случайное совпадение.