[Jan Satcitananda]

Hello guys. As some of you might know, I'm working on a retro-3D game engine inspired by old Doom, Build and Unreal engines. The engine is sector-based like Build, but envisioned to have a slew of exciting features like multiple reflections, stacked walls, dynamic ligthing, all done in software to keep the authentic look and potentially free the GPU for other important tasks.

Some recent screenshots for introduction:


At this point, the engine can flawlessly import Build engine artwork and maps. But the results are totally static and unplayable, you can just fly around the levels the way similar to Mapster32 and enjoy the new effects, and nothing interactive beside basic editing functions made for testing. The idea is to recreate (reverse-engineer) Duke3D original gameplay inside my tech. It won't be a strict replication of original physics and object behavior, but one should be able to play all original levels normally. So far I'm having certain questions to Duke3D community. First of all, can (and how can) this be done and published as a commercial product? The rights on the engine itself should remain on my side. Also can I find any investors so I could do the necessary work? I'm noob at things like crowdfunding etc.

[Phredreeke]

Jan Satcitananda, on 19 August 2018 - 02:29 PM, said:

First of all, can (and how can) this be done and published as a commercial product? The rights on the engine itself should remain on my side. Also can I find any investors so I could do the necessary work? I'm noob at things like crowdfunding etc.

Nope.

[MusicallyInspired]

Build 3?

[Jan Satcitananda]

MusicallyInspired, on 19 August 2018 - 06:49 PM, said:

Build 3?

The engine itself is called Brahma and framework underneath is NipSys64 (which can run 2D games and applications too). And no, they are not based on Build.

[Phredreeke]

Seems like a lot of effort to recreate a game that already has a quality source port.

That said, unless you have the blessing of the rightsholders (in this case Gearbox) you can't make a commercial project.

You're probably safe as a free project as long as your require users to supply their own DUKE3D.GRP to extract the game's resources. And you can still use your engine for commercial purposes not involving the Duke IP. IANAL though.

[MusicallyInspired]

The engine intrigues me for sure. Would love to play around with it. Build 2 was fun, but lacking any sort of saving ability mucks up your motivation somewhat.

[Micky C]

Phredreeke, on 20 August 2018 - 02:28 AM, said:

Seems like a lot of effort to recreate a game that already has a quality source port

From his discussion elsewhere, he’s been wanting to work on his own game using this new engine. The potential for a new Duke port out of it is a side bonus, even if it isn’t 100% authentic or compatible with more advanced mods.

Those effects do look impressive. Is it just me or is the grass 3D?

[MusicallyInspired]

Parallax?

[Hendricks266]

Jan Satcitananda, on 19 August 2018 - 02:29 PM, said:

Hello guys. As some of you might know, I'm working on a retro-3D game engine inspired by old Doom, Build and Unreal engines. The engine is sector-based like Build, but envisioned to have a slew of exciting features like multiple reflections, stacked walls, dynamic ligthing,

Cool.

Jan Satcitananda, on 19 August 2018 - 02:29 PM, said:

all done in software to keep the authentic look and potentially free the GPU for other important tasks.

It's not the Graphics Processing Unit's job to handle graphics?????

Jan Satcitananda, on 19 August 2018 - 02:29 PM, said:

The idea is to recreate (reverse-engineer) Duke3D original gameplay inside my tech. It won't be a strict replication of original physics and object behavior, but one should be able to play all original levels normally.

Using Duke 3D's name to attract attention to something that is not Duke 3D is poseury.

Jan Satcitananda, on 19 August 2018 - 02:29 PM, said:

First of all, can (and how can) this be done and published as a commercial product?

Absolutely not. You cannot sell someone else's game. At most you could sell your engine and require the user to bring their own copy of the game. If you use any of Duke 3D's code then you would need to comply with the GPL, which would neuter your revenue stream.

[Phredreeke]

Yeah, the way I see it he has two options
-Use Duke3D code, which means he has to make his engine GPL
-Rewrite the entire Duke3D game logic from scratch (hence my comment that it'd be a lot of work for something that already has a quality source port)

IMO, if you're gonna spend the effort recreating a game, pick a game that doesn't already have a port (for example LucasArt's Outlaws or 3DO's Killing Time)

[Jan Satcitananda]

Thank you guys for the comments. I was just wondering if Duke 3D copyright holders show any interest in reinterpreting the game on my engine with new fancy effects and refined gameplay.

The grass is a voxel heightmap btw. The engine will make extensive use of them.

[Phredreeke]

They did their own re-release of the game just two years ago.

Given that you're doing a lot of features in software, what framerates do you get? (also what's your CPU?)

[MrFlibble]

I suggest create your own game. Take inspiration from Duke3D and other titles from the same era, but do your own twist.

You can use free assets (textures, sprites, sounds etc.) that are available online, if only as placeholders. Freedoom could be a nice place to start, also OpenGameArt.

[Mike Norvak]

MrFlibble, on 21 August 2018 - 03:10 AM, said:

