 My name is Tomislav Ozelec 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 Godo Engine. It's a Python wrapper for the Godo Engine. And we have, I'll get 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 ten. Making these games in Python, mission impossible, one to ten and then why and then we'll try to see. Hi, everyone. So from my point of view, the most important thing is making some kind of difference between indie game and a AAA game. They are pretty different from the result to the money spent on them. In my opinion, making indie games with Python, with only Python is absolutely possible. On the other side, making a AAA game only with Python could be a really, really hard challenge. Oh, it's really hard even to define what an indie team is. Nowadays we have indie teams 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 persons 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're 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're thinking making a game means making game logic and not writing a game engine, I think it's entirely doable into Python. And that's why I want to prove by putting Python into Goddum. And I should give a mark. So I would say eight out of ten. So I would give it a ten if you give me ten million euro. Of course, it depends what you want to do. If you want to create a triple A game, no, unfortunately not. If you want to make a mobile game, yeah, I would give a one, two, three. Unfortunately. But for an indie game, I think there is some chance. If you say I want to make a game for macOS, for Linux, Linux user 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 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 seven. Now the question is why would I use Python to create that 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 one to ten. 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 sort of 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 requires 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, the Eurovide on in Bilbao, I gave a talk about OpenGL all 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 VRWords, the simulation of clothes, hair, and so on, that are really performance-intensive. 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 user team in GTA. So yes, it could be something we can do. I don't remember what was the question in the first place. Oh yeah, I think, yeah, like you said, there is really two like schools. There is the one who wants to make, to use Python as really the first language and write everything inside Python. And the other one who kind of plug from an existing engine has just one 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 scripts system. And so you can really write your scripts with multiple language. 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 the 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. So 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, et cetera, then I will fail with that approach. And that's something I want to ask you to what would you 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, it almost comes for free. At the time that 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 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 can say, 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. I know. 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 have things to say about that. So I think 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 a 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. Sure, you can script your asset pipeline. That's very useful. You're 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. So, 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 a lot of data. 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 data sets, 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 ran 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, 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 that libraries and use them into something visually really powerful. This morning, we had seen a talk about... A keynote about data 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 sides, 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 an engine, Unreal Engine, it's possible to use this kind of libraries. I don't know if you want to... I think it's something really interesting because it means that you are bringing game engine to people using Python, which means that you are bringing it to scientists, people that are used to, in the past, use R and then they go to Python now. And so, yeah, it means really new possibility for them, I think. I'm personally working in my day job with people from the scientific background and always, like, they want a new way 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 sort of represent the faction here that sort of 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. And so, you represent this faction and sort of I get it that it's wonderful. I sort of do the other thing, but I have to, like, okay, you guys defend your side, but it's wonderful. But in both of your talks, I noticed that there are, like, considerable technical difficulties in making that work because both projects are recently less than a year old. And, you know, you hear the same complaints. They're like two garbage collectors, I think, in both projects. Then there's the issue of, you know, performance. Do we want to go with JIT or the Wi-Fi? So a lot of issues sort of come up with that. And so maybe just shed some light on that. Is this, are we sort of condemned to that? Are we like 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 have the first people trying to do something like that. I suppose now that a real engine by the plug-in 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 more 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 that we have to do. I think the trouble was, Python was added to an existing engine. But I mean, it would be really simple thing to just create an engine in C++ when syncing. That's a high level scripting will be due in Python from the beginning, like it's doing a Pandas 3D. I didn't try it personally, but I think if somebody has experience 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 other 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 bunch of modifications to the engine to allow integration with scripting. And even the Godot engine added 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? 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. But 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 the Unity? It would be really interesting to know this. By the way, Unity up to the fourth version came with a Python-like language Boo. I don't know if you ever okay. Then they removed the support because no one used it. They 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 naked openGL functions. And we send our data, our buffers and 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 in my experience, I taught myself openGL by developing in Python. So maybe talk a little bit about that. OpenGL is really hard to learn especially today. OpenGL is old. The first version came out in the early 1990s. It was a time there were no GPUs yet. 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 500 lines of code just to render one single triangle. You don't only have to program in Python. You have to learn shading languages. 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 and matrix multiplication and 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 information. And I suppose it's even more difficult to learn. And again, I'm thinking, 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 the Python OpenGL 4.5 to learn. You need even maybe 100 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 all the 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 in two years when 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 drivers are not 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're 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 5 to 10 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 PySDL too. PySDL is a high quality library that handles events and all related stuff. The wrapper is really straightforward so you can use PySDL too 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. 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 is 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 the C++ because it is an industry that is fond to C++ by Beckons, so it's really hard to remove this kind of mindset and they do not 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 really a company using Python for the gameplay. Unless we speak about the server side, if you have a game that with its mail lodging on the server 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 a stackless Python for a lot of its game logic. But that is one and I have been from time to time I Google and it is hard to come up with a lot of commercial games that use Python for gameplay. There was a lot of stuff that was used before, used it for some scripting and events and modding. And here and there it will pop up but it is 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. At the end you mentioned a stackless Python. Would that be something you have 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. Even stackless for the client part. Honestly I do not know how they are 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 it 3D game. It's a turn based game, not a fall game. I don't know what to answer. I don't know if someone knows about it. It's a turn based game, not a fall action game. 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. I'm not sure about stackless. No specific info. But that helps. There is another question. From what you are speaking about, it seems that graphics is like the 99% of the problem in here. The games mostly consist of graphics. What about other parts of the game? Or even, I don't know sound, music, are there no problems in there? Or is it just the graphic is such a big problem that we start with that? Until we have solved this, we don't even try anything else. We are talking 99% about graphics because that's the most compute-intense part of games. Music needs a little bit CPU. In the whole system, 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 for 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. Do you want to hear his opinion? The audio engine just has been remade into Godot so I saw some talk about it. The really big problem with audio engine is the lag. Audio engine must really have no lag otherwise you go out of the game. Writing audio engine in Python, I would say every time you have a little garbage it won't be visible if you do frame rendering because most of the time they spend into the graphical code 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, we still use 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 I would say it's a good example of the graphics part. So in the demo I showed yes, the Python works flowless 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 a best majority of it's game play logic, the best majority of it's game play logic 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 designer to use a scripting language. Even Timbal with park, you know it? By the same author of them. Okay, you don't remember? So it works for C and SDL for the rendering part and they use 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 the most heavy one to invest on. So a different take on that. I saw a presentation by one of game developer and they were working on this game and they were working on this game. So the game 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 but coming under 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. I don't it might be a matter of personal preference so I'm not terribly into Scython probably a personal preference it's like 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 so I think if you can live with Scython as a sort of separate Python-like language 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 so if you really, really need performance you could use the basic Python, perhaps will not do I hope this helps 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 I mean you asked why using Python for game development what if you like so much the syntax of Python you could afford to not using advanced features of Python with just some basics and then 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++ he can really mess it up with 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 etc 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 transpile this 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 you have a risk thank you looks like we don't have any more questions I'd like to thank my co-panelists I'd like to thank the audience hope we have this talk again it's not the end of Python and games maybe it's just the beginning thank you all see you next time