Is python fast enough for a simulation heavy game similar to Dwarf Fortress?

python cant handle that much computation.

look at dwarf fortress. written in c++ still runs slow on high end machines.

edit:

considering OP has a need to ask this question,
i can assume he/she is not a guru.
just go with what you have experience with.

about the performance comparison:

bad written code will run slow no matter what language it is written.
but with C/C++ you can at least know that you are reason why the game runs slow.

i find it silly to even compare C execution speed with CPython's or PyPy's.

If Python is fast enough to run Eve, it's fast enough to run a simulation game.

Define "simulation heavy."


You could easily write a program that bogs down a modern machine using Python. Or C++. Or any other language.

Conversely, you can probably do a lot more than you might think if you're careful about performance at an algorithmic level.

If Python is fast enough to run Eve, it's fast enough to run a simulation game.

I'm not familiar with it but how much simulation is actually going on (and is it calling into optimized, native code to do the heavy lifting), and is it going on client-side or server-side?


I agree that the standard answer is typically, "If you have to ask, it's likely that you aren't going to do anything that would push the boundaries if you use the right algorithms." But on the other hand, if the OP really does aim for the scale and detail of Dwarf Fortress, then we do see that DF does struggle to keep up. I don't really know how tight the code is, but I do trust that the author of Dwarf Fortress isn't a fool, and I'd be surprised if he were doing anything foolish that amounted to more overhead than what a language like python (assuming non-compiled) has implicitly.

If the scope and detail of what the OP wants to do are significantly less ambitious, then the need for greatest performance diminishes, of course.


It would be an interesting exercise for the OP to do some prototyping and see what the results are.

Thank you for the responses

The project is in it's infancy, but I'm trying to make sure I start off on the right foot. I've never programmed something intensive enough for me to have to worry about the limitations of a language.

Any thoughts on SDL vs SFML for c++?

and for Python would Pyglet or Pygame be better?

I'm not familiar with it but how much simulation is actually going on (and is it calling into optimized, native code to do the heavy lifting), and is it going on client-side or server-side?

Regardless of any of these questions, simply handling the rate of traffic has to be way more operations per time than dealing with the number of actors in a DF world. Admittedly, DF's stuff is 'heavier' but regardless, there's nothing even close intrinsic to DF that somehow limits the OP to C++.

python cant handle that much computation.

look at dwarf fortress. written in c++ still runs slow on high end machines.

DF isn't a shining example of good C++ code.(DF is fairly inefficient, single threaded and keeps missing the cache), Yes it is an impressive game but you could rewrite it from scratch in pretty much any other language and get better performance.

Thank you for the responses

The project is in it's infancy, but I'm trying to make sure I start off on the right foot. I've never programmed something intensive enough for me to have to worry about the limitations of a language.

Any thoughts on SDL vs SFML for c++?

and for Python would Pyglet or Pygame be better?

Assuming you're comfortable with both C++ and Python, then once you've decided on a language the standard answer is just to use whichever of you have the most experience with. SFL or SFML for C++, or Pyglet or Pygame for Python.

That said. I have experience with both SFML and Pygame and I enjoyed using SFML a lot more (Though that might be me preferring C++). Use whatever you like. If you start making your game and it turns out you need to change to something else it probably won't take that long because most of these libraries are pretty similiar.

Once upon a time I was writing a marching cubes terrain renderer in Python (using Panda3D.) I had read on their forums that Python is internally limited to one actual thread, even though it provides a threading interface to 'fake' real multi-threading. So if you ever want to not be limited to one CPU core, you'll want to verify whether or not that's true today before you get too far with Python.

So if you ever want to not be limited to one CPU core, you'll want to verify whether or not that's true today before you get too far with Python.

It remains true for CPython (at least the 2.x branch, I know little about the 3.x branch), the global interpreter lock still prevents multiple threads from executing python code at the same time.

IronPython however, which targets the .Net runtime, doesn't have this problem.

