[Kawa]

Between all these existing BUILD games, there are a lot of differences besides who the main character is and the overall theme. As opposed to how so many modern FPS look alike enough to be referred to by a mashup name.

I've just been wondering since yesterday, what are the various aspects and features between the BUILD games? For example Duke3D, SW, and RR each have smack talk, but Duke has automatic sector vehicles, SW has/adds user-ridable sector vehicles, and RR (I think) has user-ridable sprite vehicles. By which I mean you see a sprite model of a motorcycle, use it, and the handlebars replace your weapon, while in a sector vehicle the steering mechanism is part of the sector construct.

So let's see what we can make of this, together.

KenBuild

• Aspect: Development example
  
• Hand-pixeled character art
  
• Custom format FM music
  
• Different weapons
  
• Flight item, from pickup to until it runs out
  
• Switches
  
• Bounce walls
  
• Mirror walls
  
• Touchplate sectors
  
• Sectors you sink into
  
• Teleport sectors
  
• Doom doors, going up or down, or both down the middle
  
• Vertical doors
  
• Revolving doors
  
• Swinging doors
  
• Automatic sector vehicles: subways, use walltags as endpoints

Duke Nukem 3D

• Aspects: Modern action heroics, sci-fi, dubious role model
  
• Rendered character sprites
  
• FMV cutscenes
  
• General MIDI music with proprietary extensions
  
• Snark -- random, scripted, and responsive
  
• Enemies that can play dead
  
• Static innocents that spawn enemies when killed
  
• Trash cans and such that may spawn things when destroyed
  
• Pointless Shit™ -- pool table, microphone...
  
• Keycards
  
• Sexy stuff -- strippers, clips...
  
• Leaving footprints
  
• Footfall noise
  
• Different weapons
  
• Quick melee attack (Mighty Foot, use while another weapon is drawn)
  
• CON scripts
  
• Toggle for flight (jetpack)
  
• Switches
  
• Mirror walls that also work as bounce walls for a few projectiles and can break
  
• Breakable windows
  
• Cameras
  
• Breakable sector walls -- scripted or marked by a crack
  
• Touchplate sectors
  
• Sectors you sink into
  
• Teleport sectors, with or without special effects
  
• Most if not all of KenBuild's doors, and more
  
• Automatic sector vehicles with waypoint sprites
  
• Very simple unused room-over-room, view only (SE40)
  
• No voxels -- weren't yet supported at the time

Shadow Warrior

• Aspects: Kung-fu action parody, Asian mishmash, dirty old man
  
• Rendered character sprites
  
• FMV cutscenes
  
• CD-Audio music
  
• Snark -- random, scripted, and responsive
  
• Snark from items (fortune cookies)
  
• Enemies that spawn other enemies
  
• Keycards
  
• Sexy stuff -- anime babes
  
• Pointless Shit™ -- breeding rabbits, pachinko machines...
  
• Leaving footprints?
  
• Footfall noise?
  
• Different weapons
  
• Quick melee attack? (Do the fists work like the Mighty Foot?)
  
• Switches
  
• Mirror walls that may spawn enemies
  
• Breakable windows?
  
• Breakable sector walls -- scripted or marked by a crack
  
• Touchplate sectors
  
• Sectors you sink into?
  
• Teleport sectors, with or without special effects
  
• Climbable ladders
  
• Most if not all of KenBuild's doors, and more
  
• Automatic sector vehicles -- waypoint sprites?
  
• Player-driven sector vehicles -- also, remote-controlled
  
• More mature room-over-room
  
• Different fog colors

Blood

• Aspects: Gothic (?) horror, very brown and gray
  
• Statuette character sprites
  
• FMV cutscenes
  
• CD-Audio music?
  
• Snark
  
• Dynamic innocents -- run away in fear
  
• Differently-implemented mature room-over-room

Redneck Rampage

• Aspects: hillbillies and aliens, little tiny brains and great big guns
  
• Rendered character sprites
  
• CD-Audio music
  
• Snark
  
• Climbable ladders
  
• Player-driven sprite vehicles (Rides Again only)

TekWar

• Photographic human character sprites, hand-pixeled creatures.
  
• FMV cutscenes
  
• Custom format music, MIDI based
  
• Hub level
  
• Old engine version -- no voxels, no slopes. (anything else?)
  
• William Shatner
  
• Automatic sector vehicles with waypoint sprites
  
• Climbable walls, designated with sector tags

?

Bombshell prequel

• MOD music

[MetHy]

Kawa, on 29 November 2016 - 05:25 AM, said:

RR (I think) has user-ridable sprite vehicles. By which I mean you see a sprite model of a motorcycle, use it, and the handlebars replace your weapon, while in a sector vehicle the steering mechanism is part of the sector construct.

RR doesn't, but RR Rides Again does. They're two different games, for instance Rides Again also has SW style RoR but the first RR didn't.

This could be interesting but I think it would be best to seperate features which are on the "Build side", made by Ken Silverman, and features which are on the game sides, made by each dev. I mean not every dev had support from Ken, for instance I assume that for Powerslave they acquired Build v6 but had no support whatsoever from Ken which could explain why they didn't move on to a later version before release, but I could be wrong.
However, it could be very tricky to make the difference at times and I think only a handful of people on this forum would probably be able to tell for sure on some points. Then it gets even trickier when you know that for Blood, the devs even changed things on the engine side themselves.

[Kawa]

MetHy, on 29 November 2016 - 07:04 AM, said:

This could be interesting but I think it would be best to seperate features which are on the "Build side", made by Ken Silverman, and features which are on the game sides, made by each dev.

Good point, and that's why I didn't list things such as moving walls in general, slopes, and parallax. I would mark engine changes as such. For example, if I were to add EDuke32 to the list, it'd probably look like this:

EDuke32

• Everything in Duke Nukem 3D
  
• Advanced room-over-room (engine modification)
  
• Polymer renderer (engine modification)
  
• Enhanced version of NAM's CON extensions

For Powerslave, one might list "No slopes or voxels, old version of the engine", and Duke3D might have a similar line about just the voxels.

[NNC]

I'm pretty sure, the SW engine can do almost anything that classic Duke engine can, but more stuff. Along with the RoR and the controllable vehicles, it had colored lighting and fog as well. It also used clearwater effect, although fake versions were used by Bob Averill and others for Duke too. And not to mention voxels. Were those possible for the classic Duke engine?

[Sanek]

Kawa, on 29 November 2016 - 07:11 AM, said:

TekWar

Tekwar used a subway as a hub point between locations. I don't remember such a thing in any other Build game.

[oasiz]

Tekwar was largely just the subway.
Pretty much everything they have is just a modification from Ken's stock stuff. Train is most likely just a modification of the kenbuild train, also seen in 7 paladins.

Only real major difference is the Map format, which is just XT parameters slapped at the end of the arrays. These define stuff like NPC behaviour and item drops.

Tekwar also uses an earlier version of build v6 compared to Powerslave.

It gets kind of hard to determine features like this since the games share a ton of code in some aspects.
Blood probably has the least in common with the other games since they kind of re-invented the wheel to achieve similar results in a lot of cases.

[Daedolon]

Kawa, on 29 November 2016 - 07:11 AM, said:

Enhanced version of NAM's CON extensions

NAM didn't have any "code extensions", it ran purely as a Duke Nukem 1.5 mod.

[Kawa]

Nancsi, on 29 November 2016 - 09:19 AM, said:

I'm pretty sure, the SW engine can do almost anything that classic Duke engine can, but more stuff. Along with the RoR and the controllable vehicles, it had colored lighting and fog as well. It also used clearwater effect, although fake versions were used by Bob Averill and others for Duke too. And not to mention voxels. Were those possible for the classic Duke engine?

Colored lighting? I can't recall any colored lighting. As for voxels, I understand engine support wasn't added in time for Duke or something. JFDuke has them, of course... let me check my sources.

