Discussion Is re-inventing the wheel worth it?

Soygoy

Soygoy

I will fight for /anthro/
As some of you might know, a while ago I was making a roblox clone using Godot and it was going smoothly but a part of me can't help but think about performance concerns. While BlenderChud says a lot of dumb things, ultimately, using an engine like Godot might be a bit resource intensive for what I want to make, it uses a lot of ram and has to rely on shader parameters to get textures functioning properly, using too many materials causes the game to lag a lot and loading places takes a fair bit of time, althoughbeit in normal Roblox it takes some time to load too. My project functions and that is good enough, but ultimately I am wondering if developing purely for performance is the best thing that I can do and while Godot comes with a toolset of things that are great, some other things are not so great. It's built in physics engine might not be up to par.

Roblox places can have a lot of parts in them aswell, thousands, maybe even 10 thousand. Most of them even are designed to explode or perform physics calculations and on actual old Roblox clients this causes significant lag, but with a modern updated engine, this lag could be removed entirely. I also want to write a lua interpreter so that scripts can be read by the engine, but doing so using GDScript is probably a bad idea because of how slow GDScript is compared to other languages. It is also possible to implement lua support via an addon and perhaps use that, but I'm wondering if maybe it is better to use alternatives.

For example, I've been looking into other languages like Go, Zig, Rust, etc, languages that are not interpreted like Python or Java. And I've been wondering if it's a better idea to use another language like Go to re-develop my Roblox clone but with a focus on performance. Doing so is simple, all I need is an XMLParser, a Multiplayer System, A physics engine, a 3D engine, something that handles textures and it should be as easy as loading a place = load the xml file, parse that to spawning 3D cubes with textures with enableable physics for each one, controls, controller support, and then you'd have your Roblox clone. Oh and also audio.

The issue is that I can't find a 3D game engine with physics for Go, and if you're looking for a 3D Game engine with physics for C++ then you might aswell just use Godot. I will probably have to rely on using a lot of libraries or implementing things entirely by myself which will take an extremely long time. Not to mention, a lot of the libraries I need are made solely in chinese or something, or don't even exist yet. And what about cross platform shit? I don't have Windows and I don't even want to think about attempting to install it just to test if it will work cross platform. And do I really have to deal with manual memory management and pointers and stuff?

It just seems like too much hassle. I get told this a lot "just make your own engine o algo" but it's really not that simple, it's extremely counter intuitive, the only option we have at this point is Godot. There might be another way, like using GDNative extensions to make code faster or something like that, but I am wondering if there truly is an easier way that will be good for performance that doesn't require me to spend fucking hours debugging a shitty rendering or physics issue or something like that. If I actually re-invent the wheel, I will quite literally just be recreating Roblox from the ground up. Even then, Roblox doesn't matter, it's making any kind of game with any different programming language at all, it just doesn't seem worth it. Godot is the only way, other engines just suck or aren't even as feature complete or as user friendly as Godot.

So I feel like the answer is no, but what do you think? Is it possible to have a programming language that doesn't suck, easy to read, easy to write, but extremely performative and cross platform? Java is cross platform and has garbage collection but is interpreted which means you have to download Java to even use it which sucks for user's sake unless you bundle in a version of Java with your game or something like that. Python is interpreted, easy to read and write but takes forever to load and performance wise, sucks ass. Go seems like C but easier, can be compiled, but might not be cross platform worthy. Zig also looks like C but better. It might also be possible to make an entire 3D game using lua OpenGL shit but... I wouldn't dare to be honest. And Rust just seems retarded in my opinion.

So if Godot isn't an option, do I really have another choice or do I have to spend years developing a """game""" and all I have to show for it is a basic 3D renderer geg.
 
Your concerns about performance, language choice, and the complexities of developing a 3D game from scratch are valid, especially when you're trying to balance ease of development with efficiency. Here's my take on the situation:

**Godot and performance issues:**
It's understandable that Godot, while feature-rich and user-friendly, might feel limiting when it comes to performance, especially for a project that's pushing the boundaries with thousands of physics objects and heavy material usage. However, optimizing for performance within Godot might still be possible without entirely abandoning it. GDNative and C# extensions could help bypass some of the bottlenecks you're experiencing with GDScript. GDNative, in particular, allows you to write performance-critical parts of your game in C or C++ and integrate them directly into Godot, giving you more control over memory management and execution speed.

**Lua integration concerns:**
Your plan to write a Lua interpreter for scripting makes sense if you want to mimic the Roblox environment. While doing this in GDScript might be slow, there are other ways to speed up scripting, like embedding a pre-existing Lua interpreter in your project. Using GDNative for Lua support, instead of GDScript, might also boost performance. Alternatively, some developers have used LuaJIT (a highly optimized just-in-time Lua compiler) alongside Godot to achieve better scripting performance.

**Switching to another language or engine:**
While languages like Go, Zig, or Rust offer better raw performance than GDScript or Python, they also come with steep learning curves, especially when you're not familiar with manual memory management or dealing with lower-level programming paradigms. If you're concerned about cross-platform compatibility, Rust or Go could indeed offer cross-platform development and high performance, but building an entire engine from scratch in these languages might be overwhelming.

Considering that you're concerned with how long development might take if you start from scratch, it sounds like trying to optimize Godot or use a combination of tools within its ecosystem might still be the most time-efficient option for your project.

**Potential solutions:**
1. **Stick with Godot and optimize:** You could try using C# or GDNative with C++ for performance-critical parts, which would help you avoid some of the downsides of GDScript. C++ gives you more control over memory and performance, and Godot's C++ bindings are fairly mature.

2. **Lua integration via addon:** You could explore existing addons or modules that integrate Lua into Godot, which would prevent you from having to reinvent the wheel while still allowing Lua scripting. Look into existing solutions for embedding Lua or LuaJIT.

3. **Move to a different engine:** If you're still convinced Godot won't cut it, you might want to explore engines like **Bevy** (a Rust-based engine that's becoming popular) or even Unity. Though you're likely aware of Unity's recent controversies, it remains one of the most powerful game engines with a huge support base. Bevy might be a better fit if you like the structure of Rust but want a framework that simplifies some of the engine work.

**Final thoughts:**
Ultimately, if you focus purely on performance, you might get bogged down in engine development, which could take years, like you mentioned. Sticking with Godot and leveraging its extendability with native code might be the best compromise between performance and development speed.
 
ILoveVesna said:
Your concerns about performance, language choice, and the complexities of developing a 3D game from scratch are valid, especially when you're trying to balance ease of development with efficiency. Here's my take on the situation:

**Godot and performance issues:**
It's understandable that Godot, while feature-rich and user-friendly, might feel limiting when it comes to performance, especially for a project that's pushing the boundaries with thousands of physics objects and heavy material usage. However, optimizing for performance within Godot might still be possible without entirely abandoning it. GDNative and C# extensions could help bypass some of the bottlenecks you're experiencing with GDScript. GDNative, in particular, allows you to write performance-critical parts of your game in C or C++ and integrate them directly into Godot, giving you more control over memory management and execution speed.

**Lua integration concerns:**
Your plan to write a Lua interpreter for scripting makes sense if you want to mimic the Roblox environment. While doing this in GDScript might be slow, there are other ways to speed up scripting, like embedding a pre-existing Lua interpreter in your project. Using GDNative for Lua support, instead of GDScript, might also boost performance. Alternatively, some developers have used LuaJIT (a highly optimized just-in-time Lua compiler) alongside Godot to achieve better scripting performance.

**Switching to another language or engine:**
While languages like Go, Zig, or Rust offer better raw performance than GDScript or Python, they also come with steep learning curves, especially when you're not familiar with manual memory management or dealing with lower-level programming paradigms. If you're concerned about cross-platform compatibility, Rust or Go could indeed offer cross-platform development and high performance, but building an entire engine from scratch in these languages might be overwhelming.

Considering that you're concerned with how long development might take if you start from scratch, it sounds like trying to optimize Godot or use a combination of tools within its ecosystem might still be the most time-efficient option for your project.

**Potential solutions:**
1. **Stick with Godot and optimize:** You could try using C# or GDNative with C++ for performance-critical parts, which would help you avoid some of the downsides of GDScript. C++ gives you more control over memory and performance, and Godot's C++ bindings are fairly mature.

2. **Lua integration via addon:** You could explore existing addons or modules that integrate Lua into Godot, which would prevent you from having to reinvent the wheel while still allowing Lua scripting. Look into existing solutions for embedding Lua or LuaJIT.

3. **Move to a different engine:** If you're still convinced Godot won't cut it, you might want to explore engines like **Bevy** (a Rust-based engine that's becoming popular) or even Unity. Though you're likely aware of Unity's recent controversies, it remains one of the most powerful game engines with a huge support base. Bevy might be a better fit if you like the structure of Rust but want a framework that simplifies some of the engine work.

**Final thoughts:**
Ultimately, if you focus purely on performance, you might get bogged down in engine development, which could take years, like you mentioned. Sticking with Godot and leveraging its extendability with native code might be the best compromise between performance and development speed.
Click to expand...
I'm ignoring you for this.
 
Soygoy said:
I hate ECS with all my willpower.
"Instead of doing health = 0 you have to make a health node!" FUCJK OFFFF
Click to expand...
Well now you know how I felt learning wokedot (but with a performance PENALTY instead)
But yeah, sounds like a stubbornness issue on your end
 
Spasoje's Revenge said:
Well now you know how I felt learning wokedot (but with a performance PENALTY instead)
But yeah, sounds like a stubbornness issue on your end
Click to expand...
ECS is great and a lot of systems use it, but its ultimately unimportant for a lot of things like variables like health and stuff.
I usually just find myself creating a Player node and an enemy node and making the enemy node modular o algo instead of using ECS for every little thing, you know?
 
Soygoy said:
ECS is great and a lot of systems use it, but its ultimately unimportant for a lot of things like variables like health and stuff.
I usually just find myself creating a Player node and an enemy node and making the enemy node modular o algo instead of using ECS for every little thing, you know?
Click to expand...
No, I just barely started learning about ECS myself
 
I think what you want is learn data oriented design rather than ECS (cancer). I don't think Zig or Rust are good languages right now because they have no libraries, unstable, llvm mess, and long compile times with huge binaries output.

I would say Go is bad because it is garbage collected you'd take performance hits each time it cleans up. You can remedy it by avoiding allocations at run time. For example only allocate/deallocate every time you load/unload a level.

>Is it possible to have a programming language that doesn't suck, easy to read, easy to write, but extremely performative and cross platform?
yes and it's called C [wholesome] , but seriously I'm trying to write a 2d game with C and it's not so bad merely a different approach to C++. Instead of writing `Object.update(world)` I write `update(world, object)`. Regarding reinventing the wheel in C with data structures, I just allocate a 16000 array and I don't need more.
 

Similar threads

Neutralplier
Schizo Are mechanical keyboard worth it or is it soyish
Replies
17
Views
261
Terrorbyte
Terrorbyte
Back
Top