Basically structure is the same, but I'm afraid Hexen2 has a modified version of Quake engine. You can't just load it as a mod, but it should be easy to convert it.
Anyway what's the point of doing this? :) 

I think I need to stop doing re-makes! :P 

I imagine that there is a metric arseload of little things that add up to it being a lot of work.

Off the top of my head, one big difference is that H2 is hub-based, like Quake 2, and getting all that persistant-state-across-multiple-maps stuff working in Quake would be a ballache.

Another thing is that I believe H2's entity thinks happen 20 times a second, rather than Quake's 10. That's gonna cause issues I imagine. 

Hexen 2 has a lot of extra gamecode using extra engine builtins. It would be a large project needing a lot of programming from different people.

I have an unfinished Hexen 2 map that got shelved because it broke the extremely low clipnodes limit. It wasn't clear to me while mapping that H2 has a much lower limit than Quake. When I learned the reason for the problem, I lost interest in continuing because what's the point if the map can only be 1/4th the size of a Quake map. There is the hub system but that still is very limiting.

Eric's tools and Spike's engine now support BSP2 for Hexen 2, which makes it theoretically possible to continue, but tbh I don't want to rely on FTEQW exclusively for this. If Hammer of Thyrion got BSP2 support, then maybe. But when I spoke to Ozkan Sezer about BSP2 a few years back, he didn't exactly seem thrilled by the idea.

There is also little interest in Hexen 2 maps. I've also seen a lot of dislike for the H2 monster lineup, and that's partly understandable - the skull wizard seems everyone's favourite but archer knights are really pretty boring. And I'm not a fan of the Aztec and Egyptian stuff myself. And the key items are hardcoded IIRC so it's not trivial to make your own unless you want to hack the gamecode.

There's also no good editor for Hexen 2. It's possible to use Radiant but you have to manually convert the .map files. and IIRC there is no real .def file. Divining the entity names and keys from 20 year old internet pages or from the code is annoying.

I don't think porting the entire Hexen 2 to the Quake engine would be a worthwhile project. It would be a giant pointless slog. Also some of the interesting monsters are in the expansion, so you'd have to port even more.

Not to mention legal issues of course. Similar problems to porting entire chunks of Doom etc. to a Quake mod. While no one might immediately sue you, it's still not exactly clean. 

You can't just load it as a mod, but it should be easy to convert it.

I didn't think it would work OOTB but it's encouraging that you think it might be easy/possible to convert it.

Anyway what's the point of doing this? :)

Fun! Hexen 2 (much like Heretic and Hexen before it) always felt to me like some great ideas, themes, and possibilities, hampered by reality, deadlines, and in H2's case, a really boring-looking first hub that puts off people before they've even started. But there are a lot of gameplay elements, combinations thereof might be fun to explore in more depth.

Off the top of my head, one big difference is that H2 is hub-based, like Quake 2, and getting all that persistant-state-across-multiple-maps stuff working in Quake would be a ballache.

I've no idea how H2 implemented hubs, but if it happened to be not-incompatible with the normal quake way of doing things, that might even be a nice engine feature for quake mappers.

