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.
Related
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?
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.
Is anybody familiar with Worldviz-Vizard's 3D engine for python? How does it compare to Panda3D? I have a feeling that it might be easier to learn but far more limited. They only support python 2.4 which also makes me not want to try it.
Been using Vizard for various VR and AR development for about 3 yrs now - it's NOT unity - i.e. a web enabled game engine (excellent though it is) - what Vizard provides is a highly optimized OpenGL engine, wrapped in user friendly python scripting environment BUT on top of this you get the ability to seamlessly distribute your simulations over a cluster or a network. Vizard keeps all things completely synched - invisible to the user. Connects to pretty much all known VR tracking equipment and display periphals and standard gaming equipment is also supported (Wiimote & Kinnect). Native support for frame sequential, side-by-side and anaglyph stereo, spatial sound engine and the ability to extend it with C and C++ plugins or GLSL shaders.
Didn't actually mean to write that much and I don't want to come across as a Vizard evangelist, it is not perfect, BUT comparing it to Panda3D, Unity or other game engines I feel is an unfair comparison - not like-for-like :o)
I've never heard of Worldviz Vizard or Panda3D but it seems to me like you would have to reinvent the wheel to use Pygame for 3D.
Another Option:Unity.
I'm not terribly experienced with this either but I heard it's good.
I only used Vizard, and that for one small project.
It was easy to use, well documented, and had a good set of examples.
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?
I'm trying to implement a fairly simple card game in Python so that two players can play together other the Internet. I have no problem with doing the GUI, but I don't know the first thing about how to do the networking part. A couple libraries I've found so far:
PyRO: seems nice and seems to fit the problem nicely by having shared Card objects in various states.
Twisted with pyglet-twisted: this looks powerful but complicated; I've used Pyglet before though so maybe it wouldn't be too bad.
Can anyone recommend the most appropriate one for my game (not necessarily on this list, I've probably missed lots of good ones)?
Both of those libraries are very good and would work perfectly for your card game.
Pyro might be easier to learn and use, but Twisted will scale better if you ever want to move into a very large number of players.
Twisted can be daunting at first but there are some books to help you get over the hump.
The are some other libraries to choose from but the two you found are mature and used widely within the Python community so you'll have a better chance of finding people to answer any questions.
My personal recommendation would be to use Pyro if you're just wanting to play around with networking but go with Twisted if you have grand plans for lots of players on the internet.
If you decide you don't want to use a 3rd party library, I'd recommend the asynchat module in the standard library. It's perfect for sending/receiving through a simple protocol.
Twisted is the better of the two libraries but the time spent learning to use it but learning networking will take you similar amount of time (at least for me).
If I were you I'd rather learn networking it will be much more useful to you in the future. The concepts are the same for most languages so its more portable as well. If you are going to take this approach have a look at http://www.amk.ca/python/howto/sockets/ it will take you through everything.