Untitled

Published February 21, 2010
Advertisement
I've taken the first steps towards better enemy movement in the game. Yesterday this meant rewriting the coordinate transform code of entities, and analyzing the vehicle component for how it should be designed in the future. I don't want to rush this but instead take the time to think through what types of movement it should support and by what parameters they should be controlled. Currently Vehicle is a mix of perhaps five different design ideas and works poorly as a result.

Reimplementing the transform code and defining a SpatialNode class, that is instanced by each Entity, gave me some good insight I think. Before, I was trying to decide whether to define velocity by a vector or by a speed and angle pair. The vector form was better for the transform hierarchy while the Vehicle code operates on speed and angle separately, so either way I had to do some conversion. Now that I got to think about it properly, to define a nested coordinate space in 2D you need both the vector velocity and the angle of the axes. I was good for a facepalm right then and there.

Anyway resolving this has laid the groundwork for the next generation of movement control. Now I have to think carefully of what kinds of enemy movement I want to support. The enemies uses a seeking behavior right now as well as cohesion and separation to keep them as a loose group. I need some kind of fly-by behavior to create faster fighter-like enemies. Maybe this can be constructed from some combination of seek and separation. Things like missiles could be created with pure seek and mines with pure cohesion (the difference being that cohesion attracts to all nearby targets). Actually, it would seem that if I just cleaned up the code I could create a lot with what I already have.

The model I use for the transform can be depicted as below, where system A is inert and system B has position r, velocity v, angle ? and angular velocity ?.


Made in Paint with a touchpad. Sorry about that.
Any object relative to B can be expressed relative to A as
rA = r + rB
vA = v + rot( vB, ? ) + ? rot( rB, ? + ?/2 )
?A = ? + ?B
?A = ? + ?B
where the A and B indexed quantities are those of the object relative to either system (rot means rotate by given angle). This can be recursed if system A is a rotating system relative to some other inert system, creating a hierarchy. (You may be more familiar with the 3D form where cross-products are used.)

I had a fleeting idea of using n time derivatives of r and ? to construct advanced motion. By theorem, any analytical function can be expressed as an infinite series of derivatives at some point, basically a Taylor expansion. If for instance some motion controller set n time-derivatives of r and ? instead of the current 2 (position and velocity), this system wouldn't have to be updated as often. Instead it would just integrate the n time-derivatives each time step.

Yeah this is probably moot in this kind of simple simulation where linear motion is sufficiently accurate. Maybe valuable in a more complex physical situation.

Anyone still reading? No?

... I like suiting up in rubber and getting a good spanking.

Oh you're still here. Damn!
Previous Entry VC++ issues
Next Entry Redist redone!
0 likes 0 comments

Comments

Nobody has left a comment. You can be the first!
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement