Josip Kladaric: Paradox. Very profound.
Vexelius: The thing about classes and libraries and all that is, yes, they are more work, but you can see what you’re getting. Each class has its methods and variables clearly documented. I can look and see what each function takes as a parameter, what it does, and what it returns.
Compare that to blender. Yes, the API is documented, and all my python scripts run fine. Where I’ve used bricks, they pretty much work fine too. In fact, pretty much everything I have the direct ability to influence does what I expect it to do.
The problems start where I can’t see them. The game engine seems to handle every possible thing contrary to my expectations. I’ll encounter some strange behaviour, which will delay me for days of trial, error and frustration, until I finally stumble upon a workaround. I’ll end up with an object that won’t move unless it’s parented through about five Empties, or has twenty unnecessary one-off properties. Then when I come to add in some new functionality, I have to use trial and error again to work out which of these Empties to add logic to, which properties to change, and if the property in question isn’t attached to the same Empty, how to get them to cooperate without spawning a whole load more useless spaghetti. In the end I have to bin the lot and start from scratch, and the process repeats.
For example: I found no information on how the game engine deals with groups. There was a rather useless Library Linking video on the Yo Frankie! site that walked you through the two-step process of adding a group that had no logic and sat there doing nothing. There was something else stating that groups had been successfully used for ‘logic sharing’ in Yo Frankie - it had pretty Venn diagrams and directed me to the game’s source files. On opening any of these files on my laptop (Ubuntu 8.10) blender crashes immediately, and even if they didn’t I’m afraid I’ve always found it impossible to understand things by looking at other people’s blends.
Eventually one of the devs on the forums (think it was ideasman) explained, and the explanation made sense enough once you knew about it. But since then, there have been thousands more related complications. There’s one bothering me at the moment which seems to have sprung from nowhere because I didn’t see it in the last attempt:
If I make an object and tie it to my module control.py, I can control it with the arrow keys. If I use an Empty instead of this object, with a mesh object parented to it, it works too. If I delete the mesh object and just use the Empty (which I’ve just proved works fine) as a Dupligroup instance, the orientation controls work fine, but the object won’t move backwards. Moves forwards, which is exactly the same code plus a minus sign, but doesn’t move backwards.
So I’ve ended up with one Dupligrouped Empty parented to another plain Empty with logic. Which will work fine, until tomorrow when I try to add anything else.
So, in light of that, I don’t particularly think that using another engine in place of the BGE is that bad an idea. I would rather learn a new language from scratch and do twice as much writing in exchange for being responsible for all my own bugs and able to just look through documentation instead of having to constantly second-guess the software I’m using. It may well be a lot more work, but at least I will have some confidence that I’m actually making progress.
The way you describe Sandbox, it sounds a bit too simple for what I need (I’m working on a space shooter, so I need proper physics and collision detection with 6 degrees of freedom, plus some level of scripting ability for the AI.) Unity’s website looks fantastic but it seems to be only for Mac. I’m looking at C4 now.
Sasori: I may do that, OGRE for graphics and Bullet for physics. Will spend just a bit more time looking for that mythical all-done-for-you gamekit solution and then plough in.
If anyone else has any other suggestions, please don’t hesitate to post them.