Once wrote a tutorial that assumed you knew nothing more than highschool chemistry and took you up the whole ladder into C++ and writing your own code, so you had a rough (the topics were covered all the way up, but left out certain technological improvements, that way you could see how you could go down the whole pipeline and understand things at pretty much any level by doing more search, and could theoretically build your own [albeit slow] computer with raw materials) idea what was going on. The problem was, i found people don't really do great with just information dumps. I have another tutorial on my site that goes into some of the same topics, just not as low (most people don't care how a transistor works), but i'm planning on canning it as i don't want to bother trying to support a C++ tutorial anymore.

This is a good start for the lowest levels. This will translate quite nicely into transistors, and from transistors, you'll see something like this (A and B are eventually connected to VCC aka Positive, while output eventually goes to ground aka negative) and slow you can understand and build up from there, with things like this (handles simple 3 bit addition to get 2 bits of output with carry, which can be chained to get simple addition using transistors) and understand how computers can do math.

About C# that's just your opinion. I find parenthesis easier to read than just identation (that should be used anyway). But the worst thing about python is that you need to watch the assigned value to know the type of a variable.

The performance of unity is great right now. It was bad in the past because of Unity script and other bad things that were discontinued like mono (right now they use IL2CPP as a compiler that convert IL code to cpp before compile to get max performance, and it's great).

Make the engine open source does nothing for most people. You need to know a lot to change the engine of someone else. Unity still give access to the source code if you pay money to them so if you really really need to you can get access to it. For me I never even got to take a look to the source code of godot or unreal, for me it's too difficult and I think it's the same for most people that develop games out there. If you focus on the game there is no reason to touch the engine code.
Usually performance problem are not on the engine part, you need to think about your own code before trying to fix the engine. It's like trying to fix a library or the framework itself, usually they are not the problem.

Anyway from the tone of your message I don't think you will really get anything... Focus on 2 things:

1. Not every program need to be open source... If you think that you should avoid to play most of the games out there.
2. If you got no experience with both Unity and Godot you should not say that unity got performance issues or that Godot is ready for production. There are games with performance issues out there for many engines most of the time the problem is not the engine and I can say for sure that right now unity performance is not a problem at all.
Godot is not ready for production, too many bugs and limitations.. At least the last time I tried it was not ready. If you think it is try it and tell me, I will try it again and I will tell you everything that is still wrong with the way it works.

You asked me to elaborate but you don't actually elaborate anything on your own, you just say that unity got bad performance because some games that use unity engine got performance problem but that's not a way to evaluate engines..
Not just that, Godot still use Mono for C# and, like they say on their own website, C# performance is still 4 times better than their own python like language (and mono performance is much worst than the current IL2CPP compiler of unity).

cant dev tools do that variable type watch for you?

yeah i cant see how open source engine is any helpful , it probably take months for someone to learn how the engine works , then it would just cheaper and easier to pay for official engine support

you are probably right about performance issues , i ve seen games run very well and very crappy using the same engine

yeah i wouldnt use godot until it matures , as a new engine development will run into bugs which will require huge time investment to fix or evade at least for a quality product

open source is only good if there are people actively checking it for you

I only checked the licensing of Unity before I posted my comment and I assumed that they still have engine fractured as well. If they have only different licenses but everyone use exactly the same engine then that's great. That's how it supposed to be. If all assets on the store are for the same version of an engine then that should already lessen the frustration of developers. Glad to see that been fixed.

In what way is it not ready for production? People are making and releasing games with it. I'd say that only advantage Unity has over Godot is their vast asset store. That's it. But that said, while Godot lack things on the asset store, there are plenty of stuff available on the internet. For example, only genre templates that are not completed yet are RTS and ARPG. But unlike Unity, Godot samples/tempates come usually with tutorials. It does require people to search for things, I do admit, it can be a pain. But as we write, there are plans to expand and make the Godot asset store more usable and accessible.

Also, if Godot wouldn't be ready for production then people would't be switching from Unity over to Godot like that. I suppose that it depends what you are making? Or let me put it this way: What features Godot is missing that you'd require for your production?

Fair enough. I personally haven't tempered with engine source either. BUT, at least I have gotten answers and fixes for my tickets on Godot GitHub. Which I can't say about Unity.

I have nothing against for profit companies. Nor have I anything against closed source. The thing is about transparency. Also, having source available is always better than not having access to it. I also wouldn't compare final products with tools that they were made with. Most gamers don't know how to code, while most developers do. Both the skills and needs are different for gamers and developers. Regardless, if you think about it, most games that allow you to modify them are better than games without that feature. Then again, some games depend solely on user generated content and mods.

This is not Unity specific. Both heavy weight Unity & Unreal (probably Cry, Lumberyard and other engines that concentrate on eyecandy as well) come with major bloat and therefore are really hard to optimise. This resource requirement can be felt especially on the mobile platform. Clearly developers haven't optimised their games for mobile, but in my opinion, that might not even be possible. It's not related to C# either. It's to do with engine features that chew up resources and therefore affect performance. So even if you write beautiful and optimised scripts, the engine built-in bloat is still going to make all your efforts irrelevant. This is where Godot shines since you can turn on and off even engine features. To be fair, there's not many of them. :)

If you meant actual engine editor performance then Godot is really light weight and runs in seconds. With major releases I haven't had much problems with it. It has frozen or crashed on me few times but that's not more when Unity became unresponsive. That's my personal experience though.

There's this Doom clone made with it. It's not really a full blown game but more of a mockup with one level to temonstrate how to get that specific look.

It's not really that popular engine yet but it's gaining popularity rapidly when developers using other engines discover Godot, it's learnability and ease of use. At first it was Game Maker, then Unity, and once version 4.0 comes out, I think it's goint to be much more appealing to even Unreal users. There are some games being released made with Godot, but today, I don't think you'd know any of them. The more people discover Godot, the more people are strating to use it and the more games are being released. Right now there are few games in development that have the potential to become quite popular. Once they are finished in a year or two. At least in the indie scene. In my opinion.

Unfortunately, that's not specific to python. And now in C++ you can do the same thing to a certain degree, with "auto." Coming to a C# near you, for sure. No, it's still horrendous. No no, you kinda need to know a bit about the engine to know how to write your code. Some engines are really good with certain things, other engines are better at other things, and this is not specific to engines, but also libraries you depend on. Knowing a bit about target architecture can help, too. For example, phones handle java better than computers do, because they generally have ARM processors, now, which has Jazelle mode which runs java as native code, cutting out the startup time of recompiling it to native code like you have to do with x86. Says the one who's having trouble figuring out quote tags, just sayin'... But, by all means, please project more. You're trying to talk from authority while demonstrating your... well... I never made such a statement, though that would certainly be nice if it were the case. I said nothing about godot's production value... As for unity's performance issues, handling comparable tasks between unity and, well, native code shows that unity is still quite slow. I could say that if you know nothing about the underlying CPU architecture you can't speak on performance, but this is child's game. I've managed to find 0 games that run effectively on my computer that were made with unity. Sure, my computer is old, but that's no excuse for 10fps for simple platformers or something with little to no particle effects. I call that performance issues, when skyrim runs just fine. Why are you quoting me when i'm just asking about godot and making no statements? Are you half asleep or something? Ask and you shall receive. Unity is a CPU hog, plain and simple.

I'd have to double check, but last time i had to run a C# program, it was windows targeted and it ran on my linux machine when i ran mono. I could be wrong ('cause i didn't try running a disassembler on it), but this, to me, is a huge warning that it's run in a VM or "recompiled" like java usually is. I haven't tried a recent release of unreal, though, but i wouldn't be too surprised if you're right on that one, tbh. But you're absolutely right on the primary source: featuritis, aka Wirth's Law. I might have to give it a shot, sometime, just to see how it goes. Well, if it's the only engine that has toggle-able features, that'll definitely increase it's usage over time when people keep complaining about performance issues of other engines. Personally, i'd like to see more people making things from scratch and using dedicated libraries for certain tasks instead of these attempts at making a one-size-fits-all engine. Then again, we'd just end up seeing the same thing in code form. Would be interesting to see engines that actually compiled end results, too, instead of using a script with said engine (and all features on). That said, it sounds like godot might be going this route.

Frankly, I'm sick of simple platformers and RPGs not running on my computer, simply because "well, it's old, you should upgrade" when instead skyrim runs just fine. Skyrim should not run better than any 2d platformer, RPG, shmups, etc, regardless of age. That's just embarassingly sloppy work. It's not like these kinds of things would be hard to make with SDL2, either...
In addition to the stuff for you i posted above, you might also enjoy this.

Not the same thing. auto in C++, var in C# etc... Are just optional local variable with no explicit type. It's not the same as all the variable with no explicit types.

That's not true at all. The reason skyrim got good performance on your pc while some games made with unity don't is because Bethesda know how to program while many indie just use visual scripting (with 3rd party since it was not supported by unity just a few version ago) for far too complex things like Dreamfall Chapters.
Not just that sometimes they even tried to modify the engine itself like Obsidian with Pillars of eternity (like I said you can get the engine code with money) but there were still using bad coding (they said that when they talked about pillars of eternity 2 performance in the crowd funding).
And you can see that a lot of game not using unity still got a lot of performance problem (like vampyr that use unreal 4) or other problems (skyrim still crashes a lot if you just try to change the frame rate higher than 60 fps, and it's just one of the many bugs of that game).
There are also game with no performance problem at all made with unity like Cuphead, superhot, super mario run, enter the gungeon and life is strange before the storm (my in progress game. It runs without any problem even on mobile. I never changed the engine code but I made a lot of optimization to the code like removing GameObject.Find if possible and always remove it from loops and follow the docs that explain how to actually optimize your code (like I said docs of unity is the main reason I use it, the docs are really really good)

The last time I tried it, it was not possible to do many things that I made in my unity game. The most basic thing was to actually use the engine without a lot of crashes. But maybe they fixed a lot of things (for example I saw today that now you can use C# and export the result to mobile not only desktop like it was the last time I tried it.

And about contact support to fix a bug I got answers from unity, that's my experience at least.

Yes but it's faster to just check the code than enter in debug mode.

May as well be. And games made by the same caliber of developers raw or using other engines are often just fine, for me. As for Bethesda knowing what they're doing.... oh boy... You're the first person i've read make that claim. I mean, sure, they're not as incompetent as their reputation suggest, but they're not great, either. So glad you finally mentioned some examples: i haven't played cuphead more than 5 minutes because of the performance issues. The others i haven't bothered buying. Cuphead is an absolute hog, and i vaguely remember others here complaining about it, too. I guess Bethesda's coders are the absolute best. Maybe i should use the TES construction set for an engine instead. Clearly better than unity. by what we're going by in this thread.

you don't know what you are talking about. Skyrim got no performance issues, but a lot of other problem like I already said in my previous post. Still I think they are not incompetent at all, make an engine and the game, and share the construction set to everyone to change the game is something that really few developers are able to do. The best example is Morrowind, OpenMW exist because the construction set is easy to debug and reverse engineering. I don't know what pc are you using but I tried cuphead on multiple pc and on mobile and it was always perfect with performance. If your pc cannot handle a mobile game maybe you just got a really old pc that can only run really old games.

I can't blame you for being cautious about this. By bloat I didn't really mean virtual machines. I'm not really sure but to my knowledge Unreal actually compiles to the target platform and not to a VM. As I understand it, Godot interprets the script at runtime while the editor is running, regardless of language used. But once exported, it too compiles to actual target platform. So right there comes huge performance boost between testing in editor and the final product.

You might want to wait until 4.0 is released since release candidates aren't that stable. I'd suspect that early releases can be plagued by bugs until they get fixed too. Right now 3.2.2 is the latest stable release but 4.0 supposed to be game changer or something. So there's that.

Right now only core parts of engine, like physics and certain renderers, can't be switched off.

It's beyond me why sidescroling platformer should have 3 dimensions and special effects. It doesn't add anything to gameplay.

SDL2 - I didn't know that they changed their license. Zlib is something I could use. IF only I would be making something simple as interactive novel or something like that. Right now I really appreciate ready made physics, tilemaps, pathfinding and such.

OK, so this is so funny because while I have been talking about ancient Unity, you have been talking about ancient Godot. It have had C# support since 2017. Nightly builds are unstable but stable releases are usually stable. Unless it's really fresh like 4.0 is about to come out soon. I'd wait few months before trying that once it's out though. I remember when 3.0 first came out and that was horrible.

I'm glad you have good experience with Unity. IF you're happy with it then it's better to stay with something you are familiar with. Because your workflow is going to suffer if you have to start learning something new. Tinkering with new engine can be fun at first but it's really just a distraction that simply wastes time. Unity is quite decent and it's popular and one of the mainsteam engines. And as you said, it has great customer support. They have great documentation. Plenty of tutorials. It's asset store has lot to offer, which can save time. I mean it's not just good, it's great engine. I would be using it myself if there wouldn't be Unreal or Godot really.

I actually tried Godot many times (not just in 2017 but also in 2020). I'll wait for version 4.0 like you said (maybe also 4.1)... I will continue to use Unity of course, but I do it as a hobby so I see no reason to not also try other engines... and if Godot will be really good there is a good chance I will do something on that engine too.

PS. About C# VM things:
- C# don't really work like Java. While Java compile to bytecode that run on a VM (slow but not so much in 2021), C# use JIT by default (it compile to IL (the bytecode of C#) that will run on a VM only the first time you run an application, after that the code is native).
- Not sure what Godot does (I know that it use Mono for C# and that's use JIT, at least on pc), but for Unity JIT is not even a thing anymore. Unity right now use IL2CPP that's even better since it compile to IL->C++->Native Code to the target platform. That's even better for performance because it get the same performace as a native C++ application.

Ok I find out what you are talking about:
https://godotengine.org/article/csharp-wasm-aot
https://godotengine.org/article/csharp-ios-signals-events
the AOT thing is new (I actually did not know it was possible with Mono, they made something like IL2CPP without using something different from mono) last time I tried Godot it was early 2020 so I probably just missed it, before that it was actually JIT like I said.

In the meantime just read this (from the last version of godot c#):
https://i.imgur.com/wP2rSZf.png

Like I remember is not production ready but they also say that themself about the C# release.
Still I'll try version 4.0 when it will lauch, now that I know that it use AOT compile and can export to mobile I think it's a good time to try it again.

I know unreal does, which is evidenced by having target platform. I was specifically talking about C# here. That's a good sign. When using C++ do you have to use things like "extern "C"" or anything like that? That'd be another dead giveaway. I'm in no particular hurr, just putting it on my todo list. That I can understand. You can get a performance boost ustng a 3d engine to force the video card to do the blitting. This is actually mentioned in many SDL tutorials and maybe even the manual (been a long time since i looked). But they don't need 3d path finding and all that. The game on my todo list to make is going to require i do all that myself, 'cause these engines won't have the features I actually need. Dealing with the path finding is one of those reasons i'm sitting here playing tames and talking on the forums rather than completing the project, so i get where you're coming from. I have a few ideas that could work. I've decided at this post that it's not worth persuing with him. He's either trollng or has cognitive bias to extreme degrees (notice the fanboyism and the insituation of me knowing little to nothing?). My guess is he probably won't try it, 'cause he's a little too invested in unity.

Since you have more experience trying multiple enginees, which ones do and don't suffer from gimbal lock? I imagine Unreal does, given it seems to focus on FPS games, but what about Godot and Unity? After my current project I wouldn't mind getting into flight sims or space sims, as i have some unique ideas for those.

Actually I tried it yesterday (I even posted a screenshot of what they say about Godot c# itself... The creator of that engine say that it's still in late alpha and not ready for production) and I will try it again when version 4.0 is out (why not? I love to try new engine and if I find an alternative to Unity that's a really good thing).
If I am a fanboy of unity you are a hater of unity. I am not a fanboy, I just use it a lot and I don't really found anything wrong with performance like you said (and I'm not the only one). There are bad things about unity too like the new input system that is worst than the already bad old input system (the old one do not recognize where the input is coming, the new one is so much more complicated that is a joke to use), in the end they decided to support both because the new one was so bad it got no update for like a year. I wrote a wrapper for the old input system, a workaround that make it at least good for my use but it's not the best at all.

There are even docs about how to avoid scripting that will get performance problem for unity... I don't really think that is the problem of the engine.
https://docs.unity3d.com/Manual/MobileOptimizationPracticalScriptingOptimizations.html

At least not in the last version. Version 3 of unity was really bad with a lot of problems like the free version lack of profiler, the Android and ios module that required payments even for basic usage. The animation system that was not able to automatically blend animations. From unity 3 to unity 4 the code upgrade was a disaster, the particle system was a mess, the UI system was so bad on mobile you had to use a fake ui with 3d models instead. You could not even save data to json until unity 5 by default because there was not json serialization/deserialization utility at all (and the one we use today is still not great (it does not support types like Dictionary so you need to create basic types like that on your own by wrapping into classes).

There is still a lot of things that unity can do better and a lot of things that were fixed (the performance is one of the things that was fixed with IL2CPP (it was new on 2015 and it was on mobile only for about 2-3 year).
That's why I said that you don't know what you are talking about. You are talking about unity problems but you don't even say anything about the things that they should really fix.

There's a difference.

Python:
x = 2
x = "2"

no error here, until you try to do print(x + 1)

C++:
auto x = 2;
x = "2";

The second assignment is an error, as you can't assign a pointer to character to an integer variable without a cast. (I believe you can in plain C, but expect a compiler warning if you try this. Also, the code I wrote, I believe, works the same in C (at least older standards with "implicit int"), even though the meaning of "auto" is completely different.)

For comparison:
In Perl and JavaScript:
x = 2;
x = "2";

No error here, and even x + 1 is not an error (the result is "3" in perl or "21" in JavaScript).


Anyway, I happened to read what the system requirements are for the *demo* included with UE5, and they were ridiculous.

For the game I'm thinking of writing, I may just write my own tilemap renderer (using an approach similar to what the NES did, but with perhaps more colors and such), and design the game to not need things like pathfinding or physics (or implement them in simplified form, like only having to route through squares on a grid rather than through continuous space).