Bringing Python to Godot game engine
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Emmanuel, Leblond
Bringing Python to Godot game engine Godot is an advanced, feature-packed, multi-platform 2D and 3D open source game engine. The project has joined the Software Freedom Conservancy project and it growing community makes it hopes to become a real alternative to Unity&GameMaker. This talk cover a year long journey of the port of Python as a scripting language for the engine, starting from a rant against Godot's Python-like proprietary language. We will have a look at Godot's internal architecture as is it itself a real interpreter with it garbage collector, dynamic typing, introspection and even builtin custom scripting language. All of this having to work next to our Python interpreter and communicate back and forth with it. Finally we will see the different approaches that have been tried to bind Python to Godot each with there own pros&cons: Using Micropython interpreter instead of CPython Using PyBind11 to statically bind to Godot C++ API Using CFFI and rely on a 3rd party C API The audience should have some basic knowledge of C level computing (static vs dynamic language, compilation & linking)
 So, hi, everyone. Thank you for coming. Welcome to this conference. First, let me introduce myself. I'm Emmanuel. Most of the time, I'm not doing game programming. I'm doing web stuff. It's kind of a hobby for me. I'm kind of people, you know, every six months, I get a really great idea for a game. And so I have to do that. And so I start working on the game. And after like two months and end up, I realize I spend all my time making a game engine and not a game. So I get pretty disappointed and I jump it. And so last time I had this kind of really great idea. I said, okay, this time I won't mess up. I will just take an existing game engine and focus 100% on my game. And that's how I met Godot. So what's Godot? Godot is a full feature. It's just like one binary which gets everything in the sync all around in just one package. So there is plenty of features like physical engine, 2D, 3D rendering, audio engine, script. You can do profiling. You have the input which is managed for you. Basically you have all the hassles above your plates. We are all already done for you. You just focus on the game. There's a really great feature about Godot. It's a point source. It's MIT license. So meaning you can basically do your own game close. You can sell it. You have not to pay anything. And one thing which was really important for me, it has Linux support. So you don't have to go to Windows and develop a game on Windows because it's kind of boring. So it's time for a little demo on what Godot looks like. So it's basically if you already are going to Unity game engine, it looks kind of the same. So you have this panel which is your main scene of the game. I can zoom out. There is a bit too much. There is my level. So basically what you do by building a game is you create this scene with plenty of nodes. So you can see on the right side you have nodes for basically everything. So here is kind of bonus. It's coin because we are on platform game. Every enemy is also a node like this. You can customize every node here with plenty of properties. One great thing about Godot is you can nest scenes inside scenes. So what does it mean? For example, this enemy right now in our main scene, it looks like it's just a simple node. But in fact, if we look at it, it's much more complex. In fact, our little guy, he's composed of plenty of nodes. So it's itself a scene. You can see that there is a hit box here, for example. There is a sprite. There is animation. And now we can tweak this little guy how we want. For example, I can show the working animation and work on it like that. Another thing I can do is to plug scripts on any node I want to extend it. So for example, we can see on enemy, it has a script here. It's a custom language which is called a gd script. It's kind of lookalike Python. It's inspired by Python but not Python. So there is no self keyword, for example. There is constant. We'll get about it later. So with this script, I can extend what the node can do. I can attach new property, for example. I can create new function, connect to signals, et cetera, et cetera. So if I go back to my main scene here, so I can start missing a bit around. I can move this guy here. I can change a bit to the map, how it looks like. I didn't do anything like that. I can, for example, add a new coin scene here just to put the coin. And if I'm good, I can start running the game. So here it is. It didn't crash. Incredible. And so here it is. I have my game engine with all the physics already done. You see I'm pretty poor about it. And so, yeah, it just works. So one thing about the game engine is gd scripts. It's always a question that occurs every time. Why is it so? Why did it just create from scratch a new game language, a new script language, reinventing the wheel instead of just taking Python or taking Lua, which is already designed for this kind of use case? In order to answer this question, we should look at how Godot works from the inside. So if we look at, I said later, in Godot you have your scene and everything is a node. So if we look at, for example, 2D space, which is basically you get a node and you add some property to move it into a 2D space. So for example, here you have a rotation. So for the moment it's really simple C++ code. But what you do in Godot is you add this macro gd class and this function bind method. And basically what you're doing by doing this is you add introspection into your class. So now with these things you can do two things. You can, if you want to create a game only using C++ to connecting to the C++ Godot API, you can do it just the classical C++ wage just like this. So you use a new keyword, you create an object and then you use arrows to call the function. Or you can go through this thing, which is called class dv, this singleton. And using the singleton, in fact, you go dynamically. So it's during run time that you will ask the game engine, you ask class dv to retrieve the class, which is named node2d, to instantiate it. And then after that you ask to retrieve the function set rotation and to apply it to this object. And if you apply, for example, the wrong function to the wrong object, it won't blow up like a sec fault or something like that. You just end up with an error object you can handle nicely. You can see all around there is those variant object. If you think about it, I mean it's just like in Python, in fact, in Cpython you have just your Cpython interpreter, which has not been compiled by you and you have your script. Everything, every variable in your script is represented inside Cpython as a py object structure. And so this py object can contain basically everything, a float, an object, a class, et cetera. So it's just like this in Godot. You have this variant class which contains anything. So what's about gd script? Gd script is really simpler than the dynamic interface, but in fact it's exactly the same thing. It's just a convenient way to wrap the C++ dynamic API of Godot. So putting another way, you can see that you have on the left what is the core functionality of Godot, which is this variant class which contains basically anything. And this class DB structure which can contain all the information you can retrieve at runtime about the node. And on the right side you have a really simple gd script module which is basically two things. One is a compiler to turn your Godot human redevelop source code into byte code. And another thing is just a really tiny interpreter which takes every byte code one by one and just call the equivalent code which is provided by class DB. So in the end it's a really simple module. It's something that is not like you using a really big interpreter with plenty of property and functionality and so on. It's just something really tiny, really simple and it's deeply integrated with Godot so it works pretty well. So there is nothing to fear about these gd scripts. It's one of the few use cases where inventing a new language is fine. But we're here for Python, not for gd script. And in fact, I really love Python and when I started using this game engine with Godot, with gd script, sorry, I was always thinking about Python saying we could do this better in Python. For example, I could take this game logic outside of the engine and start unit testing in with PyTest so it would be much more easier to do this thing. I could also, for example, plug the Python ecosystem into my game, for example, start using the PyTorch library to use machine learning to create AI or advance stuff like that. So I end up realizing what I really wanted is I should spend a couple of weeks, maybe a month, into trying to put Python into Godot and then after that I will go back to my game and the time I will save because now I have Python and Godot will re-watch it and so I will recover my time invested into doing this. So now how do we do that? The first thing we have to do is to tell Godot there is a new player in the game, which is Python, and know if it finds out that he is asked to load a.pi file, it should come to see our module. So doing this is pretty simple. There is already a generic class in Godot which represents what script language is and so we have to implement this. The second thing is we have to create bindings. So we have to create binding class for Python to manipulate Godot objects. So there is pretty simple object like building like a mass vector, for example, and there are more dynamics ones like the node I was saying you before. So for the node we can use the class DBA, the class DBA API to create the binding just lazily only when there are needed at run time. The only trick we have to make sure about it with those things is we must be sure to manipulate the Godot objects through our binding and not copy the data because most of the time you get data from Godot, you start modifying them a bit, you return them to Godot and then Godot is doing stuff, reading it, modifying it, et cetera. Next thing is converting variant into py object. So the way Godot represents dynamic type into the way Python represents dynamic type, so it is really straightforward and there is no big deal about this. And the much more complex thing is handle memory because now we end up with two different garbage collector. One for Godot and one for Python and we have to make them work all together and most of the time what happens is you start creating an object from inside Python, for example, you pass it to Godot and so from the Python point of view there is not much about it about this memory so it can start to clean it, to erase it and so it's brought up at any time when Godot starts to actually read those data. So we have to take care about this. Now we can talk about the implementation. So I said I was planning for something like one month, let's say, to implement this. It didn't work as planned so it's been one year now. So I start up at the beginning using MicroPython. The reason why it's first the guy behind Godot, they already tried to put Python on Godot and they said the binding was a real pain in us and so it was a lot of time and the code wasn't really elegant so it didn't work at all. So I said, okay, let's try something else. The good thing about MicroPython seems there is a lot of customization you can do when you choose to build it. You can disable plenty of features in order to have your interpreter consume less RAM and have less functionality so maybe you can make a sandbox because you reduce a lot of functionality of your script. So it seemed really interesting. The trouble about it is MicroPython is designed to be run on microcontroller so on system which are really limited with memory which is not what you do when you are running a game. Basically you have gigabytes of RAM. So the trouble with this is the C API is really lower level that it would be with C Python, for example. So for example, when you are working with strings, you are not really working with strings. Most of the time the strings are all collected together and during the compilation time MicroPython is looking for if there is some string that are reused from time to time and if they are the same, they are just all connected them together. So in the end, you don't manipulate a string, you just manipulate an AED on the string. So everything like this in MicroPython. So it makes the API much more difficult to work with. So, yeah, it was really hard to work. The other thing is it's not 100% Python. So I said I wanted to have all the really nice Python ecosystem with it. But with MicroPython, for example, you don't have the same C API, you don't support really dynamic stuff. So there is plenty of libraries that won't work with MicroPython. One example is for the moment there is no support for the PDB library which is understandable when you think about it because MicroPython is for microcontroller and when you run your code on a microcontroller you don't have access to SDN or SDD out so you just don't debug it with PDB. But when you are working with a game, it's much different. You really want to be able to just put a PDB everywhere and jump in and start doing introspection and so on. So it was not the really best idea. So around this time we got the false DEM in Belgium and just after the false DEM, still in Belgium, was the really first GodoCon. So all the Godo programmer met there. It was a really fun time especially because it's Belgium and so you eat fries and you drink beer which is really good for programmers. And so we had a lot of ID and so I realized MicroPython just won't do it. And so I switched to C Python with Pybin 11. Pybin 11 is a C plus plus library which is kind of, it does kind of magical tricks with C plus plus templates. So basically you have your C plus plus class, you wrap it with Pybin 11 and you magically end up with a Python module. So it works really well. It's really elegant. You feel like you are working with Python from within C plus plus. But the trouble is you are doing really static templates. So you have your C plus plus class, you bind it and then you get it into Python. But the way Godo works is much more dynamic. Like I said, you have this class DB things when you can do introspection. But you cannot use it with Pybin 11. So in the end you end up, I end up having to write a script which pass all the source code of Godo in order to get back the C plus plus API and then generate glue code for scripts, for bindings. So in the end it was like 100,000 lines of C plus plus with templates everywhere generated. The completion of this was a real nightmare. It was something like five minutes just for this file with five gigabytes of RAM used and in the end you add up like up to 100 megabytes of to your final binary. So it was, yeah, it works but it was really not elegant and really cumbersome to work with. I mean, every time I had to do just a simple change, I have to wait more than five minutes just to see the recompilation. So, yeah, it was kind of painful. But any time there was always the Godo community was always there. And so we had a new meeting at Mozilla in Paris. We even have the main developer of Godo which is from Argentina so we cannot see him in person normally but he went there with his wife for his vacation. It was kind of really nice. And so we talk a lot about all the troubles and so I end up, there was a new feature into inside Godo which was they created a C API on top of the C plus plus API. And so it was a real game changer because with this C API I could just drop everything and switch to CFFI which was a really good choice if you saw the conference from Armin this morning. So, basically, C API is solving every problem. What you do is just you create a script. In this script you say I want to use from into Python this function and this function. You just copy paste the function signature. Then you put your Python code. You say, okay, I want to embed this code into my module. And you end up with defining, okay, I want this Python function to look like this function into C if it calls from C. Then you run this script and you end up with one C file. You just have to compile and you get your module. The absolutely great thing about this is you, most of your binding are done now in Python. So it means that you have no longer to compile. You just compile once and given all your, most of your code is Python, you just load it dynamically. And so you can change everything at any time and you don't have to recompile. So compared to Pybin 11, it was like a game changer. On top of that, you got PyPy for free, which means the compatibility is here. It's really cheap. And so, yeah, just, I mean, PyPy is just a really good use case for, I mean, game and giant is a really good use case for PyPy because it's always the same loop, which is run, always the same script, the same data. The just-in-time compilation can really do a boost. So I hope it will make a boost eventually in Godot. So you are here. And now we have a beta, which is available. It was released last week in a hurry because we have this conference. So I have something to show. But it works really well. I didn't find any bugs so far. But that's why we need you to find the bugs. I'm sure there is plenty of them. Yeah. The other thing is PyPy. So I said it would be a really, really nice feature to have it. The only really problem is for the moment, I'm using the new version of Godot because Godot is kind of a really young project. I mean, it's been open sourced in 2014. So it's been three years. There are a lot of work on it. So there is plenty of new features. This new release, which is 3.0, which is coming soon, it will change a lot of things. They all change the 3D renderer, for example. They have new physically-based rendering. They have not the scenes. I mean, they change a lot of things. The thing is now the release is in alpha. So I got Godot in alpha. I got my module, which is really early. So I believe it is a beta. And now I'm building with this PyPy, which is in beta also for PyPy 3.5. So we have one alpha, two beta all together. And so it ended up with a big seg fault. But it built. So we have to find out, and then we're good to go. Next thing would be editor integration because right now it's a kind of raw. If you see, like I said, the editor is really nice because everything is packed together. So it looks really interesting. But right now, if I want to debug my script, I put PDB somewhere, for example. It's not like that. You have to go to the console, like this ugly console, and use PDB like that. It would be much better to be able to use the debugger panel here in order to do the stuff. Another nice thing would be to have auto completion for the Python code into the bolting editor in Godot. And last but not least, I think the most important thing would be to add, I mean, right now, the C API I use with CFFI is not complete enough. I have access to the bolting, I have access to the class DB stuff, to my introspection. But the way I register my module to Godot to say, okay, there is a new module for programming language, script language on the program. I'm still using C++. So what does it mean is I have to release an entire engine I compile myself with the support of Python, sorry, and I have to give it to people. Which is really cumbersome because I should support Windows, Linux, macOS, et cetera. And it's not like the philosophy of Godot is you have just one binary and then you just kind of use it, you don't have to recompile stuff and so on. So the really important thing I think I'm going to work on is to improve the C API in order to just be able to compile Godot as a shared library, just a simple.s or stuff, which you can just drop on your game folder. And then Godot will see these things, load it, and then you got the Python support like that. The really good things would be to have it in the asset store because you can see on Godot you have an asset store just like in Unity. For the moment it's snippets of code, of gd scripts code, but it would be really good. You start your new project, you go on the asset store, you double click on the Python and then you got your Python just like that. So that would be the final goal. And I think if I finish this, I could go back to working my game. I totally forgot what it was about, by the way. Yeah, so thank you very much. Just one more thing. I will be on, I will be all this week on the, on the Euro Python and I will also be on the sprint which are this weekend. So if you're interested in the project and want to hang out, just tell me and we will code all together. Thank you. Okay, we've got some time for questions. If you have one, please raise your hand. We have a microphone. Thank you for the talk and of course question is what about performance in comparison to gscript? There is two things. First is gscript is already known to be slow. I mean there is people complaining about it. Now we have no idea if it's because it's re-slow or because people are just comparing gscript to C++. So there need to be some tests which needs to be done but nobody has done them yet. So maybe if I run benchmark, right now Python is faster than gscript even if there is a big binding because gscript is not optimized. But I don't think it's the case. But anyway, I think to improve the performance on this binding, there is a PyPy. So that's my hope. I wish really hard that PyPy will make Python really fast and so the binding layer which makes things slower but not that slow because you get a boost from PyPy. Do you support mobile export like iOS or Android? You mean to support Android? Yeah, we support iOS. This engine has been used for releasing the MrBean game on Android and iOS for example. You can play it. It's free. I don't have share on it. This may be a related question but does Godo make it easier to distribute games for PC and does your Python integration and PyPy stuff make it harder to distribute games? Sorry I didn't get your question. Could you speak lower please? So when you want to publish games for people to use and you want to use them on PC, does Godo help with that and does using PyPy or Cpython as part of a Godo game make it harder to publish games? Basically when you read the game it's just like you have your folder which contains your assets and your script and you put the binary of Godo, just the program. You just put it inside your folder and you go to go. Everything is okay. Everything works. There is more advanced way to do it if you want for example to strip your code in order not having people can easily read what it is. There are more advanced but you can also do. I think now there are people working on supporting the Steam API to release game with Steam. So yeah there is work on it and already game which has been shipped with so long. I think it works. Thank you.
 So, hi, everyone. Thank you for coming. Welcome to this conference. First, let me introduce  myself. I'm Emmanuel. Most of the time, I'm not doing game programming. I'm doing web  stuff. It's kind of a hobby for me. I'm kind of people, you know, every six months, I get  a really great idea for a game. And so I have to do that. And so I start working on the  game. And after like two months and end up, I realize I spend all my time making a game  engine and not a game. So I get pretty disappointed and I jump it. And so last time I had this  kind of really great idea. I said, okay, this time I won't mess up. I will just take an existing  game engine and focus 100% on my game. And that's how I met Godot. So what's Godot? Godot  is a full feature. It's just like one binary which gets everything in the sync all around  in just one package. So there is plenty of features like physical engine, 2D, 3D rendering,  audio engine, script. You can do profiling. You have the input which is managed for you.  Basically you have all the hassles above your plates. We are all already done for you. You  just focus on the game. There's a really great feature about Godot. It's a point source.  It's MIT license. So meaning you can basically do your own game close. You can sell it. You  have not to pay anything. And one thing which was really important for me, it has Linux  support. So you don't have to go to Windows and develop a game on Windows because it's  kind of boring. So it's time for a little demo on what Godot looks like. So it's basically  if you already are going to Unity game engine, it looks kind of the same. So you have this  panel which is your main scene of the game. I can zoom out. There is a bit too much. There  is my level. So basically what you do by building a game is you create this scene with plenty  of nodes. So you can see on the right side you have nodes for basically everything. So  here is kind of bonus. It's coin because we are on platform game. Every enemy is also  a node like this. You can customize every node here with plenty of properties. One great  thing about Godot is you can nest scenes inside scenes. So what does it mean? For example,  this enemy right now in our main scene, it looks like it's just a simple node. But in  fact, if we look at it, it's much more complex. In fact, our little guy, he's composed of  plenty of nodes. So it's itself a scene. You can see that there is a hit box here, for  example. There is a sprite. There is animation. And now we can tweak this little guy how we  want. For example, I can show the working animation and work on it like that. Another  thing I can do is to plug scripts on any node I want to extend it. So for example, we can  see on enemy, it has a script here. It's a custom language which is called a gd script.  It's kind of lookalike Python. It's inspired by Python but not Python. So there is no self  keyword, for example. There is constant. We'll get about it later. So with this script, I  can extend what the node can do. I can attach new property, for example. I can create new  function, connect to signals, et cetera, et cetera. So if I go back to my main scene  here, so I can start missing a bit around. I can move this guy here. I can change a bit  to the map, how it looks like. I didn't do anything like that. I can, for example, add  a new coin scene here just to put the coin. And if I'm good, I can start running the game.  So here it is. It didn't crash. Incredible. And so here it is. I have my game engine with  all the physics already done. You see I'm pretty poor about it. And so, yeah, it just  works. So one thing about the game engine is gd scripts. It's always a question that  occurs every time. Why is it so? Why did it just create from scratch a new game language,  a new script language, reinventing the wheel instead of just taking Python or taking Lua,  which is already designed for this kind of use case? In order to answer this question,  we should look at how Godot works from the inside. So if we look at, I said later, in  Godot you have your scene and everything is a node. So if we look at, for example, 2D  space, which is basically you get a node and you add some property to move it into a 2D  space. So for example, here you have a rotation. So for the moment it's really simple C++  code. But what you do in Godot is you add this macro gd class and this function bind  method. And basically what you're doing by doing this is you add introspection into your  class. So now with these things you can do two things. You can, if you want to create  a game only using C++ to connecting to the C++ Godot API, you can do it just the classical  C++ wage just like this. So you use a new keyword, you create an object and then you  use arrows to call the function. Or you can go through this thing, which is called class  dv, this singleton. And using the singleton, in fact, you go dynamically. So it's during  run time that you will ask the game engine, you ask class dv to retrieve the class, which  is named node2d, to instantiate it. And then after that you ask to retrieve the function  set rotation and to apply it to this object. And if you apply, for example, the wrong function  to the wrong object, it won't blow up like a sec fault or something like that. You just  end up with an error object you can handle nicely. You can see all around there is those  variant object. If you think about it, I mean it's just like in Python, in fact, in Cpython  you have just your Cpython interpreter, which has not been compiled by you and you have  your script. Everything, every variable in your script is represented inside Cpython  as a py object structure. And so this py object can contain basically everything, a float,  an object, a class, et cetera. So it's just like this in Godot. You have this variant  class which contains anything. So what's about gd script? Gd script is really simpler than  the dynamic interface, but in fact it's exactly the same thing. It's just a convenient way  to wrap the C++ dynamic API of Godot. So putting another way, you can see that you have on  the left what is the core functionality of Godot, which is this variant class which contains  basically anything. And this class DB structure which can contain all the information you  can retrieve at runtime about the node. And on the right side you have a really simple  gd script module which is basically two things. One is a compiler to turn your Godot human  redevelop source code into byte code. And another thing is just a really tiny interpreter  which takes every byte code one by one and just call the equivalent code which is provided  by class DB. So in the end it's a really simple module. It's something that is not like you  using a really big interpreter with plenty of property and functionality and so on. It's  just something really tiny, really simple and it's deeply integrated with Godot so it  works pretty well. So there is nothing to fear about these gd scripts. It's one of the  few use cases where inventing a new language is fine. But we're here for Python, not for  gd script. And in fact, I really love Python and when I started using this game engine  with Godot, with gd script, sorry, I was always thinking about Python saying we could do this  better in Python. For example, I could take this game logic outside of the engine and  start unit testing in with PyTest so it would be much more easier to do this thing. I could  also, for example, plug the Python ecosystem into my game, for example, start using the  PyTorch library to use machine learning to create AI or advance stuff like that. So I  end up realizing what I really wanted is I should spend a couple of weeks, maybe a month,  into trying to put Python into Godot and then after that I will go back to my game and the  time I will save because now I have Python and Godot will re-watch it and so I will recover  my time invested into doing this. So now how do we do that? The first thing we have to  do is to tell Godot there is a new player in the game, which is Python, and know if it  finds out that he is asked to load a.pi file, it should come to see our module. So doing  this is pretty simple. There is already a generic class in Godot which represents what  script language is and so we have to implement this. The second thing is we have to create  bindings. So we have to create binding class for Python to manipulate Godot objects. So  there is pretty simple object like building like a mass vector, for example, and there  are more dynamics ones like the node I was saying you before. So for the node we can  use the class DBA, the class DBA API to create the binding just lazily only when there are  needed at run time. The only trick we have to make sure about it with those things is  we must be sure to manipulate the Godot objects through our binding and not copy the data  because most of the time you get data from Godot, you start modifying them a bit, you  return them to Godot and then Godot is doing stuff, reading it, modifying it, et cetera.  Next thing is converting variant into py object. So the way Godot represents dynamic type into  the way Python represents dynamic type, so it is really straightforward and there is  no big deal about this. And the much more complex thing is handle memory because now  we end up with two different garbage collector. One for Godot and one for Python and we have  to make them work all together and most of the time what happens is you start creating  an object from inside Python, for example, you pass it to Godot and so from the Python  point of view there is not much about it about this memory so it can start to clean it, to  erase it and so it's brought up at any time when Godot starts to actually read those data.  So we have to take care about this. Now we can talk about the implementation. So I said  I was planning for something like one month, let's say, to implement this. It didn't work  as planned so it's been one year now. So I start up at the beginning using MicroPython.  The reason why it's first the guy behind Godot, they already tried to put Python on Godot  and they said the binding was a real pain in us and so it was a lot of time and the code  wasn't really elegant so it didn't work at all. So I said, okay, let's try something  else. The good thing about MicroPython seems there is a lot of customization you can do  when you choose to build it. You can disable plenty of features in order to have your interpreter  consume less RAM and have less functionality so maybe you can make a sandbox because you  reduce a lot of functionality of your script. So it seemed really interesting. The trouble  about it is MicroPython is designed to be run on microcontroller so on system which are  really limited with memory which is not what you do when you are running a game. Basically  you have gigabytes of RAM. So the trouble with this is the C API is really lower level  that it would be with C Python, for example. So for example, when you are working with  strings, you are not really working with strings. Most of the time the strings are all collected  together and during the compilation time MicroPython is looking for if there is some string  that are reused from time to time and if they are the same, they are just all connected  them together. So in the end, you don't manipulate a string, you just manipulate an AED on the  string. So everything like this in MicroPython. So it makes the API much more difficult to  work with. So, yeah, it was really hard to work. The other thing is it's not 100% Python.  So I said I wanted to have all the really nice Python ecosystem with it. But with MicroPython,  for example, you don't have the same C API, you don't support really dynamic stuff. So  there is plenty of libraries that won't work with MicroPython. One example is for the moment  there is no support for the PDB library which is understandable when you think about it  because MicroPython is for microcontroller and when you run your code on a microcontroller  you don't have access to SDN or SDD out so you just don't debug it with PDB. But when  you are working with a game, it's much different. You really want to be able to just put a PDB  everywhere and jump in and start doing introspection and so on. So it was not the really best idea.  So around this time we got the false DEM in Belgium and just after the false DEM, still  in Belgium, was the really first GodoCon. So all the Godo programmer met there. It was  a really fun time especially because it's Belgium and so you eat fries and you drink  beer which is really good for programmers. And so we had a lot of ID and so I realized  MicroPython just won't do it. And so I switched to C Python with Pybin 11. Pybin 11 is a C  plus plus library which is kind of, it does kind of magical tricks with C plus plus templates.  So basically you have your C plus plus class, you wrap it with Pybin 11 and you magically  end up with a Python module. So it works really well. It's really elegant. You feel like you  are working with Python from within C plus plus. But the trouble is you are doing really  static templates. So you have your C plus plus class, you bind it and then you get it  into Python. But the way Godo works is much more dynamic. Like I said, you have this class  DB things when you can do introspection. But you cannot use it with Pybin 11. So in the  end you end up, I end up having to write a script which pass all the source code of Godo  in order to get back the C plus plus API and then generate glue code for scripts, for bindings.  So in the end it was like 100,000 lines of C plus plus with templates everywhere generated.  The completion of this was a real nightmare. It was something like five minutes just for  this file with five gigabytes of RAM used and in the end you add up like up to 100 megabytes  of to your final binary. So it was, yeah, it works but it was really not elegant and  really cumbersome to work with. I mean, every time I had to do just a simple change, I have  to wait more than five minutes just to see the recompilation. So, yeah, it was kind of  painful. But any time there was always the Godo community was always there. And so we  had a new meeting at Mozilla in Paris. We even have the main developer of Godo which is from  Argentina so we cannot see him in person normally but he went there with his wife for his vacation.  It was kind of really nice. And so we talk a lot about all the troubles and so I end up,  there was a new feature into inside Godo which was they created a C API on top of the C plus  plus API. And so it was a real game changer because with this C API I could just drop everything  and switch to CFFI which was a really good choice if you saw the conference from Armin  this morning. So, basically, C API is solving every problem. What you do is just you create  a script. In this script you say I want to use from into Python this function and this  function. You just copy paste the function signature. Then you put your Python code.  You say, okay, I want to embed this code into my module. And you end up with defining, okay,  I want this Python function to look like this function into C if it calls from C. Then you  run this script and you end up with one C file. You just have to compile and you get  your module. The absolutely great thing about this is you, most of your binding are done  now in Python. So it means that you have no longer to compile. You just compile once and  given all your, most of your code is Python, you just load it dynamically. And so you can  change everything at any time and you don't have to recompile. So compared to Pybin 11,  it was like a game changer. On top of that, you got PyPy for free, which means the compatibility  is here. It's really cheap. And so, yeah, just, I mean, PyPy is just a really good use case  for, I mean, game and giant is a really good use case for PyPy because it's always the  same loop, which is run, always the same script, the same data. The just-in-time compilation  can really do a boost. So I hope it will make a boost eventually in Godot. So you are here.  And now we have a beta, which is available. It was released last week in a hurry because  we have this conference. So I have something to show. But it works really well. I didn't  find any bugs so far. But that's why we need you to find the bugs. I'm sure there is plenty  of them. Yeah. The other thing is PyPy. So I said it would be a really, really nice feature  to have it. The only really problem is for the moment, I'm using the new version of Godot  because Godot is kind of a really young project. I mean, it's been open sourced in 2014. So  it's been three years. There are a lot of work on it. So there is plenty of new features.  This new release, which is 3.0, which is coming soon, it will change a lot of things. They  all change the 3D renderer, for example. They have new physically-based rendering. They  have not the scenes. I mean, they change a lot of things. The thing is now the release  is in alpha. So I got Godot in alpha. I got my module, which is really early. So I believe  it is a beta. And now I'm building with this PyPy, which is in beta also for PyPy 3.5.  So we have one alpha, two beta all together. And so it ended up with a big seg fault. But  it built. So we have to find out, and then we're good to go.  Next thing would be editor integration because right now it's a kind of raw. If you see,  like I said, the editor is really nice because everything is packed together. So it looks  really interesting. But right now, if I want to debug my script, I put PDB somewhere, for  example. It's not like that. You have to go to the console, like this ugly console, and  use PDB like that. It would be much better to be able to use the debugger panel here  in order to do the stuff. Another nice thing would be to have auto completion for the Python  code into the bolting editor in Godot. And last but not least, I think the most important  thing would be to add, I mean, right now, the C API I use with CFFI is not complete enough.  I have access to the bolting, I have access to the class DB stuff, to my introspection.  But the way I register my module to Godot to say, okay, there is a new module for programming  language, script language on the program. I'm still using C++. So what does it mean  is I have to release an entire engine I compile myself with the support of Python, sorry,  and I have to give it to people. Which is really cumbersome because I should support  Windows, Linux, macOS, et cetera. And it's not like the philosophy of Godot is you have  just one binary and then you just kind of use it, you don't have to recompile stuff  and so on. So the really important thing I think I'm going to work on is to improve  the C API in order to just be able to compile Godot as a shared library, just a simple.s  or stuff, which you can just drop on your game folder. And then Godot will see these  things, load it, and then you got the Python support like that. The really good things  would be to have it in the asset store because you can see on Godot you have an asset store  just like in Unity. For the moment it's snippets of code, of gd scripts code, but it would  be really good. You start your new project, you go on the asset store, you double click  on the Python and then you got your Python just like that. So that would be the final  goal. And I think if I finish this, I could go back to working my game. I totally forgot  what it was about, by the way. Yeah, so thank you very much. Just one more thing. I will  be on, I will be all this week on the, on the Euro Python and I will also be on the  sprint which are this weekend. So if you're interested in the project and want to hang  out, just tell me and we will code all together. Thank you.  Okay, we've got some time for questions. If you have one, please raise your hand. We  have a microphone. Thank you for the talk and of course question is what about performance  in comparison to gscript? There is two things. First is gscript is already known to be slow.  I mean there is people complaining about it. Now we have no idea if it's because it's  re-slow or because people are just comparing gscript to C++. So there need to be some  tests which needs to be done but nobody has done them yet. So maybe if I run benchmark,  right now Python is faster than gscript even if there is a big binding because gscript  is not optimized. But I don't think it's the case. But anyway, I think to improve the performance  on this binding, there is a PyPy. So that's my hope. I wish really hard that PyPy will  make Python really fast and so the binding layer which makes things slower but not that  slow because you get a boost from PyPy. Do you support mobile export like iOS or Android?  You mean to support Android? Yeah, we support iOS. This engine has been used for releasing  the MrBean game on Android and iOS for example. You can play it. It's free. I don't have share  on it. This may be a related question but does Godo make it easier to distribute games  for PC and does your Python integration and PyPy stuff make it harder to distribute games?  Sorry I didn't get your question. Could you speak lower please?  So when you want to publish games for people to use and you want to use them on PC, does  Godo help with that and does using PyPy or Cpython as part of a Godo game make it harder  to publish games? Basically when you read the game it's just  like you have your folder which contains your assets and your script and you put the binary  of Godo, just the program. You just put it inside your folder and you go to go. Everything  is okay. Everything works. There is more advanced way to do it if you want for example to strip  your code in order not having people can easily read what it is. There are more advanced but  you can also do. I think now there are people working on supporting the Steam API to release  game with Steam. So yeah there is work on it and already game which has been shipped  with so long. I think it works. Thank you.
Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_0_359.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_360_551.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_552_2891.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_2892_3023.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_3024_8135.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_8136_13487.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_13488_15059.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_15060_15491.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_15492_19199.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_19200_33443.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_33444_36491.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_36492_37091.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_37092_37139.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_37140_37463.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_37464_37523.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_37524_38819.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_38820_38987.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_38988_39119.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_39120_39299.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_39300_39431.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_39432_39755.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_39756_40007.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_40008_40055.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_40056_40331.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_40332_40943.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_40944_41003.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_41004_41063.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_41064_42275.png Leblond_Emmanuel_-_Bringing_Python_to_Godot_game_engine_SK0BtxHROdg_42276_42371.png