A proposal for fake orbital (With diagrams) Allows intuitive queuing of movement orders

I don't think there should be a different behaviour when you click on a location the satellite can't immediately turn to. A straight line should simply be drawn between the satellites current position and where the move order was issues, and the satellite lines up with that line, regardless of where the position is. This makes orbit changes very predictable and easy to visualize (especially when queuing up orders).

At the moment, the satellite's final vector in your proposal is somewhat random - it's either at some angle vaguely perpendicular based on the turning circle (if the movement point is far), or vaguely parallel (if nearby).

raevn

You are correct that the final vector will not be obvious. But I'm not completely sure what alternative you are suggesting?

You might be suggesting the ability to turn very quickly, however the unit has a fixed speed and large turning circle...

Why all orbits need to be at the same distance?

Why not allow the player to choose the height of it, so he can have a really high, geo-sync orbit, or a very low, but very fast one.

That could definitely happen. Maybe you could set an altitude for the launch on the orbital factory.

Due to the large OP, I wanted to keep to as simple a description as possible, focusing mainly on how the movement and control might work with a permanently moving unit. But you could easily include higher vehicles with a slower forward motion...

The new OP looks good. I assume by "turning circle matches planet circumference" you mean that the turning circle scales up for larger planets. I have done some maths and I think that if the turning circle (as if on a plane) is equal to the circumference of the planet then the satellite could loop around 1/4 of the planet. By 1/4 of the planet I mean the satellite would have a circular path of the right size to pass through a pole and exactly one point on the equator.

The orbit would trace this line:


I wanted to know how large a circle is traced by a constantly turning satellite of a given turning circle.

The circle on the sphere is the intersection of the planes y = mx and y = 0. m = tan(a) and in this picture a = pi/4.

The sphere is (x - 1)^2 + y^2 + z^2 - 1 = 0 and the circle on the sphere can be projected into the yz plane via x = y/m. It turns out that this projection is an ellipse given by (y - m/(m^2 + 1))^2/(m/(m^2 + 1))^2 + z^2*(m^2 + 1) = 1. Put the satellite as at (0,0,0), this is where the yz plane is the tangent plane to the sphere. The sphere is locally flat so by my reasoning the curvature of my ellipse at (0,0,0) should give me the turning circle of the satellite on the sphere (I haven't shown that this holds but it's good enough for now). It's easy to find the curvature of an ellipse along one of it's axes. Here it turns out to be 1/m which is sufficiently elegant for me to accept.

So if you want a satellite's maximum powered path to be "off a great circle" by angle a set it's turning circle to 1/tan(a).

-------------------------------------------

In the system currently proposed by the OP the satellites trace out an unchanging circle on the planet. The system does not allow geosync orbits because the satellites orbit with respect to the planet's surface. If it did allow geosync then the fast orbits could drift over time which would be really annoying.

On setting height in general; it sounds like an ok idea but I think a line has to be drawn otherwise we'll have feature creep. I think setting height manually would make the UI far too complicated and create too many variables for players to control. I think we would have a good enough system without changing heights and the UI is a lot easier to use.

Love it, I understand your point on this fully and is a great idea. +1

@GoogleFrog, i dont understand your post, what you show, are no physical correct orbits ^^

before we have wrong orbits in the game, we should have no orbits at all

From my understanding he's showing the resulting orbit caused if a satellite is continually applying a lateral force to change its orbit from the normal path it would follow.

This is, at a fundamental level, how I would expect the orbital layer to function.

I'm not suggesting turning quickly or changing speed - Taking your last diagram for example, at point 1, instead of turning left then right, it turns left then continues turning left until aligned with the line between point 1 and click A.

This would be a fantastic replacement. The current approach to orbital has really dampened my enthusiasm for this project. I hope there is time and budget to explore different options. This one should be front and center as a replacement.

From what I think you are suggesting, by the time the satellite reaches the line between point 1 and click A, it will be travelling in the wrong direction (ie not directly away from click A) and will need to turn right for a bit until it is moving directly away from click A. Then you have just delayed the right turn, making the move less efficient.

The right turn correction doesn't have to wait until you reach the line (it can happen before to ensure optimal efficiency, see below). The point is though, that this way you end up on a completely predictable path, and the path that was actually ordered. The current system proposed doesn't really have any correlation between where a player clicks and what orbit it ends up on.

@GoogleFrog
Yes I thought the turning circle should be linked in some way to a physical property of the planet being orbited and the circumference seemed the natural choice. I mean there would be nothing stopping you choosing the circumference of a planet with an arbitrary relationship (120%) and I guess it is a tradeoff between maneuverability and preventing an exploit.

