Making Games with Python: Mission Impossible?
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 160 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/33759 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Game theoryIntelComa BerenicesSoftwareGame theoryMultiplication signQuicksortArtistic renderingWrapper (data mining)Mereology1 (number)Range (statistics)Plug-in (computing)AuthorizationResultantVideo gameDifferent (Kate Ryan album)WordPoint (geometry)Similarity (geometry)Statement (computer science)LogicBitPropositional formulaGamma functionLine (geometry)Integrated development environmentLevel (video gaming)Lattice (order)View (database)Execution unitHierarchyWindowForm (programming)Data storage deviceMeeting/Interview
06:58
Game theoryCodeInformationData storage deviceSoftwarePoint (geometry)Formal languageProjective planeComputer simulationVideo gameComputer hardwareMereologyTask (computing)MultiplicationScripting languageBefehlsprozessorPhysical systemSoftware developerProcess (computing)QuicksortWeb browserMobile appKeyboard shortcutGoodness of fitModule (mathematics)PhysicalismComputing platformLibrary (computing)Limit (category theory)Wrapper (data mining)outputHigh-level programming languageComputer graphics (computer science)Multiplication signNeuroinformatikStandard deviationWritingSimulationBit rateCycle (graph theory)Class diagramUniverse (mathematics)Flow separationTouchscreenIRIS-TSystem callTheoryBuildingLattice (order)DataflowShared memoryProduct (business)DivisorPopulation densityOpen setLevel (video gaming)ResultantHypermediaCommutatorMeeting/Interview
14:57
Expert systemQuicksortCartesian coordinate systemSoftware testingMereologyBitLine (geometry)Library (computing)CASE <Informatik>Scaling (geometry)Scripting languageGame theoryElectronic mailing listTheory of relativityFormal languageArithmetic meanVirtual machineSoftware developerGoodness of fitProcess (computing)Execution unitWordVisualization (computer graphics)Physical systemVideo gameStandard deviationFood energyLevel (video gaming)Spontaneous symmetry breakingComputer programmingView (database)Lattice (order)Point (geometry)Electronic data processingMusical ensembleoutputSpeicherbereinigungSupercomputerProjective planeMathematicsWeb browserMultiplication signArtistic rendering1 (number)Ultimatum gameRight angleCompilerData managementAreaSingle-precision floating-point formatTask (computing)Figurate numberExtension (kinesiology)Demo (music)Open setJust-in-Time-CompilerArtificial neural networkFreewareCodeNetwork topologyServer (computing)Different (Kate Ryan album)AbstractionGeometrySet (mathematics)Meeting/Interview
22:57
Multiplication signRevision controlTransformation (genetics)BitMatrix (mathematics)Lattice (order)Formal languageOpen setPhase transitionProjective planeChainMereologyCASE <Informatik>Latent heatScripting languageAttribute grammarKeyboard shortcutQuicksortSource codePower (physics)Complex (psychology)Loop (music)Goodness of fitMoment (mathematics)AreaBuffer solutionStaff (military)Stress (mechanics)Group actionSoftware developerComputer graphics (computer science)outputStandard deviation1 (number)SpeicherbereinigungINTEGRALSpeech synthesisFunctional (mathematics)Texture mappingVector spaceTrailCodeMathematicsGame theoryLine (geometry)Extension (kinesiology)Level (video gaming)Wrapper (data mining)InformationGraphics processing unitArtistic renderingReal numberBefehlsprozessorInteractive televisionComputer architectureTriangleComputer programmingVolumenvisualisierungMeeting/Interview
30:56
Programmer (hardware)Online helpLogicSoftware maintenanceFront and back endsBitKeyboard shortcutPlug-in (computing)MereologyMoment (mathematics)Client (computing)Device driverImplementationEvent horizonServer (computing)Complete metric spaceText editorGame theorySoftware developerComplex (psychology)Civil engineeringMultiplication signCodeLine (geometry)Video gameSoftwarePortable communications deviceLibrary (computing)Wrapper (data mining)Right angleTouch typingProjective planeScripting languageTriangleDatabase normalizationPoint (geometry)Sound effectCodeComputing platformLevel (video gaming)CommutatorQuicksortMedianRevision controlPhysical systemStudent's t-testIntegrated development environmentBlogCovering spaceEndliche ModelltheorieSparse matrixCartesian coordinate systemReading (process)DialectLecture/ConferenceMeeting/Interview
38:55
Game theoryLibrary (computing)MereologyFunctional (mathematics)Graph (mathematics)Flow separationFormal languageQuicksortVector potentialWebsiteSoftware developerBitPlanningMusical ensembleEndliche ModelltheorieProjective planeTransportation theory (mathematics)Goodness of fitPower (physics)HypermediaExtension (kinesiology)Physical systemBefehlsprozessorForm (programming)Order (biology)TouchscreenLevel (video gaming)DialectLogicMultiplication signMedical imagingFinite-state machineBus (computing)Semiconductor memoryCartesian coordinate systemNeuroinformatikFood energyComputer programmingVotingPoint (geometry)Transformation (genetics)Event horizonSource codeArtistic renderingLeakPresentation of a groupInfinityView (database)Frame problemObject (grammar)Particle systemDataflowDenial-of-service attackContext awarenessHydraulic jumpResultantArtificial neural networkPlug-in (computing)Demo (music)Different (Kate Ryan album)Just-in-Time-CompilerHigh-level programming languageInstallation artCodeComputer virusOnline helpAuthorizationHand fanLecture/ConferenceMeeting/Interview
Transcript: English(auto-generated)
00:04
My name is Thomas Lavuzelat 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
00:21
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
00:47
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
01:01
Godo engine. It's a Python wrapper for the Godo engine. And we have, I will 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
01:22
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
01:47
impossible. One to ten and then why and we'll try to see. Hi everyone. So from my point of view, the most important thing is making some kind of difference
02:04
between indie game and a 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
02:22
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
02:43
team with a lot of money. Four or five people with really thousand dollars invested in them. So for an indie team, I mean something less than ten person and with zero money. For me, an indie team is something that does
03:03
not have money. An indie team works only with passion. This is my own opinion. Me, 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
03:22
C somewhere. So the only question is what is the sweet spot between the parts you are doing in C and the parts 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 F online for example. So yeah, I would say if you
03:43
if you're thinking making a games mean 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 Godot. And I should give a mark so I would say eight out of ten. So I would give it a ten if you gave me ten million euro.
04:10
No, 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, I would give a one,
04:26
two, three, unfortunately. But for an indie game, I think there is some chance. If you say I want to make a game for Mac OS, for Linux, okay, Linux, so don't you pay for games. Okay, sometimes I do. And Windows, then, okay.
04:48
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
05:05
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?
05:23
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.
05:41
Okay, so that's a sort of 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
06:01
and all of that in Python for various reasons, which I hope we'll have time to cover that 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.
06:24
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 directly working with OpenGL.
06:42
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.
07:01
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.
07:21
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.
07:46
Last year at Euroviton in Bilbao, I gave a talk about OpenGL all in Python. Absolutely it is something that we can do.
08:00
But nowadays there are a lot of technologies, high-level technologies. I'm thinking about the NVIDIA technologies like VR Worlds, the simulation of cloth, hair and so on that are really performance intensive. So from this kind of tasks, we cannot expect a high-level language like Python, JavaScript.
08:24
Every high-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.
08:52
This is the only hope I think we can have. Better hardware for using software that is not so fast.
09:02
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 a future in which all these little systems sort of exist as well-defined Python modules?
09:28
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 ballot physics library.
09:46
I don't know if you know it, it's a pretty famous physics library used even in GTA. So yes, it could be something we can do.
10:02
I don't remember what was the question in the first place. Oh yeah, I think like you said there is really two schools.
10:23
There is the one who wants to use Python as really the first language and write everything inside Python. And the other one who kind of plugs from an existing engine and just wants 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.
10:49
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
11:01
and it won't be in the final project 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 try new idea and so on. And you end up in the end rewriting everything in C++ in the last months of the development of your game.
11:27
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.
11:43
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
12:03
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
12:20
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.
12:42
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.
13:07
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.
13:20
I understand that at this point it's not a problem, it's allowed. 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.
13:45
So yeah it could be a risk. 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.
14:02
Obviously we're here at a Python conference, that's what we're interested in. 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?
14:25
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.
14:44
And so I think there are other things in a video game company that Python gets used for. And Roberto you had 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.
15:02
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 we use.
15:22
Especially from the artist's point of view where they're used to Maya, 3DS Max, Blender and so on. Basically I still have to map animators that do not script their pipeline work.
15:43
Well 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.
16:01
But it is very important for me that I can use a higher level language which I do not need to compile with a lot. Having strange errors, having to pay attention to any single line I write and so on.
16:20
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.
16:42
Okay so that's one part of it that 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.
17:12
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.
17:26
So as part of a broader question which is 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.
17:43
So you can use that in your game. It opens up a lot of possibilities 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.
18:02
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.
18:21
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 geodata abstraction library for example. Where you can load the different data sets etc.
18:42
It's really a cool way. For the data processing part in general I recommend using Python for the visualization part. We had to use WebGL because it runs the web browser.
19:03
Very simple for that project. I also saw an interesting demo on your own talk. Which again because you were importing Python into Unreal Engine.
19:23
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.
19:45
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.
20:01
Libraries that generally are not available in other languages. Or became really painful to use using lower level languages. Embedding a Python virtual machine into a professional game engine. Allowed me and the users to import that libraries.
20:20
And use them into something visually really powerful. This morning we have seen a talk about data. A keynote about data visualization. I was already thinking about how much better could be that data into Unreal Engine.
20:41
We are seeing straight line as 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. Something way more big in scale that we can do now.
21:02
So the real advantage now of using Python into Unreal Engine. Unreal Engine is good 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.
21:26
Which means you are bringing it to scientists. People used to in the past use R and then go to Python now. And so it means really new possibility for them I think. I am personally working in my day job with people from the scientific background.
21:44
And always I want new way to show the data. And for the month I 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.
22:01
That takes an existing very capable game engine. In your case it's a free engine Goto. 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 so 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.
22:22
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.
22:41
There are like two garbage collectors I think in both projects. Then there is the issue of performance. Do we want to go with JIT or the PyPy. A lot of issues sort of come up with that. Maybe just shed some light on that. Is this, are we sort of condemned to that?
23:01
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 are the first people trying to do something like that.
23:21
I suppose now that a real engine Python plugin 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 more scripting languages that will come out.
23:45
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.
24:02
I think the trouble was that Python was added to an existing engine. But I mean it would be a really simple thing to just create an engine in C++. When thinking that high level scripting will be due in Python from the beginning. Like it's doing Panda3D.
24:21
I didn't try it personally. But I think if somebody has experience with it that would be really interesting. Panda3D. Ok. Panda3D is another engine. Used a lot by Disney in the past. Now Disney has moved to another engine.
24:43
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.
25:07
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.
25:26
Panda3D lose a bit of traction nowadays that we have Unity, Unreal, Godot that are way more powerful. But as far as I know Panda is one of the first big engine with a strong Python support.
25:48
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.
26:07
But he's not in the room unfortunately. But if you find some PyPy guys you can ask him directly. It's just really a start for the moment but maybe it will go somewhere eventually.
26:23
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 a Python like language BOO.
26:46
I don't know if you ever... Okay, then they removed the support because no one uses it and don't want to use some subversion of Python.
27:03
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 our textures and have it all rendered. You know, the last of the romantics.
27:23
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.
27:45
Maybe because you also teach. And in my experience I taught myself OpenGL by developing in Python. So, you know, maybe talk a little bit about that.
28:00
Yeah, 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 only use the CPU for rendering. And this standard is actually still the same today.
28:21
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.
28:40
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.
29:02
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.
29:22
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 tough.
29:41
So you 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,
30:01
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.
30:21
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.
30:40
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.
31:03
Yeah, the Vulkan API is even harder than OpenGL 4.5 to learn. You need even maybe 1 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.
31:25
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,
31:43
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, with the implementation of Vulkan. My issue is still too early at the moment.
32:02
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,
32:22
but they are not very good maintained. Python bindings 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,
32:41
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.
33:02
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 of complexity.
33:22
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,
33:43
and then if you know the basic principles, go on and try OpenGL bindings with Python. Okay. So my takeaway, although everybody's optimistic, I think everybody's a little bit more optimistic
34:01
on the plugin side of things. It 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.
34:20
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 that.
34:40
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. This is a visual scripting tool. They still prefer to use C++ because it is an industry
35:02
that is fond to C++ by backends. So it's really hard to promote 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
35:24
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
35:46
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
36:03
to the team needs. But as far as I know, there is no AAA company using Python for the gameplay. Unless we speak about the server side, if you have a game with its main logic on the server, there are a lot of companies using Python,
36:21
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.
36:40
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 Civilization 4 that 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.
37:03
So I think this covers everything we chatted before. We have time for a Q&A. Maybe some questions from the audience.
37:20
Thank you. Right at the end you mentioned stackless Python. Would that be something you've tried or would recommend? Let's say I want to build a game in Python, should I use stackless or can I use stackless?
37:43
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 do not know how they can benefit from stack-switching technologies,
38:01
something that works like a classic engine. 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.
38:21
I suppose the issue would be performance. I really don't see a huge issue. I'm making it 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, huge slowdowns from Python.
38:40
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's another question. Okay, thank you. The discussion is very interesting, but from what you are speaking about,
39:02
it seems that graphics is like 99% of the problem in here or like the games mostly consist of graphics. What about the other parts of the game or even, I don't know, sound, music?
39:21
Are there no problems in there, or 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.
39:41
Music, it's not a problem. 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,
40:06
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,
40:21
and let me hear his opinion. Yeah, because the audio engine just has 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.
40:42
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 you spend into the graphical card, but for audio engine you will really see it, feel it, really fast.
41:08
Yes, graphics is the main part wasting your CPU power. Regarding the pure game logic, artificial intelligence,
41:23
in games we still do not 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.
41:43
So from my point of view, the Unreal Engine Python plugin works because Unreal Engine takes care of the graphics part. So in the demo I showed yesterday, Python works flawlessly because the rendering part was done with the engine, but building the AI part,
42:05
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, you know Uncharted? Its gameplay logic, the best majority of its gameplay logic
42:20
has been done in LISP, in a LISP dialect. Left 4 Dead is another one using squirrel, I think it's another high level language, scripting language and so on. It is very common for game designers to use a scripting language, even Timbal with Park, you know it? By the same author of...
42:43
Okay, I don't remember. It works for C and SDL for the rendering part and then uses again squirrel, I think, for the scripting part. For a game designer, it is way more proficient to use an high level language.
43:01
So yes, it is the rendering part the most heavy one to invest on. So different take on that. I saw a presentation by one of the game developer and they were working on this game, which has like real war happening in real time.
43:24
And if you have 1000 or 2000 or something objects, and they need to act in every single frame, which is 60 frames a second, and that means that you have about 20 instructions that you can execute per thinker,
43:41
and that's only possible if you use C++. So in these sorts of things, you really need to have performance. But coming onto that, is there any experience on using actually Cython? So you could start by doing your logic in Python and then you find the hotspots and then you rewrite them in Cython.
44:03
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 Cython. I think it's probably a personal preference.
44:20
It's sort of like another syntax you'd learn. I 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,
44:41
we didn't discuss the GIL here, but there seems to be some potential there for eliminating the GIL as well. So I think Cython is, if you can live with Cython 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.
45:00
You could separate your small functionality into some small library. You could parallelize it in some way or you could, yeah, or you could use JIT. So if you really, really need performance, just basic Python, yeah, perhaps will not do. I hope this helps.
45:26
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? I mean, you asked why using Python
45:43
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 transpile it to another language?
46:02
Yeah. Why I like Python for game program? 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 and kill the whole application.
46:21
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.
46:41
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 the project is not suitable for use of Python,
47:02
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.
47:21
Thank you. Okay, 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.
47:42
Thank you all, and see you next time.