I'm glad I bit the bullet and went all-in with GDScript when I switched to Godot. Realizing the WHYs behind the language sealed the deal (aside from the not so great current C# support). And GDScript is very approachable for a... novice programmer like me. Still, it's great to see resources like this for folks who prefer C#.
As a longtime C# developer, I can tell you... There's nothing wrong with using GDScript! It is still real code and you are still a real programmer. The primary reason to use C# is if you have existing experience and libraries in C# that you want to leverage. If you're writing everything from scratch anyway, there's no reason NOT to use GDScript, and there are several good reasons you SHOULD use it.
@@cdarklock Right on! I was never very fluent in C#, so it was easier for me to switch since I have to keep learning either way. But the biggest lesson is that coding concepts are mostly universal, and the language is mainly just the syntax the ideas are expressed with. (although I must say I actually do miss those cute curly braces! {❤️} 😂)
@@SylvanFeanturi Bad take. GDScript is not a proprietary language it's FOSS like everything in Godot. But your point is that it's only used in Godot ? If you are already a dev going into Gdscript is really easy and doesn't ask a lot of effort and if you're new to programing and want to play with godot it's a lot less comple than C# as a first language and allow you to achieve things faster and it still allow you to learn the basic of programing.
Great to see. Thank you! Been doing C# for decades now and just started getting into Godot in the last few weeks and love it. Looking forward to checking this out in detail to learn more! ❤
Coming from Unity, I went to use C# in Godot. I used a bit of GDScript as well. Just to let you know, I am making a horror game in Godot 4, programming entirely in C#. It isn't much, it's just a mix of Slender and Dark Deception.
OMG THANK YOU FOR THE FIRST ONE. Even though I'm not making a platformer, I've been trying to use C# with Godot and it's been ... Pretty terrible. I didn't have this many issues with Unity, granted, I am still relatively new to programming in general. But I'm just having the WORST time. I could do just about everything I needed/wanted in Unity but in Godot the most basic things are so frustratingly difficult. idk why. :| So, hopefully this will help give me some ideas xD
The only thing this show me is how the dotnet ecosystem is treated by godot. We're in version 4.X and this is basically the first vertical slice of a full project we've got. I thought this video would be a "look at all the amazing thing we can do!" but i'm 2 minutes in and all i'm hearing is warning about all the errors i'll get running this project. When you find resources about people trying out Godot they don't even bother with dotnet EVEN IF the engine they comes from is C# only. It just fucking sucks. I wish C# got more attention from, well, everyone.
I would really really love it if they hammer down better c# support! Like, equally as well supported as Gdscript. I feel like that would give godot a really big chunk of the Unity escapees
It will never be as supported as GDScript. Since the engine API is designed around a dynamic language in mind (all those Variants and dynamic collections and marshaling of types), every statically typed language will forever suffer from it, be it C#, Rust, or even C++ itself. As a 13-years .NET developer it pains my heart how bad C# support in Godot, but what pains me more is all commenters in Godot subreddit who proudly state that C# support is excellent. It is not.
I went into godot expecting to hate gdscript... total opposite. I LOVE it. It's honestly so polished. I haven't had to write any advanced algorithms yet, but I did write an entire character controller in gd script and it was great. No complaints. My day job is in C++ so I'm pretty biased toward strongly typed languages but gdscript has a great linter and the option to write it in a strongly typed fashion. It's great!
And if you use static typing you have a speed boost. You can also enable static typing by default and tell engine to not run project if you have anything that is not staticly typed.
GDScript is nice, but performance still trails behind C# (or C++). As mentioned above, static typing helps with performance but still a noticable performance difference between C#. Also C# has a lot more language features and flexibility.
@@ShiloBuff Problem with C# is dependency and runtime, also GC which is not actually a scalable solution to game development, honestly non-GC runtimes are just inherently more scalable (specifically reference counting, RAII, or pretty much anything that isn't a GC tbh) because you have control over memory which is actually quite crucial to game development if you care about speed, if you really need that speed, (especially since you can better take advantage of SIMD/vectorized math and the CPU cache, which GC languages kinda suck at) C# is honestly the last thing you really probably should be reaching for, but you do you.
Interesting that this gets released around the time of the Unity Unite conference. This might be a topic talked about in the corridors. For advanced scenarios Unity has some specific features that are hard to beat, especially for mobile and XR studio's. However the pace of Godot innovations seems much faster compared to the ones for Unity like DOTS/ECS and the render pipelines. It may be that the Unity innovations are more complex and aimed at professionals, but the momentum that Godot has will have an impact on the gamedev community. As it looks now, Godot seems to take over the education and hobbyist market, possibly added by high level engines like RpgMaker that will use it as their base. The market for asset packs and plugins follows the hobbyists, so that would change too. It seems like a long term process, but it may unfold itself at internet speed.
Godot actually works great for VR stuff, obviously Unity is more advanced but Godot is QUICKLY encroaching on that niche. It's super easy to set up and the built in tools have a bunch of stuff
The third person controller demo that the Chickensoft project is based on and most of the assets are courtesy of GDQuest not GDScript as mentioned in the video.
I am sorry, but your videos are quite difficult to watch. You repeat yourself over and over and jump back and forth between different projects. I am subscribed to you because you are a good news channel, but it is exhausting to watch your videos until the end. 1. C# Project 2. Hangar demo scene 3. C# Project - Cutting edge, C#, frustration, NuGet problems 4. Hangar demo scene 5. C# Project - Full C# game, pretty straightforward but then .NET/C# is tricky, issues, NuGet problems 6. Hangar demo scene 7. C# Project - C#, pain points, ... Why not: 1. C# Project - Demo - Where to get - Details/problems and how to resolve them - Conclusion 2. Hangar project - Demo - Where to get - Conclusion
I didn't have any problems with his video. I thought that his message was quite clear and found this to be an informative video. But, this is my opinion.
Mike may have room for improvement, as putting video's out at a super fast pace does take a tole. It's a bit like a friend showing me a new tool and I gladly overlook production issues for speed and enthusiasm. It's a bit like Udemy being quite crappy generally compared to Pluralsight, as that has much higher production values and it's more applicability for the enterprise. Still it has it place as video's arrive earlier earlier and on more exotic topics. Also the presenters are people from the trenches thus having more credibility, just like Mike, as he has been around for a while. I'm going to far, but you seem quite intelligent, so humour me. On the classic Aristotle's Rhetoric theory, Mike scores quite well on Ethos, Pathos and Kairos, but you point out quite elegantly that Logos could be better. 3 out of 4 is better then most. That said, if he starts to speak with a thick Indian accent, I'm at my limit too. I have some comprehension skills, but I'm not a mind reader. ;)
Mike is a great guy and he is an enrichment for the game dev community. That's why I care. If he improves his scripts (my subjective opinion) + his existing passion for game dev => Even a better channel. That's why I pointed it out.
I'd understand wanting to use C#, if that is all you know. Even though I'm interesting in learning C#, I will stick with GDScript that I find rather easy, because I already had a basic understanding of Python. No bull shit setting up, or trying to solve problems to use a language that isn't even officially supported.
Funny, I remember trying C# with Godot 3.x and THAT was actually terrible. Compared to then C# feels like it's in a pretty good spot and I didn't run into any issues during my setup while following the Godot 4 documentation. That being said reading the documentation is absolutely crutial as a lot of things work differently for the C# side of things. For now though I'm having a great time, no way I can live without my interfaces.
2:32 Ah cool to see myself in your video. As usual, thanks for your top-tier content! Regarding errors: Beta 6 is unusable for .net development. Closing the editor freezes entirely. I was hopeful in the future of C# in Godot but starting to feel like they aren't even testing the mono editor which doesn't show much promise for their priorities.
The whole point of the betas is to bugfix, there's plenty of bugs in the betas that have been just as much a pain in the ass, there's a reason they tell you not to use them on production.
Betas are testing. And the freeze that you are referring to was identified before that and got a mention in the blogpost in the "Known issues" section.
I'm glad that C# is becomming a more supported option; but the lighting show case was kinda poor. The interior lighting was great, but exterior looked like it was in a cave. Also it was obviously lagging a lot (low fps). Not a good show case when your fps dips below 60, or is your PC a potato? Because I've noticed this in other videos, you showcase features and the fps just drops in the game engine environment you're showing.
GDS is more robust in Godot so I would never choose c# especially when GDS is easier to code in. However, UE should support c# which is unfortunately not in the hands of hobbiests and we have to wait for epic games for that.
"In addition to the Godot C# project we also showcase a open source Godot 4 scene showcasing graphical capabilities using Godot." OK so the title of video is a bit misleading.
Far more interested in using C or C++ with the godot engine, do I still have to deal with GDNative for that or have they figured out a better abstraction?
I don't use C/C++ with Godot, but they no longer use GDNative and replace it with GDExtension Gamesfromscratch did a video on it : ruclips.net/video/7PpOgnujtAg/видео.html
I think if you are really good with C# , translating GD tutorials should not be that hard. I tranfered a Java tutorial to Kotlin to make a phone app. Kotlin has alot of gotchas compared to GDscript.
Yeah, a lot of the programming stuff translates over to other languages. The main thing that is different is learning how it works with the editor/engine and how to use the new API
@@KomodoBitGames I originally started in C++ as well, but I was formally trained in Java , C# and MySQL while in school. I also coded in JBasic as well. I believe the most important thing is to learn the fundamentals well. Arrays, Linkedlist, Heap, Quick, Merg sorts and understanding graphs , qeues and trees. I am currently focusing harder on Graphs , LinkedList and Trees. As long as we know all the basics well, then we can make our code more efficient, no matter what languages or frame work we use.
C# in Godot just feels clunky and hacky - until that is resolved I don't see myself using Godot. It is unfortunately a side effect of language support being an after thought and taking the backseat to the single application purposed GDScript.
GDScript is simply better for game development in Godot even if you could resolve many of those problems because GDScript has better memory management and is specifically designed with Godot in mind, you really shouldn't look down on GDScript, you really shouldn't marry yourself to one language, that's a recipe for becoming outdated.
@@Spartan322 That's true, but being able to use C# means you can re-use packages from other games without much issue (which is great in corporate environments), and also having to retrain the engineers or hire new ones will be a costly investment if the language is niche and only has one use. There are other language-specific things like C# Reflection which could also be harder to use with Godot. Not saying that C# is better than GDScript (of course not), but for the adoption of Godot to wider gamedev community and to companies (who will throw money at Godot's future) C# is pretty crucial...
@@Spartan322 I like what I like, have been a C# programmer for a very long time now, it is my favourite language and always will be, well perhaps with the exception of 6502 assembly.
@@FoxInFlame Truth be told, I don't think C# is a suitable game dev language for the simple fact that GCs are horrible for performance, CPU cache lanes, and SIMD/vectorized instruction sets, GCs tend to scale really poorly because their memory footprint becomes exponential and there is simply nothing you can really do to stop that. (and that becomes crucial as a game's size grows) Most corporate environments actually tend to prefer runtimes that manage memory a lot better, C++ analogous languages being the target most of the time, if you know C and C++, 99% of the time in corporate hiring you'll be better off, I generally see a lot more one off development in GC languages, like web design, build systems, or package management, but in a serious product that stands over a long time, unless the product itself is small, it becomes more efficient to use a system that doesn't automatically handle memory with a GC. Smaller companies and indie studios tend to use Unity more but as they get into bigger enterprises they either use a custom engine or Unreal specifically because performance is critical and pretty much all of the time that's in C++. So it be more accurate to say not corporate, less you be working in producing small services, which you can but usually people aren't aiming for those types of jobs in software. "There are other language-specific things like C# Reflection which could also be harder to use with Godot." Actually Godot's reflection is kinda better then .NET's to be honest, part of that is because the reflection is a lot simpler so it actually will trend towards being less expensive because its more upfront. Definitely helps that the references are returned from memory which should generally be cheaper. And I'm not saying Godot shouldn't support C#, but I'd say its better to treat it much like the Rust, Python, or Swift extensions which it will be getting at some point anyway, but GDScript is just going to be always be better then C# for Godot, just as GDScript will always be better then anything else, though the interface for marshaling with Godot in C++ via GDExtensions is freaking nice, .NET can go to hell for in comparison.
@@Spartan322 GDScript may be good for interfacing with the actual engine, but when it comes to writing actual engine-agnostic code such as game logic etc. it's bad, like laughably so.
I’ve been coding in C# for over 20 years… and for Godot, I prefer GDScript. It’s just nicely integrated. I’ll stick with GDScript as long as it’s fast enough for gameDev.
@@SnakeEngine I choose to let the shaders be compiled by the engine without me doing anything about it - as it should be done. I don't really understand why Godot devs couldn't just make it happen, it is a basic functionality. They could just leave running the game in the editor without compiles and then compile the shaders when making the final build. Is it really that hard to do?
@@voxelvoid You are just using a default setting of shader precompiling. Just set it in your engine of choice if it is not set by default and you are done.
I find C# for godot as not good step forward. Maybe it would be better to invest resources to create a very good visual scripting language for godot, similiar to the most popular languages, like bolt and gamecreator for unity. Such a powerful visual language combined with manual scripting would be a game changer for godot, because such platformer games and other games would be created in essentially no time without the need to connect signals and solve complex code. If someone knows c#, gdscript can learn quickly, but it doesn't work the other way around. On the other hand even kids can learn visual programming, it's really easy for non-coders and can make coders from non-coders as they are progressing and implementing custom code.
The issue is that Godot already HAS those bases covered though. It has a bunch of early-game hobbyist items, GDScript being the biggest one. It's when you start to make an actual full-scale project that things get bad, and it's that end-goal that needs more support right now. (well, really the beginning middle AND end that all need work, but less so the introduction into it all) Also, Godot used to have a Visual Scripting language. They dropped it for reasons I do not know.
Honestly, C# is kinda a terrible solution for game development, the runtime is expensive, the GC will get in your way, and there is absolutely no memory stability, also .NET doesn't like the CPU cache and sucks at SIMD/vectorized instructions. Kinda wish more people were willing to actually make themselves useful and learn other languages and runtimes, C# is a tool, too many people treat it like a religion.
@@Cleefbag71 No they don't, because they had to use "non-alloc" (which is itself a misnomer because "non-alloc" does in fact allocate, and is likely still to create garbage, it just optimizes the allocations and the minimizes garbage it creates) interfaces just to get the game to run. The fact "non-alloc" interfaces exist demonstrates that the language and runtime are terrible for game development, (it means that the language and runtime do not natively provide any manner or structure to optimize, which .NET does not) a good interface should have a native manner to optimize performance without jumping through extra hoops because of the runtime and the language. GDScript for example will not cause GC hitches because it has no GC. (in fact it has more optimal memory usage without the .NET runtime because of its memory management model being mostly reference counting and a linked tree) The biggest problem with .NET specifically is the GC which you have no control over and you will always have to wrestle with, and since you have no control over it (and it makes no guarantees) you can only pray and hope it does what you want when you want it to. Except that doesn't work because GC hitches are the most widely recognized and complained about problem in .NET and you literally have to build your entire game project around trying to avoid them. I don't have to do this in GDScript, C++, Swift, or Rust. Even Lua's memory management tends to be better. The more control over memory you take away, the less optimization you can natively perform in the system, and C#, especially Mono, has a massive optimization problem in game development. Go ahead and look into the games you just named, I can bet you every single developer involved would tell you much the same in regards to the GC being their biggest untamed enemy, you don't even have to take my word for it, I'm mostly reiterating the experience of others alongside my own experiences, its not just me.
If other languages like GDScript would stop copying Python's obnoxious indent-sensitivity I might be on board, but I'm not dealing with forced whitespace formatting.
@@Cathowl Yeah, I don't like that either, I prefer having something visible separating semantic blocks, and there are definitely languages you can use with Godot via GDExtensions that do accomplish this, like Swift, truthfully I'm not that up in arms about it so I'm fine with Python and GDScript, but you can use things other then C# and .NET, honestly the GDExtension bindings are likely to be better then the C# offering in 4.2 anyway.
@@Spartan322 It's probably more of a problem for me because of the way my brain processes stuff, but I just can't use Python and other forced whitespace formatting languages. I also don't really have the brainspace to explore around lots of different languages either -- because of disability -- so I have to pick one or two and commit. I picked C# partly because it's popular and also I've some small amount of experience with C++ from earlier attempts to make games, so I know I'm comfortable with that family. I've been tempted sometimes to try LISP and had recommendations to try PERL, but I don't really know whether I'm going to get into a second language at all and if I do it's not going to be soon... I have to focus on one thing at a time to get anything done. So. Platformer in Godot with C#. That's my goal. If I get that done then I can think about next steps.
Thanks for showcasing the new Chickensoft demo!
Thanks for making this available for the community!
@@barnesnplebian6462 my pleasure :))
I’ll be checking this out since all my scripts in my main project are written in C#. Thank you!
This looks great! Gonna take a look.
I'm glad I bit the bullet and went all-in with GDScript when I switched to Godot. Realizing the WHYs behind the language sealed the deal (aside from the not so great current C# support). And GDScript is very approachable for a... novice programmer like me.
Still, it's great to see resources like this for folks who prefer C#.
As a longtime C# developer, I can tell you...
There's nothing wrong with using GDScript! It is still real code and you are still a real programmer.
The primary reason to use C# is if you have existing experience and libraries in C# that you want to leverage. If you're writing everything from scratch anyway, there's no reason NOT to use GDScript, and there are several good reasons you SHOULD use it.
@@cdarklock Right on! I was never very fluent in C#, so it was easier for me to switch since I have to keep learning either way.
But the biggest lesson is that coding concepts are mostly universal, and the language is mainly just the syntax the ideas are expressed with.
(although I must say I actually do miss those cute curly braces! {❤️} 😂)
@@cdarklock Bad take. Any proprietary language is always a bad choice and a dead end.
@@SylvanFeanturi If the language dead ends where you're going, it doesn't actually matter
@@SylvanFeanturi Bad take. GDScript is not a proprietary language it's FOSS like everything in Godot.
But your point is that it's only used in Godot ? If you are already a dev going into Gdscript is really easy and doesn't ask a lot of effort and if you're new to programing and want to play with godot it's a lot less comple than C# as a first language and allow you to achieve things faster and it still allow you to learn the basic of programing.
Great to see. Thank you! Been doing C# for decades now and just started getting into Godot in the last few weeks and love it. Looking forward to checking this out in detail to learn more! ❤
Thanks for a quick overview before jumping into details
Coming from Unity, I went to use C# in Godot. I used a bit of GDScript as well.
Just to let you know, I am making a horror game in Godot 4, programming entirely in C#. It isn't much, it's just a mix of Slender and Dark Deception.
OMG THANK YOU FOR THE FIRST ONE. Even though I'm not making a platformer, I've been trying to use C# with Godot and it's been ... Pretty terrible. I didn't have this many issues with Unity, granted, I am still relatively new to programming in general. But I'm just having the WORST time. I could do just about everything I needed/wanted in Unity but in Godot the most basic things are so frustratingly difficult. idk why. :| So, hopefully this will help give me some ideas xD
The only thing this show me is how the dotnet ecosystem is treated by godot. We're in version 4.X and this is basically the first vertical slice of a full project we've got. I thought this video would be a "look at all the amazing thing we can do!" but i'm 2 minutes in and all i'm hearing is warning about all the errors i'll get running this project. When you find resources about people trying out Godot they don't even bother with dotnet EVEN IF the engine they comes from is C# only. It just fucking sucks. I wish C# got more attention from, well, everyone.
You gotta keep in mind that, Godot didn't had C# support until microsoft donated a lot of money to add C# Support
Firebelley Games develops his projects in C# if you're looking for a reference.
Yesssss! C# !! Thank you.
I would really really love it if they hammer down better c# support!
Like, equally as well supported as Gdscript. I feel like that would give godot a really big chunk of the Unity escapees
It's been getting better, although it was gimped when they went to GDEXTENSION
It will never be as supported as GDScript.
Since the engine API is designed around a dynamic language in mind (all those Variants and dynamic collections and marshaling of types), every statically typed language will forever suffer from it, be it C#, Rust, or even C++ itself.
As a 13-years .NET developer it pains my heart how bad C# support in Godot, but what pains me more is all commenters in Godot subreddit who proudly state that C# support is excellent. It is not.
@@thegameissimple I mean, this isn't an enterprise software suite, it's great for game dev
That abandoned spaceship demo looks like it could be from Star Wars.
I went into godot expecting to hate gdscript... total opposite. I LOVE it. It's honestly so polished. I haven't had to write any advanced algorithms yet, but I did write an entire character controller in gd script and it was great. No complaints. My day job is in C++ so I'm pretty biased toward strongly typed languages but gdscript has a great linter and the option to write it in a strongly typed fashion. It's great!
And if you use static typing you have a speed boost. You can also enable static typing by default and tell engine to not run project if you have anything that is not staticly typed.
GDScript is nice, but performance still trails behind C# (or C++). As mentioned above, static typing helps with performance but still a noticable performance difference between C#. Also C# has a lot more language features and flexibility.
@@ShiloBuff Problem with C# is dependency and runtime, also GC which is not actually a scalable solution to game development, honestly non-GC runtimes are just inherently more scalable (specifically reference counting, RAII, or pretty much anything that isn't a GC tbh) because you have control over memory which is actually quite crucial to game development if you care about speed, if you really need that speed, (especially since you can better take advantage of SIMD/vectorized math and the CPU cache, which GC languages kinda suck at) C# is honestly the last thing you really probably should be reaching for, but you do you.
@@Spartan322 So you're saying... don't use Godot, use something C++, aka Unreal.
Key Links
--------------
gamefromscratch.com/godot-c-development-sample-new-rendering-demo/
-----------------------------------------------------------------------------------------------------------
*Support* : www.patreon.com/gamefromscratch
*GameDev News* : gamefromscratch.com
*GameDev Tutorials* : devga.me
*Discord* : discord.com/invite/R7tUVbD
*Twitter* : twitter.com/gamefromscratch
-----------------------------------------------------------------------------------------------------------
The light demo looks neat
Interesting that this gets released around the time of the Unity Unite conference. This might be a topic talked about in the corridors.
For advanced scenarios Unity has some specific features that are hard to beat, especially for mobile and XR studio's. However the pace of Godot innovations seems much faster compared to the ones for Unity like DOTS/ECS and the render pipelines. It may be that the Unity innovations are more complex and aimed at professionals, but the momentum that Godot has will have an impact on the gamedev community.
As it looks now, Godot seems to take over the education and hobbyist market, possibly added by high level engines like RpgMaker that will use it as their base. The market for asset packs and plugins follows the hobbyists, so that would change too. It seems like a long term process, but it may unfold itself at internet speed.
Godot actually works great for VR stuff, obviously Unity is more advanced but Godot is QUICKLY encroaching on that niche. It's super easy to set up and the built in tools have a bunch of stuff
I still haven't switched to Godot 4 yet, because I'm still making games in Godot 3.5's 3D.
This is good for people coming from Unity.
The third person controller demo that the Chickensoft project is based on and most of the assets are courtesy of GDQuest not GDScript as mentioned in the video.
I am sorry, but your videos are quite difficult to watch. You repeat yourself over and over and jump back and forth between different projects. I am subscribed to you because you are a good news channel, but it is exhausting to watch your videos until the end.
1. C# Project
2. Hangar demo scene
3. C# Project - Cutting edge, C#, frustration, NuGet problems
4. Hangar demo scene
5. C# Project - Full C# game, pretty straightforward but then .NET/C# is tricky, issues, NuGet problems
6. Hangar demo scene
7. C# Project - C#, pain points, ...
Why not:
1. C# Project
- Demo
- Where to get
- Details/problems and how to resolve them
- Conclusion
2. Hangar project
- Demo
- Where to get
- Conclusion
I didn't have any problems with his video. I thought that his message was quite clear and found this to be an informative video. But, this is my opinion.
I feel the same. not all videos though
@@MuhammadHosny0 Yeah, not all but a well-designed script can't hurt.
Mike may have room for improvement, as putting video's out at a super fast pace does take a tole. It's a bit like a friend showing me a new tool and I gladly overlook production issues for speed and enthusiasm. It's a bit like Udemy being quite crappy generally compared to Pluralsight, as that has much higher production values and it's more applicability for the enterprise. Still it has it place as video's arrive earlier earlier and on more exotic topics. Also the presenters are people from the trenches thus having more credibility, just like Mike, as he has been around for a while.
I'm going to far, but you seem quite intelligent, so humour me. On the classic Aristotle's Rhetoric theory, Mike scores quite well on Ethos, Pathos and Kairos, but you point out quite elegantly that Logos could be better. 3 out of 4 is better then most. That said, if he starts to speak with a thick Indian accent, I'm at my limit too. I have some comprehension skills, but I'm not a mind reader. ;)
Mike is a great guy and he is an enrichment for the game dev community. That's why I care. If he improves his scripts (my subjective opinion) + his existing passion for game dev => Even a better channel. That's why I pointed it out.
I'd understand wanting to use C#, if that is all you know. Even though I'm interesting in learning C#, I will stick with GDScript that I find rather easy, because I already had a basic understanding of Python. No bull shit setting up, or trying to solve problems to use a language that isn't even officially supported.
Have you seen road to vostok?
Funny, I remember trying C# with Godot 3.x and THAT was actually terrible. Compared to then C# feels like it's in a pretty good spot and I didn't run into any issues during my setup while following the Godot 4 documentation.
That being said reading the documentation is absolutely crutial as a lot of things work differently for the C# side of things.
For now though I'm having a great time, no way I can live without my interfaces.
Thank you!
So cool! Can't wait to work with c# Godot after work!!! Also sir you seem to have a thot, I meant bot infestation.
C# workflow has been much improved in Godot 4. But it doesn't support exporting to the web platform right now which makes me very frustrated :-(
2:32 Ah cool to see myself in your video.
As usual, thanks for your top-tier content!
Regarding errors: Beta 6 is unusable for .net development. Closing the editor freezes entirely. I was hopeful in the future of C# in Godot but starting to feel like they aren't even testing the mono editor which doesn't show much promise for their priorities.
The whole point of the betas is to bugfix, there's plenty of bugs in the betas that have been just as much a pain in the ass, there's a reason they tell you not to use them on production.
Betas are testing. And the freeze that you are referring to was identified before that and got a mention in the blogpost in the "Known issues" section.
You said the assets are from "GDScript", it's "GDQuest"!
I'm so sad that there is no C++ version of Godot :(
There is a plugin, but it works differently than the standalone version of the engine, right?
I'm glad that C# is becomming a more supported option; but the lighting show case was kinda poor. The interior lighting was great, but exterior looked like it was in a cave. Also it was obviously lagging a lot (low fps). Not a good show case when your fps dips below 60, or is your PC a potato? Because I've noticed this in other videos, you showcase features and the fps just drops in the game engine environment you're showing.
GDS is more robust in Godot so I would never choose c# especially when GDS is easier to code in.
However, UE should support c# which is unfortunately not in the hands of hobbiests and we have to wait for epic games for that.
Mike, where is the C# version of the Abandoned Spaceship Scene project?
"In addition to the Godot C# project we also showcase a open source Godot 4 scene showcasing graphical capabilities using Godot." OK so the title of video is a bit misleading.
Far more interested in using C or C++ with the godot engine, do I still have to deal with GDNative for that or have they figured out a better abstraction?
I don't use C/C++ with Godot, but they no longer use GDNative and replace it with GDExtension
Gamesfromscratch did a video on it : ruclips.net/video/7PpOgnujtAg/видео.html
As long as Godot continues to refers to game classes using .cs files, C# in Godot will never be good.
I think if you are really good with C# , translating GD tutorials should not be that hard. I tranfered a Java tutorial to Kotlin to make a phone app. Kotlin has alot of gotchas compared to GDscript.
Yeah, a lot of the programming stuff translates over to other languages. The main thing that is different is learning how it works with the editor/engine and how to use the new API
I come from c++ and while I find it a lot easier to use than c#, if needed I can still pick up c#. It even translates to swift
@@KomodoBitGames I agree, I am studying C++ and C for Allegro5 game development and I want to play around with embedded programming as well.
@@KomodoBitGames I originally started in C++ as well, but I was formally trained in Java , C# and MySQL while in school. I also coded in JBasic as well. I believe the most important thing is to learn the fundamentals well. Arrays, Linkedlist, Heap, Quick, Merg sorts and understanding graphs , qeues and trees. I am currently focusing harder on Graphs , LinkedList and Trees. As long as we know all the basics well, then we can make our code more efficient, no matter what languages or frame work we use.
Is the low frame rate in the lighting demo because he run it from the IDE?, or is the scene to complicated for Godot
The latter
@@voxelvoid Runs just fine for me. Then again, I actually know what I'm doing.
I bet you do@@Cleefbag71
Whaaaaat
C# in Godot just feels clunky and hacky - until that is resolved I don't see myself using Godot. It is unfortunately a side effect of language support being an after thought and taking the backseat to the single application purposed GDScript.
GDScript is simply better for game development in Godot even if you could resolve many of those problems because GDScript has better memory management and is specifically designed with Godot in mind, you really shouldn't look down on GDScript, you really shouldn't marry yourself to one language, that's a recipe for becoming outdated.
@@Spartan322 That's true, but being able to use C# means you can re-use packages from other games without much issue (which is great in corporate environments), and also having to retrain the engineers or hire new ones will be a costly investment if the language is niche and only has one use. There are other language-specific things like C# Reflection which could also be harder to use with Godot. Not saying that C# is better than GDScript (of course not), but for the adoption of Godot to wider gamedev community and to companies (who will throw money at Godot's future) C# is pretty crucial...
@@Spartan322 I like what I like, have been a C# programmer for a very long time now, it is my favourite language and always will be, well perhaps with the exception of 6502 assembly.
@@FoxInFlame Truth be told, I don't think C# is a suitable game dev language for the simple fact that GCs are horrible for performance, CPU cache lanes, and SIMD/vectorized instruction sets, GCs tend to scale really poorly because their memory footprint becomes exponential and there is simply nothing you can really do to stop that. (and that becomes crucial as a game's size grows)
Most corporate environments actually tend to prefer runtimes that manage memory a lot better, C++ analogous languages being the target most of the time, if you know C and C++, 99% of the time in corporate hiring you'll be better off, I generally see a lot more one off development in GC languages, like web design, build systems, or package management, but in a serious product that stands over a long time, unless the product itself is small, it becomes more efficient to use a system that doesn't automatically handle memory with a GC.
Smaller companies and indie studios tend to use Unity more but as they get into bigger enterprises they either use a custom engine or Unreal specifically because performance is critical and pretty much all of the time that's in C++. So it be more accurate to say not corporate, less you be working in producing small services, which you can but usually people aren't aiming for those types of jobs in software.
"There are other language-specific things like C# Reflection which could also be harder to use with Godot."
Actually Godot's reflection is kinda better then .NET's to be honest, part of that is because the reflection is a lot simpler so it actually will trend towards being less expensive because its more upfront. Definitely helps that the references are returned from memory which should generally be cheaper.
And I'm not saying Godot shouldn't support C#, but I'd say its better to treat it much like the Rust, Python, or Swift extensions which it will be getting at some point anyway, but GDScript is just going to be always be better then C# for Godot, just as GDScript will always be better then anything else, though the interface for marshaling with Godot in C++ via GDExtensions is freaking nice, .NET can go to hell for in comparison.
@@Spartan322 GDScript may be good for interfacing with the actual engine, but when it comes to writing actual engine-agnostic code such as game logic etc. it's bad, like laughably so.
I’ve been coding in C# for over 20 years… and for Godot, I prefer GDScript.
It’s just nicely integrated. I’ll stick with GDScript as long as it’s fast enough for gameDev.
Any progress on solving shader compilation stuttering problem?
No?
Hard pass then
No engine can compile shaders at runtime without stuttering. You either precompile them, or do it at runtime and deal with stutter.
@@SnakeEngine I choose to let the shaders be compiled by the engine without me doing anything about it - as it should be done.
I don't really understand why Godot devs couldn't just make it happen, it is a basic functionality.
They could just leave running the game in the editor without compiles and then compile the shaders when making the final build.
Is it really that hard to do?
@@voxelvoid You are just using a default setting of shader precompiling. Just set it in your engine of choice if it is not set by default and you are done.
@@SnakeEngine You haven't used Godot once in your life, have you?
@@voxelvoid Used it once, but I don't need to. But like in every engine, you should be able to just precompile the shaders. It's as simple as that.
🥸
Nuh uh
I find C# for godot as not good step forward. Maybe it would be better to invest resources to create a very good visual scripting language for godot, similiar to the most popular languages, like bolt and gamecreator for unity. Such a powerful visual language combined with manual scripting would be a game changer for godot, because such platformer games and other games would be created in essentially no time without the need to connect signals and solve complex code. If someone knows c#, gdscript can learn quickly, but it doesn't work the other way around. On the other hand even kids can learn visual programming, it's really easy for non-coders and can make coders from non-coders as they are progressing and implementing custom code.
The issue is that Godot already HAS those bases covered though. It has a bunch of early-game hobbyist items, GDScript being the biggest one. It's when you start to make an actual full-scale project that things get bad, and it's that end-goal that needs more support right now. (well, really the beginning middle AND end that all need work, but less so the introduction into it all)
Also, Godot used to have a Visual Scripting language. They dropped it for reasons I do not know.
Would be nice if godot focused more on C# as well, making it more native instead of unwanted orphan.
Honestly, C# is kinda a terrible solution for game development, the runtime is expensive, the GC will get in your way, and there is absolutely no memory stability, also .NET doesn't like the CPU cache and sucks at SIMD/vectorized instructions. Kinda wish more people were willing to actually make themselves useful and learn other languages and runtimes, C# is a tool, too many people treat it like a religion.
Subnautica proves you wrong. Stardeus proves you wrong. In fact, there is a whole load of games written in C# that prove you wrong.
@@Cleefbag71 No they don't, because they had to use "non-alloc" (which is itself a misnomer because "non-alloc" does in fact allocate, and is likely still to create garbage, it just optimizes the allocations and the minimizes garbage it creates) interfaces just to get the game to run. The fact "non-alloc" interfaces exist demonstrates that the language and runtime are terrible for game development, (it means that the language and runtime do not natively provide any manner or structure to optimize, which .NET does not) a good interface should have a native manner to optimize performance without jumping through extra hoops because of the runtime and the language. GDScript for example will not cause GC hitches because it has no GC. (in fact it has more optimal memory usage without the .NET runtime because of its memory management model being mostly reference counting and a linked tree) The biggest problem with .NET specifically is the GC which you have no control over and you will always have to wrestle with, and since you have no control over it (and it makes no guarantees) you can only pray and hope it does what you want when you want it to. Except that doesn't work because GC hitches are the most widely recognized and complained about problem in .NET and you literally have to build your entire game project around trying to avoid them. I don't have to do this in GDScript, C++, Swift, or Rust. Even Lua's memory management tends to be better. The more control over memory you take away, the less optimization you can natively perform in the system, and C#, especially Mono, has a massive optimization problem in game development. Go ahead and look into the games you just named, I can bet you every single developer involved would tell you much the same in regards to the GC being their biggest untamed enemy, you don't even have to take my word for it, I'm mostly reiterating the experience of others alongside my own experiences, its not just me.
If other languages like GDScript would stop copying Python's obnoxious indent-sensitivity I might be on board, but I'm not dealing with forced whitespace formatting.
@@Cathowl Yeah, I don't like that either, I prefer having something visible separating semantic blocks, and there are definitely languages you can use with Godot via GDExtensions that do accomplish this, like Swift, truthfully I'm not that up in arms about it so I'm fine with Python and GDScript, but you can use things other then C# and .NET, honestly the GDExtension bindings are likely to be better then the C# offering in 4.2 anyway.
@@Spartan322
It's probably more of a problem for me because of the way my brain processes stuff, but I just can't use Python and other forced whitespace formatting languages.
I also don't really have the brainspace to explore around lots of different languages either -- because of disability -- so I have to pick one or two and commit. I picked C# partly because it's popular and also I've some small amount of experience with C++ from earlier attempts to make games, so I know I'm comfortable with that family.
I've been tempted sometimes to try LISP and had recommendations to try PERL, but I don't really know whether I'm going to get into a second language at all and if I do it's not going to be soon... I have to focus on one thing at a time to get anything done.
So. Platformer in Godot with C#. That's my goal. If I get that done then I can think about next steps.
jonbcrist