I suggest create your own game. Take inspiration from Duke3D and other titles from the same era, but do your own twist.

X2.

You have much much more possibilities to make a game from start to finish than waiting Gearbox to give you license to release an updated version of a game that has been already released countless times.

I'd suggest starting with something simple very simple, story and gameplay wise: player just can move, croach, jump and shoot, not third person perspective, 2-3 weapons, 2-3 enemies, 2-3 short maps, simplistic art, no items, no hud, few tiles, creative commons sounds, and that's all. Maybe a child is trying to find his teddy bear while hiding from monsters at night, maybe the player is a tank that needs to defeat buildings. I mean what I'd do is take a minimalistic approach.

Don't take the overarching aproach, trying to do a groundbreaking retro indie game, with one hundred weapons and jawdropping enemies, don't make that mistake! You don't even need to crowdfund, you have created your own engine! you can release some minigames taking advantage of what you already know how to do, while improving the engine and adding new features, that way you can test what works and what doesn't, hear people opinions, and come up with new ideas, before you make the crowdfunding step. You can even sell those mini games or ask for donations.

Perhaps I'm saying the obvious but you have an awesome project in your hands, I'm just throwing some opinions.

[Jan Satcitananda]

Mike Norvak, on 21 August 2018 - 07:49 AM, said:

I'd suggest starting with something simple very simple, story and gameplay wise: player just can move, croach, jump and shoot, not third person perspective, 2-3 weapons, 2-3 enemies, 2-3 short maps, simplistic art, no items, no hud, few tiles, creative commons sounds, and that's all. Maybe a child is trying to find his teddy bear while hiding from monsters at night, maybe the player is a tank that needs to defeat buildings. I mean what I'd do is take a minimalistic approach.

Yup, I'll keep it an indie work. Actually I'm going to create a simple playable tech demo to attract more attention to the project, and then gather a team to complete work with my LNGA startup.

[Zaxx]

Jan Satcitananda, on 19 August 2018 - 02:29 PM, said:

all done in software to keep the authentic look and potentially free the GPU for other important tasks.

But... why? Software rendering is usually a lot slower these days if the engine is not using every single drop of CPU power through multi threading.

[MusicallyInspired]

Ken did this with Build 2 as well. I don't get it. He said his reason was because he didn't liked dealing with OpenGL code or something.

[Phredreeke]

Yeah, I don't see what advantage software rendering would bring, and it would hold back potential performance a lot.

[Jan Satcitananda]

Zaxx, on 22 August 2018 - 03:49 PM, said:

But... why? Software rendering is usually a lot slower these days if the engine is not using every single drop of CPU power through multi threading.

Potential speed gain doesn't really matter. My goal is not to replicate what already exists in other engines. My engine already supports some form of multithreading and can handle pretty heavy effects, some of which can be adequately done only in software (or using indexed color palette). My goal is to have stable 120 fps on 1920x1080 resolution throughout the game with no stuttering. I've noticed that many games suffer from stuttering when the engine attempts to load some assets on the fly, or having excessive loading times, when you have to wait a minute or so just to load your game. My guess it that too many steps are done to load every little asset. My engine runs instantly, loads precompiled resources in a matter of seconds, and you're already in game. Instant load/save, smooth play even if you introduce a 32768x32768 megatexture and lots of mirrors everywhere.

Eventually later versions of the engine might get OpenGL support, but what defines the engine's personality lies inside the software. Now I'm doing a reasonably fast prototype, the next version will be a native 6-DOF renderer with realtime compiled self-modifying code.

[Zaxx]

Jan Satcitananda, on 22 August 2018 - 07:58 PM, said:

Potential speed gain doesn't really matter. My goal is not to replicate what already exists in other engines. My engine already supports some form of multithreading and can handle pretty heavy effects, some of which can be adequately done only in software (or using indexed color palette). My goal is to have stable 120 fps on 1920x1080 resolution throughout the game with no stuttering. I've noticed that many games suffer from stuttering when the engine attempts to load some assets on the fly, or having excessive loading times, when you have to wait a minute or so just to load your game. My guess it that too many steps are done to load every little asset. My engine runs instantly, loads precompiled resources in a matter of seconds, and you're already in game. Instant load/save, smooth play even if you introduce a 32768x32768 megatexture and lots of mirrors everywhere.

Eventually later versions of the engine might get OpenGL support, but what defines the engine's personality lies inside the software. Now I'm doing a reasonably fast prototype, the next version will be a native 6-DOF renderer with realtime compiled self-modifying code.

I see, it's just that when I search for reasons on why such an old school engine could be awesome today I always come to the conclusion that it's because you can put a lot on stuff on screen if it's properly optimized. I mean nowadays CPUs are strong enough that a good, multi-threaded engine that focuses on lowering the CPU's load as much as possible when it comes to rendering could run infamous stuff like this smoothly:

