Making Games with Python: Mission Impossible?
Christen, Martin
De Ioris, Roberto
Uzelac, Tomislav
Making Games with Python: Mission Impossible? EuroPython 2017 - Panel - 2017-07-11 - Arengo. Rimini, Italy A discussion about making full-featured, commercial games in python, both 2D and 3D. Looking at state of the art approaches to using python in gaming, we will compare the alternatives: pygame (2D API), OpenGL (via pygame/pySDL2), Unreal Engine 4 and the Godot Engine (with further comparison to Unity 3D game engine). We will also look at other benefits of using python in the gaming context, such as integration with 3D modelling software, scripting the asset pipeline and GIS data integration. Finally, can (and should) python move beyond being the language of plugins and scripts, and become the main language for creating game development projects
 My name is Thomas Lavazelot and I make video games entirely in Python, which is sort of my claim to fame and why I'm here today with you. And the idea is to have a discussion about whether making video games entirely in Python is in fact a viable proposition for us. And I have three guests with me joining us. There's Roberto, who is the author of the Unreal Engine Python plugin. I get that right. He's also a lecturer at the Italian Academy of Video Games. We get Emmanuel. He's the author of the plugin for, well, no, it's a wrapper for the Godot Engine. It's a Python wrapper for the Godot Engine. And we have, I'll get to you, and then we have Martin, who is a lecturer and a tutor in Python and 3D. So guys, my question, and I'm thinking, I was thinking how to start this, was to sort of take this from the back end, let's sort of start with some strong statements and then we'll try to defend them later. And so just try to pose this question immediately and ask you to give me an answer on like one to 10, making these games in Python mission impossible, one to 10 and then why and then we'll try to see, maybe from... Hi everyone. So from my point of view, the most important thing is making some kind of difference between Indie Game and the AAA game. They are pretty different from the result to the money spent over them. In my opinion, making Indie games with Python, with only Python is absolutely possible. On the other side, making AAA game only with Python could be a really, really hard challenge. One to 10. What did you say Indies are 10? Oh, it's really hard even to define what Indie Team is. Nowadays we have Indie Team with a lot of money. Four or five people with really thousands of dollars invested in them. So for an Indie Team, I mean something less than 10 person and with zero money. For me, an Indie Team is something that does not have money. An Indie Team works only with patience. This is my own opinion. I think it really depends on what you are defining when you say entirely in Python. Because if you dig enough, in the end you always end up finding some C somewhere. So the only question is what is the sweet spot between the part you are doing in C and the part you are doing in Python. So I think it's entirely doable to have a lot of your game logic written in Python. Like they do in the EVE online for example. So yeah, I would say if you are thinking, making a game means making game logic and not writing a game engine. I think it's entirely doable in two Python. And that's why I want to prove by putting Python into Goddow. And I should give a mark, so I would say 8 out of 10. So I would give it a 10 if you give me 10 million euro. Of course it depends what you want to do with. You want to create a triple A game. No, unfortunately not. If you want to make a mobile game. Yeah, I would give a 1, 2, 3. Unfortunately. But for indie game I think there is some chance. If you say I want to make a game for Mac OS, for Linux, Linux also don't pay for games. Okay, sometimes I do. And Windows then okay. I was in the game industry some years ago and it's really like this Mac users, they spend the most money on games. So I would make a Mac game, put it in the Apple store. And there I'm sure there would be a big interest. If the game is good, if it's an indie game, yeah, I would give it a 7. Now the question is why would I use Python to create a game? Is it really necessary? Wouldn't it be cheaper to just buy a license of Unity 3D or any other engine? So if I go to investor, I think he would say no, please take Unity or whatever. If it's me, I would like to use Python. Okay, but we have to think about that too. So it depends what, ranging from 1 to 10. Okay, so that's a broad range of answers. I have to sort of admit that I agree with Martin that it's a bit of a stretch to do everything in Python, which incidentally is what I do in my games, implement the whole rendering and all of that in Python, for various reasons which I hope will have time to cover that doesn't, it's really hard to do. But I can gather from you guys that there is hope. So maybe try to be informative and describe everybody. Each one of us has been doing some approach. Roberto, you've been doing Unreal Engine. You have been working on Godot which has similarities with Unity. Obviously Martin and I have had approaches which is more like directly working with OpenGL. So just a few quick words on each approach so that people who don't necessarily know what it entails to work with each one. So just a few quick words on everybody's approach. It's a strange term, hope for me, because it's like saying, is there hope for using Python as the language for your browser instead of JavaScript? Making a game or generally making a software does not necessarily require a single technology. There are technologies better suited than others and so on. From my point of view, there are some parts of building a game and its game engine that can be done in a really good way with Python and other parts, especially from the engine side, that not came out so good when using such a high-level language. Last year at the Eurovision in Bilbao, I gave a talk about OpenGL or in Python. Absolutely, it is something that we can do. But nowadays there are a lot of technologies, high-level technologies. I'm thinking about the NVIDIA technologies like VRWars, the simulation of cloth, hair and so on, that are really performance intensive. So from these kind of tasks, we cannot expect a higher-level language like Python, JavaScript, every higher-level language can be used in this day. We can hope in the sense that future computers can be way more powerful than nowadays computers, so we can even use less fast language instead of relying on languages like C or C++ for doing high CPU intensive tasks. This is the only hope I think we can have, better hardware for using software that is not so fast. I just wanted to ask before we move on. Sure, a big engine like Unreal packs a lot of punch. It does physics, it does all these simulations, and it's kind of difficult to imagine all of this intensive CPU side code being done in Python. But what about the future in which all these little systems sort of exist as well-defined Python modules? I know it's fanciful, but just in theory, couldn't that be a future that exists? Yeah, it could be. My company released a bunch of years ago a Python wrapper for a Ballet Physics library. I don't know if you know it. It's a pretty famous physics library, even in GTA. So yes, it could be something we can do. I don't remember what was the question in the first place. We have a question. Can you just explain your approach? Yeah, I think, like you said, there is really two schools. There is the one who wants to use Python as the first language and write everything inside Python. And the other one who kind of plug from an existing engine, has just wanted to extend this engine with Python. So I'm part of the second school. And the great thing with Godot is the code is clean enough to just separate the engine and what should be the script system. And so you can really write your scripts with multiple languages. And the great thing is maybe you can even think about Python like a part of your development process. And it won't be in the final product because you find it's too slow, maybe. But during development, if you could use Python to just try really fast some ideas, I think it could be really like boost the development, like trade new ideas and so on. And you end up in the end rewriting everything in C++ in the last months of the development of your game. Yeah, I used the approach to use OpenGL bindings. OpenGL is a very old standard of computer graphics. Every big GPU supports it, like NVIDIA, AMD and so on Intel. And I think it's possible to create good games using pure OpenGL bindings. So pure Python with OpenGL bindings. Okay, it's not pure anymore. But we call these things and it works. However, the problem is, as I mentioned before, if I create a big game project, and I want to submit it to an app store, iOS, Android, etc., then I will fail with that approach. And that's something I want to ask you to think about that. If in future, I mean, if I publish a game, I don't know if it's a big success. And the next step is I want to publish it to the app store. So what do I do? And that's my big question about that. If I do it entirely with Python, then I'm limited in that. Well, I can tell you that since we're making a game and publishing it on Steam, obviously on Steam it's a PC platform. You don't really have limitations on Python. You're fine. You distribute your code, you distribute your Python, you distribute your modules. Linux, Windows Mac, almost comes for free. At the time, I released our biggest game, it was a question like whether we want to move to iOS. And technically, it was possible to put everything on iOS, but at the time there was a big uncertainty about whether Apple would let you have Python on an iOS device. I understand that at this point it's not a problem. It's allowed, but perhaps someone in the audience will know more up-to-date information. Because I don't know, for example, on the PlayStation, does this work? A lot of these stores and ecosystems are not really happy about interpreted code and bringing stuff in. So yeah, it could be a risk. And I think you guys, it's sort of, I think a more fundamental question then is why use Python? I mean, if you want to make a game, you could use other languages. Obviously, we're here at the Python conference. That's what we're interested. But I think if you're talking to somebody who just wants to make games, there's a question of why Python? And there are good reasons, I know, but we'll talk about them. I just wanted to ask any people who work in video games with us right now? There's one. There's you, I know you. Just two? Three? Okay. This is what it is for a Python conference this time. I hope there will be more. And so I think there are other things in a video game company that Python gets used for. And, you know, Roberto, you had things to say about that. So I think you could just, we can just discuss it because the big appeal of Python is that it gets used throughout the development process. And that's why it would be perhaps good to put more of it into the actual gameplay. So, yes, in the video game industry, Python is basically one of the reference script languages you use, especially from the artist point of view where they used to my other 3ds Max blender and so on. Basically, I still have to met animators that do not script their pipeline work. Well, from, again, from my point of view, programming is a lot about automating tasks. So, personally, it's not a huge problem for me that I cannot script my engine with a higher level language, but it is very important for me that I can use a higher level language, which I don't need to compile with a lot, having strange error, having to pay attention to any single line I write and so on. Having the possibility to use such a language to automate and simplify my work is really, really important. More important than the ability to use it for every part of my work. Okay, so that's one part of it. A lot of people who already work in the industry will know the language. And as a looking, I have a list of things that you can use. You know, sure you can script your asset pipeline. That's very useful. Your testing. A lot of people use it for server-side applications for games, which are depending on what your game is, that can be really important. One thing that I've done and Martin, you're a bit of an expert for is we import a lot of geographic data. If your game is on a map, that will happen. So as part of a broader question, which is, you know, how is Python beneficial? Because it gives you access to a lot of tools that are in the Python system. So yeah, it's a bit of a question for you, Martin, you work with Geo. You can use that in your game. It opens up a lot of possibility, doesn't it? Yes, for data processing, Python is really one of the best ways to go. So I developed a virtual globe some years ago similar to Google Earth. And there we had to process terabytes of data for the visualization afterwards. And we used Python on a high-performance computing system, and we processed all the data there, and it was really great. And the code is really maintainable. But that's not for actually the rendering. The rendering was done in the web browser using WebGL. So that's pity, but it's like it is. But for the data processing part, it's cool. There are many libraries like GDAL, the Geo data abstraction library, for example, where you can load the different datasets, et cetera, et cetera. It's really a cool way. Please go on. I need to fix that. Change back to... Okay. And for the data processing part in general, I recommend using Python for the visualization part. We had to use WebGL because it run in the web browser. Very simple for that project. Okay. So when we discussed... I also saw an interesting demo on your own talk, which, again, because you were importing Python into Unreal Engine, you were able to access OpenCV. So, you know, could you talk a little bit more about that and just the possibilities that it gives you just by importing stuff unrestricted from the Python system? I think one of the advantages of using Python in a game development pipeline is the amount of third-party libraries that are available, especially in the scientific area. Artificial intelligence, big data management, and so on. Libraries that generally are not available in other languages or became really painful to use using lower-level languages. Embedding Python Virtual Machine into a professional game engine allowed me and the users to import the depth libraries and use them into something visually really powerful. This morning we had seen a keynote about that visualization. I was already thinking about how much better could be that data into Unreal Engine. We are seeing straight-liners, trees. In my mind, we can reproduce the whole earth with trees, with the real size, with the right kind of tree, and so on. So, something way more big in the scale that we can do now. So, the real advantage now of using Python into Unreal Engine, is that it's possible to use this kind of libraries. I don't know if you want to answer. I think it's something really interesting, because it means that you are bringing a game engine to people using Python, which means you are bringing it to scientists, people that are used to, in the past, use R and then they go to Python now. So, it means really new possibility for them, I think. I'm personally working in my day job with people from the scientific background, and I want new ways to show the data, and for the moon they don't even think about game engine, because it's for game, it's not for working. I just wanted to ask you guys to represent the faction here that takes an existing very capable game engine. In your case it's a free engine, Godot. In your case it's like an industry standard, top of the line engine, not free, but super. So, you represent this faction, and I get it that it's wonderful. I sort of do the other thing, but I have to, okay, you guys defend your side, but it's wonderful. But in both of your talks, I noticed that there are considerable technical difficulties. In making that work, because both projects are recently less than a year old, and you hear the same complaints, they're like two garbage collectors, I think in both projects. Then there's this issue of performance, do we want to go with JIT, with the PyPy? So, a lot of issues sort of come up with that. Maybe just shed some light on that. Are we sort of condemned to that? Two garbage collectors, does this really have to be? Just some input on that. Well, I think we have been both really unlucky, because we are pioneers, we are the first people trying to do something like that. Because now that Unreal Engine PyToplogin is way more mature, a lot of wrapper for the languages will come out, because now I've made a lot of research for them, so they can start working on their wrappers. And the same for the Godot wrapper, I suppose now we will see a lot of scripting languages that will come out. Yes, we are condemned, but now we have some tech info, we have some kind of literature to allow other people to do this work, without so much pain. I think the trouble was Python was added to an existing Engine, but it would be a really simple thing to just create an Engine in C++ when syncing. That's a high-level scripting that will be done in Python from the beginning, like it's doing a Pandas 3D. I didn't try it personally, but I think if somebody has experienced with it, it would be really interesting. Pandas 3D. Okay. Pandas 3D is another Engine, used a lot by Disney, in the past now Disney has moved to another Engine. It's allowed to be scripted in Python from the beginning, so it's architecture allowed for high interaction with Python. It is a pretty specific case. I have to say that the Epic stuff the guys making Unreal Engine has been very supportive with me, so they even made some modifications to the Engine to allow integration with scripting. Even the Godot Engine had new features to allow, big features to allow integration with other languages. Pandas 3D loses a bit of traction nowadays that we have Unity, Unreal, Godot, that are way more powerful. But as far as I know, Pandas is one of the first big Engine with a strong Python support. Does anyone know the situation with Unity and Python? Yeah, there is a... I heard that some guy working on PyPy has just started to work on Unity and Python, but he's not in the room, unfortunately. But if you find some PyPy guys, you can ask him directly. It's just a really start for the moment, but maybe it will go somewhere eventually. I'm really curious about how they can do it without sources, because both Unreal Engine and Godot have sources, so how could they do with Unity? It would be really interesting to know this. By the way, Unity, up to the fourth version, came with Python-like language, Boo. I don't know if you ever... Then they removed the support because no one used it and don't want to use some subversion of Python. Okay, so Martin, you and I are on the side where we want to do everything in Python. We create our own rendering loop. We call make it openGL functions, and we send our data, our buffers, and the textures, and have it all rendered, you know, the last of the romantics. I think that the fact that there are not many games out there that do that sort of speaks for the fact that it's not straightforward to do. But we chatted before, Martin, and you said that a big part of the appeal of doing all of that in Python is the sort of instructional value, because you also teach. So... And in my experience, I taught myself openGL by developing in Python. So, you know, maybe talk a little bit about that. OpenGL is really hard to learn, especially today. Maybe... Okay, OpenGL is old. The first version came out in the early 1990s. It was a time there were no GPUs yet, so you could also use... Only use the CPU for rendering. And this standard is actually still the same today. However, there are many extensions and new versions, and the current version 4.5 has many new things. And if you want to learn version 4.5 today, you have to program maybe, let me say, three to five hundred lines of code just to render one single triangle. You don't only have to program in Python, you have to learn shading languages, the OpenGL shading language. You have to understand the concepts there. You have to understand there. You have to learn many mathematics. You have to be good in vector math, in matrix multiplication, in projections, and so on. It's really very, very hard to get into. And it's not possible to learn that in half an hour, and that's a really big issue. And learning OpenGL today is, as I said, even harder than it was before. So the best way would be to start learning the old version and then propagate, but that's not really a good solution. So you need time. And I'm teaching computer graphics and I know the difficulties. Sometimes I also don't know where to start. Do you start with the OpenGL shading language or do you start with OpenGL basics? It's really a tough, so you don't need much time to invest if you want to create your own render engine. So the best way to go, in my opinion today, is get Unity or another engine and learn principles there. And then if you understand the basic principles of transformations of all these things, then you can try to create your own thing in OpenGL. That's my advice today. But it doesn't seem that the future is getting any simpler. We have a new API, the Vulkan API, and I don't know how many of you are following the developments there. The Vulkan API is designed to be the new standard by the Kronos group, the same group that developed OpenGL. And it's an even more low-level API which gives you a lot of power. And I suppose it's even more difficult to learn. And again, I think you worked with the Python bindings for it. I understand it's very complex. I didn't work with it. But again, we're going to need a good teaching tool just to grasp the complexities of it. It's a really big, nasty piece of code. Yeah, the Vulkan API is even harder than OpenGL 4.5 to learn. You need even maybe one to 200 lines more code to render one single triangle. But if you understand these principles, then it's easy. So to make two triangles, you need only 501 lines of code, for example. So it gets easier. But it's a low-level API, so you have to do all things yourself. You have to create your models, your projection systems, and so on. It's really very low. So to get started, I don't recommend using Vulkan API at the moment. Especially not using Python. We have to wait maybe next year or two years, and there's stable binding available. Are you saying there's an issue with the binding? Because I think that there's an issue with the drivers themselves, but the implementation of Vulkan. My issue is still too early at the moment. There is almost no documentation. And the drivers are not really very stable at the moment. We have to wait a little bit until the big graphics companies distribute new versions. And then we can start creating a good binding. There are, I think, two bindings available at the moment, but they are not very good maintained. Python bindings, they are not very well maintained. So someone has to step up and say, yes, I create a binding, and I will maintain this for the next five to ten years. Okay. So I think on our side, the kind of people who want to really do everything in Python, the answer is still OpenGL, no matter the complexity. And then to complete the whole application, you would need either Pygame, or myself I use PySDL2. SDL is a high-quality library that handles events and all related stuff. The wrapper is really straightforward, so you can use PySDL2 that gives you portability on all platforms. And because I've used Python, I would say that it's a little bit more low-level, but it's really good and I'd recommend it over Pygame. It's just a touch more complexity. But I would say that if you want to do this kind of an approach, that's the solution right now. Yes. I would recommend starting with 2D games, using Pygame, creating really simple games to understand the principles, how a game actually works. And then if you know the basic principles, go on and try OpenGL bindings with Python. Okay. So, you know, my takeaway, although everybody's optimistic, I think everybody's a little bit more optimistic on the plugin side of things. This seems to me that right now it's a more realistic approach to get Python into an existing engine and have really nice plugins that will give you access to the whole ecosystem. And I understand, Roberto, you've been doing work with AAA Studios that use your plugin, but not necessarily for gameplay events. So, could you...maybe somebody's using it? You'd know if they're using it. You don't have to mention names. Just...yes, maybe. As far as I know, none of the AAA Studios that is using the plugin is using it for the gameplay. They are not even using Blueprints in Unreal Engine. It's a visual scripting tool. They still prefer to use C++ because it is an industry that is fun to C++ by the backends. So, it's really hard to remove this kind of mindset. And they don't even see a reason to remove C++ from their gameplay logic because they have good programmers with it, and they have performance that are very important for them. For all of the other side of the development pipeline, they use the plugin and they use it heavily, even for customizing the editor completely. If you are able to see the desktop of a person working with Unreal Engine in a AAA studio, generally you do not recognize that it is Unreal Engine. They customize it totally. We are talking about pipeline with hundreds of people, so I find it pretty normal to customize your main software to the team needs. But as far as I know, there is not a company using Python for the gameplay. Unless we speak about the server side, if you have a game that with its main lodging on the server, there are a lot of companies using Python with other engines, with other technologies and so on. I think I actually know an example. Eve Online is a famous game that uses Stackless Python for a lot of its game logic. But that's one. And from time to time I Google and it's hard to come up with a lot of commercial games that use Python for gameplay. There was a civilization for it, used it for some scripting and events and modding. And here and there it will pop up, but it's not a big thing yet necessarily. So I think this sort of covers everything we sort of chatted before. We have time for a Q&A. Maybe some questions from the audience. Yeah, thank you. So right at the end you mentioned Stackless Python. Would that be something you've tried or would recommend to... Let's say I want to build a game in Python, should I use Stackless? Or can I use Stackless? I think Eve Online uses Stackless Python not for the game but for the server. Yeah, yeah, yeah. Even Stackless for the client part. Honestly, I don't know how they can benefit from StackSuite switching technologies, something that works like a classic engine. So honestly, I don't know what to answer. I don't know if someone knows how they're using it. I'm not that into details of Stackless. I suppose the issue would be performance. I really don't see a huge issue with... I'm making a 3D game. It's a turn-based game, not a full action game, so it has slightly slower real-time requirements. I don't see huge slowdowns from Python. It doesn't have a huge performance effect. It's doable. Basically, I'm not sure about Stackless. No specific info. But that helps. There was another question. Okay, thank you for the discussion. It's very interesting. But from what you are speaking about, it seems that graphics is like the 99% of the problem in here, or like the games mostly consist of graphics. What about the other parts of the game? Or even sound music? Are there no problems in there? Is it just... The graphic is such a big problem that we start with that, and until we have solved this, we don't even try anything else. Yeah, we are talking 99% about graphics because that's the most compute-intense part of games. Music... It's no problem. Music needs a little bit CPU. No, I mean, in the whole system, you have the GPU takes most parts. And if you look at the compute power that we see today, NVIDIA GTX 1080 has this power of... If you look maybe 20 years ago, you had to spend billions of the compute power you have in a GTX 1080. So graphics is the compute-intense part. And compared to that, music and sound doesn't really take too much away. Let me hear his opinion. Yeah, because the audio engine has just been remade into Godot, so I saw some talk about it. And the really big problem with audio engine is the lag. Audio engine must really have no lag, otherwise you just go out of the game. So writing audio engine in Python, I would say every time you have a little garbage collecting, things like that, even maybe it won't be visible if you do a frame rendering because most of the time, they spend into the graphical card. But for audio engine, you will really see it, feel it really fast. Well, yes, graphics is the main part wasting your CPU power. Regarding the pure game logic, artificial intelligence, in games we still don't use the real, from the academic point of view, artificial intelligence. We still use cheap tricks like finite state machine, behavior tree, something that works perfectly in Python. They are not heavy in resources. So from my point of view, a real engine Python plugin works because on real engine, take care of the graphics part. So in the demo, I showed the Python works flawlessly because the rendering part was done with the engine. But building the AI part or the pure game logic part, it could be absolutely doable. And the best majority of the AAA games, like the first installment of Uncharted, it's game play logic, the best majority of it has been done in Lisp, in a Lisp dialect. Left for dead is another one using squirrel, I think it's another high level scripting language and so on. It is very common for game designers to use a scripting language. Even Timbal with Park, you know it? But it's the same author of... okay, I don't remember. It works for CN, SDL, for the rendering part and then used again squirrel, I think, for the scripting part. For a game designer, it is way more proficient to use an L level language. So yes, it is the rendering part that most heavy want to invest on. So, a different take on that. I saw a presentation by one of the game developers and they were working on this game, which has real war happening in real time. And if you have 1,000 or 2,000 or something objects, and they need to act in every single frame, which is 60 frames a second, that means that you have about 20 instructions that you can execute per thinker. And that's only possible if you use C++. So in these sorts of things, you really need to have performance. But coming on to that, is there any experience on using actually Scython? So you could start by doing your logic in Python and then you find the hotspots and then you rewrite them in Scython. I did try, personally, so I can give you that answer. It might be a matter of personal preference, so I'm not terribly into Scython. I think it's probably a personal preference, it's another syntax you'd learn and already know Python and C, so as long as I'm doing it, might as well just jump into C. I'm actually holding high hopes for using PyPy in this context. It seems to me the way to go, we didn't discuss the gil here, but there seems to be some potential there for eliminating the gil as well. I think if you can live with Scython as a separate Python-like language, it could be the solution, but there could be other, if you need performance, other ways to do it. You could separate your small functionality into some small library, you could paralyze it in some way, or you could use JIT. If you really, really need performance, just basic Python, perhaps will not do. I hope this helps. Hello. Have you ever considered code transpilation from Python to another language for the game logic part in order to embed the result into an engine or something? You asked why using Python for game development, what if you like so much the syntax of Python that you could afford to not using advanced features of Python, but just some basics and then compile it to another language? Yeah, why I like Python for game? Answer this part first. If, for example, a new developer comes into the team, it's much easier if we program Python. If a new developer comes with little experience in C++, you can really mess it up and kill the whole application. I experienced that two times, so that really someone messes up, creates memory leaks, and after no one really knows where these memory leaks were created, et cetera. So using Python solves that a little bit, not fully, but it's much better. And then the part about transpilation, I'm not a big fan of transpilation. The problem is at some point you will have to debug something, and then debugging code that was transpiled is really hard. So that's not, I personally would not do that. If we see that project is not suitable for use of Python, I would recommend using another language in the first place. That's much better than transpiling in my opinion. But then you have to know that if you have a new developer who doesn't really speak C++, you have a risk. Thank you. Okay, it looks like we don't have any more questions. I'd like to thank my co-panelists. I'd like to thank the audience. I hope we have this talk again. It's not the end of Python and games. Maybe it's just the beginning. And thank you all, and see you next time. Thank you.
 My name is Thomas Lavazelot and I make video games entirely in Python, which is sort of  my claim to fame and why I'm here today with you.  And the idea is to have a discussion about whether making video games entirely in Python  is in fact a viable proposition for us.  And I have three guests with me joining us.  There's Roberto, who is the author of the Unreal Engine Python plugin.  I get that right.  He's also a lecturer at the Italian Academy of Video Games.  We get Emmanuel.  He's the author of the plugin for, well, no, it's a wrapper for the Godot Engine.  It's a Python wrapper for the Godot Engine.  And we have, I'll get to you, and then we have Martin, who is a lecturer and a tutor  in Python and 3D.  So guys, my question, and I'm thinking, I was thinking how to start this, was to sort  of take this from the back end, let's sort of start with some strong statements and then  we'll try to defend them later.  And so just try to pose this question immediately and ask you to give me an answer on like one  to 10, making these games in Python mission impossible, one to 10 and then why and then  we'll try to see, maybe from...  Hi everyone.  So from my point of view, the most important thing is making some kind of difference between  Indie Game and the AAA game.  They are pretty different from the result to the money spent over them.  In my opinion, making Indie games with Python, with only Python is absolutely possible.  On the other side, making AAA game only with Python could be a really, really hard challenge.  One to 10.  What did you say Indies are 10?  Oh, it's really hard even to define what Indie Team is.  Nowadays we have Indie Team with a lot of money.  Four or five people with really thousands of dollars invested in them.  So for an Indie Team, I mean something less than 10 person and with zero money.  For me, an Indie Team is something that does not have money.  An Indie Team works only with patience.  This is my own opinion.  I think it really depends on what you are defining when you say entirely in Python.  Because if you dig enough, in the end you always end up finding some C somewhere.  So the only question is what is the sweet spot between the part you are doing in C and the part you are doing in Python.  So I think it's entirely doable to have a lot of your game logic written in Python.  Like they do in the EVE online for example.  So yeah, I would say if you are thinking, making a game means making game logic and not writing a game engine.  I think it's entirely doable in two Python.  And that's why I want to prove by putting Python into Goddow.  And I should give a mark, so I would say 8 out of 10.  So I would give it a 10 if you give me 10 million euro.  Of course it depends what you want to do with.  You want to create a triple A game.  No, unfortunately not.  If you want to make a mobile game.  Yeah, I would give a 1, 2, 3.  Unfortunately.  But for indie game I think there is some chance.  If you say I want to make a game for Mac OS, for Linux, Linux also don't pay for games.  Okay, sometimes I do.  And Windows then okay.  I was in the game industry some years ago and it's really like this Mac users, they spend the most money on games.  So I would make a Mac game, put it in the Apple store.  And there I'm sure there would be a big interest.  If the game is good, if it's an indie game, yeah, I would give it a 7.  Now the question is why would I use Python to create a game?  Is it really necessary?  Wouldn't it be cheaper to just buy a license of Unity 3D or any other engine?  So if I go to investor, I think he would say no, please take Unity or whatever.  If it's me, I would like to use Python.  Okay, but we have to think about that too.  So it depends what, ranging from 1 to 10.  Okay, so that's a broad range of answers.  I have to sort of admit that I agree with Martin that it's a bit of a stretch to do everything in Python,  which incidentally is what I do in my games, implement the whole rendering and all of that in Python,  for various reasons which I hope will have time to cover that doesn't, it's really hard to do.  But I can gather from you guys that there is hope.  So maybe try to be informative and describe everybody.  Each one of us has been doing some approach.  Roberto, you've been doing Unreal Engine.  You have been working on Godot which has similarities with Unity.  Obviously Martin and I have had approaches which is more like directly working with OpenGL.  So just a few quick words on each approach so that people who don't necessarily know what it entails to work with each one.  So just a few quick words on everybody's approach.  It's a strange term, hope for me, because it's like saying,  is there hope for using Python as the language for your browser instead of JavaScript?  Making a game or generally making a software does not necessarily require a single technology.  There are technologies better suited than others and so on.  From my point of view, there are some parts of building a game and its game engine  that can be done in a really good way with Python and other parts, especially from the engine side,  that not came out so good when using such a high-level language.  Last year at the Eurovision in Bilbao, I gave a talk about OpenGL or in Python.  Absolutely, it is something that we can do.  But nowadays there are a lot of technologies, high-level technologies.  I'm thinking about the NVIDIA technologies like VRWars, the simulation of cloth, hair and so on,  that are really performance intensive.  So from these kind of tasks, we cannot expect a higher-level language like Python, JavaScript,  every higher-level language can be used in this day.  We can hope in the sense that future computers can be way more powerful than nowadays computers,  so we can even use less fast language instead of relying on languages like C or C++  for doing high CPU intensive tasks.  This is the only hope I think we can have, better hardware for using software that is not so fast.  I just wanted to ask before we move on.  Sure, a big engine like Unreal packs a lot of punch.  It does physics, it does all these simulations, and it's kind of difficult to imagine all of this intensive CPU side code  being done in Python.  But what about the future in which all these little systems sort of exist as well-defined Python modules?  I know it's fanciful, but just in theory, couldn't that be a future that exists?  Yeah, it could be.  My company released a bunch of years ago a Python wrapper for a Ballet Physics library.  I don't know if you know it.  It's a pretty famous physics library, even in GTA.  So yes, it could be something we can do.  I don't remember what was the question in the first place.  We have a question.  Can you just explain your approach?  Yeah, I think, like you said, there is really two schools.  There is the one who wants to use Python as the first language and write everything inside Python.  And the other one who kind of plug from an existing engine, has just wanted to extend this engine with Python.  So I'm part of the second school.  And the great thing with Godot is the code is clean enough to just separate the engine and what should be the script system.  And so you can really write your scripts with multiple languages.  And the great thing is maybe you can even think about Python like a part of your development process.  And it won't be in the final product because you find it's too slow, maybe.  But during development, if you could use Python to just try really fast some ideas,  I think it could be really like boost the development, like trade new ideas and so on.  And you end up in the end rewriting everything in C++ in the last months of the development of your game.  Yeah, I used the approach to use OpenGL bindings.  OpenGL is a very old standard of computer graphics.  Every big GPU supports it, like NVIDIA, AMD and so on Intel.  And I think it's possible to create good games using pure OpenGL bindings.  So pure Python with OpenGL bindings.  Okay, it's not pure anymore.  But we call these things and it works.  However, the problem is, as I mentioned before, if I create a big game project,  and I want to submit it to an app store, iOS, Android, etc., then I will fail with that approach.  And that's something I want to ask you to think about that.  If in future, I mean, if I publish a game, I don't know if it's a big success.  And the next step is I want to publish it to the app store.  So what do I do?  And that's my big question about that.  If I do it entirely with Python, then I'm limited in that.  Well, I can tell you that since we're making a game and publishing it on Steam,  obviously on Steam it's a PC platform.  You don't really have limitations on Python.  You're fine.  You distribute your code, you distribute your Python, you distribute your modules.  Linux, Windows Mac, almost comes for free.  At the time, I released our biggest game, it was a question like whether we want to move to iOS.  And technically, it was possible to put everything on iOS, but at the time there was a big uncertainty  about whether Apple would let you have Python on an iOS device.  I understand that at this point it's not a problem.  It's allowed, but perhaps someone in the audience will know more up-to-date information.  Because I don't know, for example, on the PlayStation, does this work?  A lot of these stores and ecosystems are not really happy about interpreted code and bringing stuff in.  So yeah, it could be a risk.  And I think you guys, it's sort of, I think a more fundamental question then is why use Python?  I mean, if you want to make a game, you could use other languages.  Obviously, we're here at the Python conference.  That's what we're interested.  But I think if you're talking to somebody who just wants to make games, there's a question of why Python?  And there are good reasons, I know, but we'll talk about them.  I just wanted to ask any people who work in video games with us right now?  There's one.  There's you, I know you.  Just two?  Three? Okay.  This is what it is for a Python conference this time.  I hope there will be more.  And so I think there are other things in a video game company that Python gets used for.  And, you know, Roberto, you had things to say about that.  So I think you could just, we can just discuss it because the big appeal of Python is that it gets used throughout the development process.  And that's why it would be perhaps good to put more of it into the actual gameplay.  So, yes, in the video game industry, Python is basically one of the reference script languages you use,  especially from the artist point of view where they used to my other 3ds Max blender and so on.  Basically, I still have to met animators that do not script their pipeline work.  Well, from, again, from my point of view, programming is a lot about automating tasks.  So, personally, it's not a huge problem for me that I cannot script my engine with a higher level language,  but it is very important for me that I can use a higher level language, which I don't need to compile with a lot,  having strange error, having to pay attention to any single line I write and so on.  Having the possibility to use such a language to automate and simplify my work is really, really important.  More important than the ability to use it for every part of my work.  Okay, so that's one part of it.  A lot of people who already work in the industry will know the language.  And as a looking, I have a list of things that you can use. You know, sure you can script your asset pipeline.  That's very useful. Your testing.  A lot of people use it for server-side applications for games, which are depending on what your game is,  that can be really important.  One thing that I've done and Martin, you're a bit of an expert for is we import a lot of geographic data.  If your game is on a map, that will happen.  So as part of a broader question, which is, you know, how is Python beneficial?  Because it gives you access to a lot of tools that are in the Python system.  So yeah, it's a bit of a question for you, Martin, you work with Geo.  You can use that in your game. It opens up a lot of possibility, doesn't it?  Yes, for data processing, Python is really one of the best ways to go.  So I developed a virtual globe some years ago similar to Google Earth.  And there we had to process terabytes of data for the visualization afterwards.  And we used Python on a high-performance computing system, and we processed all the data there,  and it was really great. And the code is really maintainable.  But that's not for actually the rendering.  The rendering was done in the web browser using WebGL.  So that's pity, but it's like it is.  But for the data processing part, it's cool.  There are many libraries like GDAL, the Geo data abstraction library, for example,  where you can load the different datasets, et cetera, et cetera.  It's really a cool way.  Please go on. I need to fix that.  Change back to...  Okay. And for the data processing part in general,  I recommend using Python for the visualization part.  We had to use WebGL because it run in the web browser.  Very simple for that project.  Okay. So when we discussed...  I also saw an interesting demo on your own talk,  which, again, because you were importing Python into Unreal Engine,  you were able to access OpenCV.  So, you know, could you talk a little bit more about that  and just the possibilities that it gives you  just by importing stuff unrestricted from the Python system?  I think one of the advantages of using Python in a game development pipeline  is the amount of third-party libraries that are available,  especially in the scientific area.  Artificial intelligence, big data management, and so on.  Libraries that generally are not available in other languages  or became really painful to use using lower-level languages.  Embedding Python Virtual Machine into a professional game engine  allowed me and the users to import the depth libraries  and use them into something visually really powerful.  This morning we had seen a keynote about that visualization.  I was already thinking about how much better could be that data  into Unreal Engine.  We are seeing straight-liners, trees.  In my mind, we can reproduce the whole earth with trees,  with the real size, with the right kind of tree, and so on.  So, something way more big in the scale that we can do now.  So, the real advantage now of using Python into Unreal Engine,  is that it's possible to use this kind of libraries.  I don't know if you want to answer.  I think it's something really interesting,  because it means that you are bringing a game engine to people using Python,  which means you are bringing it to scientists,  people that are used to, in the past, use R and then they go to Python now.  So, it means really new possibility for them, I think.  I'm personally working in my day job with people from the scientific background,  and I want new ways to show the data,  and for the moon they don't even think about game engine,  because it's for game, it's not for working.  I just wanted to ask you guys to represent the faction here  that takes an existing very capable game engine.  In your case it's a free engine, Godot.  In your case it's like an industry standard, top of the line engine,  not free, but super.  So, you represent this faction, and I get it that it's wonderful.  I sort of do the other thing, but I have to,  okay, you guys defend your side, but it's wonderful.  But in both of your talks, I noticed that there are considerable technical difficulties.  In making that work, because both projects are recently less than a year old,  and you hear the same complaints, they're like two garbage collectors,  I think in both projects.  Then there's this issue of performance, do we want to go with JIT, with the PyPy?  So, a lot of issues sort of come up with that.  Maybe just shed some light on that.  Are we sort of condemned to that?  Two garbage collectors, does this really have to be?  Just some input on that.  Well, I think we have been both really unlucky,  because we are pioneers, we are the first people trying to do something like that.  Because now that Unreal Engine PyToplogin is way more mature,  a lot of wrapper for the languages will come out,  because now I've made a lot of research for them,  so they can start working on their wrappers.  And the same for the Godot wrapper,  I suppose now we will see a lot of scripting languages that will come out.  Yes, we are condemned,  but now we have some tech info,  we have some kind of literature to allow other people to do this work,  without so much pain.  I think the trouble was Python was added to an existing Engine,  but it would be a really simple thing to just create an Engine in C++ when syncing.  That's a high-level scripting that will be done in Python from the beginning,  like it's doing a Pandas 3D.  I didn't try it personally, but I think if somebody has experienced with it,  it would be really interesting.  Pandas 3D.  Okay.  Pandas 3D is another Engine,  used a lot by Disney,  in the past now Disney has moved to another Engine.  It's allowed to be scripted in Python from the beginning,  so it's architecture allowed for high interaction with Python.  It is a pretty specific case.  I have to say that the Epic stuff the guys making Unreal Engine has been very supportive with me,  so they even made some modifications to the Engine to allow integration with scripting.  Even the Godot Engine had new features to allow,  big features to allow integration with other languages.  Pandas 3D loses a bit of traction nowadays that we have Unity, Unreal, Godot,  that are way more powerful.  But as far as I know, Pandas is one of the first big Engine with a strong Python support.  Does anyone know the situation with Unity and Python?  Yeah, there is a...  I heard that some guy working on PyPy has just started to work on Unity and Python,  but he's not in the room, unfortunately.  But if you find some PyPy guys, you can ask him directly.  It's just a really start for the moment, but maybe it will go somewhere eventually.  I'm really curious about how they can do it without sources,  because both Unreal Engine and Godot have sources, so how could they do with Unity?  It would be really interesting to know this.  By the way, Unity, up to the fourth version, came with Python-like language, Boo.  I don't know if you ever...  Then they removed the support because no one used it and don't want to use some subversion of Python.  Okay, so Martin, you and I are on the side where we want to do everything in Python.  We create our own rendering loop.  We call make it openGL functions, and we send our data, our buffers, and the textures,  and have it all rendered, you know, the last of the romantics.  I think that the fact that there are not many games out there that do that  sort of speaks for the fact that it's not straightforward to do.  But we chatted before, Martin, and you said that a big part of the appeal of doing all of that in Python  is the sort of instructional value, because you also teach.  So...  And in my experience, I taught myself openGL by developing in Python.  So, you know, maybe talk a little bit about that.  OpenGL is really hard to learn, especially today.  Maybe...  Okay, OpenGL is old.  The first version came out in the early 1990s.  It was a time there were no GPUs yet, so you could also use...  Only use the CPU for rendering.  And this standard is actually still the same today.  However, there are many extensions and new versions, and the current version 4.5 has many new things.  And if you want to learn version 4.5 today, you have to program maybe, let me say,  three to five hundred lines of code just to render one single triangle.  You don't only have to program in Python, you have to learn shading languages, the OpenGL shading language.  You have to understand the concepts there.  You have to understand there.  You have to learn many mathematics.  You have to be good in vector math, in matrix multiplication, in projections, and so on.  It's really very, very hard to get into.  And it's not possible to learn that in half an hour, and that's a really big issue.  And learning OpenGL today is, as I said, even harder than it was before.  So the best way would be to start learning the old version and then propagate,  but that's not really a good solution.  So you need time.  And I'm teaching computer graphics and I know the difficulties.  Sometimes I also don't know where to start.  Do you start with the OpenGL shading language or do you start with OpenGL basics?  It's really a tough, so you don't need much time to invest if you want to create your own render engine.  So the best way to go, in my opinion today, is get Unity or another engine and learn principles there.  And then if you understand the basic principles of transformations of all these things,  then you can try to create your own thing in OpenGL.  That's my advice today.  But it doesn't seem that the future is getting any simpler.  We have a new API, the Vulkan API, and I don't know how many of you are following the developments there.  The Vulkan API is designed to be the new standard by the Kronos group,  the same group that developed OpenGL.  And it's an even more low-level API which gives you a lot of power.  And I suppose it's even more difficult to learn.  And again, I think you worked with the Python bindings for it.  I understand it's very complex.  I didn't work with it.  But again, we're going to need a good teaching tool just to grasp the complexities of it.  It's a really big, nasty piece of code.  Yeah, the Vulkan API is even harder than OpenGL 4.5 to learn.  You need even maybe one to 200 lines more code to render one single triangle.  But if you understand these principles, then it's easy.  So to make two triangles, you need only 501 lines of code, for example.  So it gets easier.  But it's a low-level API, so you have to do all things yourself.  You have to create your models, your projection systems, and so on.  It's really very low.  So to get started, I don't recommend using Vulkan API at the moment.  Especially not using Python.  We have to wait maybe next year or two years, and there's stable binding available.  Are you saying there's an issue with the binding?  Because I think that there's an issue with the drivers themselves, but the implementation of Vulkan.  My issue is still too early at the moment.  There is almost no documentation.  And the drivers are not really very stable at the moment.  We have to wait a little bit until the big graphics companies distribute new versions.  And then we can start creating a good binding.  There are, I think, two bindings available at the moment, but they are not very good maintained.  Python bindings, they are not very well maintained.  So someone has to step up and say, yes, I create a binding,  and I will maintain this for the next five to ten years.  Okay. So I think on our side, the kind of people who want to really do everything in Python,  the answer is still OpenGL, no matter the complexity.  And then to complete the whole application, you would need either Pygame,  or myself I use PySDL2.  SDL is a high-quality library that handles events and all related stuff.  The wrapper is really straightforward, so you can use PySDL2 that gives you portability on all platforms.  And because I've used Python, I would say that it's a little bit more low-level,  but it's really good and I'd recommend it over Pygame.  It's just a touch more complexity.  But I would say that if you want to do this kind of an approach, that's the solution right now.  Yes. I would recommend starting with 2D games, using Pygame,  creating really simple games to understand the principles, how a game actually works.  And then if you know the basic principles, go on and try OpenGL bindings with Python.  Okay. So, you know, my takeaway, although everybody's optimistic, I think everybody's a little bit more optimistic  on the plugin side of things.  This seems to me that right now it's a more realistic approach to get Python into an existing engine  and have really nice plugins that will give you access to the whole ecosystem.  And I understand, Roberto, you've been doing work with AAA Studios that use your plugin,  but not necessarily for gameplay events.  So, could you...maybe somebody's using it? You'd know if they're using it.  You don't have to mention names. Just...yes, maybe.  As far as I know, none of the AAA Studios that is using the plugin is using it for the gameplay.  They are not even using Blueprints in Unreal Engine. It's a visual scripting tool.  They still prefer to use C++ because it is an industry that is fun to C++ by the backends.  So, it's really hard to remove this kind of mindset.  And they don't even see a reason to remove C++ from their gameplay logic  because they have good programmers with it, and they have performance that are very important for them.  For all of the other side of the development pipeline, they use the plugin and they use it heavily,  even for customizing the editor completely.  If you are able to see the desktop of a person working with Unreal Engine in a AAA studio,  generally you do not recognize that it is Unreal Engine. They customize it totally.  We are talking about pipeline with hundreds of people, so I find it pretty normal to customize your main software to the team needs.  But as far as I know, there is not a company using Python for the gameplay.  Unless we speak about the server side, if you have a game that with its main lodging on the server,  there are a lot of companies using Python with other engines, with other technologies and so on.  I think I actually know an example. Eve Online is a famous game that uses Stackless Python for a lot of its game logic.  But that's one. And from time to time I Google and it's hard to come up with a lot of commercial games that use Python for gameplay.  There was a civilization for it, used it for some scripting and events and modding. And here and there it will pop up,  but it's not a big thing yet necessarily.  So I think this sort of covers everything we sort of chatted before. We have time for a Q&A.  Maybe some questions from the audience.  Yeah, thank you. So right at the end you mentioned Stackless Python.  Would that be something you've tried or would recommend to...  Let's say I want to build a game in Python, should I use Stackless? Or can I use Stackless?  I think Eve Online uses Stackless Python not for the game but for the server.  Yeah, yeah, yeah.  Even Stackless for the client part.  Honestly, I don't know how they can benefit from StackSuite switching technologies, something that works like a classic engine.  So honestly, I don't know what to answer. I don't know if someone knows how they're using it.  I'm not that into details of Stackless. I suppose the issue would be performance.  I really don't see a huge issue with... I'm making a 3D game.  It's a turn-based game, not a full action game, so it has slightly slower real-time requirements.  I don't see huge slowdowns from Python. It doesn't have a huge performance effect. It's doable.  Basically, I'm not sure about Stackless. No specific info. But that helps.  There was another question.  Okay, thank you for the discussion. It's very interesting. But from what you are speaking about,  it seems that graphics is like the 99% of the problem in here, or like the games mostly consist of graphics.  What about the other parts of the game? Or even sound music? Are there no problems in there?  Is it just... The graphic is such a big problem that we start with that, and until we have solved this,  we don't even try anything else.  Yeah, we are talking 99% about graphics because that's the most compute-intense part of games.  Music... It's no problem. Music needs a little bit CPU.  No, I mean, in the whole system, you have the GPU takes most parts.  And if you look at the compute power that we see today, NVIDIA GTX 1080 has this power of...  If you look maybe 20 years ago, you had to spend billions of the compute power you have in a GTX 1080.  So graphics is the compute-intense part. And compared to that, music and sound doesn't really take too much away.  Let me hear his opinion.  Yeah, because the audio engine has just been remade into Godot, so I saw some talk about it.  And the really big problem with audio engine is the lag.  Audio engine must really have no lag, otherwise you just go out of the game.  So writing audio engine in Python, I would say every time you have a little garbage collecting, things like that,  even maybe it won't be visible if you do a frame rendering because most of the time, they spend into the graphical card.  But for audio engine, you will really see it, feel it really fast.  Well, yes, graphics is the main part wasting your CPU power.  Regarding the pure game logic, artificial intelligence,  in games we still don't use the real, from the academic point of view, artificial intelligence.  We still use cheap tricks like finite state machine, behavior tree, something that works perfectly in Python.  They are not heavy in resources.  So from my point of view, a real engine Python plugin works because on real engine, take care of the graphics part.  So in the demo, I showed the Python works flawlessly because the rendering part was done with the engine.  But building the AI part or the pure game logic part, it could be absolutely doable.  And the best majority of the AAA games, like the first installment of Uncharted,  it's game play logic, the best majority of it has been done in Lisp, in a Lisp dialect.  Left for dead is another one using squirrel, I think it's another high level scripting language and so on.  It is very common for game designers to use a scripting language.  Even Timbal with Park, you know it?  But it's the same author of... okay, I don't remember.  It works for CN, SDL, for the rendering part and then used again squirrel, I think, for the scripting part.  For a game designer, it is way more proficient to use an L level language.  So yes, it is the rendering part that most heavy want to invest on.  So, a different take on that.  I saw a presentation by one of the game developers and they were working on this game,  which has real war happening in real time.  And if you have 1,000 or 2,000 or something objects, and they need to act in every single frame,  which is 60 frames a second, that means that you have about 20 instructions that you can execute per thinker.  And that's only possible if you use C++.  So in these sorts of things, you really need to have performance.  But coming on to that, is there any experience on using actually Scython?  So you could start by doing your logic in Python and then you find the hotspots and then you rewrite them in Scython.  I did try, personally, so I can give you that answer.  It might be a matter of personal preference, so I'm not terribly into Scython.  I think it's probably a personal preference, it's another syntax you'd learn and already know Python and C,  so as long as I'm doing it, might as well just jump into C.  I'm actually holding high hopes for using PyPy in this context.  It seems to me the way to go, we didn't discuss the gil here,  but there seems to be some potential there for eliminating the gil as well.  I think if you can live with Scython as a separate Python-like language,  it could be the solution, but there could be other, if you need performance, other ways to do it.  You could separate your small functionality into some small library, you could paralyze it in some way,  or you could use JIT.  If you really, really need performance, just basic Python, perhaps will not do.  I hope this helps.  Hello. Have you ever considered code transpilation from Python to another language for the game logic part  in order to embed the result into an engine or something?  You asked why using Python for game development, what if you like so much the syntax of Python  that you could afford to not using advanced features of Python,  but just some basics and then compile it to another language?  Yeah, why I like Python for game? Answer this part first.  If, for example, a new developer comes into the team, it's much easier if we program Python.  If a new developer comes with little experience in C++, you can really mess it up and kill the whole application.  I experienced that two times, so that really someone messes up, creates memory leaks,  and after no one really knows where these memory leaks were created, et cetera.  So using Python solves that a little bit, not fully, but it's much better.  And then the part about transpilation, I'm not a big fan of transpilation.  The problem is at some point you will have to debug something,  and then debugging code that was transpiled is really hard.  So that's not, I personally would not do that.  If we see that project is not suitable for use of Python,  I would recommend using another language in the first place.  That's much better than transpiling in my opinion.  But then you have to know that if you have a new developer who doesn't really speak C++, you have a risk.  Thank you.  Okay, it looks like we don't have any more questions.  I'd like to thank my co-panelists.  I'd like to thank the audience.  I hope we have this talk again.  It's not the end of Python and games.  Maybe it's just the beginning.  And thank you all, and see you next time.  Thank you.
Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_0_3203.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_3204_3815.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_3816_3923.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_3924_10355.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_10356_10559.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_10560_12263.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_12264_13439.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_13440_14375.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_14376_16691.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_16692_17135.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_17136_18935.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_18936_22979.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_22980_23663.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_23664_24347.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_24348_26483.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_26484_28427.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_28428_29783.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_29784_31979.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_31980_34871.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_34872_36143.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_36144_36803.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_36804_39203.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_39204_40583.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_40584_40631.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_40632_42143.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_42144_45371.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_45372_47063.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_47064_47159.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_47160_52283.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_52284_56015.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_56016_56495.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_56496_56735.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_56736_58355.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_58356_58439.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_58440_59351.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_59352_62927.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_62928_63143.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_63144_64955.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_64956_66215.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_66216_68123.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_68124_68207.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_68208_69083.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_69084_69191.png Martin_Christen__Roberto_De_Ioris__Tomislav_Uzelac_-_Making_Games_with_Python__Mission_Impossible__y_69192_71677.png
My name is Thomas Lavazelot and I make video games entirely in Python, which is sort of my claim to fame and why I'm here today with you. And the idea is to have a discussion about whether making video games entirely in Python is in fact a viable proposition for us. And I have three guests with me joining us. There's Roberto, who is the author of the Unreal Engine Python plugin. I get that right. He's also a lecturer at the Italian Academy of Video Games. We get Emmanuel. He's the author of the plugin for, well, no, it's a wrapper for the Godot Engine. It's a Python wrapper for the Godot Engine. And we have, I'll get to you, and then we have Martin, who is a lecturer and a tutor in Python and 3D. So guys, my question, and I'm thinking, I was thinking how to start this, was to sort of take this from the back end, let's sort of start with some strong statements and then we'll try to defend them later. And so just try to pose this question immediately and ask you to give me an answer on like one to 10, making these games in Python mission impossible, one to 10 and then why and then we'll try to see, maybe from... Hi everyone. So from my point of view, the most important thing is making some kind of difference between Indie Game and the AAA game. They are pretty different from the result to the money spent over them. In my opinion, making Indie games with Python, with only Python is absolutely possible. On the other side, making AAA game only with Python could be a really, really hard challenge. One to 10. What did you say Indies are 10? Oh, it's really hard even to define what Indie Team is. Nowadays we have Indie Team with a lot of money. Four or five people with really thousands of dollars invested in them. So for an Indie Team, I mean something less than 10 person and with zero money. For me, an Indie Team is something that does not have money. An Indie Team works only with patience. This is my own opinion. I think it really depends on what you are defining when you say entirely in Python. Because if you dig enough, in the end you always end up finding some C somewhere. So the only question is what is the sweet spot between the part you are doing in C and the part you are doing in Python. So I think it's entirely doable to have a lot of your game logic written in Python. Like they do in the EVE online for example. So yeah, I would say if you are thinking, making a game means making game logic and not writing a game engine. I think it's entirely doable in two Python. And that's why I want to prove by putting Python into Goddow. And I should give a mark, so I would say 8 out of 10. So I would give it a 10 if you give me 10 million euro. Of course it depends what you want to do with. You want to create a triple A game. No, unfortunately not. If you want to make a mobile game. Yeah, I would give a 1, 2, 3. Unfortunately. But for indie game I think there is some chance. If you say I want to make a game for Mac OS, for Linux, Linux also don't pay for games. Okay, sometimes I do. And Windows then okay. I was in the game industry some years ago and it's really like this Mac users, they spend the most money on games. So I would make a Mac game, put it in the Apple store. And there I'm sure there would be a big interest. If the game is good, if it's an indie game, yeah, I would give it a 7. Now the question is why would I use Python to create a game? Is it really necessary? Wouldn't it be cheaper to just buy a license of Unity 3D or any other engine? So if I go to investor, I think he would say no, please take Unity or whatever. If it's me, I would like to use Python. Okay, but we have to think about that too. So it depends what, ranging from 1 to 10. Okay, so that's a broad range of answers. I have to sort of admit that I agree with Martin that it's a bit of a stretch to do everything in Python, which incidentally is what I do in my games, implement the whole rendering and all of that in Python, for various reasons which I hope will have time to cover that doesn't, it's really hard to do. But I can gather from you guys that there is hope. So maybe try to be informative and describe everybody. Each one of us has been doing some approach. Roberto, you've been doing Unreal Engine. You have been working on Godot which has similarities with Unity. Obviously Martin and I have had approaches which is more like directly working with OpenGL. So just a few quick words on each approach so that people who don't necessarily know what it entails to work with each one. So just a few quick words on everybody's approach. It's a strange term, hope for me, because it's like saying, is there hope for using Python as the language for your browser instead of JavaScript? Making a game or generally making a software does not necessarily require a single technology. There are technologies better suited than others and so on. From my point of view, there are some parts of building a game and its game engine that can be done in a really good way with Python and other parts, especially from the engine side, that not came out so good when using such a high-level language. Last year at the Eurovision in Bilbao, I gave a talk about OpenGL or in Python. Absolutely, it is something that we can do. But nowadays there are a lot of technologies, high-level technologies. I'm thinking about the NVIDIA technologies like VRWars, the simulation of cloth, hair and so on, that are really performance intensive. So from these kind of tasks, we cannot expect a higher-level language like Python, JavaScript, every higher-level language can be used in this day. We can hope in the sense that future computers can be way more powerful than nowadays computers, so we can even use less fast language instead of relying on languages like C or C++ for doing high CPU intensive tasks. This is the only hope I think we can have, better hardware for using software that is not so fast. I just wanted to ask before we move on. Sure, a big engine like Unreal packs a lot of punch. It does physics, it does all these simulations, and it's kind of difficult to imagine all of this intensive CPU side code being done in Python. But what about the future in which all these little systems sort of exist as well-defined Python modules? I know it's fanciful, but just in theory, couldn't that be a future that exists? Yeah, it could be. My company released a bunch of years ago a Python wrapper for a Ballet Physics library. I don't know if you know it. It's a pretty famous physics library, even in GTA. So yes, it could be something we can do. I don't remember what was the question in the first place. We have a question. Can you just explain your approach? Yeah, I think, like you said, there is really two schools. There is the one who wants to use Python as the first language and write everything inside Python. And the other one who kind of plug from an existing engine, has just wanted to extend this engine with Python. So I'm part of the second school. And the great thing with Godot is the code is clean enough to just separate the engine and what should be the script system. And so you can really write your scripts with multiple languages. And the great thing is maybe you can even think about Python like a part of your development process. And it won't be in the final product because you find it's too slow, maybe. But during development, if you could use Python to just try really fast some ideas, I think it could be really like boost the development, like trade new ideas and so on. And you end up in the end rewriting everything in C++ in the last months of the development of your game. Yeah, I used the approach to use OpenGL bindings. OpenGL is a very old standard of computer graphics. Every big GPU supports it, like NVIDIA, AMD and so on Intel. And I think it's possible to create good games using pure OpenGL bindings. So pure Python with OpenGL bindings. Okay, it's not pure anymore. But we call these things and it works. However, the problem is, as I mentioned before, if I create a big game project, and I want to submit it to an app store, iOS, Android, etc., then I will fail with that approach. And that's something I want to ask you to think about that. If in future, I mean, if I publish a game, I don't know if it's a big success. And the next step is I want to publish it to the app store. So what do I do? And that's my big question about that. If I do it entirely with Python, then I'm limited in that. Well, I can tell you that since we're making a game and publishing it on Steam, obviously on Steam it's a PC platform. You don't really have limitations on Python. You're fine. You distribute your code, you distribute your Python, you distribute your modules. Linux, Windows Mac, almost comes for free. At the time, I released our biggest game, it was a question like whether we want to move to iOS. And technically, it was possible to put everything on iOS, but at the time there was a big uncertainty about whether Apple would let you have Python on an iOS device. I understand that at this point it's not a problem. It's allowed, but perhaps someone in the audience will know more up-to-date information. Because I don't know, for example, on the PlayStation, does this work? A lot of these stores and ecosystems are not really happy about interpreted code and bringing stuff in. So yeah, it could be a risk. And I think you guys, it's sort of, I think a more fundamental question then is why use Python? I mean, if you want to make a game, you could use other languages. Obviously, we're here at the Python conference. That's what we're interested. But I think if you're talking to somebody who just wants to make games, there's a question of why Python? And there are good reasons, I know, but we'll talk about them. I just wanted to ask any people who work in video games with us right now? There's one. There's you, I know you. Just two? Three? Okay. This is what it is for a Python conference this time. I hope there will be more. And so I think there are other things in a video game company that Python gets used for. And, you know, Roberto, you had things to say about that. So I think you could just, we can just discuss it because the big appeal of Python is that it gets used throughout the development process. And that's why it would be perhaps good to put more of it into the actual gameplay. So, yes, in the video game industry, Python is basically one of the reference script languages you use, especially from the artist point of view where they used to my other 3ds Max blender and so on. Basically, I still have to met animators that do not script their pipeline work. Well, from, again, from my point of view, programming is a lot about automating tasks. So, personally, it's not a huge problem for me that I cannot script my engine with a higher level language, but it is very important for me that I can use a higher level language, which I don't need to compile with a lot, having strange error, having to pay attention to any single line I write and so on. Having the possibility to use such a language to automate and simplify my work is really, really important. More important than the ability to use it for every part of my work. Okay, so that's one part of it. A lot of people who already work in the industry will know the language. And as a looking, I have a list of things that you can use. You know, sure you can script your asset pipeline. That's very useful. Your testing. A lot of people use it for server-side applications for games, which are depending on what your game is, that can be really important. One thing that I've done and Martin, you're a bit of an expert for is we import a lot of geographic data. If your game is on a map, that will happen. So as part of a broader question, which is, you know, how is Python beneficial? Because it gives you access to a lot of tools that are in the Python system. So yeah, it's a bit of a question for you, Martin, you work with Geo. You can use that in your game. It opens up a lot of possibility, doesn't it? Yes, for data processing, Python is really one of the best ways to go. So I developed a virtual globe some years ago similar to Google Earth. And there we had to process terabytes of data for the visualization afterwards. And we used Python on a high-performance computing system, and we processed all the data there, and it was really great. And the code is really maintainable. But that's not for actually the rendering. The rendering was done in the web browser using WebGL. So that's pity, but it's like it is. But for the data processing part, it's cool. There are many libraries like GDAL, the Geo data abstraction library, for example, where you can load the different datasets, et cetera, et cetera. It's really a cool way. Please go on. I need to fix that. Change back to... Okay. And for the data processing part in general, I recommend using Python for the visualization part. We had to use WebGL because it run in the web browser. Very simple for that project. Okay. So when we discussed... I also saw an interesting demo on your own talk, which, again, because you were importing Python into Unreal Engine, you were able to access OpenCV. So, you know, could you talk a little bit more about that and just the possibilities that it gives you just by importing stuff unrestricted from the Python system? I think one of the advantages of using Python in a game development pipeline is the amount of third-party libraries that are available, especially in the scientific area. Artificial intelligence, big data management, and so on. Libraries that generally are not available in other languages or became really painful to use using lower-level languages. Embedding Python Virtual Machine into a professional game engine allowed me and the users to import the depth libraries and use them into something visually really powerful. This morning we had seen a keynote about that visualization. I was already thinking about how much better could be that data into Unreal Engine. We are seeing straight-liners, trees. In my mind, we can reproduce the whole earth with trees, with the real size, with the right kind of tree, and so on. So, something way more big in the scale that we can do now. So, the real advantage now of using Python into Unreal Engine, is that it's possible to use this kind of libraries. I don't know if you want to answer. I think it's something really interesting, because it means that you are bringing a game engine to people using Python, which means you are bringing it to scientists, people that are used to, in the past, use R and then they go to Python now. So, it means really new possibility for them, I think. I'm personally working in my day job with people from the scientific background, and I want new ways to show the data, and for the moon they don't even think about game engine, because it's for game, it's not for working. I just wanted to ask you guys to represent the faction here that takes an existing very capable game engine. In your case it's a free engine, Godot. In your case it's like an industry standard, top of the line engine, not free, but super. So, you represent this faction, and I get it that it's wonderful. I sort of do the other thing, but I have to, okay, you guys defend your side, but it's wonderful. But in both of your talks, I noticed that there are considerable technical difficulties. In making that work, because both projects are recently less than a year old, and you hear the same complaints, they're like two garbage collectors, I think in both projects. Then there's this issue of performance, do we want to go with JIT, with the PyPy? So, a lot of issues sort of come up with that. Maybe just shed some light on that. Are we sort of condemned to that? Two garbage collectors, does this really have to be? Just some input on that. Well, I think we have been both really unlucky, because we are pioneers, we are the first people trying to do something like that. Because now that Unreal Engine PyToplogin is way more mature, a lot of wrapper for the languages will come out, because now I've made a lot of research for them, so they can start working on their wrappers. And the same for the Godot wrapper, I suppose now we will see a lot of scripting languages that will come out. Yes, we are condemned, but now we have some tech info, we have some kind of literature to allow other people to do this work, without so much pain. I think the trouble was Python was added to an existing Engine, but it would be a really simple thing to just create an Engine in C++ when syncing. That's a high-level scripting that will be done in Python from the beginning, like it's doing a Pandas 3D. I didn't try it personally, but I think if somebody has experienced with it, it would be really interesting. Pandas 3D. Okay. Pandas 3D is another Engine, used a lot by Disney, in the past now Disney has moved to another Engine. It's allowed to be scripted in Python from the beginning, so it's architecture allowed for high interaction with Python. It is a pretty specific case. I have to say that the Epic stuff the guys making Unreal Engine has been very supportive with me, so they even made some modifications to the Engine to allow integration with scripting. Even the Godot Engine had new features to allow, big features to allow integration with other languages. Pandas 3D loses a bit of traction nowadays that we have Unity, Unreal, Godot, that are way more powerful. But as far as I know, Pandas is one of the first big Engine with a strong Python support. Does anyone know the situation with Unity and Python? Yeah, there is a... I heard that some guy working on PyPy has just started to work on Unity and Python, but he's not in the room, unfortunately. But if you find some PyPy guys, you can ask him directly. It's just a really start for the moment, but maybe it will go somewhere eventually. I'm really curious about how they can do it without sources, because both Unreal Engine and Godot have sources, so how could they do with Unity? It would be really interesting to know this. By the way, Unity, up to the fourth version, came with Python-like language, Boo. I don't know if you ever... Then they removed the support because no one used it and don't want to use some subversion of Python. Okay, so Martin, you and I are on the side where we want to do everything in Python. We create our own rendering loop. We call make it openGL functions, and we send our data, our buffers, and the textures, and have it all rendered, you know, the last of the romantics. I think that the fact that there are not many games out there that do that sort of speaks for the fact that it's not straightforward to do. But we chatted before, Martin, and you said that a big part of the appeal of doing all of that in Python is the sort of instructional value, because you also teach. So... And in my experience, I taught myself openGL by developing in Python. So, you know, maybe talk a little bit about that. OpenGL is really hard to learn, especially today. Maybe... Okay, OpenGL is old. The first version came out in the early 1990s. It was a time there were no GPUs yet, so you could also use... Only use the CPU for rendering. And this standard is actually still the same today. However, there are many extensions and new versions, and the current version 4.5 has many new things. And if you want to learn version 4.5 today, you have to program maybe, let me say, three to five hundred lines of code just to render one single triangle. You don't only have to program in Python, you have to learn shading languages, the OpenGL shading language. You have to understand the concepts there. You have to understand there. You have to learn many mathematics. You have to be good in vector math, in matrix multiplication, in projections, and so on. It's really very, very hard to get into. And it's not possible to learn that in half an hour, and that's a really big issue. And learning OpenGL today is, as I said, even harder than it was before. So the best way would be to start learning the old version and then propagate, but that's not really a good solution. So you need time. And I'm teaching computer graphics and I know the difficulties. Sometimes I also don't know where to start. Do you start with the OpenGL shading language or do you start with OpenGL basics? It's really a tough, so you don't need much time to invest if you want to create your own render engine. So the best way to go, in my opinion today, is get Unity or another engine and learn principles there. And then if you understand the basic principles of transformations of all these things, then you can try to create your own thing in OpenGL. That's my advice today. But it doesn't seem that the future is getting any simpler. We have a new API, the Vulkan API, and I don't know how many of you are following the developments there. The Vulkan API is designed to be the new standard by the Kronos group, the same group that developed OpenGL. And it's an even more low-level API which gives you a lot of power. And I suppose it's even more difficult to learn. And again, I think you worked with the Python bindings for it. I understand it's very complex. I didn't work with it. But again, we're going to need a good teaching tool just to grasp the complexities of it. It's a really big, nasty piece of code. Yeah, the Vulkan API is even harder than OpenGL 4.5 to learn. You need even maybe one to 200 lines more code to render one single triangle. But if you understand these principles, then it's easy. So to make two triangles, you need only 501 lines of code, for example. So it gets easier. But it's a low-level API, so you have to do all things yourself. You have to create your models, your projection systems, and so on. It's really very low. So to get started, I don't recommend using Vulkan API at the moment. Especially not using Python. We have to wait maybe next year or two years, and there's stable binding available. Are you saying there's an issue with the binding? Because I think that there's an issue with the drivers themselves, but the implementation of Vulkan. My issue is still too early at the moment. There is almost no documentation. And the drivers are not really very stable at the moment. We have to wait a little bit until the big graphics companies distribute new versions. And then we can start creating a good binding. There are, I think, two bindings available at the moment, but they are not very good maintained. Python bindings, they are not very well maintained. So someone has to step up and say, yes, I create a binding, and I will maintain this for the next five to ten years. Okay. So I think on our side, the kind of people who want to really do everything in Python, the answer is still OpenGL, no matter the complexity. And then to complete the whole application, you would need either Pygame, or myself I use PySDL2. SDL is a high-quality library that handles events and all related stuff. The wrapper is really straightforward, so you can use PySDL2 that gives you portability on all platforms. And because I've used Python, I would say that it's a little bit more low-level, but it's really good and I'd recommend it over Pygame. It's just a touch more complexity. But I would say that if you want to do this kind of an approach, that's the solution right now. Yes. I would recommend starting with 2D games, using Pygame, creating really simple games to understand the principles, how a game actually works. And then if you know the basic principles, go on and try OpenGL bindings with Python. Okay. So, you know, my takeaway, although everybody's optimistic, I think everybody's a little bit more optimistic on the plugin side of things. This seems to me that right now it's a more realistic approach to get Python into an existing engine and have really nice plugins that will give you access to the whole ecosystem. And I understand, Roberto, you've been doing work with AAA Studios that use your plugin, but not necessarily for gameplay events. So, could you...maybe somebody's using it? You'd know if they're using it. You don't have to mention names. Just...yes, maybe. As far as I know, none of the AAA Studios that is using the plugin is using it for the gameplay. They are not even using Blueprints in Unreal Engine. It's a visual scripting tool. They still prefer to use C++ because it is an industry that is fun to C++ by the backends. So, it's really hard to remove this kind of mindset. And they don't even see a reason to remove C++ from their gameplay logic because they have good programmers with it, and they have performance that are very important for them. For all of the other side of the development pipeline, they use the plugin and they use it heavily, even for customizing the editor completely. If you are able to see the desktop of a person working with Unreal Engine in a AAA studio, generally you do not recognize that it is Unreal Engine. They customize it totally. We are talking about pipeline with hundreds of people, so I find it pretty normal to customize your main software to the team needs. But as far as I know, there is not a company using Python for the gameplay. Unless we speak about the server side, if you have a game that with its main lodging on the server, there are a lot of companies using Python with other engines, with other technologies and so on. I think I actually know an example. Eve Online is a famous game that uses Stackless Python for a lot of its game logic. But that's one. And from time to time I Google and it's hard to come up with a lot of commercial games that use Python for gameplay. There was a civilization for it, used it for some scripting and events and modding. And here and there it will pop up, but it's not a big thing yet necessarily. So I think this sort of covers everything we sort of chatted before. We have time for a Q&A. Maybe some questions from the audience. Yeah, thank you. So right at the end you mentioned Stackless Python. Would that be something you've tried or would recommend to... Let's say I want to build a game in Python, should I use Stackless? Or can I use Stackless? I think Eve Online uses Stackless Python not for the game but for the server. Yeah, yeah, yeah. Even Stackless for the client part. Honestly, I don't know how they can benefit from StackSuite switching technologies, something that works like a classic engine. So honestly, I don't know what to answer. I don't know if someone knows how they're using it. I'm not that into details of Stackless. I suppose the issue would be performance. I really don't see a huge issue with... I'm making a 3D game. It's a turn-based game, not a full action game, so it has slightly slower real-time requirements. I don't see huge slowdowns from Python. It doesn't have a huge performance effect. It's doable. Basically, I'm not sure about Stackless. No specific info. But that helps. There was another question. Okay, thank you for the discussion. It's very interesting. But from what you are speaking about, it seems that graphics is like the 99% of the problem in here, or like the games mostly consist of graphics. What about the other parts of the game? Or even sound music? Are there no problems in there? Is it just... The graphic is such a big problem that we start with that, and until we have solved this, we don't even try anything else. Yeah, we are talking 99% about graphics because that's the most compute-intense part of games. Music... It's no problem. Music needs a little bit CPU. No, I mean, in the whole system, you have the GPU takes most parts. And if you look at the compute power that we see today, NVIDIA GTX 1080 has this power of... If you look maybe 20 years ago, you had to spend billions of the compute power you have in a GTX 1080. So graphics is the compute-intense part. And compared to that, music and sound doesn't really take too much away. Let me hear his opinion. Yeah, because the audio engine has just been remade into Godot, so I saw some talk about it. And the really big problem with audio engine is the lag. Audio engine must really have no lag, otherwise you just go out of the game. So writing audio engine in Python, I would say every time you have a little garbage collecting, things like that, even maybe it won't be visible if you do a frame rendering because most of the time, they spend into the graphical card. But for audio engine, you will really see it, feel it really fast. Well, yes, graphics is the main part wasting your CPU power. Regarding the pure game logic, artificial intelligence, in games we still don't use the real, from the academic point of view, artificial intelligence. We still use cheap tricks like finite state machine, behavior tree, something that works perfectly in Python. They are not heavy in resources. So from my point of view, a real engine Python plugin works because on real engine, take care of the graphics part. So in the demo, I showed the Python works flawlessly because the rendering part was done with the engine. But building the AI part or the pure game logic part, it could be absolutely doable. And the best majority of the AAA games, like the first installment of Uncharted, it's game play logic, the best majority of it has been done in Lisp, in a Lisp dialect. Left for dead is another one using squirrel, I think it's another high level scripting language and so on. It is very common for game designers to use a scripting language. Even Timbal with Park, you know it? But it's the same author of... okay, I don't remember. It works for CN, SDL, for the rendering part and then used again squirrel, I think, for the scripting part. For a game designer, it is way more proficient to use an L level language. So yes, it is the rendering part that most heavy want to invest on. So, a different take on that. I saw a presentation by one of the game developers and they were working on this game, which has real war happening in real time. And if you have 1,000 or 2,000 or something objects, and they need to act in every single frame, which is 60 frames a second, that means that you have about 20 instructions that you can execute per thinker. And that's only possible if you use C++. So in these sorts of things, you really need to have performance. But coming on to that, is there any experience on using actually Scython? So you could start by doing your logic in Python and then you find the hotspots and then you rewrite them in Scython. I did try, personally, so I can give you that answer. It might be a matter of personal preference, so I'm not terribly into Scython. I think it's probably a personal preference, it's another syntax you'd learn and already know Python and C, so as long as I'm doing it, might as well just jump into C. I'm actually holding high hopes for using PyPy in this context. It seems to me the way to go, we didn't discuss the gil here, but there seems to be some potential there for eliminating the gil as well. I think if you can live with Scython as a separate Python-like language, it could be the solution, but there could be other, if you need performance, other ways to do it. You could separate your small functionality into some small library, you could paralyze it in some way, or you could use JIT. If you really, really need performance, just basic Python, perhaps will not do. I hope this helps. Hello. Have you ever considered code transpilation from Python to another language for the game logic part in order to embed the result into an engine or something? You asked why using Python for game development, what if you like so much the syntax of Python that you could afford to not using advanced features of Python, but just some basics and then compile it to another language? Yeah, why I like Python for game? Answer this part first. If, for example, a new developer comes into the team, it's much easier if we program Python. If a new developer comes with little experience in C++, you can really mess it up and kill the whole application. I experienced that two times, so that really someone messes up, creates memory leaks, and after no one really knows where these memory leaks were created, et cetera. So using Python solves that a little bit, not fully, but it's much better. And then the part about transpilation, I'm not a big fan of transpilation. The problem is at some point you will have to debug something, and then debugging code that was transpiled is really hard. So that's not, I personally would not do that. If we see that project is not suitable for use of Python, I would recommend using another language in the first place. That's much better than transpiling in my opinion. But then you have to know that if you have a new developer who doesn't really speak C++, you have a risk. Thank you. Okay, it looks like we don't have any more questions. I'd like to thank my co-panelists. I'd like to thank the audience. I hope we have this talk again. It's not the end of Python and games. Maybe it's just the beginning. And thank you all, and see you next time. Thank you.
And the idea is to have a discussion about making game logic and not writing a game engine. for using Python as the language for your browser so you can really write your scripts with in the last months of the development of your script your asset pipeline. That's very useful. game development pipeline is the amount of into Unreal Engine. We are seeing making that work, because both projects are with scripting. Even the Godot Engine had new integration with other languages. Pandas 3D loses send our data, our buffers, and the textures, and Pygame, creating really simple games to and have really nice plugins that will give you your main software to the team needs. But as far commercial games that use Python for gameplay. you look at the compute power that we see today,