How about porting Duke 3D to my new engine? "Make Duke levels playable in a game powered by my Brahma engine"
#1 Posted 19 August 2018 - 02:29 PM
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.
#2 Posted 19 August 2018 - 03:49 PM
Jan Satcitananda, on 19 August 2018 - 02:29 PM, said:
Nope.
#4 Posted 19 August 2018 - 09:55 PM
MusicallyInspired, on 19 August 2018 - 06:49 PM, said:
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.
This post has been edited by Jan Satcitananda: 19 August 2018 - 09:57 PM
#5 Posted 20 August 2018 - 02:28 AM
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.
#6 Posted 20 August 2018 - 05:04 AM
#7 Posted 20 August 2018 - 05:55 AM
Phredreeke, on 20 August 2018 - 02:28 AM, said:
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?
This post has been edited by Micky C: 20 August 2018 - 05:58 AM
#9 Posted 20 August 2018 - 09:18 AM
Jan Satcitananda, on 19 August 2018 - 02:29 PM, said:
Cool.
Jan Satcitananda, on 19 August 2018 - 02:29 PM, said:
It's not the Graphics Processing Unit's job to handle graphics?????
Jan Satcitananda, on 19 August 2018 - 02:29 PM, said:
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:
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.
#10 Posted 20 August 2018 - 09:51 AM
-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)
This post has been edited by Phredreeke: 20 August 2018 - 09:54 AM
#11 Posted 20 August 2018 - 12:40 PM
The grass is a voxel heightmap btw. The engine will make extensive use of them.
#12 Posted 20 August 2018 - 03:07 PM
Given that you're doing a lot of features in software, what framerates do you get? (also what's your CPU?)
#13 Posted 21 August 2018 - 03:10 AM
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.
#14 Posted 21 August 2018 - 07:49 AM
MrFlibble, on 21 August 2018 - 03:10 AM, said:
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.
#15 Posted 22 August 2018 - 10:15 AM
Mike Norvak, on 21 August 2018 - 07:49 AM, said:
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.
#16 Posted 22 August 2018 - 03:49 PM
Jan Satcitananda, on 19 August 2018 - 02:29 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.
#17 Posted 22 August 2018 - 05:10 PM
#18 Posted 22 August 2018 - 05:15 PM
#19 Posted 22 August 2018 - 07:58 PM
Zaxx, on 22 August 2018 - 03:49 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.
#20 Posted 23 August 2018 - 01:24 AM
Jan Satcitananda, on 22 August 2018 - 07:58 PM, said:
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.
This post has been edited by Zaxx: 23 August 2018 - 01:27 AM
#21 Posted 23 August 2018 - 02:34 AM
#22 Posted 23 August 2018 - 07:19 AM
#23 Posted 24 August 2018 - 01:44 AM
Phredreeke, on 23 August 2018 - 02:34 AM, said:
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:
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.
#26 Posted 09 September 2018 - 07:40 PM
Jan Satcitananda, on 19 August 2018 - 02:29 PM, said:
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.
This post has been edited by icecoldduke: 09 September 2018 - 09:22 PM
#27 Posted 09 September 2018 - 08:56 PM
#28 Posted 10 September 2018 - 03:57 AM
Phredreeke, on 09 September 2018 - 08:56 PM, said:
Maybe he's following the MAME philosophy: "Don't bother solving slowdowns on current hardware, because in the future, CPUs will be faster."
#29 Posted 10 September 2018 - 06:30 AM
Zaxx, on 23 August 2018 - 01:24 AM, said:
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.
This post has been edited by icecoldduke: 10 September 2018 - 06:37 AM
#30 Posted 10 September 2018 - 08:26 AM
Phredreeke, on 09 September 2018 - 08:56 PM, said:
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.