On Sun, 2005-02-06 at 16:56 -0800, Sean R. Lynch wrote: > Michael Edwards wrote: > > Cool, no sweat! The bowling app is here: > > http://workingweek.org/apps/bowling-0.1.tar.gz > > > > It makes pretty good use of the ode extensions, though I'd like to add > > more complexity to the physics. It requires the latest Soya from CVS > > (to get the linear velocity to work). > > > > To play: > > * By default, the game is for two players. You can specify more or less > > on the command line, like so: > > python bowling.py 3 > > * To aim the ball, hold down the left mouse button > > * To throw, release the left mouse button > > * After your ball has hit all the pins you think it's going to hit, > > press "Enter" to continue. > > > It's funny that if you just wait, the ball starts rolling away. I > should probably provide a way to stop the simulation, but doing the > simulation step in begin_round is not conducive to that. Eventually > there will be a separate step method. For now you could just > deactivate the ball until the person throws it.
Yeah, that's odd. I noticed that the ball stayed put when the alley was just a box. I'm not sure of the GeomShape of the alley is affecting the roll or what. Does deactivating the ball Body mean setting enabled = False? > > Notes: > > * Scoring is VERY generous. Just tapping a pin will mark it as hit > > (TODO: make this tougher) > > * The game logic isn't finished yet, so there is no end to the game. > > (TODO: add 10th-frame logic) > > * The struck pins get moved behind the "player". Don't be surprised if > > you see them in the background. (TODO: find a better place to stash > > these, probably behind some scenery) > > > You could just delete them from the simulation, which I think > world.remove(pin) would do. Come to think of it, it probably won't > work right. I need to override the remove method in ode.World. Yeah, that's what I had tried earlier, but I couldn't get the deletion to work. Or, rather, they would delete but something was still remaining and causing the processor to work harder and harder each round. Something in there wasn't getting removed, I think. > > * I'm really looking for ideas to make the game look and play better, so > > all suggestions welcome. > > > The pins could be fatter. Also, the center of mass and intertia tensor > for them aren't quite right. You can adjust the center of mass without > adjusting your model by making a subvolume to contain the shape as a > child of the actual body of the pins. Any suggestions on the inertia tensor? I tried the set_parameters method, but I didn't know how to calculate the tensor. I also tried making the mass smaller and translating it -Y, but I'm not sure if that had any effect. The pin models should improve soon--randomly, I just got a class assignment to build a bowling alley in Maya, so I'll actually be doing some research for references! > > * Any tips on using FRICTION would be appreciated. I played around with > > mu and slip, but I didn't get good results. Eventually, I'd like the > > ball to be able to hook, which would require that the ball spin fast > > enough at first to overcome static friction, then slow down enough to > > catch the floor and start hooking. Not sure how to make this work. > > > The friction model in ODE is somewhat simplistic, so it may be hard to > get good results. For one thing, the ball will probably tend to > suddenly "catch" as soon as the speed slows down enough to get below > the static friction. That's probably good enough. I'm really just curious about the slip in general, if only to see if I can get it working. > > * The code is an undocumented mess. Sorry! > > * The scale is wacked out. The units are about 4 times as large as they > > ought to be, assuming 1 unit ought to equal 1 meter, hence my fudging > > the gravity. 4 units = 1 meter. > > * Does anyone have any idea how to use the widgets? Right now, I'm just > > using text labels, but I'd like to use Banner objects if I can get them > > to work. > > > > Hope it's fun and educational! > > > It's great! > > Couple bits of advice: > > * You don't need to implement methods if you're not overriding > them. For example, you don't need begin_round on any of your > classes, since you're just calling ode.Body.begin_round with > no modifications. > * Alley can be a Volume. It doesn't need to be a Body because it > doesn't get affected by anything else in the simulation. > How come you are using a box for the pin geometry? I noticed the > commented out cylinders are on the wrong axis. Were you not able to > get that to work? GeomShape won't work right now as you've probably > noticed. It collides fine with anything other than another GeomShape, > which is what you're using for the alley. If you used a bunch of boxes > for the alley geom, you could use GeomShape for the pins, but then > they would tend to stick to one another, which is bad. I *think* the > problem is my setting of the previous state each step. If you can > figure it out, it would make me very happy :) > Yeah, for the bodies, I used to have stuff in the begin_round methods, but I probably should just pull those out now. For the game objects, I have methods named "begin_round", but I should probably rename those since they don't do the same thing. As for the alley, can it not be a Body, but still use the GeomShape? Is there a way to do it so that I don't have to assign it nearly infinite Mass? Regarding the pins, this was a bummer--the cylinders are capped! It took me a while to figure out what the meant, but, after trying in vain to get the pins to stand up, I realized it meant they had spherical ends. I tried to implement the flat-ended cylinder in the ode contribs directory, but, for some reason, the pyrex call kept not finding the right ode symbol in the library. So I chucked the idea and used boxes instead. It's shame, really, because the cylinder pins fell and collided much more believably. Any suggestions on getting the flat cylinder ported? -Mike --
