Okay, you seem to be unclear on the concept. Blender provides a graphics renderer. It supports at least basic real time animation, and probably camera manipulation, but a game is not a renderer. There's complex realtime physics, there's events, there's AI, there's character interaction, there's pathfinding, there's environment loading and unloading, there's timers, there's scripting, there's a thousand elements that you never think you need until you realize that they're missing.
Look around. Commercial games aren't
ever written in python, though they might use it for scripted events. And I don't know about you, but I haven't seen any killer python games on the market or in the open source community.
Also, Blender is a content creation application. In general, if it runs inside Blender, it's probably not a game. I'm not insulting Blender there; it's just not what it was designed for. Games, particularly RPG's, require a whole new level of immersion that requires a completely different application design. Blender can make and build, but it can't truly play.
Ok then I was wrong with python. But the programming language doesn't decide how fast the engine is. Blender is capable of making great games. Just look at these screens below. All made in blender. So you are joking right, that it wouldn't be able to make a Final Fantasy VII game. Of course it's maybe not the best engine for the genre. But it's possible.
Actually, the programming language is almost entirely responsible for deciding how fast the game runs, if hardware is kept constant. In C++, the code is compiled into a straight binary that can be run by the CPU directly. In Python, the code is written, possibly compiled to a bytecode-equivalent (I forget what Python calls it), and then loaded by an interpreter. The interpreter has to compile the code to binary before the CPU can process it, creating a large overhead that is simply used to process the code, not to run your game. That overhead isn't a problem in applications like Blender, or in the many places where Python has been used successfully. When you start trying to run many frames in a second, and a frame consists of more than rendering, that overhead becomes unacceptable.
If nothing else, a major reason Python can work well for rendering is that it doesn't actually render anything, it just passes the data on to libraries of the renderer, be it DirectX or OpenGL. Guess what those libraries are written in? Yep, mostly C or Assembly Language. DirectX might include some C++.
I will admit it's possible, but if a project tried to write a replacement game engine in Python, the project would be in grave danger from the day of it's inception. The QGears project is already pursuing a goal like this, and, interestingly enough, they're writing it in C++.
So stop babbling about blender wouldn't be able to make a Final Fantasy VII. Lol final fantasy VII was made for the PS1...blender can make late PS2 graphics...soon pS3...
Actually, I'm "babbling" from the many game programming books I've written. I'm babbling from the many programming design books I've written. I'm babbling from my programming experiences.
I do agree with you though. Blender can make PS1, PS2, and PS3 graphics. However, Blender is not a game, a game engine, or a part of a game in any way. Blender is a content creation suite, an excellent one at that, but that is its purpose, and nothing more. People may try to extend it, but it will at best perform marginally compared to real applications designed from the ground up for this purpose.
