implementing patrolling/circle strafing

[namer4]

I've been implementing my own space game, and in adding new behaviors to ships I've gotten tripped up by the problem of circle strafing, i.e., traveling in a roughly fixed-radius path around a target while periodically turning to fire at it.

I've spent a bit of time trying to work out a solution analytically, but my relevant math skills are a little rusty.

Can anyone help? More generally, are there any Newtonian physics cookbooks?

[Ttech]

I've been implementing my own space game, and in adding new behaviors to ships I've gotten tripped up by the problem of circle strafing, i.e., traveling in a roughly fixed-radius path around a target while periodically turning to fire at it.

I've spent a bit of time trying to work out a solution analytically, but my relevant math skills are a little rusty.

Can anyone help? More generally, are there any Newtonian physics cookbooks?

Is this part of Transcendence? Or trying to make a seperate game?

[namer4]

It's a separate game, unlike transcendence and much more modest. There are certain elements I've felt are missing from 4X games, so I've decided to create my own that implements them. At the moment I have basic combat, a simple planet model, the beginnings of a tech tree, and the beginnings of an XML framework for specifying content.

Right now the hangups I'm facing are that 1) ship behaviors are pretty limited because sorting out the planning is tricky (hence my question) and 2) having an asynchronous model and view is proving to be more difficult to get right than I'd originally thought; the latest issue is a visual `jitter' bug that's very mysterious.

[Ttech]

It's a separate game, unlike transcendence and much more modest. There are certain elements I've felt are missing from 4X games, so I've decided to create my own that implements them. At the moment I have basic combat, a simple planet model, the beginnings of a tech tree, and the beginnings of an XML framework for specifying content.

Right now the hangups I'm facing are that 1) ship behaviors are pretty limited because sorting out the planning is tricky (hence my question) and 2) having an asynchronous model and view is proving to be more difficult to get right than I'd originally thought; the latest issue is a visual `jitter' bug that's very mysterious.

What about making mods for this game to make it better?

[namer4]

That's a reasonable suggestion, and I thought about trying to make it work, but given my goals it's a nonstarter. The main problem is that the transcendence interface isn't appropriate for a 4X game. For instance, I want a planetary resource and infrastructure model. I can see how one might implement such a thing as a trans. mod, but it would be a lot of work, and visualization and management would be really kludgy with the available functions. I also want to be able to see events unfold at dramatically different scales and to permit arbitrary rotations for ships.

I also enjoy the coding and math for its own sake -- although I've done a couple of brief software engineering stints I'm not a coder by trade, and it's nice to take a break from my day job and learn something new.

I've also discovered that I don't enjoy playing my own mods. Since I put together the ship I posted I've made a couple of weapon and ship tweaks and I just couldn't get excited about them. I've concluded that I treat transcendence like a rereadable novel, and as in a novel I value the coherence of the storyline, the details that make the observable world feel like part of a much grander one, and the little surprises. George does a wonderful job managing all of those, and I'm happy waiting for the next version.

[george moromisato]

I'd love to help--I think it's cool that you're creating a game.

But I'm not sure I understand what you're looking for. Are you looking for an iterative solution or a time-parametric solution? Are you looking for a 2D solution or a 3D solution?

I don't have a 3D solution off the top of my head, but a 2D solution might be something like:

Let's say you have a center C and a point P and you want P to move some distance along a circle around C.

First compute the polar coordinates of P with C as the origin:

P-radius = sqrt((Px - Cx)^2 + (Py - Cy)^2)
P-angle = atan2(Py - Cy, Px - Cx)

Now advance the angle by whatever amount you want (this is the distance that you will travel around the circle)

Then convert back to cartessian:

Px = (cos(P-angle) * P-radius) + Cx
Py = (sin(P-angle) * P-radius) + Cy

Hope that helps, but if not, let me know what your code is like and maybe I can't help.

[namer4]

Thanks for your help! I'll try to summarize the important parts:
* Everything is 2D.
* The model I'm using updates with frequent ticks of variable length, in order to maximize accuracy while permitting me to target different rates of time passage a la your autopilot).
* Everything is Newtonian, and I try to keep it fairly realistic but there are some inaccuracies, such as not integrating thrust direction over a tick of turning.
* Ships have limited turn rates.
* I'm currently capping ship speeds because things behave badly otherwise (but I'd like to drop that restriction and achieve the same effect by imposing realistic constraints on energy consumption and ship behavior).

As for my goal, I originally wanted to be able to specify a radius around a target and get a ship to maximize its time spent firing at that target while staying within some error bound of the radius. I was thinking I could specify waypoints around the target (per the math you suggested) but figuring out how to take a starting velocity, starting rotation, and a target waypoint and translate that into a rotation/acceleration plan that hits the target waypoint at a velocity that makes the next one attainable just seems too hard. So now I'm just trying to sort out a heuristic circle strafing routine that I can parameterize with a rough distance goal.

Since the ship's ultimate goal is just to be firing at a target while accelerating in a way that makes it hard to *be* hit, my backup plan is to have a routine that goes like this:
1) if (abs(distance(ship,target)-target_dist) < error_bound)) ||
decreasing(abs(distance(ship,target)-target_dist)) {
if(pointing_at_target) /** accounting for leading **/ {
fire;
} else {
turn toward target;
}
} else {
/** turn & accelerate s.t. ship is on a heading that is somewhere between tangential to vector to target and directly approaching target distance **/
}

I hope I've been clear. I really appreciated your help with leading targets way back when (and I feel a little guilty that my progress has been so slow since).

[george moromisato]

I think the algorithm you described should work.

Obviously, you will have to balance error_bound with the ship's turning speed. The danger is that if the ship moves out of the error_bound range before it can turn to fire, it will be forced to turn to accelerate and never get a chance to fire. If that happens you can increase error_bound or increase the ship's turning speed.

In any case, it sounds like you have a good plan.

[Ttech]

hehe... I still say that this could be made as impovements to good ole' Transcendece. But perhaps thats just me

[namer4]

Great, I'll give it a shot.

[Ttech]

Great, I'll give it a shot.

ok