Can Python handle...

You may not want to have very low level things done in Python, like a renderer. But, you could certainly use Python for your game-specific code. Many libs have Python bindings. So, while you might be using Python to use the graphics lib, everything under the hood was done in C++.

Ok, that's helpful I think. See, I have all these gaps in my knowledge because I'm self taught, and I've focused on web programming, and even when I do other stuff it's all button-up business database stuff... so when you talk about rendering engines bound to python it sounds like a big, scary black hole of complexity to me... I don't have the low-level knowledge to implement something like that, and I'm not familiar with how a game is tiered... I've made little demo games where it displays a background, and you can push a little tank image around the screen with the keyboard or click with a mouse and have it travel there, but... as far as a well structured game, I'm lost. Are there any resources that address a person in my situation, or am I stuck reading books geared toward total newbies, in order to pick up the things I've missed?

It's somewhat difficult to know. If you're using hardware rendering and can do stuff efficiently without needing tight loops inside your python code doing lots of work, I don't see why not.

Remember that using a scripting language like python, although it's several times slower than (say C), probably isn't that much slower that it slows your program down to the speed of one in C on hardware that you had when Diablo was released (2000, was it?)

That said, if you've got tight rendering loops they might be able to benefit somewhat from being written in native code. You'll have to see.

I guess you should just try it to see if it works. Lots of people apparently use pygame which as far as I can tell basically wraps SDL - this is far from ideal if you're using hardware rendering (and software rendering is far from ideal on modern systems anyway).

Mark

Python is pretty fast, but I'd still defer performance-critical code (such as tight inner loops) to C and call it from Python. It's certainly powerful enough to do a Diablo-like game in pure Python, calling an external graphics library through Pygame or PyOpenGL to handle the heavy lifting.

Most games I see these days are GPU-bound, so the performance difference in the game code shouldn't be that much of an issue.

I'd just write the damn game; if it's too slow, then you can start worrying about porting some of it to C.

Quote:

I'd just write the damn game; if it's too slow, then you can start worrying about porting some of it to C.

Good call.

Quote:

Original post by Pete Michaud ... and even when I do other stuff it's all button-up business database stuff...

That sucks, doesn't it? I spend 80% of my programming energy on business crap. But it pays the bills, so...

Quote:

Original post by Ravuya I'd just write the damn game; if it's too slow, then you can start worrying about porting some of it to C.

This is Important Rule #1 of software development. Just do it! Then take care of optimizations.

Think about it for a sec. Would you rather spend time developing the game itself, fleshing out the design and getting something working or would you rather first spend time stuck in the seg-fault hell and figuring out very low-level details of a speedy renderer?

There are many Python extensions that wrap mature and efficient C/C++ libraries; among the most relevant for games are Ogre (PyOgre) and other 3D engines, OpenGL (PyOpenGL), SDL (PyGame) and Allegro, WxWidgets (WxPython), FLTK (PyFLTK), GTK (PyGTK) and other cross-platform windowing toolkits.
Given these tools, I wouldn't worry about graphics performance; a Python program can use more or less the same library calls for the same job as its equivalent C or C++ program, with an insignificant overhead.

Moreover, an easy, "powerful" language like Python allows the use of advanced, efficient algorithms that would be a nightmare in low level languages.

I don't mean to hijack the thread (Sorry) But I'm wondering, if Python is 'good enough', would C# be as well? I know they are (very) different languages, but I've heard that C# gets compiled into the host machine language at runtime through a JIT, so is this theoretically faster than Python? Not trying to put Python down, it's more of a question of "If Python can do it, shouldn't C# be able to?". Thanks.

I think it'd be best to stay away from any sort of C# vs. Python discussion, but yes, C# would also certainly be more than capable of producing a Diablo-like game. You'd probably want to make use of either MDX or the Tao OpenGL bindings for your rendering.

Keep in mind that for both Python and C# (as well as any other programming language you'd care to name) you will still have to be using them appropriately to get good performance.

Quote:

Original post by ddx You may not want to have very low level things done in Python, like a renderer.

Don't be quite so hasty. What about a renderer would be so perf intensive, especially in a game like Diablo? In fact, youre probably going to be bottlenecked by the driver for that one, with submitting lots of draw calls and all.

If I had to guess at the perf hotspots in a Diablo game, I'd look at the dungeon generation and the pathfinding first. It is not a heavy game. Diablo 2's system requirements call for a Pentium 233.

I'd be interested in hearing more input in the rest of his question:

Quote:

Original post by Pete Michaud I don't have the low-level knowledge to implement something like that, and I'm not familiar with how a game is tiered... as far as a well structured game, I'm lost. Are there any resources that address a person in my situation, or am I stuck reading books geared toward total newbies, in order to pick up the things I've missed?

You're best off reading a book or two, really. Tutorials rarely go into the depth you need, and forum posts tend to address things in isolation.

Python is definitely fast enough for a game like this. I'd recommend using PyGame to handle the graphics drawing and input.

Python is a lot faster than people give it credit for. For instance, right now I'm working on a first person shooter written in a mix of Python and C (although the vast majority is Python), and performance has been much less of an issue than you'd expect (right now it runs at 90FPS on a 150,000 polygon scene with physics and AI running).