• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Gnorme

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

23 posts in this topic

Would I end up running in to problems down the line trying to make a simulation heavy game with python? am I stuck using c++?
0

Share this post


Link to post
Share on other sites
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.

[b][u]about the performance comparison:[/u][/b]

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. Edited by saejox
-3

Share this post


Link to post
Share on other sites
[quote name='Telastyn' timestamp='1345662725' post='4972321']
If Python is fast enough to run Eve, it's fast enough to run a simulation game.
[/quote]

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.
1

Share this post


Link to post
Share on other sites
Thank you for the responses [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]

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? Edited by Gnorme
0

Share this post


Link to post
Share on other sites
[quote name='Ravyne' timestamp='1345664821' post='4972343']
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?
[/quote]

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++.
0

Share this post


Link to post
Share on other sites
[quote name='saejox' timestamp='1345662463' post='4972320']
python cant handle that much computation.

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

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.
1

Share this post


Link to post
Share on other sites
[quote name='Gnorme' timestamp='1345665205' post='4972346']
Thank you for the responses [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]

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?
[/quote]

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.
1

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
[quote name='Suspense' timestamp='1345675070' post='4972404']
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.
[/quote]

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...) Edited by phantom
2

Share this post


Link to post
Share on other sites
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.
2

Share this post


Link to post
Share on other sites
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.. Edited by ddn3
1

Share this post


Link to post
Share on other sites
Many existing math libraries for python (such as numpy) are often implemented in C anyway.
[quote name='ddn3' timestamp='1345688030' post='4972446']
if you can leverage optimized versions like CPython or IronPyhon
[/quote]
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.
1

Share this post


Link to post
Share on other sites
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?
0

Share this post


Link to post
Share on other sites
[quote name='Gnorme' timestamp='1345731580' post='4972581']
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?
[/quote]

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.
2

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
[quote]
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? Edited by breinygames
0

Share this post


Link to post
Share on other sites
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 :P "I wonder what's the sum of all prime numbers up to a million..."
0

Share this post


Link to post
Share on other sites
I'm currently developing an heavy simulation game and has already some experience with script languages in such an area. On some of my applications there were a very strong deceleration when I used Lua or plugin based dlls. Python Interfaces are not really different.

Example:
My fractal viewer was based at first on internal codes but this was bad and not really scalable. After that I used a very simple dll interface. The performance breaks down (nearly 30%!) . I also started a lua interface. The performance breaks down once more (nearly 50%!).

So on my opinion. Don't use scripting languages in big loops (10000 iterations and up) but you can use it for simple things.
This was my experience with scripting languages. I used lua the most of the time. But lua is a little bit faster than Python, so there shouldn't be much difference.

Regards
Ömercan
1

Share this post


Link to post
Share on other sites
Python can be used for games and simulations but the need for using optimization algorithms, DLL bindings (ctypes) or Cython ([url="http://www.cython.org/"]http://www.cython.org/[/url]) may become mandetory. Python however is a very efficient programming language.

While it seems not as popular as Pygame, I can highly recommend Pyglet for rendering your game (2D or 3D).
0

Share this post


Link to post
Share on other sites
Python gets a bad rep for multi-threading due to the Global Interpreter Lock. There is however no reason why you can't use multiple [i]processes[/i] (instead of threads), and communicate over pipes/shared memory/sockets (a la Chrome's process separation model). Especially when combined with tasklets/greenlets, this can be a very efficient model.

A word on PyPy:

CPython is obviously slow, and that is somewhat intrinsic to the fact that it is a straight-forward bytecode interpreter. Others have mentioned IronPython, native code modules, or hybrids thereof (cython, shedskin, etc.), to obtain better performance, but PyPy takes the cake for simplicity, being pretty much a drop-in replacement for CPython.

Is PyPy as fast as hand-coded C modules? Not yet, but it's getting closer. It is already significantly faster than CPython for most workloads, and even measures up to cython in some places. Plus there are the cases where a [url="http://morepypy.blogspot.com/2011/08/pypy-is-faster-than-c-again-string.html"]tracing JIT is just plain better at optimising than a static compiler[/url]...
0

Share this post


Link to post
Share on other sites
[quote name='Gnorme' timestamp='1345665205' post='4972346']
Any thoughts on SDL vs SFML for c++?[/quote]
I can't comment on the rest of the thread, and I'm not advocating C++ over Python, but if you [i]do[/i] go the C++ route, I [i]am[/i] advocating SFML over SDL (if you use C++).

[size=2]Reason: SDL has somewhat lagged in development as of the past few years though it's still chugging along, SFML has a more C++ friendly interface, multi-window support, full hardware acceleration by default (SDL's is software by default with hardware optional). They both are well documented.[/size]
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0