Checking that I'm on the right track

Over the last few days I’ve made progress on learning the use of both Panda and Python, I believe. However, being a beginner at both, I’m not sure that I’m writing good, efficient, idiomatic code using either.

I would appreciate it if someone were to take a look at the (currently short) beginnings of a game that I’m working on, and let me know whether or not I’m on the right track, and, if there are any issues (especially efficiency or speed issues), let me know about them. :slight_smile:

Most of what I have thus far is taken from the tutorials (and in fact, I’m currently using the panda and environment from the first tutorial as placeholders), but I’m not sure that these same techniques are what I should use for something larger than a beginner tutorial.

By the way, the camera isn’t terribly intelligent, I know; I intend to keep this game fairly simple, and simply design environments that don’t extend above the camera’s final altitude.

The code can be found here. (Stored in this way to avoid making this post too long. :wink:

My thanks to anyone who takes the time and effort to provide feedback - thank you! :slight_smile:

[edit] By the way, I hope that I’ve placed this in the correct sub-forum; I considered the Scripting Issues forum, but the description didn’t seem to quite match, and this seemed like a fairly safe bet. ^^;

your code is quite well written considering you are new! I think you are on a good trak!

Now the bad things:
if (*): should be if * without the ( ) … next time you write if(a=3,): you will know why!

            friction = Vec3(0, 0, 0)
            friction.setX(self.velocity.getX())
            friction.setY(self.velocity.getY())
            friction.setZ(self.velocity.getZ())
            friction.normalize()

why not?

            friction = Vec3(self.velocity)
            friction.normalize()

Why?

 if(self.velocity.lengthSquared() > FRICTION*FRICTION*dt*dt):

maybe ?

self.velocity.length() > FRICTION*dt

(its ALWAYS faster in python to do less operation then a sqrt in C++ … )

impulse = [0, 1, 0]

smells like a Vec3

if you are doing simple things in panda3d any kind of math is too complex

impulse[0] = math.cos(act_dir)
impulse[1] = math.sin(act_dir)

is probably better done with thing.setPos(thing,movevec)
set position of thing relative to itself (thing) effectively moving it using the move vector

some odd things which i probably will not do

extend nodepath … i use obj.node (where object has a node path not is a node path)
pass render to a function.
comment so much :slight_smile:

good luck

You can also Panda’s ultrafast deg2Rad and rad2Deg functions:

from pandac.PandaModules import deg2Rad, rad2Deg
print deg2Rad(x)
print rad2Deg(x)

Thank you both for your help! :slight_smile:

I seem to recall seeing those, but didn’t think that they were faster than the multiplication system that I have been using - which I take it now that they are. :slight_smile:

Thank you very much! That’s encouraging to hear. :slight_smile:

Having done a little experimentation, followed by a look at a Python reference, I see now that, if I’m not much mistaken, “(a==3,)” defines a tuple, and, while such use of a comma seems unlikely as an intended usage (unless a tuple is meant, of course), such a typo could have produced a bug that could have been a nuisance to track down.

Aah, yes, that looks much better. :slight_smile:

(I take it that you mean “… less operations and a sqrt …”, since length() very probably involves a square root, while lengthSquared() should not)

Really? o_o

Hmm… What about storing a “FRICTION_SQUARED” value, and using “… lengthSquared() > FRICTION_SQUAREDdtdt”?

[edit] Ahh, wait, I think that I see - the sqrt used in the length method is handled in C++, not Python, and even a square root in C++ is faster than a few multiplications in Python. Wow… o_o [/edit]

A good point - I think that I was originally put off by Vec3s apparently not liking assignment by square-bracket index, although admittedly they do, I seem to recall, have assignment functions for the individual axes…

Well, I do use a movement (or rather, velocity) vector for movement, and use relative positioning to update the object’s position in the update method (albeit that I didn’t know about the two-parameter version of the method, I don’t think). The push method simply alters the object’s current velocity. This should allow for “soft” slow-downs (rather than the character simply ceasing to move when the keys are released), smooth transitions in direction, and, once implemented, the exertion of external forces (having an enemy send the player flying, or vice versa, for example).

Why is that, if I may ask, and what are the advantages of extending obj.node rather than extending NodePath?

The degree of commenting was intended for the purpose of this thread, to inform readers of my intentions. :wink:

if ( a == 2 ) : pass
is just not python way
its like writing
if (( a == 2)) {}
in c++, looks very odd.

obj has a node node instead of obj is a node.

Its just some thing i do, you don’t have to follow this convention just be aware of it I guess. Just like commenting and render thing … not really an error just personal preference.

Just for me it seems like object has a “property” which is that it belongs to a scene graph some place.

Also if you stick your object in a scene graph and get it back out again it will loose all of its python things and other subtile oddities can come out, but if you cant stick your object into the scene graph you dont run into them.

Fair enough, and thanks. :slight_smile:

Aah - that’s a potential concern. In that case, you may well be right - I think that I will change over to looking at my class as a container of various properties, rather than being one of them (the NodePath property).

Thank you again! :slight_smile: