Is modding in Build anything like modding Doom?

[Szuran]

If I wanted to try making maps or weapons in Build, would it be similar to Doom? Do you also create maps by making sectors and changing ceiling/floor heights? In general, how much more complex is Build and would someone with relatively OK knowledge of Doom modding get into Build easy?

[Graf Zahl]

The fundamental concepts are similar - you also got sectors and walls - but sectors in Build work a little differently. A sector will always be closed and won't have multiple disjoint parts. Self referencing sectors do not exist. In Doom a sector is nothing more than a collection of properties, aside from that it has no defined shape - the shape is only determined by the subsectors (as a mapper you'll never see this, though) but in Build a sector defines its own shape - which means that all those sector hacks Doom modders are so fond of do not exist.

 

As for the rest, you should not forget that there is no such thing as "Build mapping". Since each game uses very different approaches to implement game logic, this also directly affects how things need to be done in the editor. Some are identical, some are different.

 

All that said, moving from Doom to Build is not that easy. For example, there is no good editor - it's still all primitive DOS-based tools running in a window.

So better forget about the editing comfort you are used to from things like DoomBuilder or Slade - Build editing tools are more than a decade behind and generally in a pathetic state from what I have seen so far.

 

With weapon or actor/monster modding things will get even more tricky. Duke Nukem (and the other games based on it) has its CON language. What Build had was definitely a giant leap ahead from what Doom originally provided, and still a lot more powerful than Dehacked, but it stands no comparison to what can be achieved with DECORATE or ZScript, not only in terms of available features but also in the language's syntax.

The other Build games have nothing user facing to offer, though.

 

Unfortunately the game shot itself in the foot by how it organizes its logic. It's poorly constructed and hard to maintain - and even harder to refactor into something more editing friendly. Blood is better in this regard, but it still suffers from not having had a source port available until earlier this year so it will take time for the modding situation to improve.

 

Ultimately, the problem with Build is not complexity - it's more like the engine's design has been standing in the way for the entire time these games have been available. Navigating this is more like an obstacle course.

 

 

[Szuran]

Thanks, that's exactly what I needed. I'm happy I've started with Doom and not Build. It's funny though how a new official Build game was made and no new Doom projects like Ion Fury are in the works, since Doom has the better toolset.

 

Also, are you familiar with Quake in the same way and could provide same insight as to going from Doom to Quake modding (including your own enemies etc. - is there an easy modelling and animation tool)?

[Graf Zahl]

1 hour ago, Szuran said:

Thanks, that's exactly what I needed. I'm happy I've started with Doom and not Build. It's funny though how a new official Build game was made and no new Doom projects like Ion Fury are in the works, since Doom has the better toolset.

 

It's not funny if you consider that the people behind the game are the developers of the EDuke32 port themselves. Of course they used their own engine for their game.

 

 

1 hour ago, Szuran said:

Also, are you familiar with Quake in the same way and could provide same insight as to going from Doom to Quake modding (including your own enemies etc. - is there an easy modelling and animation tool)?

 

Quake is an entirely different beast because it is true 3D. Editing has little in common with the older 2.5D technology. It was also one of the first games to come with a good scripting language for defining gameplay. So if you want to get inti that, prepare to learn QuakeC.

That's as far as I can help you here

[Szuran]

Thanks, I appreciate it.

[Gez]

Quake has some modern editors, notably one called Trenchbroom.

 

 

[Szuran]

So Quake has WADs as well?! :D

[andrewj]

13 minutes ago, Szuran said:

So Quake has WADs as well?!

The format is different from DOOM wads, and Quake only uses them to store some graphics, not for levels.

[Gez]

Half-Life, too.

http://www.gamers.org/dEngine/quake/spec/quake-spec34/qkspec_7.htm

http://hlbsp.sourceforge.net/index.php?content=waddef

 

[seed]

3 hours ago, Graf Zahl said:

The fundamental concepts are similar - you also got sectors and walls - but sectors in Build work a little differently. A sector will always be closed and won't have multiple disjoint parts. Self referencing sectors do not exist. In Doom a sector is nothing more than a collection of properties, aside from that it has no defined shape - the shape is only determined by the subsectors (as a mapper you'll never see this, though) but in Build a sector defines its own shape - which means that all those sector hacks Doom modders are so fond of do not exist.

 

As for the rest, you should not forget that there is no such thing as "Build mapping". Since each game uses very different approaches to implement game logic, this also directly affects how things need to be done in the editor. Some are identical, some are different.

 

