 Is Emmanuel Le Bon, please welcome him on stage. 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, which every six months I get a really great idea for a game and so I'm like, oh, I have today 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 drop 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, the boiler plates we are all already done for you when you just focus on the game. There's a really great feature about Godot. It's a pen source. It's a 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 account 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're 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 is composed of plenty of nodes. So it's itself a scene. You can see that there is a hitbox 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 a lookalike Python. It's inspired by Python, but it's 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 messing a bit around. I can move this guy here. I can change a bit 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? Re-inventing 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 that in Godot you have your scene and everything is a node. So if we look at, for example, 2D node, which is basically you get the 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 db, this singleton. And using the singleton, in fact, you go dynamically. So it's during runtime that you will ask the game engine, you ask class db to retrieve the class, which is named node2d, to instantiate it. And then after that, you ask to retrieve the function setRotation 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 objects. 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 GdScript? GdScript is really simpler than the dynamic interface, but in fact is 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 G script module, which is basically two things. One is a compiler to turn your Godot human readable 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're using a really big interpreter with plenty of property and functionality and so on. Something really tiny, really simple and really... And it's deeply integrated with Godot so it works pretty well. So there's nothing to fear about these G scripts. It's one of the few use cases where inventing a new language is fine. But we're here for Python, not for G script. And in fact, I really love Python and when I started using this game engine with Godot, with G script, sorry, I was always thinking about Python saying, oh, 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 advanced stuff like that. So I end up realizing what I really wanted is I should spend a couple of weeks, maybe a month, 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 really wash 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 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 a pretty simple object like Boldin, like a mass vector for example, and there are more dynamics ones, like the node I was telling 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 runtime. 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 .pi object. So the way Godot represents dynamic type into the way Python represents dynamic type, is pretty straightforward, there is no really 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 well as planned, so it's been one year now. So I start up at the really 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 the ass, 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 bold 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 microcontrollers, so on systems 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 CAPI is really lower level that it would be with Cpython, 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, all connect them together. So in the end, you don't manipulate a string, you just manipulate an AD on the string. So everything like this in MicroPython, so it makes the API much more difficult to work with and 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 CAPI, 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 FOSDEM in Belgium and just after the FOSDEM, still in Belgium, was the really first Godokon, so all the Godok 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 very 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 Cpython with Pybin11. Pybin11 is a C++ library, which is kind of, it does kind of magical tricks with C++ templates, so basically you have your C++ class, you wrap it with Pybin11 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++, but the trouble is you are doing really static templates, so you have your C++ class, you bind it and then you get it into Python, but the way Godok works is much more dynamic. Like I said, you have this class DB things when you can do introspection, but you cannot use it here with Pybin11. So in the end you end up, I end up having to write a script, which pass all the source code of Godok in order to get back the C++ API and then generate a glue code for scripts, for bindings. So in the end it was like 100,000 lines of C++ with templates everywhere generated. The compilation of this was a real nightmare, it was something like 5 minutes just for this file with 5 gigabytes of RAM used and in the end you add up like up to 100 megabytes to your final binary. So it works, but it was really not elegant and really cumbersome to work with. Every time I had to do just a simple change, I had to wait more than 5 minutes just to see the recompilation. So yeah, it was kind of painful. But anytime there was always the Godok, the Godok community was always there and so we had a new meeting at Mozilla in Paris. We even have the main developer of Godok, 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 inside Godok, which was they created a CAPI on top of the C++ API. And so it was a real game changer because with this CAPI I could just drop everything and switch to CFFI, which was a really good choice if you sold a conference from Armin Russia this morning. So basically CFFI 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 the 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 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. PyPy is just a really good use case for game engine 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 and so I have something to show, 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 probable 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 the 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, 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 ends up with a big segfault. But it both, 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, for script language on the program, I'm still using C++. So what that means 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, I should support Linux, Mac OS, and etc. 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 would see these things, would 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 GT Scripts code, but it would be really good, you know, 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 finished 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 all this week on the EuroPython, 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, the question is what about performance in comparison to GT Script? There is two things. First is GT Script 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 really slow or because people are just comparing GT Script 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 GT Script even if there is a big binding because GT Script 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, or iOS. Yeah, we support iOS. This engine has been used for releasing 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 release a 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 get 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 games with Steam. So, yeah, there is work on it and the already game which has been shipped with, so I think it works. Thank you.