There is also Stackless Python, which if memory serves is what Eve uses, [strike]which can let use us multiple threads too.[/strike] (Except it doesn't; see below...)

There is also Stackless Python, which if memory serves is what Eve uses, which can let use us multiple threads too.

Yes, EvE uses stackless python. It does not, however, use multiple threads. It suffers from the GIL as well. It uses tasklets which are essentially microthreads which get run on a single thread. The "multithreading" behavior is cooperative.

Python is used quite extensively in EvE, both on the client and server. Most of the game simulation is actually run using python. The heavy math parts get offloaded to C++ modules, as do some other high performance modules (graphics for instance). Networking actually wraps IOCP up in channels to allow for asynchronous networking concurrent to the simulation.

I could wax on about python and eve for hours, but I'll stop there.

Washu hit on the key points for making sure that your game is fast when using Python, at least in my experience. Some parts should be offloaded to C++ modules. I always tended to look at it on the basis of abstraction. Some things operate best at a low level of abstraction. Bare-metal stuff, like physics and rendering. Other stuff works well at a higher level of abstraction, such as logic and AI. The logic and AI can live well inside Python, and in fact is very well served by living in Python, but the rendering, collision, physics and pathfinding stuff would probably be best handled by C++, built as a layer upon which the higher levels of abstraction can operate.

It's a question of scale, sure Python is fast enough for a subset of Dwarf Fortress.. To simulate DF in its entirety in Python? Maybe depends on alot of things, how well DF is written, the bottlenecks of DF and how well you know Python and if you can leverage optimized versions like CPython or IronPyhon. One thing is for sure, a high level languages like Python makes writing complex simulations like DF easier..

DF looks like alot of cellular automatas and control logic running in a micro threaded message passing scheme is my guess. Something like that shouldn't be too hard to code up in Python, give it a try. I love those old school sim games aka Rollercoaster Tychoon etc.. which is very similar to DF in ways..

Many existing math libraries for python (such as numpy) are often implemented in C anyway.

if you can leverage optimized versions like CPython or IronPyhon

Yeah, about that. CPython is the reference version. IronPython is much faster though if the OP is willing to use .net (or mono), this would of course mean pyglet or pygame would be out of the window, SDL has a .net binding though which works from IronPython (pygame is also just an SDL binding).

IronPython would open the door to XNA or Monogame though.



Back onto the OP's original question:
Dwarf fortress is supposedly badly optimised, very badly, it also suffers from alot of features being added on that weren't originally planned for and so kludging them into the engine has impacted performance. If your feature list was set out more rigidly (or the engine designed for easier expansion) from the start and you optimise things nicely then any language should suffice. Python would be pushing it but its possible. One thing that could help performance a little, DF simulates injuries to each limb independantly and even internal bleeding, not really needed, can probably scrap that alongside several other things.

This thread has become much more than I was expecting it to, in a good way

I personally prefer coding in Python, and I don't know enough c++ to make more optimized code than DF (although I could learn). I've looked in to Stackless Python and it seems promising. I just checked out IronPython quickly per recommendation, and just one question. If I start going that route, why not just use c# directly then? I'm not the biggest fan of the Visual IDE and XNA, but I will go that route if it's very appealing. What sort of cross platform doors will be open to me if I do?

If I start going that route, why not just use c# directly then? I'm not the biggest fan of the Visual IDE and XNA, but I will go that route if it's very appealing. What sort of cross platform doors will be open to me if I do?

With XNA there is just Microsofts platforms allthough monogame looks "promising".
(You can use C# or IronPython with for example OpenTK instead though if you want to run on Mac, Linux, etc and there is Xamarin (commercial unfortunatly) if you want to target iOS and Android).

The main reason to use IronPython over C# is that IronPython is Python, just like the main reason to use C# over IronPython is that C# is C#. You probably get better IDE support with C#(atleast in visual studio) and the compiler might generate better MSIL code from C# than it does from Python (I havn't checked, both seem good enough for me) but unless there is a real issue with one of the languages you're best off going with the one you prefer working with.

Monogame is an attempt to exactly clone XNA but using openGL and other open source cross platform technologies as a backend. It can be used in IronPython. Monogame will be one of the only options for cross platform going down the IronPython or C# line.

A good IronPython IDE for .net development (although with some hacking you can fool it into using mono compilers instead) is SharpDevelop. I had issues using the various visual studio plugins to use IronPython. It also has features to convert code between C#, VB.net, IronPython and IronRuby, they work quite nicely.

IronPython vs C#, thats just a case of do you know how to use C# or not, IronPython is essentially identical to Python 2.6 (I think, might be 2.7 actually). Only difference is one extra module to enable importing of .net/mono assemblies instead. Most existing Python applications will compile under IronPython already. So really its just Python but faster and with more libraries available. Any existing python module that has sections implemented in C (such as pygame) unfortunately will not work, some of the standard library for Python had bits written in C aswell but they've been ported to be IronPython compatible instead. Most of the best python modules have .net counterparts that you can use instead.

Assuming you're comfortable with both C++ and Python, then once you've decided on a language the standard answer is just to use whichever of you have the most experience with. SFL or SFML for C++, or Pyglet or Pygame for Python.
[/quote]

I think you meant SDL. ;)
But he's right in my opinion. You can write whatever type of game you want in what ever language you want. It's just up to you to make you that you are writing clean efficient code in order to avoid performance issues. I'm actually writing a full-scale 2D action RPG in Python with Pygame right now and though I'm not too far into it, I haven't run into any big issues regarding performance. I think the biggest set back with using Python/Pygame or C++/SDL is going to be the both SDL and Pygame aren't hardware accelerated, so it would always be a good idea to use an OpenGL wrapper for rendering so you can have hardware accelerated graphics. That's what I plan on doing, Pygame for user input, sounds and music, PyOpenGL for rendering, and Python as the main programming language because that's what I enjoy and am most confident in.

But I would just use whatever language you are more comfortable with and have more fun programming in. After all, is is supposed to be fun right?

Python is slow but you can use functions compiled in fortran and C. But I would advice agaisnt it, I regret deeply having used it for my simulations during my masters. It's great for its ease of use, quick prototyping etc. I still use it frequently as an advanced calculator "I wonder what's the sum of all prime numbers up to a million..."