On a related note, do quake engine maintainers simply resist adding features, or is there any coordination for how feature support works across engines? The situation in the Doom community (I'm more familiar with) is a mess.

Another thing is that I believe H2's entity thinks happen 20 times a second, rather than Quake's 10. That's gonna cause issues I imagine.

If you're right then yes, that could be a problem. 

Despite differences in the quake engine such as string processing, destructible brushes, game menu with different options, etc. I don't think the other minor things would be much impediment. HUD can be done with CSQC and graphics can be modded as desired. One thing that could be a concern though would be hub levels with data persistence.
But is this all really worth the trouble of implementing?

As for the mapping to H2 subject, it's not hard at all. Use trenchbroom(v2) + compiling tools at http://uhexen2.sourceforge.net.
Build your map, compile and run. And if you're using FTE, there are a lot of other stuff you can use to speed up your dev process. 

cutting off all the extra stuff Quake engine doesn't have...
Would be like making a strife mod for doom engine. Limited but fun nevertheless. 

Trenchbroom 2 has H2 support now? That's good news. Stupidly low limits, hardcoded stuff and lackluster monster lineup are still an issue for H2 mapping though. 

 

 

To be honest, this is a massive amount of work for a project that is technically illegal to do anyway.

However, the idea of making a robust system for having a persistant game-state that transcends map changes - for quake - has been very high on my wishlist for a while, and is currently motivating my push to finally do some big-boy programming, so that I can get that shizzle up and running for my purposes, if no-one beats me to it.

(caveat - as with anything I say I might be working on, don't hold your breath). 

How hard would it be to modify HoT qbsp's bsp output format? I would need to know bsp and bsp2 limits and format specs so i could try something... 

FTE supports the Hexen 2 hub system, so that could perhaps be ported.

/waits for Spike to chime in 

don't hit me, but RemakeQuake contains two testmaps (with source) that demonstrate working hub system in Quake with persistent entities etc. Thanks to Spike IIRC

http://svn.icculus.org/remakequake?view=rev&revision=3807 

Cheers, I might have a gander at the sauce when I get time. 

TB2, which is currently in closed Alpha with a public Beta imminent, supports Hexen 2. 

regarding bsp2, its fairly simple really, just change the 4-byte magic, then change all the shorts to either 32bit ints or floats (depending on whether they're indexes or coords).
doing it in such a way that you do not break bsp29 is the challenge.
you'll probably also need to increase some of the bsp limits, if they're still hardcoded somewhere.

Its also worth noting that ericw's qbsp can compile either quake or hexen2 format .maps as hexen2 bsps. this means that you can map for hexen2 in any quake map editor you want (ignoring possible palette issues, and easy ent definitions).

Regarding porting hexen2 to quake, ignoring the legal issues, I'm not sure that there's much point.
Practically speaking, most nq engines are basically crippleware. In order to get hexen2 working, you'd still need a load of extensions - starting with tracebox. You'd also need lots of particle stuff too, and yes, a hud.
Realistically the only new engine that it'd run okay on would be DP, and even then all the things you'd have changed (like particles and the hub system) would result in it just feeling wrong.
It might be an interesting undertaking for someone, but I don't see it as a practical one as it'll probably always feel a bit crippled.

The issues I can think of, in no particular order(and with hints on what fte can cushion), are header(which is what enables the h2 builtins+writebytes), extra builtins(yay for extensions - you might need to use builtin number 0 in the interim), extra networked fields (drawflags, with its abslight and scale origins being the most annoying), the whole writebyte nightmare (sv_csqcdebug 1 should help diagnose stuff a little), particle effects (good luck getting those looking faithful without engine code), the hud (yay csqc!), you'll need to reskin player models or just ditch colormaps entirely too, the mission pack adds a new mdl format too. 

I was wondering how neat it would be if people were interested in a doing the odd Hexen 2 level.

This is going to be a huge uphill battle because of several factors; Engine, editor, compiler, mapping talent and eventually audience!

At the root of any flourishing game community is coders; they essentially extend the (existing) engine limits and compiler tools. On this front you have spike with the FTE engine and eric with his compiler toolset. You can certainly compile a map and run it with FTE and Hexen2 resources, the issue I see with making H2 maps is that the original engine limits are just not fun to work with anymore and seriously need to be upgraded and modernized!

I am sure you can certainly create a map with plenty of different editors but the technical hurdle is the def/fgd entity file. This is the real nuts and bolts of how a map is created, without one there is no easy map creation process. Someone would have to create/find and validate an entity file. This can involve a crazy amount of work, especially as it requires a good knowledge of how the entity actually works in engine.

Who plays H2 anymore? Is there really an audience for this? No one wants to spend hours, days or weeks making something and then find no one is going to play it and give feedback!

The final issue is you need level designers that are going to push the original game design in interesting directions. There needs to be designers with proper experience of what H2 does and a good idea of what it does not do. There is no point in just creating generic H2 maps which mirror content that already exists in the game. You will ultimately want level design that is fresh and different and sits well within the existing game world. That kind of knowledge and understanding takes time to discover. 

Thanks all for a really interesting discussion. One point I wanted to pick up on

> To be honest, this is a massive amount of work for a project that is technically illegal to do anyway.

I'm not sure where the concern about legality comes in. Unless I'm mistaken, the only bits of hexen2 not released under the GPL are the asset (pak0.pak contents) and the soundtrack (redbook audio); the engine is GPL2 and the progs.dat sources were released that way too. So there's no impediment to mixing those h2 bits and quake engine sources. The problem is if one needed to modify the hexen2 assets in any way as part of this hypothetical cut-and-shut job. But enlighten me if I'm missing a nuance. 

I'm pretty sure that Hexen 2 has a proper source port so I don't think you'll run into engine limits and stuff. If I remember rightly Hexen 2 did have a lot of harsh limits and that's why the levels are carved up into smaller chunks than usual. 

They are because H2 uses a lot more clipping hulls right? 

Not sure exactly what it was but I thought it was linked to entities or something? But the maps being chopped up and hub based was a work-around I believe. 

aye, hexen2 has 5 hulls using clipnodes instead of 2, so you burn through them much faster.

its actually possible to get fte to accept maps with no clipnodes at all (brush collisions!), but bsp2 is more mainstream, albeit less awesome. 

I just wonder why not use uHexen2 or other Hexen engine? 

You can get the update version HeXeN II from

http://HeXeNWorld.org