This is a chance to use my aiming math (here's another explanation from Scott Lembcke with graphs instead of equations). So far I have the turrets aiming without regard for acceleration of any kind. I'm searching for a combination of parameters that will make the player react while still leaving them enough time to do so. I think I will want to make the turrets smart enough to take into account the rocket's acceleration; otherwise it's too easy to dodge them by just flying through with your engine blazing. Maybe there will be different kinds of turrets with different target-leading algorithms; if they're clearly visually different it could be interesting. One would aim to hit the rocket without considering velocity or acceleration; one would aim considering only velocity; and one would aim considering both velocity and acceleration.
Having some additional projectiles is making me realize that my gravity is not very strong. The bullets don't arc much. I don't remember but I think I originally sized the gravity so it would be similar to Earth gravity based on the rough size of the rocket. Just looking at how long it takes to fall its own height when starting from rest (at sea level). After I have the turrets basically working I think I'll do a round of gravity strength experiments. Of course the rocket engine will have to be scaled accordingly; it needs to be able to deliver greater acceleration than gravity at “sea level” (where the gravity is strongest). Scaling gravity up might speed up the gameplay which could be interesting. I have it in my mind to add on-foot movement (a la Star Guard) and wheeled vehicle movement, so the gravity will need to feel OK for those too.
The projectiles need a lot of extra work. They need to go away upon intersection with the rocket, and they need to deliver an impulse and some damage. At the moment they are regular colliding bodies, so they do deliver some impulse and damage but I'd like it to be arbitrarily tunable. I think I will have the bullets “fade out” over time so they deliver less damage as they age, before disappearing entirely.
The turrets need to have their range of motion clamped so they can't shoot into the ground.
I'm weighing whether it's worth it to have my own version of the physics library (I translated it from C to C++) and keep porting vendor drops from the original, or whether I should just write the necessary shims to connect up the C library to my vector class and what-not so I can use it directly. I'm sort of inclining toward the latter. I'm also looking at Box2D again, although I haven't quite figured out how I would translate my collision shapes to their model. They have a maximum of eight vertices per convex shape, I think, so I'd need to make a bunch of shapes to represent my curved surfaces (my game's all about curved surfaces).
6 comments:
Heh. If you've just spelled my last name and thought to yourself "Wow, that is a lot of consonants in a row", then you probably still missed one. :p -> Lembcke
Also, IIRC I think Box2D has a compile time constant for the number of vertexes per polygon. Chipmunk uses SAT to collide polygons which is O(n*m) and has a compile time constant of 6 contact points per shape pair. Maybe Box2D makes some similar assumptions, it might be good to find out why before changing the number.
Sorry about the misspelling! Should be fixed now.
Yeah, Box2D has a compile-time constant. In its architecture the untransformed shape data is shared amongst all instances of that shape, to save memory I expect. The limitation is in that shape-data structure, not in the contact-management code. I'm not sure why yet.
If the shapes are convex I would expect to have zero, one, or two contacts per pair; is that right?
Well, the way it's implemented in Chipmunk is to take all vertexes that lie within the opposing shape. The problem is that with deeply penetrating shapes with a lot of vertexes you can get some really complicated overlaps. I tried a couple of different ways to estimate collision points, but no other method produced stable contacts. I was also able to modify it to handle deeply penetrated shapes with no overlapping vertexes (like a star of david).
That said, it is very rare to get collisions with more than 2 contacts per pair.
Oh, and the 6 points per pair is a very generous upper limit so that I know when I should consider a fixed size buffer of contact points to be full to allocate a new one.
Hehe ground combat with vehicles or on foot?? Awesome! :D
Judging by some indie games, no one will mind if the stranded astronauts are just ballooned-up stick figures. It will look just as cool :)
Also, did you get my idea in the other comment about centering the screen on the nearest collision point of the trajectories? I kinda got off-topic with the interpolation stuff, but I think it's the single most useful criterion... since usually the player wants to see what it's going to hit next, be it the ground or an asteroid :P
In my initial prototype one of the camera modes framed the rocket and its projected impact point; this is similar to what you're suggesting. If it was centered on the impact point it would show a lot of ground behind the impact point.
This kind of framing is ideal for landing; where it breaks down is when the impact point changes rapidly, for instance when you're in orbit and your trajectory slides across a floating island as you're adjusting it. I'll be experimenting with ways to mitigate that, though. A slow interpolation might help. I've also considered making the camera interpolation speed be inversely related to how much input the player is giving, so if you hold still the camera will adjust but if you're moving it will try to stay steady.
Post a Comment