Godot & C++ -- How, What and Why?

though the lady's gentleness my carrot game from scratch and today we are going to answer a question as old as time itself can you use C++ with the Godot game engine and the answer is yes you can there are three ways of interfacing with Godot using C++ and we are going to cover all three of them in this particular video now two of them are very similar but there is a key distinction we're gonna cover that as well so weird Oh further do let us jump in and take a look at the three different ways you can use Godot with your game now can you use it to write your game in C++ the answer is yes but you probably don't want we'll get to that in a minute now the first way that you can use Godot with C++ is actually a bit of a no-brainer the Godot source itself if you head on over to github and you check out the repositories such as in the core folder this is the heart of Godot these are all the projects that use on things like the mass input handling IO that kind of stuff you'll notice it's all see it's actually C++ C++ 11 for the most part right now I believe they're gonna start allowing more C++ 17 style code in there but if you wish at any point in time you can go over to github you can clone the repository and you can start making changes the key thing here is it's under the MIT source license under unlike the GPL license or LGPL license you do not have to contribute your source code back so you can download Godot and heavily modify the game engine yourself to do what you wish and we are going to find out that the Godot source code itself is also extremely modular and we're going to see that a little bit later on so that's probably how you would wish to extend it but if you wanted to change it you want to make key sweeping changes to Godot but you didn't necessarily want to contribute them back or they didn't make sense to be shared with other people you've got that option so that's number one you can basically just download the source code and make changes how you wish using C++ so maybe not that the most satisfying answer but that is the easiest way now that is there are a couple of requirements there you need to have a C++ environment set up you need to have Python installed and you need to install something called scons which is a python-based build system with all those things clone the repository down make the changes you're working in C++ now the next way we've got is more I want to say modular in nature but that's actually there's gonna be a distinction between Gd native and modules and we're gonna look at that in a minute but GT native is kind of the newest way to extend C++ you would use Gd native to do things like bind to a C or a C++ library or interface with an SDK that needed native support or perhaps you just needed to add some support but you want to have C++ style native experience but the key thing is you would use GD native if you wanted to share your results through your writing an add-on and it wasn't using GD script you would probably want to do Gd native now this is kind of a bridge between C++ and Godot to make your life a little bit easier you can write your code in either C or C++ using a very specific defined interface and then you can expose that code out to GD script that can be extended in order to do so you need to have a Godot executable for your target version C compiler of some form get so you can download the Godot headers and then you basically just follow through the instructions your code has to be in a very specific structure but now you can basically go ahead and define GD native modules these things are really nice on the level that you can now you could share them with other people they were basically external to Godot so you don't have to completely rebuild everything every time there's a new version you can think of GT native output as basically binary compatible extensions the closest way I could describe GT native to other systems is that these are plugins you can write them in the C or C++ they can be basically added into your project they don't have to be recompiled for any minor changes that happen it's a nice way of basically having a C++ code that is a callable firm in Godot but not tightly bound to it like changing the dough itself would be or like modules ultimately will be that we'll see in a second so what GT native allows you do it's a layer of abstraction between Godot itself and binary generally dll's or SOS or you know it's a dynamic link library of some sort that extends the good dope game engine what you can do with it is almost identical to what you could do with modules there are some limits but as we're going to see there is quite a bit that is implemented using GD native so if you're looking for examples you head on over to the GD natives Gd native demo repository I will link this in with all the other links down below you will see there are examples for both C and C++ you're basically doing a bridge of your C++ code to a C compatible interface that's pretty standard to be honest when it comes to dll's and device linking and all that stuff you take all the the c++ heinous out of it you take away the v table and all that stuff you're basically creating a C interface you can see a couple of different examples of how to go about and create a GD native demo so go over here you look source code is pretty straightforward and it's it's a bunch of basically different callbacks in the lifecycle so you've got the initialization code termination code and then so this is the code that all runs when it first starts so that's basically about it and then you've got the ability to pass data between them it is a defined bridge between the two but it allows you to basically hook up C++ to Godot but without tightly coupling it like you'll see in just a second now if you're looking for an example of something that uses GD native a great example is open V R so the virtual reality support for the Godot engine is available in the asset library as an add-on it was implemented using the entire GT native support so you can understand the kind of functionality you can do you can extend it to support virtual reality devices you could use it to you could do game logic in there if you had a little bit if you wanted to implement an algorithm for example a better version of a star or something you do it using GD native you can get native performance as a direct result but it's not going to require people to do a complete rebuild to make it work it's not going to require a specific version match and so on it's going to be decoupled to a certain degree so that is what is nice with GD native so it's a little bit easier I bet you then module and that's a little arbitrary to be honest but the biggest thing is it's slightly decoupled so you do it you can make plugin so there's easier to share you can easier to give to people other than yourself but if you are working internally entirely on a project it's quite possible that what instead you want to work with is modules now modules are basically I've really core part of the game engine itself we're gonna see in just a few seconds that a whole lot of Godot itself it's actually implemented as modules and a lot of wise modules are just organized code basically if you want it to yep you could do your entire code in C++ implemented as a module it's going to be directly tied into your game there are some interfaces you are going to provide you're basically defining of the the things that that you're glowing your class has so your binding methods out so here is an example of implementing an ADD method in your binding methods so there's something at the core level called the class DB that you're registering things into so you're registering three functions in here the cool thing is once you've done that those things can ultimately call using Gd script I've actually done a tutorial on creating a module there's some setup you got to do some scons configuration stuff then the downside to modules is these are effectively causing you to basically recompile everything if you've got a minor minor minor change of Godot itself if it went from three point two point one to three point two point one B you'll have to rebuild your module and a lot of ways modules are basically part of Godot itself now you can have your own you don't have to contribute these back but you're really cooking deep into the engine itself so if anything at the engine level changes on a binary level you have to completely rebuild your modules that is not true Rajini native that's kind of probably the biggest distinction between the two now in terms of what can be done using modules well as you will see a lot in fact if we go back to the Godot Engine repository so here we are in Godot itself you'll notice there is a directory off of it so earlier on we were in core for example there is modules if you look at the kind of stuff that was implemented in Godot itself as part of the entire project that everybody gets if you clone the repository we have things like bullet physics asset importing they are kits support internet support our networking support that was just added freetype font support and then here's where we get really kind of kicker GT native the thing that we were just talking about a second ago that is implemented as a module what about mono or c-sharp support implemented as a module heck even GD script itself the ki scripting language in Godot it is implemented as a module so you're gonna see modules are basically really integral parts of Godot in a lot of ways Godot is implemented as modules and then these are when you download your dough itself they're gonna be built as part of it but you can also create these external modules that you are your own that it's a nice way of kind of separating your code from the main repository but it's not a nice way to distribute your code so if you want to create an add-on for your project you're going to probably want to use GT native but if you want to do like low level implementation stuff that you think everyone is going to want well you could potentially be a contributor and add it into the main repository as a module or you can work on your own in module format and yes if you really wanted to you could put your game logic in a module that you build yourself you've got to define a couple things once again you've got to find a SC sub for the sconce know how to build your code where the key projects are and so on there's a couple of really simple config files that you've got to build in there such as this guys basically there that's kind of the thing you're looking at very simple very straightforward for the most part and then on top of that you've got your code your code has to follow some particular things mostly it's going to be in registering stuff so that those class those core DB or yes core DB or class or the class DB you're gonna be doing a lot of class DB registrations it's these class DB calls that are ultimately going to hook your code into and be aware of and knowledgeable to the rest of the Godot system and you can implement a ton of stuff as you can see this is GD script itself that we were looking at right now there is a ton of things that you can do using modules so that's it those are the three ways you can work directly in C++ with Godot number one clone Godot build it from source yourself add whatever you want with the MIT license you do not have to contribute it back up to the main people and that's not even rude sometimes you're just making changes that only make sense to you if you want to be a contributor also that is an option you could submit your stuff up potentially other people will we find it interesting the next option of course is GD native genie native as we saw was implemented as a module but the cool thing is it gives you a bit of an abstraction layer there so it allows you to create extensions for Godot that could be brought in kind of in binary format that way when there's a small change to get dough it doesn't break all of the stuff that you've created using GD native it's going to be working at a slightly higher level than what you're working with modules and then finally of course we do have modules for example half of how things are implemented in Godot itself and if you were going to create C++ code that you wanted to run your own game obviously that's not something you're going to share with someone else and it doesn't necessarily make sense to be GT native you're probably not going to want to extend or change Godot itself so in that case extending it via a module probably makes the most sense so if you really wanted to write your game logic using C++ ultimately modules probably makes the most sense but I have to say at the end of the day doing game logic using C++ doesn't make a lot of sense that's why things like blueprints c-sharp GD script etc are all used at that level you would normally just put your performance critical code in there so they say you had an algorithm you wanted to implement and GD script wasn't fast enough that makes more sense to implement it either as GD native especially if you want to share it with other people or as a module if you're going to contribute it to the core team or if you're going to you know be working with your own project and you're not sharing with other people and it's fine to recap I'll it every time there is a minor change so that is it those are the three different ways hopefully that was useful asking questions please let me know comments down below and I'll talk to you all later good

Channel: Gamefromscratch

Views: 65,848

Keywords: Godot, C++, CPP, Modules, GDNative, DLL, Plugins, GameDev, Game Development, Programming, Native, Extension, Plugin, Addon, Source, Code

Id: MscgBCzA7eA

Length: 12min 56sec (776 seconds)

Published: Tue Jul 07 2020