Comments by "George Albany" (@Spartan322) on "Fireship"
channel.
-
9
-
7
-
7
-
@charlesm.2604
"Don't get surprised when those who do work in C# and C++ are favoriting alternative engines with first class support for them."
Statistics disagrees, its not a matter of Godot not supporting them for it does, but there's rarely good reason to use them unless you need their benefits which is rarely ever the case. (and anyone who claims they do, they're likely lying about that, there's a very small set of needs that GDScript doesn't address by itself) Any decent and experienced programmer will tell you the language doesn't matter so long as it actually works as a tool. Even as much as I hate Python (and for which I very much hate it) and love C++ and C#, I will tend to prefer GDScript in Godot specifically because its rarely ever necessary not need exactly what it does. And even if it doesn't fulfill my needs, I can write all my robust lower level code in those languages segregated from my scripts and write the rest in GDScript.
"I'm not saying GDScript is bad (in fact it has been a real advantage for beginners to get into game dev), I'm saying it makes no sense to enforce its use to people who prefer other languages."
Nobody said this and you can already do this. But its inherently foolish and detrimental if the expectation is for most people to generally defer to using anything other then GDScript as the main language they interact with Godot on. Aside from first party support, built in engine support and integration, it also does not require extrinsic compilation and does not produce native code. If you need native code then you can already handle that separately, your main interaction is rarely justified to be by native code because it will not help you in most circumstances. Even in the case you want to use C# you will always be a minority, sometimes I like to use C# in my projects, but its rarely necessary.
"As far as funding goes, I agree, Godot isn't going to run off of financial support. But it's very hard for professionnals to trust a FOSS project. If we want professional adoption we need an income-bringing activity."
Linux is literally the most professionally supported server kernel (with GNU, OS) in the world, it has no intrinsic income and doesn't endorse anything or anyone. And that aside w4games exists and there are already multiple big name business supporters involved with Godot. I don't see why it needs to provide any income.
"It's a tough problem to tackle and it needs to be discussed as a community because it could change the direction the project is trying to take. Some of my ideas:
- Asset library fees.
- Working with a hosting platform to offer multiplayer infrastructure and SDK.
- Godot Ads.
- Premium support."
Literally every single one of these violate the core principles of the Godot project and its developers and contributors. Its also exceedingly unnecessary and foolish as its also opposed by the community. The point of Godot is that everyone is treated equally in regards to the engine, that including their financial status. The development of Godot intentionally does not expect to provide you more then the game engine and the basic necessities regarding the engine, the only way I see asset library fees existing (which is the closest to acceptable) even is if you can sell assets in the asset library, which isn't even a library fee, that's a private sales tax.
"Thanks for reading and please be informed my intent isn't to detract Godot, the core team or anyone working on the project. It's to help them."
I can understand that but I think you've misunderstood what Godot is supposed to be, the developers expect the community to provide most of the work beyond the engine itself. Its the reason why so much of the engine is limited in how it addresses problems because it believes to provide a framework for others to solve problems, not to solve the problems itself. And said problems that the engine does solve must be small, self-contained, and otherwise necessary to address for most if not all who use the engine.
6
-
@charlesm.2604
"There is barely any documentation outside of API browsers and a few articles-styled guides."
That's not documentation just to point out, its a problem obviously, just calling it documentation is a bit misleading.
"There is a push for GDScript as a first support language when people in game dev mostly work in C# and C++ which are better for bigger projects (strictly typed, OOP, better for tests, etc...)."
Devs who get into Godot do not work in C# or C++. There's very little reason to. While both are useful and have a place especially for performance reasons, unless you are hitting a bottleneck, this isn't a problem. Even for large projects you can segment parts to C++ or C# if necessary but it rarely ever is unless you are doing something very special, like building a procedural-capable voxel mesh that doesn't tank performance. But you can still devise the functional use of that system in GDScript, its merely the backend that's in C++.
"Indie game dev is highly tied to social media and influencers. We need more Godot endorsed YouTubers/streamers to work on educational material."
I don't see why Godot would need to endorse anyone, even with all the support it has that money is spent on refining the development. I'm not so sure you need to endorse anyone to produce educational material on it either. We already have a lot of folks working on that without any endorsements.
"We need more showcases, show people what the engine can do."
Everyone already does that, Godot devs do it all the time on twitter, they did a full demo reel of many projects on Godot the 6th of this month, new features almost always have demo video as well, and a lot of youtubers are already promoting demonstrations of games and projects. The subreddit is also full of many demonstrations too.
"Get more funds. There needs to be a money bringing activity to establish Godot as a trust worthy project that will never run out of financial support."
Yeah but the question is how? And as it currently stands Godot isn't gonna run out financial support, least of all any time soon, and even if it did its not exactly a big deal like Unity or Unreal had that happen since everything is covered under an FOSS MIT license anyway. And all that aside some of the major contributors are already running their own publishing company for the sake of licensing and publishing Godot games on consoles. This is the biggest problem preventing adoption, its not any of the other stuff, its the lack of console support which was hard because it was MIT and thus can't intrinsically support any proprietary console API. That's where W4Games enters the fray.
5
-
3
-
The cool thing that I'd say makes Godot's system stand above web tech is its trivial to design your own custom nodes in Godot and they are highly independent, whereas in the web tech you can't exactly design custom elements to function the same way and not easily and they're never independent. The only thing Godot currently doesn't have in its pocket yet is animated UI, the UI is extremely reactive, more then you can currently achieve with basically any other system with way better performance too, but animations are a pain specifically in container UI nodes:
So containers are special UI control nodes that define how its children are shaped, act, and are organized. Like for example you have a tab container, where each child of the container is a separate tab you can show or hide by clicking on said tab. (think of the child nodes as each a web page for the tab bar) You can also make scalable reactive lists which adjust to screen size perfectly, we even have flow containers now too. But there is one issue with all of this. You can not animate the position or shape of a container's child because the container has full control over its size and shape. (there is a customizable minimum size for container children and it will always shrink to that min size if its more then default min size of the node, however it can be larger then the min size, we do not have a max size value) This means for recyclable animation behavior you need to hack it in and remove it from being a container child. I've pondered on a few methods to correct this, but otherwise haven't tried to correct it.
There's another issue with UI similar but distinct from this and that's style resources also do not support animations, mostly for performance reasons. Styles expect that change would only happen if interaction is committed, this is okay if you make a shader animation for say ripples on clicking a button, but say you wanted to gradually change the color and/or shape of the button there is no method to ensure this, and neither can you create a continuous animation with styles and themes. This is the only issue I can think of with Godot's UI theming system. (and its not like the other UI toolkits don't suffer similar issues, it just sucks with Godot because its a game engine where this is quite useful functionality) You can relatively easily get around this behavior but that too is hacking around Godot and reducing the reliance on intrinsic behaviors found in Godot which is less performant, scalable, flexible, and accessible.
2
-
2
-
2
-
2
-
2
-
1
-
Honestly I have to wonder the brain of some FOSS folks, I love FOSS, I'm a fanatic of it, (though I'm an unlicensed anti-IP law kind of fanatic of FOSS, which means I also hate GPL) but if you don't have an existing financial scheme to provide for yourself or job, that's your fault. Aaron Swatz's criminal trial is insane and I think everyone involved should be executed for "a perversion of justice from authority" (and yes I think all perversions of justice from authority should be swiftly and ruthlessly executed) but what he did was thievery and vandalism, nobody is obligated to give you information, I agree we should be free to volunteer our information, but nobody else is obligated to give that information to you, that doesn't make you morally right. Just because information itself can't be owned does not mean the means to acquire, use, and abuse said information is free to you.
1
-
1
-
1
-
1
-
1
-
1
-
1