Per-ship policy
cbbrowne opened this issue · comments
You have set up a way of having hooks to do sophisticated fleet policy management, which is excellent.
I think it would become more convenient to program the fleet if there was also, added in, some primitive, but still useful, per-ship policy that would be executed as part of the per-tic ship processing.
What I suggest is to have a small set of tightly specified choices, defined with a view to them being very cheap to implement.
a) MINE
If there is a planet belonging to me at the ship's location, mine it.
b) ATTACK
If there is an enemy ship in range, shoot at it. If there are multiple to choose from, I suggest leaving the choice implementation-dependent. I'd like a random selection, but I'm not sure it's worth paying for that.
c) REPAIR
If there is a friendly ship in range in need of repairs, fix it. Again, choice being implementation-dependent.
d) BURN
I have an idea about making motion more interesting; if the efficiency of the rocket motor was best at low power, then there would be value in doing small burns each tic, so as to use fuel most efficiently, building up Delta-V over several tics. In the absence of some changes to that, probably pointless.
Given that, the "tic" loop might look like:
a) Move the ships based on previous state
b) Set up automatic actions for any ships with the above policies set
c) Run fleet methods
d) Allow users to request further actions
e) End of tic: process actions
Making the ships a little bit intelligent should make it a lot easier to manage the fleets.
When I started to write the Schemaverse, there actually wasn't any fleet scripts, instead each ship had a ship_script. Then folks came along and made 40,000 ships and, as you can imagine, the tic system basically came to a halt.
A,B & C) Right now each ship does have the ability to hold a 'state' where you can say MINE this PLANET, basically until you give it a new command. This way, it doesn't have to look around it's locations each time and decide to mine that specific planet because it is closest. The other two states you can choose are ATTACK, SHIP and REPAIR, SHIP.
I think it is up to you as the player to use your fleet scrip time accordingly to monitor the surroundings and change these states as you see fit. Maybe you don't' always have time to change the state of every ship in your fleet each tic but I think there is some fun game mechanics in that. Maybe other players could chime in here and say their own thoughts on the matter too?
D) This is also slightly in play already, right now you can have a MAX_SPEED that is greater then the allowed MAX_FUEL. In order to climb to that speed, you need to set your target speed to MAX_SPEED and then refuel your ship repeatedly throughout it's trip. Similarly, once you start getting close to your destination, you need to start refuelling again repeatedly so you can slow down in time. I think it is aspects like this that would make script writing interesting so I am hesitant about automating this. But, again, I am certainly willing to hear everyones thoughts on this as well.
Hmm, I actually hadn't realized you could already do A,B,C (although it's fairly clear once you look at tic.pl). Is setting action and action_target_id explicitly mentioned somewhere (I wouldn't be surprised if I missed it when I was first learning).
D) I think basically I agree with Abstrct on this. There's already problems to solve and optimize with respect to ship movement / acceleration / speed. The new movement system will slow you down when you get near your destination, but if you're going faster than you can slow down in a single tic (because MAX_FUEL is the limiting factor in your acceleration) you're still going to end up over-shooting. You could make an argument that this should be factored into the MOVE_SHIPS() backend method, but I think it's actually an interesting discrete math / engineering / optimization problem for players to solve.
I was thinking a bit more last night about the BURN notion, and I think I have an improvement in this regard to consider...
Was thinking about how to head to a desired destination. What's wanted is generally to get from point A to point B and, upon reaching point B, have velocity of 0.
I was thinking about having this take place via continuous burn rather than the present "get up to speed" then "stop when you get there."
Thus, the notion would be that the control is "burn N units of fuel per turn 'towards' the destination." But that's an oversimplification... Split that burn into two pieces:
a) How much of the burn is used to shift velocity to point directly at the destination? That will involve taking a tangent vector to the difference between current velocity and current destination, and using whatever portion is needed (perhaps 100%!) to shift the velocity vector to the same direction as the direction vector.
If present velocity is 0, or the ship is heading directly towards the destination, then this portion of the burn is 0. If you change destinations, the portion might be 100% for a number of turns.
b) Now, if there is burn left over after adjusting the velocity to match the destination, then the remainder of the burn may be used to either:
i) Accelerate towards the destination, or
ii) Decelerate, to slow towards a stop
Now, mumble, mumble, Optimal Control Theory, mumble, mumble, Pontryagin's Minimum Principle, this is a bang-bang control, with either maximum acceleration or deceleration, depending on whether, at maximum deceleration, you'd stop short of the target or not. (Should be able to work out a polynomial approximation for that, and get at least 'pretty close.')
I'd like to throw in an extra change, namely to allow some low burn rate to be considered free of charge. The "science fictiony" justification would be that the ship has a built-in ion drive that can support 10 units of acceleration per tic without consuming any fuel. That gives a good reason to do continuous low rate burns, if it's cheap to do so. In addition, I'd be inclined to eliminate MAX_SPEED as a constraint.
Methinks it's much more interesting to have fleets of ships doing 10 unit/tic burns that get them up to enormous void-crossing speeds. Makes me think of a Known Space torch ship. (And fleets of Pak Protectors...)
There's something of an illogic to being able to refuel any ship, anywhere.
I think I see the point you're making and a lot of it crossed my mind when I reworked movement recently. At the time I stuck with what's there now since it seemed like we ought to just start by fixing existing movement and then can consider new versions.
It sounds like you're general idea is that you'd want to define a ship's control by its daily (I'm going to just refer to our one-tic-of-time as a day) acceleration. So if you need to do a course correction or are less than half way to your target, you're still accelerating by that amount, and otherwise you need to start decelerating in order to stop in time. Makes sense to me so far.
But here's the catch. Suppose you want your ship to travel from (0,0) to (0,1000) at a constant acceleration of 10. This would end up taking (... gets some paper and does calculus ...) roughly 16 days and so you would have used 160 units of fuel. Now suppose instead I spend one day accelerating at 80, cruise at speed 80, and then spend one day decelerating at 80 to stop. I would have traveled the same distance using the same amount of fuel, but it would only take 13 days. This is why it seems to me like a target cruising speed is a better parameter to work with.
(By the way, the best time to start decelerating can be found by solving a kinematic equation for constant acceleration which is quadratic so yields a reasonable solution. You just need to do a bit of rounding since we're using discrete time units. But I can go into that later; I've clearly spent some time thinking about it.)
I'd agree that MAX_SPEED doesn't really make sense in this context, so I'd throw a vote behind getting rid of that. Instead what I think would make more sense is to have a MAX_ACCELERATION, which we more or less do already via MAX_FUEL (since the amount you can accelerate in a single tic is limited by the current fuel). In this case you could probably just eliminate each ship having its own fuel count, since I'm not sure if there's any utility to that (I certainly just refuel all my ships every turn, so any fuel cost is effectively just pulled from my player fuel reserve anyway).
Final comment on the free 10 units of acceleration: I don't personally have strong feelings one way or another about that, but I have to say that 10 units isn't really enough to make a difference in the game as it is. The average minimum distance between two distinct planets is around 250,000 (yes of course I calculated that. How else would I determine the typical optimal ... nevermind), so at 10 units of acceleration it would take about 4,167 tics to get from one planet to another. Since I think rounds have been around 2000 tics (rough guess) you wouldn't even get to the point where you start slowing down... and that's just to get to one more planet. So you'd probably have to up the free value (in which case would we be giving too much away for free?) or else it seems like it'd be moot.