Edit: okay yeah, Chocolate Duke has no "vox" anywhere in it, and that's the closest to the original non-JF version I have on short notice.

[Jblade]

Kawa, on 29 November 2016 - 11:25 AM, said:

Colored lighting? I can't recall any colored lighting. As for voxels, I understand engine support wasn't added in time for Duke or something. JFDuke has them, of course... let me check my sources.

They have it listed here on the 3DR website:

http://ftp.3drealms.com/sw/index.html

I'm not entirely sure what the difference is between SW's coloured lighting and Duke's palette system since all things considered that had coloured lighting too - only thing I can maybe think of is that SW had better support for changing rooms from one palette to another? Somebody who knows more about SW build could fill us in.

[MetHy]

The difference is that DN3D doesn't support different palettes with working lights (pulsating lights might be an exception though? never used those myself).
Ever notice how if you use triggerable lights on a texture with a custom palette it just turns the texture back to the default palettes?

SW supports palettes+lights; and you get to choose if each surface is affected by the palette, etc there are plenty of freedom of use with palettes and lights, and for the two at the same time. There is a room with light/palette effects in the ST1 map coming with the game, so anyone can just have a look at it.

"Coloured light" is just a more commercial way to say it. Just like Powerslave DOS was being advertised for its supposed "dynamic lights".

[Hendricks266]

This would be great as a wiki page.

Kawa, on 29 November 2016 - 05:25 AM, said:

So let's see what we can make of this, together.

Shadow Warrior has MIDI music in the shareware and CD audio in the full version.

Blood has MIDI music in the shareware and both MIDI and CD audio in the full version depending on whether or not you had the disc in.

TekWar and the Witchavens use MIDI music, but it is stored on disk in a custom container format in the SONGS file so that different MIDI files can be used on different sound cards (IIRC). The container does not change the fact that the music is MIDI.

Technically, Duke Nukem 3D and Shadow Warrior's MIDI files have additional events defining looping and enabling/disabling certain channels (again, for different sound cards) using a custom spec Apogee designed called EMIDI.

SW has a jetpack-like mode if you activate a cheat code.

RR has FMV cutscenes, but Rides Again does not (IIRC).

I would distinguish between the ANM cutscenes that Duke and SW have which are highly similar to a GIF in what can be displayed, and the Smacker format movies used in Blood, RR, and TekWar. They are both full-motion but offer different levels of image quality.

Kawa, on 29 November 2016 - 07:11 AM, said:

EDuke32

• Everything in Duke Nukem 3D
  
• Advanced room-over-room (engine modification)
  
• Polymer renderer (engine modification)
  
• Enhanced version of NAM's CON extensions

I know this is an example, but that list should be way longer.

Daedolon is right: you're probably thinking of WWII GI's CON extensions, which were carried into DOS EDuke, and merged with JFDuke3D circa 2004 to form EDuke32.



(This image is missing World Tour, which is a first-generation descendant from the topmost node.)

Nancsi, on 29 November 2016 - 09:19 AM, said:

I'm pretty sure, the SW engine can do almost anything that classic Duke engine can, but more stuff. Along with the RoR and the controllable vehicles, it had colored lighting and fog as well. It also used clearwater effect, although fake versions were used by Bob Averill and others for Duke too. And not to mention voxels. Were those possible for the classic Duke engine?

Everything you mentioned is not part of the engine and should not be referred to as such. They are game features bolted on top of the highly dynamic nature of the engine.

Kawa, on 29 November 2016 - 11:25 AM, said:

Edit: okay yeah, Chocolate Duke has no "vox" anywhere in it, and that's the closest to the original non-JF version I have on short notice.

Chocolate Duke has no right to call itself Chocolate since it's such an indirect descendant of the original code, through ports that have some non-trivial changes made.

https://vision.gel.u.../~klein/duke3d/
http://www.rancidmea...oject.php3?id=1
https://icculus.org/duke3d/