All that said, moving from Doom to Build is not that easy. For example, there is no good editor - it's still all primitive DOS-based tools running in a window.

So better forget about the editing comfort you are used to from things like DoomBuilder or Slade - Build editing tools are more than a decade behind and generally in a pathetic state from what I have seen so far.

 

With weapon or actor/monster modding things will get even more tricky. Duke Nukem (and the other games based on it) has its CON language. What Build had was definitely a giant leap ahead from what Doom originally provided, and still a lot more powerful than Dehacked, but it stands no comparison to what can be achieved with DECORATE or ZScript, not only in terms of available features but also in the language's syntax.

The other Build games have nothing user facing to offer, though.

 

Unfortunately the game shot itself in the foot by how it organizes its logic. It's poorly constructed and hard to maintain - and even harder to refactor into something more editing friendly. Blood is better in this regard, but it still suffers from not having had a source port available until earlier this year so it will take time for the modding situation to improve.

 

BloodGDX was available for over a year or so, what this year saw was the first public release of NBlood.

 

On topic, yes, Graf is right here, "modding for Build" differs fundamentally from Doom, and certain aspects even vary between the Build engine games. Additionally, they also have tools that are ancient when compared to something like GZDB and Slade, not to mention they're far less user-friendly, and if I'm not mistaken, some of them are even required to be run through DOSBox in order to work (I think this was the case of Blood?) Now thankfully, since NBlood is somehow getting a map editor things will probably take a turn for the better, but that remains to be seen.

 

But, the lack of powerful modding tools are pretty much the main reason why Doom had (and still has) a far more active modding community than the Build engine games ever had.

[snapshot]

[deleted, someone already mentioned it]

Edited October 17, 2019 by tempdecal.wad

[Graf Zahl]

44 minutes ago, seed said:

Now thankfully, since NBlood is somehow getting a map editor things will probably take a turn for the better, but that remains to be seen.
 

 

Yes, the same map editor that's already available for EDuke32 with all the same problems and still looking like a DOS app run in a window. It won't improve matters much - most people who are modding Doom today will thankfully decline.

 

47 minutes ago, seed said:

BloodGDX was available for over a year or so, what this year saw was the first public release of NBlood.

 

Heh, I tend to forget that software that's written in Java even exists... >D

 

[Doom64hunter]

With CON you can at least still apply general programming knowledge to work with it.

 

With the map editor, have fun learning a few dozen keybinds by heart. (though that's probably more efficient than using a GUI in any case)

[Graf Zahl]

14 minutes ago, Doom64hunter said:

(though that's probably more efficient than using a GUI in any case)

 

Only for Unix/Linux users. I found the experience thoroughly unappealing, I do not like working with tools that have no user guidance whatsoever and assume that their users intricately know how things are to be done. I guess once you got used to it, things may be better - but to get there is the hard part where GUIs are helpful.

 

One funny thing about the Build editors is how tightly coupled they are with the game code - so tightly in fact that they have to be built from the same project. And I think that's why they don't have anything better - any aspiring Build editor writer first needs to master the engine itself - and that's no small feat.

I also think this is one of the reasons why the games themselves are somewhat stuck. In order to not break the editor they cannot randomly change code around.

 

 

[Master O]

2 hours ago, Szuran said:

So Quake has WADs as well?! :D

 

Quake's map files are called .bsp files.

 

BSP stands for Bit Space Partition.

[reflex17]

30 minutes ago, Master O said:

BSP stands for Bit Space Partition.

 

It stands for binary space partitioning.

 

1 hour ago, Graf Zahl said:

Yes, the same map editor that's already available for EDuke32 with all the same problems and still looking like a DOS app run in a window. It won't improve matters much - most people who are modding Doom today will thankfully decline.

 

 

It's not that bad, if I can make something like this then anyone can. 

 

Spoiler

 

[Master O]

1 hour ago, reflex17 said:

 

It stands for binary space partitioning.

 

 

 

It's not that bad, if I can make something like this then anyone can. 

 

 

Doh!  I meant to say binary.  Thanks for the correction.

[reflex17]

6 hours ago, Master O said:

Doh!  I meant to say binary.  Thanks for the correction.

 

 

No worries. By the way, don't tell anyone but the map that's in the screenshot I posted was actually corrupt, when opened in the editor. I don't know how because I haven't opened it in about 5 years, but it's still fully playable.

 

@Szuran This goes to show that Build is not the most stable engine, I've had some maps that got wrecked over the years because the editor glitches out and turns the level into a spider-web of lines and vertices. The worst part was Build only had a certain maximum grid/view size at the time, and if the engine glitched out and decided to toss vertices beyond the boundary limit, then the map was beyond repair. These glitches of course are few and far between, and if you build according to the rules of the engine and don't test the sector/line limits to the extreme, everything should work fine. Build has gone from Ken Silverman who was the original creator, to 3drealms, and then it was ported by user Jonof to modern systems. This port was further enhanced by user TerminiX and others into the Eduke32 port we have today. I am less familiar with any of the ports for Blood and Shadow Warrior.

 

The main thing Doom and Build have in common is that maps can be made using vanilla assets without additional files required by the map-maker. The file types associated with Doom and Duke3d are .wad and .map respectively. Both engines can do slopes, parallax and stretching/panning of textures. Both engines can now do sector stacking/portals to make 'true' 3d spaces. This is where the similarities start to end, however. Both engines have very similar line-tagging systems, but they handle sector effects in different ways. In Doom the effects are applied to a sector directly, whereas in Build, the engine requires function sprites to be placed in sectors to cause various actions, like doors, lifts, blinking lights etc. These sprites are invisible in-game, and their tags are applied to the sector to change sounds, speeds and timing of effects. In Build sctors can be tagged as well, and this is required, but most effects need the placement of these function sprites as well. The different effects are possible in both engines, just implemented differently.

 

Now on to modding: the Build engine uses .ART files to handle new textures and sprites, these are resource files that must be located in the root directory of the game in question. The art files are loaded into their own section after the game assets in the texture list automatically, so they don't overwrite the original artwork. Multiple files can be loaded in this way, TILES013.art - TILES020.art inclusive, for example. 

 

Game code in the Build engine is handled via .CON files. There are 3 of these files that the game uses at runtime -

 

DEFS.CON - contains the definitions to associate sounds, actors, etc.

USER.CON - has all the values for weapon damage, HP for objects and actors etc.

GAME.CON - this has the core game code, it's what the engine uses to compile everything when the game is started.

 

So, if the goal is new weapons and enemies, then .CON editing is what would handle that sort of thing. I've made maps and used new textures before, but I haven't done much .con file editing myself, so I can't be too much help in that regard.

 

Edited October 17, 2019 by reflex17

[Avoozl]

I attempted to make maps for Shadow Warrior but I never got anywhere, the Build editor seem so much more complicated than DB2.

[Graf Zahl]

51 minutes ago, reflex17 said:

Game code in the Build engine is handled via .CON files. There are 3 of these files that the game uses at runtime -

 

DEFS.CON - contains the definitions to associate sounds, actors, etc.

USER.CON - has all the values for weapon damage, HP for objects and actors etc.

GAME.CON - this has the core game code, it's what the engine uses to compile everything when the game is started.

 

 

Don't confuse the Build engine with the Duke Nukem game engine. CON files only exist in DN3D and the games being built on the same game engine. Neither Blood nor Shadow Warrior have CON files and neither have those more obscure games supported by Build GDX such as Witchaven or TekWar.

 

[reflex17]

22 minutes ago, Avoozl said:

I attempted to make maps for Shadow Warrior but I never got anywhere, the Build editor seem so much more complicated than DB2.

 

Yeah it's strange and counter-intuitive especially if you're used to Doom editors. Blood and SW added a lot of variables to the sprite tagging system and it was tough to find documentation of any kind.

 

11 minutes ago, Graf Zahl said:

Don't confuse the Build engine with the Duke Nukem game engine. CON files only exist in DN3D and the games being built on the same game engine. Neither Blood nor Shadow Warrior have CON files and neither have those more obscure games supported by Build GDX such as Witchaven or TekWar.

 

Ah yes, maybe I wasn't as clear as I should've been. I've tinkered with Blood and SW maps but only ever spent large amounts of time working on Duke3d stuff.

[Szuran]

7 hours ago, reflex17 said:

 

 

So, if the goal is new weapons and enemies, then .CON editing is what would handle that sort of thing. I've made maps and used new textures before, but I haven't done much .con file editing myself, so I can't be too much help in that regard.

 

 

That's great to know, though, thanks. Build sounds rather convoluted and I'd rather master Doom building first in this case.

[AndrewB]

If you were to ask the question 20 years ago, the answer would be that BUILD is marginally easier to mod than Doom.

 

These days, it's probably pretty close.

[Graf Zahl]

Even 20 years ago Build didn't have a reputation of being easily moddable. The obstacles were pretty much the same as now, and even the first generation Doom editors had a better user interface than the Build editor.

[reflex17]

Blood and Shadow Warrior were a little tougher to edit, but the obstacles were fewer at the initial launch of Duke3d. There were tools available to palettize textures for the Build engine, and the game launched with a program to convert wads into Duke maps. I myself converted map01 of Doom2, but of course being different engines, the Doom levels were a larger scale in relative proportion after being changed, so it felt kind of odd.

 

Example maps were also included on the CD which showed the effects possible in the game, and there was also a "zoo" map that showed the examples in practice. Text files also listed all tags in the game and the associated effects, and there were basic breakdowns of starter con file editing.

 

The following is a history of Duke3d source ports from Wikipedia, for anyone interested:

 

Spoiler

Following the release of the Doom source code in 1997, gamers wanted a similar source code release from 3D Realms. The last major game to make use of the Duke Nukem 3D source code was TNT Team's World War II GI in 1999. Its programmer, Matthew Saettler, obtained permission from 3D Realms to expand the gameplay enhancements done on WWII GI to Duke Nukem 3D.

 

EDuke was a semi-official branch of Duke Nukem 3D that was released as a patch as Duke Nukem 3D v2.0 for Atomic Edition users on July 28, 2000. It included a demo mod made by several beta testers. It focused primarily on enhancing the CON scripting language in ways which allowed those modifying the game to do much more with the system than originally possible. Though a further version was planned, it never made it out of beta. It was eventually cancelled due to programmer time constraints. About a month after the release of the Duke Nukem 3D source code, Blood project manager Matt Saettler released the source code for both EDuke v2.0 and EDuke v2.1, the test version of which would have eventually become the next EDuke release, under the GPL.

 

The source code to the Duke Nukem 3D v1.5 executable, which uses the Build engine, was released as free software under the GPL on April 1, 2003. The game content remains under a proprietary license. The game was quickly ported by enthusiasts to modern operating systems.

The first Duke Nukem 3D port was from icculus.org. It is a cross-platform project that allows the game to be played on AmigaOS, AmigaOS 4, AROS, BeOS, FreeBSD, Linux, Mac OS X, MorphOS, Solaris, and Windows rather than MS-DOS. The icculus.org codebase would later be used as the base for several other ports, including Duke3d_32.

 

Another popular early project was Jonathon Fowler's JFDuke3D, which, in December 2003, received backing from the original author of Build, programmer Ken Silverman. Fowler, in cooperation with Silverman, released a new version of JFDuke3D using Polymost, an OpenGL-enhanced renderer for Build which allows hardware acceleration and 3D model support along with 32-bit color high resolution textures. Another project based on JFDuke3D called xDuke, unrelated to the xDuke project based on Duke3d_w32, runs on the Xbox. Silverman has since helped Fowler with a large portion of other engine work, including updating the network code, and helping to maintain various other aspects of the engine. Development appears to have stopped; as of January 2015, there have been no new versions since October 9, 2005.

 

While a few short-lived DOS-based EDuke projects emerged, it was not until the release of EDuke32, an extended version of Duke3D incorporating variants of both Fowler's Microsoft Windows JFDuke3D code, and Saettler's EDuke code, by one of 3D Realms' forum moderators in late 2004, that EDuke's scripting extensions received community focus. Among the various enhancements, support for advanced shader model 3.0 based graphics was added to EDuke32 during late 2008-early 2009. In June 2008, thanks to significant porting contributions from the DOSBox team, EDuke32 became the only Duke Nukem 3D source port to compile and run natively on 64-bit Linux systems without the use of a 32-bit compatibility environment.

 

On April 1, 2009, an OpenGL Shader Model 3.0 renderer was revealed to have been developed for EDuke32, named Polymer to distinguish from Ken Silverman's Polymost. It allows for much more modern effects such as dynamic lighting and normal mapping. Although Polymer is fully functional, it is technically incomplete and unoptimized, and is still in development. As of the fifth installment of the High Resolution Pack, released in 2011, the Polymer renderer is mandatory. In 2011, another significant development of EDuke32 was the introduction of true room over room (TROR), where sectors can be placed over other sectors, and can be seen at the same time. In practice, this allows for true three-dimensional level design that was previously impossible, although the base engine is still 2D.

 

On December 18, 2012, Chocolate Duke3D port was released. Inspired by Chocolate Doom, the primary goal was to refactor the code so developers would easily read and learn from it.

 

In February 2013, a source code review article was published that described the internal working of the code.