I would not have guessed that picking the circumference of the planet would have led to the tightest turn being able to go from equator to pole to equator, so I'm very grateful to you for having calculated that! You didn't say explicitly but you appear to think that the proposed system fell within acceptable boundaries?

I guess you might consider banning patrol moves on satellites, at least force the player to micro the exploit every time...

@raevn
Yes, I see what you mean, however it still looks to me like the necessary right turn is delayed, meaning that you are not taking the quickest route to your selected target. I see that you get a benefit of having a final direction that *you* were expecting, but I don't see that everyone would expect or want that particular direction.
An alternative method if you wanted to control the final vector would be to draw a number of move orders (say along the line on your diagram)

I appreciate that it takes more clicks, but you still achieve your desired result and you don't force other players to use less efficient routes.

Additionally, your proposal doesn't cater for the case where the target is within the turning circle. Normally, you still would not be travelling in the direction *you* expect (not directly away from the start of the manoeuvre) Are you suggesting to put in a reverse turn even if the target is within the turning range? What if you had enough room to reach it by turning but if you wanted to correct the vector to *your* expectation then there was not enough room for that? Should the vehicle perform an additional orbit so it crosses the target using your preferred vector? Would you want to force that behaviour on all players?

If you don't delay the turn, you aren't heading towards the selected target, being where you clicked. Without a clear mapping between where you click and where the final orbit is, there is no target at all.

In the original image, click point A is roughly 45 degrees left of the satellite, yet it ends up travelling mostly parallel to it's current heading. I'm not sure how anyone would expect or want that particular heading. If you click somewhere 45 degrees from a units position, I would say most people would expect the satellite to end up moving on a 45 degree angle.

The move order in my diagram could be anywhere along the green line, even extending outwards, and the behaviour of the satellite would be identical. I'm not really understanding what you are saying here.

Contrast the two systems:


If a satellite is at position 1, and you issue a move command to A, which makes more sense: black line or red? Both will eventually cross position A after an orbit if they can't do it within their turning circles, but the method I propose allows the player to also control final heading, and it's movement is consistent regardless of whether the order is within it's turning circle or not.

Using your system, imagine the case where you are at point B on the final diagram and your next target happens to be where the satellite is labelled 6.

You can reach this position just by turning left, but you will not then be on *your* preferred vector, therefore you will have to turn right and miss the target. You then won't intercept the target for another full orbit, a pointless waste of time.

Lets be clear, I think the difference of opinion here is that I'm expecting the move orders to be given by selecting a target that you want the satellite to pass over, you obviously are expecting to tell the satellite what direction to move in by giving it a move order. That would be a different system.

If you want to scout the enemy base then click on the enemy base and the satellite will take the most direct route
there and regardless of which direction it approached from, it will pass over the enemy base again and again at regular intervals. This is the kind of behaviour the proposed system is designed for, although adding a few more movement orders would also achieve your desired behaviour.

If you have a proposal for your own alternative method, then do outline the entire system and how it would work. Although if it is a long post about a different proposal, then with respect, you might consider it's own thread.

I think you're right (to a point - both systems still end up crossing the clicked spot), and I see what you're saying about not immediately going over a spot in your B -> 6 example. However I consider direction to be very important if movement is constant, since you want to know what the satellite will pass over on it's way. There's also some tweaks that can occur to make the satellite wait until after it's passed the target to correct it's vector, if it's able to do so this orbit.

Anything I didn't mention would otherwise follow your original post, I wasn't trying to suggest an entirely new one.
I'm still not in favor of a constantly moving orbital system, but for gameplay rather than UI/command issues, so I'll bow out. I do want to say you've done a good job with the fleshed out idea though.

Don't go down this path. If a system of mechanics creates undesirable behaviour you should try to fix the mechanics rather than hiding the behaviour behind a bad UI.

There seem to be two opposing view here. realtimeshepherd thinks that the most important thing is for your satellite to pass over the desired location as fast as possible, the orbit it ends up in doesn't matter. raevn thinks that the most important thing is to be able to define the orbit. I think you're both wrong.

I can imagine situations where I would want a quick flyover and other situations where I want to define an orbit. The real test of either system is this; how easy is it to control the movement of your satellites in the way which the system is not designed for? My answer to this is realtimeshepherd's system. It would take a bit of fiddling with but some practice I think players would be able to queue a few orders which puts them in any orbit they desire.