As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm looking to make a 2d side scrolling game in Python, however I'm not sure what library to use. I know of PyGame (Hasn't been updated in 3 years), Pyglet, and PyOpenGL. My problem is I can't find any actually shipped games that were made with Python, let alone these libraries - so I don't know how well they perform in real world situations, or even if any of them are suitable for use in an actual game and not a competition.
Can anyone please shed some light on these libraries? Is PyGame still used effectively? Is Pyglet worth while? Have either of them been used to make a game? Are there any other libraries I'm forgetting?
Honestly I'm not even sure I want to use Python, it seems too slow, unproven (For games written solely in Python), etc.... I have not found any game that was made primarily in Python, for sure, that has been sold. If I don't end up going with Python, what would a second/better choice be? Java? LUA?
Pygame is just a wrapper for SDL, so technically a lot of games have been made using it, most of the work is done C-side anyways. It's a little slow, though if you are doing a 2D game, it should be sufficient. Frets-on-Fire was written in pure python with PyGame, and FoFiX was written in python with C extensions, and those games are both pretty great, altough on slower computers FoFiX can have trouble running 4 player.
Pyglet is also pretty nice, though I've only used it for emulator development, drawing single layers, so I don't know how well it actually works for game development. I've found that it's much easier to use direct OpenGL with Pyglet than it is with SDL/PyGame, so if you are doing a 3D game, it's probably better than using SDL. Also, since it's written in python, it's very easy to extend classes to change how a function is handled. For instance, I was trying to load data into an openGL texture through the pyglet Texture class, but the class couldn't load the data in a format I wanted, so I extended that class and changed the function that got the texture type (comes from a string) to include the texture I wanted, quick and painless.
One library I don't see mentioned enough is SFML. The 2.0 API (currently in beta) is pretty stellar and simple to use, and, if I remember correctly, runs a little faster than SDL. It is also more "object oriented" than SDL, which is really nice if you are working in an OO language like Python. It has some nice Python bindings written by Bastien Leonard in Cython that are pretty easy to use (or you can use the old C bindings if you don't want to use the most up to date version). I used this a while back and it was quite an enjoyable experience.
The reason why there aren't a lot of shipped games using Python is pretty simple: You can't close Python source. Even if you "compile" python into an executable using Py2Exe or something, it really just packs up the interpreter and python source into an exe file, and the source can be got just by opening up the exe in a hex editor.
While I'm a supporter of the "write it in Python, write time critical parts in C", if you feel python is going to be too slow, I would probably suggest C or, preferably, C++ as the way to go, simply because you don't get that much of a usability advantage for writing in Java, and the C languages can be quite a bit faster running than Java, and Lua will just take away some of the usability of Python without giving you any noticeable performance enhancement. SFML and SDL can both be used straight from C(++).
Advice if you do decide to use python: Use it as it is supposed to be used, as a scripting language. Do not try to bit twiddle or load images in pure python, either use the interfaces available in the library you choose (they all have very good interfaces for those kinds of things) or write an extension module to do that for you. Use python for logic control and fetching data from your libraries. If you follow that simple rule, you really shouldn't run into any performance issues.
In my experience, the things that are really going to kill you aren't generally related to graphics at all. Sure, it's a challenge to get all your frame rendering done in less than 16 ms without techniques like dirty-rectangle updating, but that's not going to be the big thing you'll lose sleep over. The biggest performance considerations are going to come from much more elementary things - collision detection, spatial searching, and pathfinding are three of the big ones - that can easily send your logic frame rate into the floor if done inefficiently over even a few hundred objects. For problems like these, pure Python may not be the best choice, but it's not hard to offload these to C/C++ while retaining Python for higher-level logic. This is essentially what games like Civilization 4 and EVE Online (client and server!) do - offload performance-critical code to C++ while retaining the flexibility and simplicity of Python for 'everyday' tasks.
pygame is actively developed (they haven't had a stable release in a while, but the Mercurial repository is quite lively) and fairly popular. It also uses the well-regarded (C-based!) SDL library under the hood. pyglet is also actively developed and uses OpenGL for all of its rendering, making moving to 3D development easier if you're planning to go in that direction (since you'll already have most of the basics).
If you decide to go the not-Python route, you can use SDL directly with C/C++, along with addon libraries like SDL_gfx (for primitives), SDL_ttf (for text), and SDL_net (for basic networking). Another excellent and widely used alternative for C/C++ is Allegro. I've used both, and I will claim that it's largely a matter of taste which one you go with.
Pygame should suffice for what you want to do. Pygame is stable and if you look around the websites you will find games which have been coded in pygame. What type of game are you looking to implement?
Related
I am a great python fan. Recently I got an idea to write RTS engine and/or maybe a simple RTS game based upon this engine. There are a couple of things I need to think about and maybe you can give me some advice on these:
Performance. Most games are written in C++. Isn't python too slow for game engine? I am aiming only at 2D, but still it may be too demnading.
Graphics. Are there any good graphics libraries for python? SDL/OpenGL bindings or maybe something more suitable for python?
Game engines. Do you know of any existing RTS engine written in python?
Any tools/libraries for python that maybe helpful in developing RTS
Thanks in advance!
Performance may be an issue with heavy graphics/math processing. If so, see Panda3D, NumPy, Cython, and PyPy.
Use Pyglet, PyOpenGL with Pyglet, Panda3D (although you are writing in 2D, you can still use a 3D engine), or perhaps some other library.
There don't seem to be existing RTS libraries, but there are definitely pre-existing generalized engines.
Try searching for RTS-related libraries in general: you'll need AI, pathfinding, networking, and so on. Therefore, you may be interested in Twisted, for instance, since it helps with networking.
I can answer your first two.
Python isn't too slow for games. That all games must be written in C++ is a myth. Sure C++ (or C) might give you the best performance, but it doesn't mean you're unable to write a game in another language.
Try PyGame: SDL bindings for Python.
How practical would it be to use Cython as the primary programming language for a game?
I am a experienced Python programmer and I absolutely love it, but I'm admittedly a novice when it comes to game programming specifically. I know that typically Python is considered too slow to do any serious game programming, which is why Cython is interesting to me. With Cython I can use a Python-like language with the speed of C.
I understand that I'll probably need to learn a bit of C/C++ anyway, but it seems like Cython would speed up development time quite a bit in comparison.
So, is it practical? And would I still be able to use C/C++ libraries like OpenGL, OpenAL, and Bullet Physics?
If you're working with a combination like that and your goal is to write a 3D game, you'd probably get better mileage out of a ready-made 3D engine with mature physics and audio bindings and a Python API like OGRE 3D or Panda3D. Even if you don't, this post about using Cython with Panda3D may be helpful.
I'm not sure about now, but back in 2007, the trade-off between the two was basically that:
Panda3D was better-documented and designed from the ground-up to be a C++ accelerated Python engine (apparently they made some API design decisions that don't occur to C++ engine projects) and, predictably, had a more mature Python API.
PyOgre was built on top of a much more advanced engine and had a larger and more vibrant community.
...however it's quite possible that may have changed, given that, passage of time aside, in 2007, Panda3D was still under a GPL-incompatible license and that drove off a lot of people. (Myself included)
I'm the developer for the Ignifuga Game Engine, it's 2D oriented and Python/Cython/SDL based. What I generally do is develop the code in Python, and then profile the engine to see if there are some obvious bottlenecks (the main loop, the rendering code are good candidates), and convert those modules to Cython. I then run all the code (Python and Cython based) through Cython, and compile it statically against SDL.
Another of Cython's big "pluses" is that binding to SDL, or any C based library, is almost trivial.
Regarding threads, the engine is currently single threaded with cooperative multitasking via Greenlets, though this comes from a design decision to mitigate potential multi threaded pitfalls that unexperienced developers might fall into, rather than a limitation on Cython's part.
at this date (12th of April 2011) unixmab83 is wrong.
Cython doesn't forbid the use of threads, you just needs to use the no_gil special statements.
Beside the bindins of c++ is now functional in cython.
We do use it for something which is close to gamedev. So while I cannot be final on this, cython is a valid candidate.
I've found that a lot of the time, especially for larger libraries, you wind up spending a tremendous amount of time just configuring the Cython project to build, knowing which structures to import, bridging the C code into Python in either direction etc. While Cython is a nice stopgap (and significantly more pleasant than pure C/C++ development), the amount of C++ you'd have to learn to effectively use it basically means you're going to have to bite the bullet and learn C++ anyway.
How about PyGame?
I know Cython and you do not have to know C/C++.
You will use static typing but very easy.
The hardest part is to get the compiling working, I think on Windows this is done over visual studio thing.
There is something like a standard library including math for example. The speed gain is not too big but this depends on your scope.
ctypes was much faster (pure C) but the connection to Python was very slow so that i decided to look for Cython which can still be dynamic.
For speed gain in a game Cython will be the right choice but i would name this performance also limited.
Threads!!! A good modern game must use threads. Cython practically forbids their use, holding to GIL (global interpreter lock) the entire time, making your code run in sequence.
If you are not writing a huge game, than Python/Cython is okay. But Cython is no good as a modern language without good thread support.
I want to start learning OpenGL but I don't really want to have to learn another language to do it. I already am pretty proficient in python and enjoy the language. I just want to know how close it is to the regular api? Will I be able to pretty easily follow tutorials and books without too much trouble?
I know C++ gives better performance, but for just learning can I go wrong with PyOpenGL?
With the caveat that I have done very little OpenGL programming myself, I believe that for the purposes of learning, PyOpenGL is a good choice. The main reason is that PyOpenGL, like most other OpenGL wrappers, is just that: a thin wrapper around the OpenGL API.
One large benefit of PyOpenGL is that while in C you have to worry about calling the proper glVertex3{dfiX} command, Python allows you to just write glVertex3(x,y,z) without worrying about telling Python what type of argument you passed in. That might not sound like a big deal, but it's often much simpler to use Python's duck-typing instead of being overly concerned with static typing.
The OpenGL methods are almost completely all wrapped into Python methods, so while you'll be writing in Python, the algorithms and method calls you'll use are identical to writing OpenGL in any other language. But since you're writing in Python, you'll have many fewer opportunities to make "silly" mistakes with proper pointer usage, memory management, etc. that would just eat up your time if you were to study the API in C or C++, for instance.
PyOpenGL
I don't think it is a good choice. In my opinon in C/C++ it is easier to play around around with your OpenGL code - start with simple app, then add shader, then add some geometry functions, make a texture/geometry generator, build scene via CSG, etc. You know - to have fun, play around with code, experiment and learn something in process. I honestly just don't see myself doing this in python. Surely it is possible to do OpenGL programming in Python, but I see no reason to actually do it. Plus several OpenGL functions take memory pointers as arguments, and although there probably a class (or dozen of alternatives) for that case, I don't see a reason to use them when a traditional way of doing things is available in C/C++, especially when I think about amount of wrappers python code uses to pass vector or array of those into OpenGL function. It just looks like making things more complicated without a real reason to do that. Plus there is a noticeable performance drop, especially when you use "RAW" OpenGL.
Besides, if you're going to make games, it is very likely that you'll have to use C++ or some other "non-python" language.
P.S. I've done enough OpenGL programming, a lot of DirectX programming, but I specialize on C++, and use python only for certain algorithmic tests, tools and scripts.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'm starting a computer graphics course, and I have to choose a language.
Choices are between C++ and Python. I have no problem with C++, python is a work in progress. So i was thinking to go down the python road, using pyopengl for graphics part.
I have heard though, that performance is an issue.
Is python / pyopengl mature enough to challenge C++ on performance?
I realize its a long shot, but I'd like to hear your thoughts, experiences on uses of pyopengl.
It depends a LOT on the contents of your computer graphics course. If you are doing anything like the introductory course I've taught in the past, it's basically spinning cubes and spheres, some texture mapping and some vertex animation, and that's about it. In this case, Python would be perfectly adequate, assuming you can get around the Unpythonic (and, lets be honest, un-C++) OpenGL state-machine paradigm.
For things like doing your matrix maths you can use Numpy, the core of which is written in C and is really quite quick. You'll be up and running faster, iterate faster and most likely have more fun.
If, however, you are doing some hardcore, cutting edge, millions-of-triangles-per-scene-skinned-animated-everything computer graphics course, stick with C++.
If your class has given you the choice it's probably a safe bet that Python will be ok.
If you want to leverage your knowledge into a real job in computer graphics though, pretty much every game and graphics engine is written in C or C++, while Python (or Lua) is left as a scripting language.
Here's my personal experience:
When I first heard about PyOpenGL, I was absolutely thrilled. OpenGL in my favourite language? Deal! So I started learning 3D graphics programming by myself.
I went through several tutorials and books like NeHe and the OpenGL SuperBible. Because PyOpenGL's functions are identical to that of OpenGL itself's (with very minor differences), it wasn't hard to replicate most of the examples. Besides, NeHe has many source code in Python that others made.
It wasn't too long after (about 2 weeks) I read up on Quaternions and implemented in Python myself. Now I have a GLSL-enabled environment with full 3D camera interaction options. I made a simple Phong shader, and used Quaternions to drive my camera rotations. I haven't got a single performance hit, yet.
Months later, I came back to this code.
I attempted a Python Octree implementation, and when I went to 8 levels (256x256x256 voxels), it took more than 2G of RAM to compute and minutes after, it still isn't done. I realised when you store many objects in Python, it's not just a simple struct like in C++. That's where I realised I need to factor this out, write this in C++, and then glue it back with a Python call.
Once I'm done with this, if I remember, I will update you. ;]
(To answer your question, no, Python will never replace C++. Those two lanaguages have different purposes, and different strengths.)
Python is the way to go. Since all opengl programming is uploading data to the video card RAM, then using opengl to operate on it, the speed limitations in python are moot. Also it makes the hard things in C++ easy ie opening files, images, sounds etc.
As for the person above implementing octrees, there is nothing stopping you from using numpy, which is written in C, from implementing it. (also make sure you are using linear memory like a binary tree, and not pointers to objects in a link like structure)
Blog post on this subject
Python is an awesome language, but it's not the right tool for graphics. And if you want to do anything remotely advanced you'll have to use unpythonic libraries and will end up with ugly C code written in Python.
Python is a dynamic language that get interpreted and compiled on runtime and as such cannot have better performance then C++ - take a look at this post for comparison between several programming languages.
Another good reason to prefer C++ is parallel execution. Many tasks in CG can be optimized by splitting them to multiple threads tgat run in parallel - ever tried to start a new thread using Python?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Right now I'm developing mostly in C/C++, but I wrote some small utilities in Python to automatize some tasks and I really love it as language (especially the productivity).
Except for the performances (a problem that could be sometimes solved thanks to the ease of interfacing Python with C modules), do you think it is proper for production use in the development of stand-alone complex applications (think for example to a word processor or a graphic tool)?
What IDE would you suggest? The IDLE provided with Python is not enough even for small projects in my opinion.
We've used IronPython to build our flagship spreadsheet application (40kloc production code - and it's Python, which IMO means loc per feature is low) at Resolver Systems, so I'd definitely say it's ready for production use of complex apps.
There are two ways in which this might not be a useful answer to you :-)
We're using IronPython, not the more usual CPython. This gives us the huge advantage of being able to use .NET class libraries. I may be setting myself up for flaming here, but I would say that I've never really seen a CPython application that looked "professional" - so having access to the WinForms widget set was a huge win for us. IronPython also gives us the advantage of being able to easily drop into C# if we need a performance boost. (Though to be honest we have never needed to do that. All of our performance problems to date have been because we chose dumb algorithms rather than because the language was slow.) Using C# from IP is much easier than writing a C Extension for CPython.
We're an Extreme Programming shop, so we write tests before we write code. I would not write production code in a dynamic language without writing the tests first; the lack of a compile step needs to be covered by something, and as other people have pointed out, refactoring without it can be tough. (Greg Hewgill's answer suggests he's had the same problem. On the other hand, I don't think I would write - or especially refactor - production code in any language these days without writing the tests first - but YMMV.)
Re: the IDE - we've been pretty much fine with each person using their favourite text editor; if you prefer something a bit more heavyweight then WingIDE is pretty well-regarded.
You'll find mostly two answers to that – the religous one (Yes! Of course! It's the best language ever!) and the other religious one (you gotta be kidding me! Python? No... it's not mature enough). I will maybe skip the last religion (Python?! Use Ruby!). The truth, as always, is far from obvious.
Pros: it's easy, readable, batteries included, has lots of good libraries for pretty much everything. It's expressive and dynamic typing makes it more concise in many cases.
Cons: as a dynamic language, has way worse IDE support (proper syntax completion requires static typing, whether explicit in Java or inferred in SML), its object system is far from perfect (interfaces, anyone?) and it is easy to end up with messy code that has methods returning either int or boolean or object or some sort under unknown circumstances.
My take – I love Python for scripting, automation, tiny webapps and other simple well defined tasks. In my opinion it is by far the best dynamic language on the planet. That said, I would never use it any dynamically typed language to develop an application of substantial size.
Say – it would be fine to use it for Stack Overflow, which has three developers and I guess no more than 30k lines of code. For bigger things – first your development would be super fast, and then once team and codebase grow things are slowing down more than they would with Java or C#. You need to offset lack of compilation time checks by writing more unittests, refactorings get harder cause you never know what your refacoring broke until you run all tests or even the whole big app, etc.
Now – decide on how big your team is going to be and how big the app is supposed to be once it is done. If you have 5 or less people and the target size is roughly Stack Overflow, go ahead, write in Python. You will finish in no time and be happy with good codebase. But if you want to write second Google or Yahoo, you will be much better with C# or Java.
Side-note on C/C++ you have mentioned: if you are not writing performance critical software (say massive parallel raytracer that will run for three months rendering a film) or a very mission critical system (say Mars lander that will fly three years straight and has only one chance to land right or you lose $400mln) do not use it. For web apps, most desktop apps, most apps in general it is not a good choice. You will die debugging pointers and memory allocation in complex business logic.
In my opinion python is more than ready for developing complex applications. I see pythons strength more on the server side than writing graphical clients. But have a look at http://www.resolversystems.com/. They develop a whole spreadsheet in python using the .net ironpython port.
If you are familiar with eclipse have a look at pydev which provides auto-completion and debugging support for python with all the other eclipse goodies like svn support. The guy developing it has just been bought by aptana, so this will be solid choice for the future.
#Marcin
Cons: as a dynamic language, has way
worse IDE support (proper syntax
completion requires static typing,
whether explicit in Java or inferred
in SML),
You are right, that static analysis may not provide full syntax completion for dynamic languages, but I thing pydev gets the job done very well. Further more I have a different development style when programming python. I have always an ipython session open and with one F5 I do not only get the perfect completion from ipython, but object introspection and manipulation as well.
But if you want to write second Google
or Yahoo, you will be much better with
C# or Java.
Google just rewrote jaiku to work on top of App Engine, all in python. And as far as I know they use a lot of python inside google too.
I really like python, it's usually my language of choice these days for small (non-gui) stuff that I do on my own.
However, for some larger Python projects I've tackled, I'm finding that it's not quite the same as programming in say, C++. I was working on a language parser, and needed to represent an AST in Python. This is certainly within the scope of what Python can do, but I had a bit of trouble with some refactoring. I was changing the representation of my AST and changing methods and classes around a lot, and I found I missed the strong typing that would be available to me in a C++ solution. Python's duck typing was almost too flexible and I found myself adding a lot of assert code to try to check my types as the program ran. And then I couldn't really be sure that everything was properly typed unless I had 100% code coverage testing (which I didn't at the time).
Actually, that's another thing that I miss sometimes. It's possible to write syntactically correct code in Python that simply won't run. The compiler is incapable of telling you about it until it actually executes the code, so in infrequently-used code paths such as error handlers you can easily have unseen bugs lurking around. Even code that's as simple as printing an error message with a % format string can fail at runtime because of mismatched types.
I haven't used Python for any GUI stuff so I can't comment on that aspect.
Python is considered (among Python programmers :) to be a great language for rapid prototyping. There's not a lot of extraneous syntax getting in the way of your thought processes, so most of the work you do tends to go into the code. (There's far less idioms required to be involved in writing good Python code than in writing good C++.)
Given this, most Python (CPython) programmers ascribe to the "premature optimization is the root of all evil" philosophy. By writing high-level (and significantly slower) Python code, one can optimize the bottlenecks out using C/C++ bindings when your application is nearing completion. At this point it becomes more clear what your processor-intensive algorithms are through proper profiling. This way, you write most of the code in a very readable and maintainable manner while allowing for speedups down the road. You'll see several Python library modules written in C for this very reason.
Most graphics libraries in Python (i.e. wxPython) are just Python wrappers around C++ libraries anyway, so you're pretty much writing to a C++ backend.
To address your IDE question, SPE (Stani's Python Editor) is a good IDE that I've used and Eclipse with PyDev gets the job done as well. Both are OSS, so they're free to try!
[Edit] #Marcin: Have you had experience writing > 30k LOC in Python? It's also funny that you should mention Google's scalability concerns, since they're Python's biggest supporters! Also a small organization called NASA also uses Python frequently ;) see "One coder and 17,000 Lines of Code Later".
Nothing to add to the other answers, besides that if you choose python you must use something like pylint which nobody mentioned so far.
One way to judge what python is used for is to look at what products use python at the moment. This wikipedia page has a long list including various web frameworks, content management systems, version control systems, desktop apps and IDEs.
As it says here - "Some of the largest projects that use Python are the Zope application server, YouTube, and the original BitTorrent client. Large organizations that make use of Python include Google, Yahoo!, CERN and NASA. ITA uses Python for some of its components."
So in short, yes, it is "proper for production use in the development of stand-alone complex applications". So are many other languages, with various pros and cons. Which is the best language for your particular use case is too subjective to answer, so I won't try, but often the answer will be "the one your developers know best".
Refactoring is inevitable on larger codebases and the lack of static typing makes this much harder in python than in statically typed languages.
And as far as I know they use a lot of python inside google too.
Well i'd hope so, the maker of python still works at google if i'm not mistaken?
As for the use of Python, i think it's a great language for stand-alone apps. It's heavily used in a lot of Linux programs, and there are a few nice widget sets out there to aid in the development of GUI's.
Python is a delight to use. I use it routinely and also write a lot of code for work in C#. There are two drawbacks to writing UI code in Python. one is that there is not a single ui framework that is accepted by the majority of the community. when you write in c# the .NET runtime and class libraries are all meant to work together. With Python every UI library has at's own semantics which are often at odds with the pythonic mindset in which you are trying to write your program. I am not blaming the library writers. I've tried several libraries (wxwidgets, PythonWin[Wrapper around MFC], Tkinter), When doing so I often felt that I was writing code in a language other than Python (despite the fact that it was python) because the libraries aren't exactly pythonic they are a port from another language be it c, c++, tk.
So for me I will write UI code in .NET (for me C#) because of the IDE & the consistency of the libraries. But when I can I will write business logic in python because it is more clear and more fun.
I know I'm probably stating the obvious, but don't forget that the quality of the development team and their familiarity with the technology will have a major impact on your ability to deliver.
If you have a strong team, then it's probably not an issue if they're familiar. But if you have people who are more 9 to 5'rs who aren't familiar with the technology, they will need more support and you'd need to make a call if the productivity gains are worth whatever the cost of that support is.
I had only one python experience, my trash-cli project.
I know that probably some or all problems depends of my inexperience with python.
I found frustrating these things:
the difficult of finding a good IDE for free
the limited support to automatic refactoring
Moreover:
the need of introduce two level of grouping packages and modules confuses me.
it seems to me that there is not a widely adopted code naming convention
it seems to me that there are some standard library APIs docs that are incomplete
the fact that some standard libraries are not fully object oriented annoys me
Although some python coders tell me that they does not have these problems, or they say these are not problems.
Try Django or Pylons, write a simple app with both of them and then decide which one suits you best. There are others (like Turbogears or Werkzeug) but those are the most used.