Do space games using addforce add too much when combining thrusters?

I'm playing a few space games that I do actually have the unity project for, since they were either publicly available or given to me. I have looked in the scripts for acceleration and the games just use unity's mechanism to add force to rigid-bodies. basically, they both feature 6axis manual thrust, so that all inputs are certainly from me.

First, correct me if I'm wrong, but if you use two thrusters that are 90 degrees out in angle, then the resulting vector should be the result of the Pythagorean theorem yes? So, you add force from one thruster, a , then from another thruster, b, and your resulting vector is a2 + b2 = c2 ?? (irl)

my question is,, is this how these games are working?? I don't find anywhere in the projects that the game devs do anything about how force is added to the rigid-body I'm really sure they're just using addForce. But,, when I play the games, I don't have confidence that my resulting vector changes are "within video game realism" because sometimes or maybe always I change vector quite quickly. Not always, of course,, this is particularly noticeable when using only one thruster, but I imagine that perhaps the game is adding them straight up sometimes?? Is this possible? I recall the "Descent Communty" always enjoying what they called "trichording" where this is the case, that all 3 forces are combined as though applied in the same resulting vector, it's today an option in the game "Overload". (which I really would love to see a full manual thrust mode included in)

My gametime would make me so much happier if I could be confident that although realism is extremely complex, at least my basic vector addition is realistic.

Thanks!!!

 

It will be a result of vector addition, not Pythagorean theorem.

Space games normally do not use physically correct newtonian flight model, because it is hard to control. They use arcade flight physics, which are not realistic. Thrusters normally do nothing and are purely visual effect.

Now, you CAN find games with newtonian flight, first one that comes to mind is space engineers.

Spoiler

When a game is using AddForce, then it is adding force to the rigidbody every frame(in FixedUpdate) when thruster is on, and stops adding it when it is off. Normally t here's also a mechanism in place to limit maximum velocity, because continuously adding force would allow you to accelerate your ship to infinity.

 

Space games do always have to bend realistic physics, because in reality, space missions take months or years... Haven't been able to google how fast a space shuttle etc. can simply turn for example, but I'd bet it's minutes.

Not sure it's exactly the same (because I have strong friction) but I'm developing an underwater game and also had trouble with moving the objects. I did stick to addForce but ended up making a virtual point for the forces to apply, outside what would be visually realistic for the object. Effectively my diver is getting pulled instead of actually pushed because pushing was uncontrollable.
A system like this would also result in un-intuitive behavior when only one truster is applied.

 

right so these games do use addforce to the rigid-body, they don't have like,, thrusters. (which I've seen tutorials for). I don't know how Flight of Nova works,, but it's certainly more intended for realism simulation. The public game Fly Dangerous does have a speed cap,, but you can crank it to 9999 and because you are flying around in a little arena your relative velocity shouldn't ever get to that.

space engineers (separately) makes me unhappy because it doesn't support my homemade controller. There's also only two options for xbox controller config, neither of which I like, and otherwise you're left with keyboard and mouse, which sure is fine depending, but is not what I came here to play, (because I only went looking after making my homemade controller). Fly Dangerous is the one I'm most worried about, because it's a potential exact match for my desired gameplay, which is to simulate real drone racing,, but in space. (so ,, thruster drones like NASA SPHERES) . you would have maybe a small course inflate from a sub-orbital hop rocket, and drones would use up their measely thrust in the 3-5 minutes of zero-g before the race plummets back into the desert.

I don't require full realism,, but I do hope that my timing is in the ballpark, which is why I really worry about the vector addition. (of course, the more realistic the better, right down the amount of co2 in a bottle) but Fly Dangerous Dev Options allow you to change a bunch of traits.

 

Well,, not ALL imaginable maneuvering scenarios take months and years. as I mentioned above my intention is to simulate drones being raced around little hoops (just like quadcopter FPV, but of course thruster drones in space). ,,, actually were this to be implemented in an underwater environment, or really any 6axis underwater navigation game that supports my home-made controller, I might be interested. Of course top tier is the drone racing simulator of submarine vehicles,, (which one wins I just don't know,, torpedoes are not 6axis, so although they can turn it's not the same as rcs docking or something,, so a drone with 6axis underwater might be a better kind of racing drone)

 

It is possible to have thrusters. Force can be applied to a point.

However, flying with newtonian physics AND point-thrusters is quite difficult. And making a controller for a physically based ship with point thruster approaches complexity of writin drone control software.

For example, at a minimum a physically based ship will need 18 thrusters to be controllable.
Lateral movement thrusters - 6 of them (forward, backward, left, right, up, down)
And rotational thrusters - 12 of them (4 per every rotational axis. Technically you can have 2 per axis, but controlling with 4 will be easier)
All of this has to be positioned carefully so the thrust vectors pass through center of mass for lateral movement, and t hat rotational axes also pass through center of mass for rotational thrusters.

Now, in player hands, this will require six analog axes to be controllable, and if you just give it a human player with no computerized aid and ask them to hover over a planet with no gravity, they'll just crash in a minute.

That's why space sim provide aids or ignore newtonian physics. The computer cancels unwanted torque when the player no longer wants to turn, maintains speed, brakes, etc.
---------
Anyway, this is a gamedev forum, so what are you trying to do, exactly?

 

The "but" there is hiding an order of magnitude of additional complexity. Quadcopters can work with 4 thrusters because they have a significant perpendicular force to work against, i.e. gravity. You don't have that in space.

Air resistance / drag is also worth consideration, as you don't have that in space, either.

Mathematically it's not going to be much harder to make space craft functional in a game or sim, but as neginfinity has already asked, how are players going to control that? You mentioned a home made controller, which I assume is your answer to this.