[MetHy]

Hendricks266, on 29 November 2016 - 02:58 PM, said:

Everything you mentioned is not part of the engine and should not be referred to as such. They are game features bolted on top of the highly dynamic nature of the engine.

I get what you're telling Nancsi; and that's why I suggested we made the difference between what was made on Ken's side of things and what was made on the devs' side.

Nancsi, and everyone, should read these explanations by Fabien Sanglard, the maker of 'Chocolate Duke', that really helps understanding on how things work in Build games:
http://fabiensanglard.net/duke3d/

However couldn't we argue that the combination of the two ("game" side and "engine" side) results in what people usually refer to as an "engine" ?

[Kawa]

MetHy, on 30 November 2016 - 01:55 AM, said:

However couldn't we argue that the combination of the two ("game" side and "engine" side) results in what people usually refer to as an "engine" ?

With the exception of a few games using older versions of Build and maybe Blood, it's the same shared Build library for the lot of them, providing everything but sound support. The Build library allows teleporters, touchplates, and doors that go either which way, but it's the game that actually implements these things. Between studios, these game-side implementations may be shared between various games and improved over time, using KenBuild as the base game-side library.

For example, KenBuild has revolving doors but no sector effectors. Thus, his revolving doors only go in one direction using the center of the structure as the pivot point. Duke adds sector effectors, allowing it to designate a sector as revolving, and use itself as the pivot point. KenBuild has a live-rendered slime tile, which I don't think I've seen in any other Build game though I remember Blood having a similarly-dynamic fire texture. And for the same reason, (almost?) every Build game has some form of sector vehicle, since KenBuild has a simple subway to build from.

Mirrors are a bit of both, having the setup on the engine side and the extra render calls on the game side. Duke's security cameras are a natural offshoot with just the extra render calls. Room over room is purely game-side... except in EDuke32.

But that's just my observation. Feel free to correct me.

[Micky C]

What do you mean live-rendered?

[Daedolon]

The texture in Blood is just that, a texture.

[Kawa]

Micky C, on 30 November 2016 - 03:48 AM, said:

What do you mean live-rendered?

I mean that the slime in KenBuild is animated in code. Check

void movelava(char *dapic)

in KenBuild's game.c.

Daedolon, on 30 November 2016 - 03:55 AM, said:

The texture in Blood is just that, a texture.

Then I may have misremembered that part.

[oasiz]

Water in lameduke is also generated

[DustFalcon85]

Redneck Rampage Rides Again has slot machines that'll spit out an item if you won. Also the bobbing up and down motion on that ferry level in RA IIRC.

[Kawa]

oasiz, on 30 November 2016 - 07:12 AM, said:

Water in lameduke is also generated

So it is



Looks nice.

[NNC]

MetHy, on 29 November 2016 - 12:20 PM, said:

The difference is that DN3D doesn't support different palettes with working lights (pulsating lights might be an exception though? never used those myself).
Ever notice how if you use triggerable lights on a texture with a custom palette it just turns the texture back to the default palettes?

SW supports palettes+lights; and you get to choose if each surface is affected by the palette, etc there are plenty of freedom of use with palettes and lights, and for the two at the same time. There is a room with light/palette effects in the ST1 map coming with the game, so anyone can just have a look at it.

"Coloured light" is just a more commercial way to say it. Just like Powerslave DOS was being advertised for its supposed "dynamic lights".

Thanks for clarification. I always thought the color lights are more advanced in SW, but I don't know the real technical differences to DN3D's sector palettes...

[Kawa]

I guess if you want dynamic lights that actually are what they imply, you need something like Polymer.

And for comparison with LameDuke, here's KenBuild's slime:


I'm a little tempted to bring it back for my game.

[Hendricks266]

MetHy, on 30 November 2016 - 01:55 AM, said:

However couldn't we argue that the combination of the two ("game" side and "engine" side) results in what people usually refer to as an "engine" ?

I am highly against this, because your average noob will interpret that as "the Build engine" and go right back to the "SW and Blood have more advanced versions of the engine that have ROR" misconception that has proliferated.

We are arguing semantics, but having worked with the source code for the engine and multiple Build games, I stand by my assertion.

[NNC]

When I say Duke engine, of course I mean the game side, the exe, the cons, etc., not the Build engine in general. That's why I said classic Duke engine (read: not EDuke32, which use IIRC the same Build engine, but many upgrades on the game's side), It's really just semantic, but if that bothers you understand my post saying "classic Duke game".

[Kawa]

Nancsi, on 30 November 2016 - 01:50 PM, said:

not EDuke32, which use IIRC the same Build engine, but many upgrades on the game's side

Nope. Besides the Polymost and Polymer renderers, EDuke32's TROR is part of the engine.

[Hendricks266]

Nancsi, on 30 November 2016 - 01:50 PM, said:

It's really just semantic, but if that bothers you understand my post saying "classic Duke game".

It doesn't bother me that I'm reading it, it bothers me that other people are saying it, and therefore that others are reading misinformation.

[Kawa]

And (mis)information is what this thread's all about

[NNC]

Kawa, on 30 November 2016 - 02:01 PM, said:

Nope. Besides the Polymost and Polymer renderers, EDuke32's TROR is part of the engine.

Nah, this is where I got it wrong. I never thought TROR and new rendering were part of Build engine upgrades. But thanks for clarification.

[TerminX]

Hendricks266, on 30 November 2016 - 01:30 PM, said:

I am highly against this, because your average noob will interpret that as "the Build engine" and go right back to the "SW and Blood have more advanced versions of the engine that have ROR" misconception that has proliferated.

We are arguing semantics, but having worked with the source code for the engine and multiple Build games, I stand by my assertion.

I dunno, I think "EDuke32 engine" or the like is a fairly accurate description. I also think it's accurate to say that Blood had a more advanced version of the engine than the other games... after all, they wrote their own versions of important engine functions in order to implement various things.

There's also a point to be made that Shadow Warrior and Blood were linked against newer versions of the Build engine library, which had the support for transparent floors and ceilings added specifically to enable things like ROR to be done on the game side. They literally run on a more advanced version of the engine that has features required for ROR. It's not that much of a misconception.

[Hendricks266]

TerminX, on 30 November 2016 - 04:12 PM, said:

I dunno, I think "EDuke32 engine" or the like is a fairly accurate description.

When it comes to source ports as opposed to the original games, agreed, but that's partly because we have morphed the game into something more like an engine.

TerminX, on 30 November 2016 - 04:12 PM, said:

I also think it's accurate to say that Blood had a more advanced version of the engine than the other games... after all, they wrote their own versions of important engine functions in order to implement various things.

Calling it an "advanced version" as such is a technicality, as it is not really a newer version of Build, it's a hacked, edited version. Noobs will not know the nuance of such a statement and will continue to think Ken made a newer build with ROR.

TerminX, on 30 November 2016 - 04:12 PM, said:

There's also a point to be made that Shadow Warrior and Blood were linked against newer versions of the Build engine library, which had the support for transparent floors and ceilings added specifically to enable things like ROR to be done on the game side. They literally run on a more advanced version of the engine that has features required for ROR. It's not that much of a misconception.

It is a misconception because the "advanced version" is not responsible for implementing the ROR. An update that removes one small obstacle to implementing it should not get the credit for the feature as a whole.

[TerminX]

Hendricks266, on 30 November 2016 - 04:20 PM, said:

It is a misconception because the "advanced version" is not responsible for implementing the ROR. An update that removes one small obstacle to implementing it should not get the credit for the feature as a whole.

It's not responsible for implementing the ROR, but the ROR is impossible without the engine modifications made explicitly to allow it. The technically correct answer is that those games used a newer version of the engine with added features that made it possible to implement ROR on the game side. It's not that far off from what the average guy probably thinks the situation is.