Prototype!

I've put together a very early prototype release of my game, please feel free to have a test and a poke around. The rope swinging and collision detection are essentially final (some tweaking to be done, and fixing any bugs that might crop up). Nothing else works yet, but I'm feeling quite happy with the fruits of Day 1 :)

I look forward to any comments! :)

(log in to comment)

Comments

Wow, pretty impressive for one day of coding. Still has a lot of little buggy issues, but it's not bad. We managed to attach to a point far off screen, not sure what's with that. If you swing off the ceiling and move left/right you can make the rope go through the ledges :) Making it more like rope and less like a straight line would probably take a lot more work though.
Thanks for the comments :)

I'm probably going to have to compromise on the rope/straight line issue, because this is my first go with PyODE, and the time is so tight :( I should really be happy that the player doesn't go through ledges! ;)

What kind of framerate are you getting? I'd like to maintain a fairly high rate on most systems, because I think that's what's causing the grapple bugs - I think it might be moving just a little bit too fast for PyODE to keep up when frame rates dip. If it persists, I might have to slow the grapple a bit :(
Don blake got 80 fps, and I got 15-20; the main problem was that on my computer the simulation ran extremely slow - so you have some framerate dependence going on that you need to take care of. Ode should be able to handle that just fine - but you need to pay attention to the time that passes between frames and make sure to pass that to ode.


I agree that the rope through the ledge bug is fine to leave, the other bug is pretty ugly though. It happens when you attach the rope (to anything) and then move to a corner and hold the directions into the corner. Something is happening to the attach point, might be an issue with Ode.

I have discovered that ODE's built-in collision detection is NOT framerate-independent - I discovered this during the first PyWeek challenge, when I went to the trouble of using ODE for collision detection, only to find out it didn't solve the problem I was hoping it would (that bullets passed through objects at low framerates/high speeds). If it is framerate-independent these days, then that's a big step forward, but for myself it was just wasted time: if I'd known ODE would just give me standard sphere/sphere collisions (in the case of my game), then I could have just implemented them myself (since ODE really wasn't used for anything else), and would at least have known I would definitely have problems instead of thinking I'd got round them.

If this continues to be an issue, you might want to look at Bullet. Haven't actually used it myself, but it definitely does do framerate-independent collision detection, and probably ships with Python bindings since it's used by Blender's game engine.

This is going to cause me some problems. Apparently, there are no Python bindings for Bullet outside of Blender at present :( I might have to look at using a mix of ODE collision detection and Pygame collision detection... That might let me eke out a few more FPS.
great work! I'm doing something similiar (but without ode) in sticky. are on IRC sometime? would like to hear more about your ODE experience :-)
Just a thought: I haven't tried this, but if you're having trouble with something like a bullet passing through things, maybe you could give the bullet a long cylindrical geom, calculated to be about as long as the distance the bullet travels in a frame. Then you shouldn't miss any collisions.

You won't miss collisions, true; but if the thing it's hitting is also mobile (and potentially fast), you will get false positives. If you have fast-moving objects colliding with strictly static objects, then this won't be an issue. The shape of your objects, and how closely you want the collision geometry to match the visible geometry, will also affect whether or not you can use an approximation like this. Disclaimer: I haven't actually seen this prototype thingy in action :)

In the case of my own game, I could have used raycasting, since bullets only ever travelled in straight lines and were only ever collision tested against static objects. I considered this, but firstly by the time I realised this it was already too late, and secondly, even after thinking about it I decided I didn't want to design in the limitation that collisions would only work correctly with stationary things. (I had vague plans of continuing development beyond the original week; I still do, sort of, but it hasn't exactly been a priority.)

It's not that the collision detection is framerate dependant, the whole physics was moving really slow for me. You can fine tune how much time to add to the simulation, so you have to control whether its framerate independant or not. I use pyode for my "real" game and have not had trouble with it. Bullet is a better collision detection library than opcode (what comes with ODE) but you can also use rays to help the simulation, by using a ray that's as long as the bullets velocity and using that for the collision. (So after one timestep, the ray would go from the bullets last known spot to the bullets current spot).

The rope going through issue seen here is an unrelated thing having to do with the rope being a simple straight joint :)
Well, I read "rope through ledge bug" and the hint of some "grapple bugs" that the OP thinks may be related to framerate.. perhaps I ought to actually try this thing out before commenting further, because it seems there are at least two - probably unrelated - issues being talked about here, and I'm probably only confusing things ;)
The "rope through ledge" bug means that rather than bending on contact with a ledge, lik a rope would, the joint I'm using just passes straight through as though the ledge wasn't there, until such time as the player on the end of the rope hits the ledge. I consider this very minor, and will not be spending very long making it work. It's not framerate related in any way.

Then, there's the issue of the grapple shooting clean through ledges sometimes. That, I think, *is* frame-rate related, that or I'm still using too large a scale with PyODE, which I will be looking into.

To simono: Thanks for the comments, I'm probably unlikely to make it onto IRC during the competition due to time constraints and my tendency to get very distracted by things like that ;) But I can tell you that PyODE does seem to be well worth playing with! There are three basic tutorials on their homepage which have provided most of the physics I'm now using. I was quite surprised at how straightforward it was to create and manipulate physics objects!
*sheepish* I know why you can shoot the grapple through ledges... I'd set it to create the grapple a fixed distance above the player, and then forgot all about it. I'm just writing some new code to better manage my collisions, which I hope will sort this and some other issues out.