It might actually be a good use case for VR, for two reasons. First is that it's pretty standard for VR kits to come with a pair of controllers which offer 6DOF, and second is that looking around can be done by moving your head, rather than having to take up another set of manual inputs... assuming your audience is up for that.

 

It's not clear what the question is here, but a good question is what gameplay value will all this complexity provide? Is it going to feel better to steer? Is the player going to be able to take the context and its complexity and use it to take actions that master the game? Do you have a basic series of steps that you expect the player will go through - learn A, then use it to do B and C and be rewarded with D, etc?

Because the way you frame the question it's as if you're afraid that you will not please the space gods if your game is not complicated enough. The most successful space games generally have very simple flight models.

 

I have released two space games on Steam. One of the biggest challenges for a 3D space game is trying to design it to seem real enough for some players while still being fun for other players. Nearly every player has their own custom idea of how a space ship should fly. A lot of players will advocate for complete realism, but then argue for some arcade centric compromises to increase enjoyment.

For example, players want realistic sizes and distances, but unrealistic times and speeds. Players want sub-light space ships to move at 4-10 times the speed of light. That excessive speed is needed to make far away objects increase in visual size at a similar rate as large distant reference objects here on Earth. If I drive my car toward a building in real life, the building appears larger as I travel. In a completely realistic space simulation, it would take months to get a similar visual size increase from another planet in our solar system. Players need that feedback in seconds, not months.

Another issue for completely realistic 3D space games is max speed for turning. With complete realism, a player should be able to apply rotational force to continue increasing the spinning speed of the space craft to near infinite speed. In a completely realistic simulation, it should also require a lot of force to stop a rotation of a space craft. But players on Steam also want to use their mouse to instantly aim their space ship, which is the opposite of realistic turning.

I played a lot of Descent 1 & 2 and some Overload, so I am very familiar with the flight model for those games. I was ranked 11th for a time on the old Descent ladder back in the day. Those games let the player add the movement vectors, which allowed for a higher max speed. For example, I would fly forward, strafe, rotate, and aim the ship at the same time, and that would yield a higher top speed than simply flying forward. That was an effective way to gain an edge in a competitive match. Keep in mind those games were not applying physics forces to add force in a realistic simulation. The flight model for those games was designed to feel fun rather than be completely realistic. There was some lerping of the ship speed and ship rotations in those games to give the feeling of having some weight, but it was not a realistic physics simulation.

The main thing to remember when making a 3D space game is that the game designer needs to develop a fun experience for players. Decide how you want your space ships to handle in your game, and then fake all of the movement. Then get player feedback. Be prepared to hear a wide variety of feedback. Many players expect space ships to handle like a car, despite the fact that boats don't even handle like cars. Other players expect space ships to handle like planes, even though planes deal with lift and gravity forces.

 

A spontaneous thought:
Have a fairly realistic implementation for the physics but then give the player an assistant that translates the space ship controls into easier controls for the player (just like the board computer of modern jet fighters). Such an assistant can use "serious" algorithms from control theory like the proportional-integral-derivative (PID) controller to perform tasks like setting an accurate angle of the ship by using thrusters.

Someone has already implemented a PID in Unity: https://assetstore.unity.com/packages/add-ons/pid-control-224496

 

Actually you could definitely make a quadrocopter fly in ZeroG, as long as there's air. Because quadrocopter's blades SPIN, they provide everything that's necessary to turn around all 6 axes, and also provide forward/backward thrust.

However, writing a controller for that would be a royal pain in the backside, plus it will be flying belly-forward.

PID controller is one way to do it, however PID is not a silver bullet, basically this thing can oscillate and then your vehicle will crash.

Actually, steam had a nice little game called "Main Assembly" which allows you to experiment with physically based designs.

Spoiler

Whoever is interested in making a physical-based fliers should probably check that out.

 

are you making a simulation for NASA or a game for dorks to have fun with for a few hours?

If #2, forget the code and design the gameplay. Then figure out code to accomplish the gameplay. Not code first, then gameplay.

 

KSP does point thrusters and force based physics. Definitely worth checking out if you are interested in space navigation. They do use a PID type setup to control which thrusters fire based on user input. They also have a stabilisation system which basically uses a PID to achieve a target rotation.

This does some interesting things to gameplay. For example stopping is just as hard as starting. This means its pretty impractical to make major direction changes in space. (And even KSP cheats significantly here by allowing players to continuously aerobrake with no real penalty).

Rendezvous is quite challenging (although this is also due to orbital physics coming into play). Its a significant learned skill to be able to get two space craft to the same place and at the same velocity.

Finally humans suck at controlling spin. Kerball lets you hand this over to the computer with the SAS module. Without some sort of automatic stabilisation you are liable to simply make players vomit (especially in first person).

 

PID works fine for simple case scenarios. And assuming conditions doesn't dramatically changes. Which is fine in games.

Few years back I wanted have spaceship, which is controlled with 8 directional thrusters. No cheating involved with physics or artificial drag. PID wasn't able to manage controlling my craft reliably, when condition significantly changed. For example center of mass changed. Or had loss of some thrusters.

I have decided to use AI for training controlling spacecraft, to managed controlled spinning and desired orientation. My Neural Net written in C# was able to train in few doesn't of eseconds, how to control such craft.
I could use any arbitrary number of thrusters I wanted.

But doing the same with PIDs, would be not feasible for game purposes.

For OP use case, I would simply use physics, and ad low side drag factor, to alow vehicles to skid. Then side drag would automatically simulate the effect of stabilisation. Same for angular velocities.

This way controls can be ma gable. And AI or either player can handle such, withouth too much hastle. Consider drag as auto stabilisation system.