I’m thinking of making an ebook that will guide newbies of Panda3d and gamedev in general in making a game from start to finish.
Here is what I have so far: 2shared.com/document/7UPedmO … guide.html
I try to explain things in a simple way.
I wouldn’t mention DirectStart and simply say that people need to instance ShowBase. I think that’s less confusing.
Away from that it’s a nice beginning.
Why? Just about every sample code I’ve come across uses DirectStart. Users should know what it is. And there really is no difference between importing DirectStart and creating an instance of ShowBase named “base” in your code, is there?
There is little functional difference, but the use of DirectStart is considered poor coding style by many, as the underlying functionality is hidden to the programmer. Most programmers who are familiar with VHLLs like Python will not expect a simple import command to actually create a window and all that.
Subclassing from ShowBase is currently the recommended and supported way to do it; likely, DirectStart will be deprecated in the future. It is demonstrated in the “Hello, world” sample program in the manual.
I could never understand this point: you first need to know what the module is for before using it, otherwise it is always “hidden”.
Anyway, I assumed that was the accepted way in the Panda community. I’ll still explain DirectStart though, because it appears so much in sample snippets.
But I see no reason to subclass instead of creating an instance though.
By subclassing ShowBase some people try to hide the variables which showbase throws into global namespace.
When you subclass ShowBase, then “base” becomes “self” and all attributes of base become attributes of self.
That doesn’t have any effect on the code, but some people think that this way it’s easier to undertand where things come from.
And so do the syntax checkers in IDEs, at least EasyEclipse.
I don’t see how they can hide the builtins even then, unless they overwrite that builtins some way in their code, which I don’t see is being done.
I really don’t see how that helps in understanding where things come from. “base.camera” means “camera” belongs to “base”, and if you make an instance of ShowBase in your code (instead of importing DirectStart), you know where “base” comes from, right?
And I’m not sure how IDEs would be more confused with instances, but not instances of an inherited class.
Not quite. “base” also is a variable that it stores in builtins. This means that it becomes accessible from any scope in any module. So if you’re creating an instance of ShowBase and putting it in a “base” variable, that’s actually quite misleading because when your “base” goes out of scope, it won’t be garbage collected, because it’ll still be in your scope, which could lead to some confusing situations if the system is not understood properly.