(Btw. I'm really curious to see how Serious Sam 4 will handle the 50 000 - 100 000 enemies on screen Croteam is promising )

And when it comes to the gaming industry it seems like that modern games focus on the GPU handling as many of the complex stuff as possible: you see GPU-physics, GPU particles and whatnot, all the stuff that was handled by the CPU a decade ago. But it's great that you're focusing on multi threading because as far as I know even the more advanced source ports of classic engines like GZDoom or Eduke32 rely on just the one core.

[Phredreeke]

What effects are you doing on the CPU that you can't do on programmable pixel shaders?

[Mark]

I read Jan's post about instantly loading pre-compiled resources. Does that mean all maps have to be pre-compiled too. I remember not being too thrilled from a modding standpoint when ICD mentioned that for his NG renderer. After every little change made during a map's creation the map would have to be re-compiled before testing.

[Jan Satcitananda]

Phredreeke, on 23 August 2018 - 02:34 AM, said:

What effects are you doing on the CPU that you can't do on programmable pixel shaders?

Heightmapping is an example that would be extremely cumbersome if done with shaders. Also I'm not an expert in shader programming, so I just do what I can do with software.

Mark., on 23 August 2018 - 07:19 AM, said:

I read Jan's post about instantly loading pre-compiled resources. Does that mean all maps have to be pre-compiled too. I remember not being too thrilled from a modding standpoint when ICD mentioned that for his NG renderer. After every little change made during a map's creation the map would have to be re-compiled before testing.

My BHM map format is editable pretty much the same way the Build maps can be edited, because the engine is sector-based, not BSP nor other shit. Just the game resources are aggregated so that every sound/image file can hold any number of items, what is handy and reduces loading times considerably.

[Mark]

+1

[Jimmy]

Pretty sick engine, interested to see further development.

[icecoldduke]

Jan Satcitananda, on 19 August 2018 - 02:29 PM, said:

All done in software to keep the authentic look and potentially free the GPU for other important tasks.

Doing raycasting/triangle fill/raytracing on the CPU(for graphics purposes) is just silly and is a waste of your time, your not looking forward to the future, and are holding on to graphics development practices of the past.

Looking to the future, especially on RTX Turing, graphics work is going to be a lot more complicated then just doing a simple raycaster and saying "oooh I have something". Aside from all the obvious things your missing out on(programmable shaders and such), graphics work is going to involve things like neural networks, which Volta's dedicated hardware units called Tensor Cores, that are going to be in Turning, crunch neural networks a fuck ton faster then the CPU ever will. That's just the tip of the iceberg.

I really do like your enthusiasm, and I think you might be able to be useful as a graphics developer if you open your eyes a bit , but your useless if you continue development on old ideas.

[Phredreeke]

I'm thinking, what happens when you want to move to 4K? what happens when you got a few dozen monsters on screen?

[Altered Reality]

Phredreeke, on 09 September 2018 - 08:56 PM, said:

I'm thinking, what happens when you want to move to 4K? what happens when you got a few dozen monsters on screen?

Maybe he's following the MAME philosophy: "Don't bother solving slowdowns on current hardware, because in the future, CPUs will be faster."

[icecoldduke]

Zaxx, on 23 August 2018 - 01:24 AM, said:

And when it comes to the gaming industry it seems like that modern games focus on the GPU handling as many of the complex stuff as possible: you see GPU-physics, GPU particles and whatnot, all the stuff that was handled by the CPU a decade ago. But it's great that you're focusing on multi threading because as far as I know even the more advanced source ports of classic engines like GZDoom or Eduke32 rely on just the one core.

My PolymerNG work was multithreaded. I had the game running on one core and the engine running on another core. That's how most engine's work, while the game is doing work, the render thread is building up command buffers and submitting all that stuff to the GPU. Multithreading the "software renderer" would be a waste of time. The "Software Renderer" would be benefit from parallelization, but not on the CPU. As it turns out the GPU can run a lot more work in parallel then the CPU ever could(in terms of vector math processing), so you could easily get a huge speed up by moving the "software renderer" over to GPU compute.

[Jan Satcitananda]

Phredreeke, on 09 September 2018 - 08:56 PM, said:

I'm thinking, what happens when you want to move to 4K? what happens when you got a few dozen monsters on screen?

In multithreaded mode, it will handle everything smoothly. Also there's "realtime adaptive detail" feature that will automatically adjust visual quality based on rendering time so the game will never slow down and you'll see perfectly stable framerate. My goal is to develop a technology from scratch that is internally unique down to pixel level, not relying on specific hardware. There's a lot of GPU-powered engines, all of them look pretty much the same using polygon meshes, BSP and bilinear texture filters. This is not what I want. I want a powerful but nonconventional engine that I fully understand. Perhaps, mine will use GPU for physics or AI.

Just added KVX support to my engine. After I complete the voxel drawing procedure (again done from scratch, not based on Build source code), I'm going to introduce my own voxel format supporting large sizes and transparency, as well as dynamic lighting-ready.