It's an obsession with optimization, one of these engines has to be easy enough to make a game with. 

300-400 MHz CPU. Are you planning to port it to old consoles like the PS2 or the GameCube?

Even smartphones have higher clock speeds nowadays.

The one that's easiest to work with is the one that you'll spend the less time learning. You will be more productive with an old engine that you know inside out than with a modern engine that you know nothing about. Always factor the learning time into the work time. 

I know nothing about any of these engines, so I mean, it's a bit of a crapshoot here.

No plans to port, the idea is for it to run on old PC hardware, maybe even DOS. 

Why running it on old PCs? 

Someone suggested UE4 can actually be hugely optimized but I'm not sure I buy it. To the point that it would be able to go down to that level 

Does dos support any 3D APIs? If not you will be stuck using a software renderer, and no other windows functions, this might rule out all of your proposed engines. (Does mark v have a dos port?) 

It does, people ported Quake II to DOS and I love the software renderer so it doesn't matter, you can also add colored lighting to Quake II's software renderer if you're so inclined, there's qbism super8 which has a DOS port so you can have colored lighting and palette switching in DOS, which is really cool.

I've decided against the Quake I engine because QuakeC, and having people be able to mod what you make sounds good so I'm not too big on the Half-Life engine, which leaves it between Cube 2 and Quake II, I know nothing about Cube 2's engine. 

Cube 2 is OpenGL only. No software renderer. 

https://ioquake3.org 

sysreq too high, with no clear benefit over the Quake II engine, so it's just that.

Why use ioquake? I saw nothing in Quake III I needed, I don't need shaders, Yamagi Quake II already includes support for upgraded audio, is it somehow easier to develop games with while still maintaining comparable system requirements? 

Quake II, Half-Life, Sauerbraten have game logic in DLLs. C/C++ in a development experience required. Debugging DLLs is harder than even ordinary C/C++ coding.

If someone isn't regularly using C/C++ already, it would be 2 years before scaling up to be comfortable with all the hidden rules of C/C++.

For some, the significance of the above does not sink in immediately.

Usually that happens later when someone gets their hands dirty and starting trying something ...

Only then will they have that soul-killing "Oh ..." moment. 

Well I haven't used C before, so that might be something to convince me not too.

Why is debugging DLLs more difficult than ordinary C/C++ coding?

Would coding for Quake III be easier? 

To test an external DLL used by an engine is like testing a program on top of a program, you may need to learn about call conventions or fight a development environment to get it setup.

The project files for some of those engines are going to be meant for ancient Visual Studio, Visual Studio has been updated many times since then. You'd have to convert the project, the conversion might go fine but I wouldn't expect it too. Someone with a lot of C experience could deal with conversion problems, they often aren't fun even if you do have C experience.

You might consider Unity or some actually supported engine with great tutorials for those starting and a nice choice of video tutorials.

Or if you want to use Quake or Quake 2, start with mapping and go from there ... mapping can really give some people insight into what is going on in the game. It can be a lot of fun.

/One line of thinking ... 

I wouldn't recommend idTech engines to anyone who isn't a modder with several years of experience in them.

Engines like Unity are specifically targeted to newbies. They've got tons of features and huge development communities.

Quake evolved a lot, specially in the mapping aspect, but it's still too primitive. Quake's MDL model format sucks. Q2's MD2 format still sucks. Q3A's MD3 format is fine, but Q3A doesn't have a software renderer and therefore won't run in DOS.

You've cornered yourself into using the Quake 2 engine. 

Would it be possible to make the game in another engine and make sure the game logic was as abstracted as possible from the rest of the code, the audio and rendering stuff, etc. Is there any chance I could do that and port it to another engine later? Obviously not taking advantage of Unreal specific elements, no fancy modern Unreal lighting, etc. Unreal is just C++ at its core right? 

I'm still waiting for an oldschool shooter that would work on oldschool hardware.

Tested Ion Maiden (it's built on Build engine) – don't work on P III Win XP :-P. 

Would it be possible to make the game in another engine and make sure the game logic was as abstracted as possible

Only if your game logic is so simplistic that it sucks.

Different game engines have different physics, for example. Modern engines (including FTE) have more standard physics solutions such as Bullet. But physics are only one of the subsystems that will define your gamecode. The whole picture is even worse.

I strongly suggest that you read some detailed articles on the development of Daikatana and Duke Nukem Forever. 

Tested Ion Maiden (it's built on Build engine) – don't work on P III Win XP :-P.

Did you use its software renderer? Was it too slow, or didn't work at all? 

Ion Maiden should at least be open source, they've said they could easily make a 32-bit executable if they wanted, which they should do so the game can work on Win98 and stuff. 

Ion Maiden
Copyright © 2018 Voidpoint, LLC.
All Rights Reserved.

Build Engine used under commercial license.

Ion Maiden uses open source EDuke32 technology. The following terms apply only to the Ion Maiden game executable:
Engine code available under the Build License. See buildlic.txt.
Game code and supporting libraries available under the GNU GPL v2 with a linking exception for the Build Engine. See gpl-2.0.txt.

And

The DOS engine source and Polymost belong to Ken. Subsequent modifications belong to JonoF and Voidpoint. You can talk to us and we'll handle the legwork.

3D Realms is not a party at all.

Source 

there were no 400mhz dos machines 

Maybe the engine isn't such a big decision.

Maybe you get started and then find out you have don't have the talent for making an interesting game or you find out you don't have the chops to do game logic.

Whether C/C++ or QuakeC or .NET or some other language, all games require some form of coding and some form of mapping. You code in one, you'll be able to apply much of it to a different language. Same for mapping.

The difference between doers and daydreamers is that the doers get started.

The daydreamers always find a trivial imaginary obstacle that stops them from getting started so they can continue to indulge in fantasy without the risk of failure.

But it is the risk of failure that makes completing anything or leveling up satisfying. 

Does dos support any 3D APIs?

3dfx Glide, and Mesa OpenGL using Glide are the only available ones. Using Mesa, we were able to run Q1, Q2, and Sin on pure Dos in 3D-accelerated mode.