Just wanted to apologise for a previously slightly clickbaity video name & thumbnail. I don't think I'd recognised that initially, as I created it in the context of my journey. It wasn't meant to be misleading, and I'm sorry. Hopefully, the updated title & thumbnail should make it far more reflective of its content.
As someone that writes my own engine in C++, I can pretty much say that a beginner should never start with C++. C was my gateway into lower level programming as it is way more minimal, and it made it a very smooth transition over to C++. If you wanna learn low level stuff, learn C first. Also when it comes to cross platform development, that is a whole different kettle of fish. Im writing the platform layer for mac in my engine in Objective-C for example. Granted Godot would do a lot of that stuff for you, but still.
Thanks for the advice, I think if I come back to more complex languages down the line, I will likely look to do this. Also it's nice to see that I'm not the only madman trying to do stuff on a Mac, which seems a minority choice vs Windows or Linux.
@@TheInfiniteInkwell Yeah mac is in the minority because no one sees the point in porting because the market is so small, so the market stays small :/ Im doing my bit, I'm porting my game and engine to Windows & Linux in addition to natively running on mac os. Maybe also consoles if the game actually catches on :D
@@TheInfiniteInkwell actually, Mac is kinda a unix-like platform, so it's probably easier to use Mac for cpp development, than Windows. For example, package managers can help a lot, and Windows doesn't have one. Unix-like filesystem structure is tailored around c\c++ dev, and Windows doesn't. Cpp is an eldritch incantation black magic, but it's so worth it, when you master it. Instead of giving you the tools to code, cpp gives you the tools to make your tools, and that's something magical.
Just to clarify, the Godot engine is written in C++, so C++ is THE native language of the engine. GDScript is basically an easy-to-use scripting language that allows easy access to those complex Godot engine API functions, and it's used to script gameplay rather than build functionality. Just thought you'd like to know what each of the languages are used for, If I were to give you an advice I'd say to continue with Godot rather than GMS, and start learning C#, it's a much easier language compared to C++ and won't melt your brain :)
Ahh that's really interesting, thanks for the explainer. I think if I go down the Godot route, I'm definitely going to consider my options. Knowing C# won't slowly melt me is reassuring! 😂 Thanks
"easy-to-use" as long as you can stand the horrendous syntax, dynamic typing, lack of classes or structs, no way to import or include another gdscript like a header file and the inability to dictate whether the thing is passed by reference or by value other than by wrapping it in another type but then you need to write a lot of extra code to ensure the proper thing is being passed. i really wish godot would support a C style language out of the box, i don't even care which one and i don't even care if it's interpreted,JIT or compiled. just something normal and explicitly not python style syntax.
@@logangraham2956 Godot has a c# build on their main website. its not C or c++ but its way closer than GDScript. the c# build also has GDScript and allows you to mix and match languages over different scripts.
@@logangraham2956 Godot has a c# build on their website, it allows you to use gdscript or c# in your scripts. This has been standard for godot for a while it's just not what most tutorials use. the script editor built into godot isnt great for c# but you can link godot to vs code or another IDE
@@logangraham2956 i would recommend c#, i believe is almost as easy, but has way more use in real life. GdScript is worse in every aspect outside being a little bit easier
It's the journey that makes you grow. Not the successes nor the failures. Personally, I think that going with C++, working through the difficulties, and then deciding to look for something else, helped you refine what is it exactly that you want and what works best for you. Your decision process is now based on a much stronger foundation.
Scripting will introduce different challenges though. So don't think you are off the hook. There's the problem of structure and organization of your codebase that now will become more spread out and less clear. I don't suggest making your game projects too big or complex. Another concern is technical limitations that these script languages introduce that may stop you from pursuing a game feature or a design choice. My suggestion is for you to not plan your project to far, but instead in smaller chunks, so you can understand whether you can implement your vision or not and then adjust it to the reality of the tools in front of you.
Thank you so much @Marfig ! My aim is to try stuff and be willing to fail all the way through this process. Your suggestions around game building have actually helped with some of my thinking about the game itself. Chunking things into different areas or types of gameplay. I think at some point the planning of this will be a weirdly interesting and exciting thing to do. Thank you for your kind words of support and advice.
I've written C for over 20 years but I struggle with C++ and and some modern build environments. I don't think anyone writes their first anything in C++, the bar of entry is just way to high.
Did anyone ever ask the question, are Classes really a good idea? I kinda think the concept might become outdated in time to give rise to a more intuitive solution. Ironically Godot possibly shows a better solution with it's nodes based order to everything...😆
Props for giving it a go. There is also a visual scripting plugin for Godot if you want to keep everything on a level playing field (drag-and-drop code).
C++ and openframeworks is nice and easy . Mac friendly too. But my honest advice is don’t worry about engine . Just make a commercial game on itch in the next 7 days in any language it can even be pen and paper, just get it done. That will help you much more than engine comparisons .
Thanks for sharing your experience. I will take a look at Openframeworks - especially as it's Mac friendly. I've already started my game design document and outlined a lot of the story, features that I wanted to include, the art style, mechanics and such. The engine felt like the best next step in understanding where the best place to build it would be. I did consider the seven-day thing, but I didn't have the time to dedicate to it in one big hit and didn't feel like it was enough time to build a more interesting story.
That's a fair question. For some reason my Terminal just kept rejecting the command. I thought I'd try it again as I was replying to you, and now I've installed Xcode and the command works first time 🤦🏻♂️
I'm so glad I have come across your channel! I am currently learning C as I want to learn this for entry level and will then learn C++ for game development. I am also looking at GameMaker myself.
Thanks so much! It’s definitely not the easiest, but it’s quite rewarding to see things come to life. You got this! Good luck with your game dev journey too! Do you know what you want to make first?
Any type o programming in C or C++ demands strong knowledge about program logic and program design, algoritms and design patterns used in game programming. C++ is not for noobies or people dont love coding is for profissional programmers
Thanks 😀 100% its part of the learning process, I think you're right that I would have regretted it had I not explored it. Also there's no reason why I might not revisit it at a much later date if I think I need a more powerful language. Likely not for this game, but maybe a future one, at least I know some of the challenges with it, but with a bit more experience under my belt, it might not be as daunting.
Haha, thank you. I think sometimes it's always worth a look, even if it scares you off of something. Sharing my perspective as a complete newbie, is hopefully useful, for those looking at game dev for the first time.
Unless you're rewriting Godot's code (like how it load sprites, objects etc), any Godot bindings for any programming language will produce essentially the same performance. They all are interfacing with the Godot API (Essentially code that can be interacted with other languages on top of what Godot use, which is C++). So the only real reason one should considered when using C#, C++, or other languages over GDScript is a matter of *preference* and nothing more (unless, like I mentioned earlier, you want to rewrite some of the engine's source code itself, then you have to use C++ there).
there is overhead. Just looping over a lot of elements is slow in scripting languages (e.g. 1024x1024). GC is known to cause GCpauses late in development. If you need to do something computationally expensive, then slow languages are too slow. Doesn’t matter often, but when it does, it does.
"So the only real reason one should considered when using C#, C++, or other languages over GDScript is a matter of preference and nothing more..." I utterly disagree. Sure, preference is a factor, but the main reason you'd choose C++ (or even C#) over GDScript is performance. C++ will blow GDScript and C# out of the water in terms of the amount of game logic processing you can squeeze into a frame. So for computationally heavy games, like... Kerbal Space Program, Factorio, etc., C++ would be the shiz. If you're doing something... less extreme, such as a cosy farming game, you would likely be fine with one of the interpreted options.
@@TheBunzinator I don't think you read my comment correctly. C# binds on godot API... just like GDScript.... you can't really do anything performant if it's calling the same exact code.... LIke I said you have to directly modify the Godot API to do your own way of rendering etc etc, which would only mean you can use C++ since that is what Godot is written in. Probably you can kind of use plain C as well because it interop with C++ but I digress. If you want to actually do low level / performant stuffs imo just use a game framework and not a game engine / code your own graphics thing with OpenGL. In your quoted text of mine, I was referring to using C# and C++ as just an API caller, much like GDScript. In which would resulted in the same thing with calling them inside GDScript itself. I was not too clear in the original comment I guess, but this reply should make it clear that I do think you can optimize stuffs, but only if you code in C++ and you interact with the Godot source code directly.
@@opposite342I'm talking about code that doesn't hit on the Godot API often. So, things doing intensive looping over non-godot data structures are going to be enormously more performant in C++. But sure, for many cases that rely mostly on working with Godot internal code, it's not going to make that much of a difference. It really depends on your use case. And preferentially, I try to avoid GDScript because I think indentation defined blocking is a hideous abomination. :)
@@TheBunzinator fair point but it's not as important as the rendering process itself + technically if you really want you probably can do a transpilation of sort downwards, but yeah
I haven't even got around to trying C# with Godot yet. Thinking to do that to revive my C# ability which is years old now. C++ must be painful since it requires building the entire engine each time that you run the new code.
If I'm honest, given what I experienced, I think if you're already familiar with GDScript, I'd only look at C# if it's going to give you something you absolutely need. I think this is somewhere else I think where C++ was a mistake for me - it's far more powerful and lets you control some complex things, but I don't need them.
C and Raylib is a good pairing. Its an open source cross playform libary. The things I write tend to lean to being cpu heavy games with the graphics just providing the interface and information to present the user. Its a lot of work but I would work with my tilemap over godot's even though theirs is probably much better just because I know it in and out.
I've not heard of Raylib before, I'll take a look thanks. I'm intrigued to see the games you've made, if you're ok to share? Also with a lot of this, sometimes being comfortable with a tool makes it far easier to use. Switching platforms adds a learning curve that slows everything down.
Pretty sure for starting out Odin + Raylib is better than C, but to be fair Raylib does handle a lot of the hardwork you have to do already to get things runnings so maybe using C is fine too. Still, if you want to try Raylib, go check out all the programming languages that you can interface with Raylib first (there are more than 60 languages that has Raylib bindings, though each with different level of supports) and pick the one you think you'd be comfortable using the most.
If you are really good at story then you should focus on creating the story of a game and communicate with C++ developers to make your story come alive in Godot. C++ is just a different beast to tame. It is difficult that you even need to spend at least 6 minutes just to understand the basic. Also, making a game needs multiple files so it's like creating multiple "windows" of codes and make a "source code" of all the the "minor" source code to build a functional game especially if you are dealing with 3D.
Yea, with C++ you'd really have to go through the basics first, with a book or something, and it would still take you some time to become productive with it. It's kinda like pushing a train into motion: it takes a lot of energy and starts very slow. I think what you did is still valuable, though. There are many things in programming that can't be taught by words, only by experience. Often you have to try something yourself in order to actually see the problems and understand the "dos" and "don'ts". Sometimes it can be a waste of time, but then sometimes you learn something valuable. Trying out different engines is a good idea too, I think. You never know, some other engine might click better with you. I'm quite fond of the way GMS workspace is displayed. It's pretty neat and unique.
Thanks so much for sharing your experience. That's exactly the mindset I've been going with - try and fail, because you learn a load from failing. I don't mind wasting time if I learn from it. I did like quite a lot about GMS, the workspace display was a big contributor to wanting to look at it, same as Unreal for Blueprints. I may have judged it harshly as I looked at it after I looked at Godot, but I'm going to try and be more balanced when I make my final decision.
@@TheInfiniteInkwell yea, normally I go with Godot myself, mostly because Unity never clicked and Unreal doesn't even like my potato (and I don't really like blueprints -- or C++ for that matter). I don't use GMS myself, I just think it's quite interesting. I tried it a few years ago, and I've been keeping it under my radar as it evolves, and I do recommend it as a worthy option to consider. What I do also use is Love2d, but I'm not sure I should recommend this to absolute beginners. It's a plain framework without the bells and whistles of Godot or UE, so it may be a bit more difficult to learn, as you have to do many things yourself (e.g. animate sprites through code). Being more bare-bones is why Love2d's performance goes through the roof though (that, and Lua being a very fast language).
@@TheInfiniteInkwell seems like youtube deleted my reply (as it often does), so I'm just trying again: Yea, normally I go with Godot myself, mostly because Unity never clicked and Unreal doesn't even like my potato (and I don't really like blueprints -- or C++ for that matter). I don't use GMS myself, I just think it's quite interesting. I tried it a few years ago, and I've been keeping it under my radar as it evolves, and I do recommend it as a worthy option to consider. What I do also use is Love2d, but I'm not sure I should recommend this to absolute beginners. It's a plain framework without the bells and whistles of Godot or UE, so it may be a bit more difficult to learn, as you have to do many things yourself (e.g. animate sprites through code). Being more bare-bones is why Love2d's performance goes through the roof though (that, and Lua being a very fast language).
Ha ha, my glasses mostly have a yellow tint to them, it's meant to help with eye fatigue. I end up spending about 10-15 hours a day in front of screens, so anything to help them is a win for me. Also some colours look more vivid with them, which I did not expect.
even if you use unreal engine, I'd say just use blueprint visual scripting. you're not trying to make AAA game with hyper realistic graphic and complex real time calculation, so the performance differences would be negligible. I'd even recommend people to start making pen&paper game to understand the game design in general.
Thanks for the recommendation. I'm looking at Blueprint in an upcoming video, I think it'll be an interesting experience, based on what I learnt when I looked at GameMaker. I'm really hoping it's very intuitive. I've already done a lot of documentation on the game I'm trying to build. I have a game design document outlining the story, mechanics, design and that sort of thing. I think after the engine, art & design will be a big element, as will be organising my work.
@@TheInfiniteInkwell maybe try analyze the scope carefully again. My original project was big enough to make trilogy out of it, then just the first part was so big that it's required me at least 2-3 years to finish it. Now since I cut down until the very minimum, it should be within a few months or so I hope.
@@dreamingacacia@dreamingacacia That's so cool that you have something that deep. And now you have future games in the pipeline too. I have a future idea that could be like that, but it certainly won't be this one. That's going to be one of my next tasks after the engine evaluation. With what I'll know at the end, I'm hoping I'll have enough to reevaluate my original idea.
@@TheInfiniteInkwell Well it's been over 10 years since I started gamedev, though only around 3 years since I do it seriously. Not to mention I had some level of interest in designing my own games since I was 12, though I took the novel writing path instead for early life. Now I'm getting 32. So 20 years. My gaming life started at 3 which is much faster than people in my generation.
As i dev working in industry i tried to learn C++ as my first programming language when i was making my first games in The Game factory back around 12/15 years ago and decided i need to learn C++ to make 3D games and i got soo blocked by it and gave up on programing early. Couple years later i was learning unity and C# language and this language really open the can for me. No Pointers and Memory management. Just focusing on creating. Really if youre like total psycho(inpositive way) that can learn and track multiple things at once, C++ its great for start. But if you're not. Welp There is plenty easier languages like Python etc. For me, when i started using C# i felt like "Wow i feel like i am programming!" :D
Thanks so much for sharing your experience. Ha ha, I can confirm I’m not that level of psycho. That’s great you found that with C#. I am hoping to find something that feels right as I go on this journey. Maybe at some point I’ll have that same reaction.
Fair question-C# would have allowed me to use either Godot or Unity. Given their behaviour last year, I have some pretty big concerns over Unity, and I don't think I could trust them as a new game developer. C++ would have allowed me to look at Unreal in a bit more detail, with greater flexibility.
For your first project go with the tools that are used the most and have the best support. Also game dev is done on Windows, you are going to constantly find doing things on your Mac are a pain in the ass. Make life easy for yourself and start using Windows now. I’m a Mac user and if you were doing regular dev I would say use the Mac but you are just making life difficult. Good luck ! And remember me when you are swearing at git 😊
Thanks for your thoughts, I've been doing a lot of reading about the tools and I think I have most of the recommended ones now. I think given the expense of moving to Windows (buying a decent machine), I'll probably soldier on right until the point where I'm spending more time troubleshooting Mac specific issues vs developing. I'm hoping it'll be alright for art work design and exploration, which will buy me some more time. Thanks so much for your support! I'm sure there may well be a video in the future which is just my thoughts on Git, which from what everyone has told me, will just be complaining 😂
Interesting, thanks for sharing your experience. I didn't pick C# because the other main engine it would have brought to the table for consideration was Unity. Given their behaviour last year, I have some pretty big concerns with them moving forward. I think it might be a fallback if I get to a point where I need a more flexible language if I go down the Godot route.
I'm hearing a lot of Windows & Linux championing within Game Dev. I think it might be a consideration, as and when I move to a PC platform. I think trying to do it on the OS on my SteamDeck will be a stretch 😂 Thanks for sharing!
@@TheInfiniteInkwell there's actually a hack: a unix-like environment called MSYS2, that allows to use clang/gcc on windows, so you can develop on whatever OS you like and have the same build system working on every platform
Ha ha, Mac is what I've got for now. If I were to move over to a Windows build it would be quite the expense, but it's on the list of considerations. Definitely if I intend to stream.
Just wanted to apologise for a previously slightly clickbaity video name & thumbnail.
I don't think I'd recognised that initially, as I created it in the context of my journey. It wasn't meant to be misleading, and I'm sorry. Hopefully, the updated title & thumbnail should make it far more reflective of its content.
As someone that writes my own engine in C++, I can pretty much say that a beginner should never start with C++. C was my gateway into lower level programming as it is way more minimal, and it made it a very smooth transition over to C++. If you wanna learn low level stuff, learn C first.
Also when it comes to cross platform development, that is a whole different kettle of fish. Im writing the platform layer for mac in my engine in Objective-C for example. Granted Godot would do a lot of that stuff for you, but still.
This. Learning simpler stuff in C first, and trying to do basic games in C is the way to go.
Thanks for the advice, I think if I come back to more complex languages down the line, I will likely look to do this. Also it's nice to see that I'm not the only madman trying to do stuff on a Mac, which seems a minority choice vs Windows or Linux.
for real! I recommend the K&R 2nd edition!
@@TheInfiniteInkwell Yeah mac is in the minority because no one sees the point in porting because the market is so small, so the market stays small :/ Im doing my bit, I'm porting my game and engine to Windows & Linux in addition to natively running on mac os. Maybe also consoles if the game actually catches on :D
@@TheInfiniteInkwell actually, Mac is kinda a unix-like platform, so it's probably easier to use Mac for cpp development, than Windows. For example, package managers can help a lot, and Windows doesn't have one. Unix-like filesystem structure is tailored around c\c++ dev, and Windows doesn't.
Cpp is an eldritch incantation black magic, but it's so worth it, when you master it. Instead of giving you the tools to code, cpp gives you the tools to make your tools, and that's something magical.
Just to clarify, the Godot engine is written in C++, so C++ is THE native language of the engine. GDScript is basically an easy-to-use scripting language that allows easy access to those complex Godot engine API functions, and it's used to script gameplay rather than build functionality. Just thought you'd like to know what each of the languages are used for, If I were to give you an advice I'd say to continue with Godot rather than GMS, and start learning C#, it's a much easier language compared to C++ and won't melt your brain :)
Ahh that's really interesting, thanks for the explainer. I think if I go down the Godot route, I'm definitely going to consider my options. Knowing C# won't slowly melt me is reassuring! 😂 Thanks
"easy-to-use" as long as you can stand the horrendous syntax, dynamic typing, lack of classes or structs, no way to import or include another gdscript like a header file and the inability to dictate whether the thing is passed by reference or by value other than by wrapping it in another type but then you need to write a lot of extra code to ensure the proper thing is being passed.
i really wish godot would support a C style language out of the box, i don't even care which one and i don't even care if it's interpreted,JIT or compiled.
just something normal and explicitly not python style syntax.
@@logangraham2956 Godot has a c# build on their main website. its not C or c++ but its way closer than GDScript. the c# build also has GDScript and allows you to mix and match languages over different scripts.
@@logangraham2956 Godot has a c# build on their website, it allows you to use gdscript or c# in your scripts. This has been standard for godot for a while it's just not what most tutorials use. the script editor built into godot isnt great for c# but you can link godot to vs code or another IDE
@@logangraham2956 i would recommend c#, i believe is almost as easy, but has way more use in real life. GdScript is worse in every aspect outside being a little bit easier
It's the journey that makes you grow. Not the successes nor the failures. Personally, I think that going with C++, working through the difficulties, and then deciding to look for something else, helped you refine what is it exactly that you want and what works best for you. Your decision process is now based on a much stronger foundation.
Scripting will introduce different challenges though. So don't think you are off the hook. There's the problem of structure and organization of your codebase that now will become more spread out and less clear. I don't suggest making your game projects too big or complex. Another concern is technical limitations that these script languages introduce that may stop you from pursuing a game feature or a design choice. My suggestion is for you to not plan your project to far, but instead in smaller chunks, so you can understand whether you can implement your vision or not and then adjust it to the reality of the tools in front of you.
But people have been doing amazing and beautiful games with these tools. Here's to you being one of them! 🍷
Thank you so much @Marfig ! My aim is to try stuff and be willing to fail all the way through this process. Your suggestions around game building have actually helped with some of my thinking about the game itself. Chunking things into different areas or types of gameplay. I think at some point the planning of this will be a weirdly interesting and exciting thing to do.
Thank you for your kind words of support and advice.
I've written C for over 20 years but I struggle with C++ and and some modern build environments. I don't think anyone writes their first anything in C++, the bar of entry is just way to high.
Well that's weirdly reassuring that it was only partly a noob issue and part that it's a just hard. Thanks for the reassurance I wasn't going mad!
Did anyone ever ask the question, are Classes really a good idea? I kinda think the concept might become outdated in time to give rise to a more intuitive solution. Ironically Godot possibly shows a better solution with it's nodes based order to everything...😆
Props for giving it a go. There is also a visual scripting plugin for Godot if you want to keep everything on a level playing field (drag-and-drop code).
Oooo interesting. Thanks for letting me know about that.
As a gamemaker dev - glad to see you're giving it a try. :)
It made sense to bring it back into the mix. It's been a very different experience. Your new game looks super interesting btw 🤓
@@TheInfiniteInkwell Thankyou!
C++ and openframeworks is nice and easy . Mac friendly too. But my honest advice is don’t worry about engine . Just make a commercial game on itch in the next 7 days in any language it can even be pen and paper, just get it done. That will help you much more than engine comparisons .
Thanks for sharing your experience. I will take a look at Openframeworks - especially as it's Mac friendly. I've already started my game design document and outlined a lot of the story, features that I wanted to include, the art style, mechanics and such. The engine felt like the best next step in understanding where the best place to build it would be.
I did consider the seven-day thing, but I didn't have the time to dedicate to it in one big hit and didn't feel like it was enough time to build a more interesting story.
I'm a bit intrigued what you found difficult setting up git with homebrew? It can't really be any simpler than brew install git.
That's a fair question. For some reason my Terminal just kept rejecting the command. I thought I'd try it again as I was replying to you, and now I've installed Xcode and the command works first time 🤦🏻♂️
@@TheInfiniteInkwell well, computers... It's closely related to "works on my machine".
@@strangnet 🤣🤣🤣🤣🤣
I'm so glad I have come across your channel! I am currently learning C as I want to learn this for entry level and will then learn C++ for game development. I am also looking at GameMaker myself.
Thanks so much! It’s definitely not the easiest, but it’s quite rewarding to see things come to life. You got this! Good luck with your game dev journey too! Do you know what you want to make first?
Any type o programming in C or C++ demands strong knowledge about program logic and program design, algoritms and design patterns used in game programming. C++ is not for noobies or people dont love coding is for profissional programmers
cool that you went foward anyway. In some way that was part of your learning process, and maybe in the future you wold've regret to not had tried c++
Thanks 😀 100% its part of the learning process, I think you're right that I would have regretted it had I not explored it. Also there's no reason why I might not revisit it at a much later date if I think I need a more powerful language. Likely not for this game, but maybe a future one, at least I know some of the challenges with it, but with a bit more experience under my belt, it might not be as daunting.
You did that so we don't have to :)
Haha, thank you. I think sometimes it's always worth a look, even if it scares you off of something. Sharing my perspective as a complete newbie, is hopefully useful, for those looking at game dev for the first time.
Unless you're rewriting Godot's code (like how it load sprites, objects etc), any Godot bindings for any programming language will produce essentially the same performance. They all are interfacing with the Godot API (Essentially code that can be interacted with other languages on top of what Godot use, which is C++). So the only real reason one should considered when using C#, C++, or other languages over GDScript is a matter of *preference* and nothing more (unless, like I mentioned earlier, you want to rewrite some of the engine's source code itself, then you have to use C++ there).
there is overhead. Just looping over a lot of elements is slow in scripting languages (e.g. 1024x1024). GC is known to cause GCpauses late in development. If you need to do something computationally expensive, then slow languages are too slow. Doesn’t matter often, but when it does, it does.
"So the only real reason one should considered when using C#, C++, or other languages over GDScript is a matter of preference and nothing more..." I utterly disagree. Sure, preference is a factor, but the main reason you'd choose C++ (or even C#) over GDScript is performance. C++ will blow GDScript and C# out of the water in terms of the amount of game logic processing you can squeeze into a frame. So for computationally heavy games, like... Kerbal Space Program, Factorio, etc., C++ would be the shiz. If you're doing something... less extreme, such as a cosy farming game, you would likely be fine with one of the interpreted options.
@@TheBunzinator I don't think you read my comment correctly. C# binds on godot API... just like GDScript.... you can't really do anything performant if it's calling the same exact code....
LIke I said you have to directly modify the Godot API to do your own way of rendering etc etc, which would only mean you can use C++ since that is what Godot is written in. Probably you can kind of use plain C as well because it interop with C++ but I digress.
If you want to actually do low level / performant stuffs imo just use a game framework and not a game engine / code your own graphics thing with OpenGL.
In your quoted text of mine, I was referring to using C# and C++ as just an API caller, much like GDScript. In which would resulted in the same thing with calling them inside GDScript itself. I was not too clear in the original comment I guess, but this reply should make it clear that I do think you can optimize stuffs, but only if you code in C++ and you interact with the Godot source code directly.
@@opposite342I'm talking about code that doesn't hit on the Godot API often. So, things doing intensive looping over non-godot data structures are going to be enormously more performant in C++. But sure, for many cases that rely mostly on working with Godot internal code, it's not going to make that much of a difference. It really depends on your use case.
And preferentially, I try to avoid GDScript because I think indentation defined blocking is a hideous abomination. :)
@@TheBunzinator fair point but it's not as important as the rendering process itself + technically if you really want you probably can do a transpilation of sort downwards, but yeah
I haven't even got around to trying C# with Godot yet. Thinking to do that to revive my C# ability which is years old now. C++ must be painful since it requires building the entire engine each time that you run the new code.
If I'm honest, given what I experienced, I think if you're already familiar with GDScript, I'd only look at C# if it's going to give you something you absolutely need. I think this is somewhere else I think where C++ was a mistake for me - it's far more powerful and lets you control some complex things, but I don't need them.
C and Raylib is a good pairing. Its an open source cross playform libary. The things I write tend to lean to being cpu heavy games with the graphics just providing the interface and information to present the user.
Its a lot of work but I would work with my tilemap over godot's even though theirs is probably much better just because I know it in and out.
I've not heard of Raylib before, I'll take a look thanks. I'm intrigued to see the games you've made, if you're ok to share? Also with a lot of this, sometimes being comfortable with a tool makes it far easier to use. Switching platforms adds a learning curve that slows everything down.
Pretty sure for starting out Odin + Raylib is better than C, but to be fair Raylib does handle a lot of the hardwork you have to do already to get things runnings so maybe using C is fine too. Still, if you want to try Raylib, go check out all the programming languages that you can interface with Raylib first (there are more than 60 languages that has Raylib bindings, though each with different level of supports) and pick the one you think you'd be comfortable using the most.
If you are really good at story then you should focus on creating the story of a game and communicate with C++ developers to make your story come alive in Godot. C++ is just a different beast to tame. It is difficult that you even need to spend at least 6 minutes just to understand the basic. Also, making a game needs multiple files so it's like creating multiple "windows" of codes and make a "source code" of all the the "minor" source code to build a functional game especially if you are dealing with 3D.
Yea, with C++ you'd really have to go through the basics first, with a book or something, and it would still take you some time to become productive with it. It's kinda like pushing a train into motion: it takes a lot of energy and starts very slow.
I think what you did is still valuable, though. There are many things in programming that can't be taught by words, only by experience. Often you have to try something yourself in order to actually see the problems and understand the "dos" and "don'ts". Sometimes it can be a waste of time, but then sometimes you learn something valuable.
Trying out different engines is a good idea too, I think. You never know, some other engine might click better with you. I'm quite fond of the way GMS workspace is displayed. It's pretty neat and unique.
Thanks so much for sharing your experience.
That's exactly the mindset I've been going with - try and fail, because you learn a load from failing. I don't mind wasting time if I learn from it. I did like quite a lot about GMS, the workspace display was a big contributor to wanting to look at it, same as Unreal for Blueprints. I may have judged it harshly as I looked at it after I looked at Godot, but I'm going to try and be more balanced when I make my final decision.
@@TheInfiniteInkwell yea, normally I go with Godot myself, mostly because Unity never clicked and Unreal doesn't even like my potato (and I don't really like blueprints -- or C++ for that matter).
I don't use GMS myself, I just think it's quite interesting. I tried it a few years ago, and I've been keeping it under my radar as it evolves, and I do recommend it as a worthy option to consider.
What I do also use is Love2d, but I'm not sure I should recommend this to absolute beginners. It's a plain framework without the bells and whistles of Godot or UE, so it may be a bit more difficult to learn, as you have to do many things yourself (e.g. animate sprites through code).
Being more bare-bones is why Love2d's performance goes through the roof though (that, and Lua being a very fast language).
@@TheInfiniteInkwell seems like youtube deleted my reply (as it often does), so I'm just trying again:
Yea, normally I go with Godot myself, mostly because Unity never clicked and Unreal doesn't even like my potato (and I don't really like blueprints -- or C++ for that matter).
I don't use GMS myself, I just think it's quite interesting. I tried it a few years ago, and I've been keeping it under my radar as it evolves, and I do recommend it as a worthy option to consider.
What I do also use is Love2d, but I'm not sure I should recommend this to absolute beginners. It's a plain framework without the bells and whistles of Godot or UE, so it may be a bit more difficult to learn, as you have to do many things yourself (e.g. animate sprites through code).
Being more bare-bones is why Love2d's performance goes through the roof though (that, and Lua being a very fast language).
I think you should go on a trying out different shades journey
Ha ha, my glasses mostly have a yellow tint to them, it's meant to help with eye fatigue. I end up spending about 10-15 hours a day in front of screens, so anything to help them is a win for me. Also some colours look more vivid with them, which I did not expect.
I have tryed 5 times already, still nothing to show.
even if you use unreal engine, I'd say just use blueprint visual scripting. you're not trying to make AAA game with hyper realistic graphic and complex real time calculation, so the performance differences would be negligible. I'd even recommend people to start making pen&paper game to understand the game design in general.
Thanks for the recommendation. I'm looking at Blueprint in an upcoming video, I think it'll be an interesting experience, based on what I learnt when I looked at GameMaker. I'm really hoping it's very intuitive.
I've already done a lot of documentation on the game I'm trying to build. I have a game design document outlining the story, mechanics, design and that sort of thing. I think after the engine, art & design will be a big element, as will be organising my work.
@@TheInfiniteInkwell maybe try analyze the scope carefully again. My original project was big enough to make trilogy out of it, then just the first part was so big that it's required me at least 2-3 years to finish it. Now since I cut down until the very minimum, it should be within a few months or so I hope.
@@dreamingacacia@dreamingacacia That's so cool that you have something that deep. And now you have future games in the pipeline too. I have a future idea that could be like that, but it certainly won't be this one.
That's going to be one of my next tasks after the engine evaluation. With what I'll know at the end, I'm hoping I'll have enough to reevaluate my original idea.
@@TheInfiniteInkwell Well it's been over 10 years since I started gamedev, though only around 3 years since I do it seriously. Not to mention I had some level of interest in designing my own games since I was 12, though I took the novel writing path instead for early life. Now I'm getting 32. So 20 years. My gaming life started at 3 which is much faster than people in my generation.
As i dev working in industry i tried to learn C++ as my first programming language when i was making my first games in The Game factory back around 12/15 years ago and decided i need to learn C++ to make 3D games and i got soo blocked by it and gave up on programing early. Couple years later i was learning unity and C# language and this language really open the can for me. No Pointers and Memory management. Just focusing on creating. Really if youre like total psycho(inpositive way) that can learn and track multiple things at once, C++ its great for start. But if you're not. Welp There is plenty easier languages like Python etc. For me, when i started using C# i felt like "Wow i feel like i am programming!" :D
Thanks so much for sharing your experience. Ha ha, I can confirm I’m not that level of psycho. That’s great you found that with C#. I am hoping to find something that feels right as I go on this journey. Maybe at some point I’ll have that same reaction.
why not use C#? it's natively supported in godot
Fair question-C# would have allowed me to use either Godot or Unity. Given their behaviour last year, I have some pretty big concerns over Unity, and I don't think I could trust them as a new game developer. C++ would have allowed me to look at Unreal in a bit more detail, with greater flexibility.
For your first project go with the tools that are used the most and have the best support. Also game dev is done on Windows, you are going to constantly find doing things on your Mac are a pain in the ass. Make life easy for yourself and start using Windows now. I’m a Mac user and if you were doing regular dev I would say use the Mac but you are just making life difficult. Good luck ! And remember me when you are swearing at git 😊
Thanks for your thoughts, I've been doing a lot of reading about the tools and I think I have most of the recommended ones now. I think given the expense of moving to Windows (buying a decent machine), I'll probably soldier on right until the point where I'm spending more time troubleshooting Mac specific issues vs developing. I'm hoping it'll be alright for art work design and exploration, which will buy me some more time.
Thanks so much for your support! I'm sure there may well be a video in the future which is just my thoughts on Git, which from what everyone has told me, will just be complaining 😂
@@TheInfiniteInkwell good luck, it’s tough for everyone at first !
I like c# better for Godot, interfaces, LINQ, better type checking and easier to refactor in my opinion.
Interesting, thanks for sharing your experience.
I didn't pick C# because the other main engine it would have brought to the table for consideration was Unity. Given their behaviour last year, I have some pretty big concerns with them moving forward. I think it might be a fallback if I get to a point where I need a more flexible language if I go down the Godot route.
@@TheInfiniteInkwell Oh well in that case I see why you tried with c++. Makes sense, I come from Unity after all.
Insane that a non programmer would consider C++ for anything.
how old you?
Hi bro i saw your yr channel and your killing it !! Do you need a video editor bro? I can do a sample vid for free so you can seee
Thanks for your support. I'm alright for now thanks, I'm actually quite enjoying the editing process.
Just switch to Linux - is much better for dev stuff.
I'm hearing a lot of Windows & Linux championing within Game Dev. I think it might be a consideration, as and when I move to a PC platform. I think trying to do it on the OS on my SteamDeck will be a stretch 😂 Thanks for sharing!
@@TheInfiniteInkwell there's actually a hack: a unix-like environment called MSYS2, that allows to use clang/gcc on windows, so you can develop on whatever OS you like and have the same build system working on every platform
@@TheInfiniteInkwell I'm using Godot, VS Code and Git on Mac and having zero issues. There are plenty of devs on Mac.
😄: Looking at the title for struggling cpp
🤣: Heard using Mac
So youve never written code before, yet you named your title why you quit c++ ?
The title is why he quit trying C++
@@n00bc0de7 Okay fair, i should have read the title again
c++ sucks, but mac sucks even more. quit that next
🤣🤣🤣
Ha ha, Mac is what I've got for now. If I were to move over to a Windows build it would be quite the expense, but it's on the list of considerations. Definitely if I intend to stream.
Godot was, is, and forever will be a meme engine.