Yeah, it’s newtonian too. There are automatics in place that restrict the rotation rate that the player can command, and the ship also automaticaly counter-fires thrusters to cancel rotation once the player is no longer commanding it.
I restricted myself to depicting the player WASD+QE commands because that was the source of confusion about translation. It would take more work to depict the counter-firing and the restrictions on rotation.
So if the display was totally accurate, the thrusters would not be firing once the maximum rotation rate was achieved, and once the player stopped commanding rotation, the opposite thrusters would light up to indicate the counter-firing by the ship.
You can see some of the newtonian rotation stuff at about the 2:15 mark in the Intercepts video when I “dock” with the cruiser by slamming into it. My ship goes spinning away from the impact at a much higher rotation rate than I could command. You don’t see the counter-firing, but the ship is damping the rotation as quickly as it can because I wasn’t commanding rotation.
Yes I understand that. 'Relative-velocity-ometer was a bad suggestion.
The thing is it’s an indicator rather than a setting - You don’t set your ‘ideal’ speed and then wait for your ship to accelerate to that speed. The bar shows your current FOMPS at any given time. Or have I misunderstood?
Yes that was perfectly clear, at least it was to me.
Could you explain a little bit about your implementation of manoeuvrability inside a ribbon/tunnel?
At 8:45 you say you attempted a hard left but the little line that indicates the facing of the ship did not change. However, at 16:00 you appear to rotate the ship reasonably easily, and then accelerate towards the edge of the ribbon very slightly, at which point you are pulled back towards the middle?
Why were you unable to navigate the corner at 8:45?
In the game there should certainly be a line or something indicating the current “setting”. So that the pilot can know what he entered into it without having to wait for the ship to reach that point.
The FOMPS value translates to an actual velocity depending on the current context. A ship that has a FOMPS of 0.5 and that is sitting next to the space station is moving at 1.5km/s. Teleport that ship instantaneously into interplanetary space and it will be moving at 0.05AU/s. There is no acceleration from one speed to the other; the change is instantaneous.
[quote=“hrobertson, post:43, topic:709”]
At 8:45 you say you attempted a hard left but the little line that indicates the facing of the ship did not change. However, at 16:00 you appear to rotate the ship reasonably easily, and then accelerate towards the edge of the ribbon very slightly, at which point you are pulled back towards the middle?[/quote]
At 8:45 I tried to strafe to stay in the ribbon because it would be faster than turning and then moving forward.
At 16:00, I turned the ship and thrust forwards, then stopped thrusting. The ribbon pushed me back towards the center.
Because of the aggressive way that the ribbon pushes ships along the centerline of the ribbon. Tuning is required if players are going to take a greater role in flying ribbons.
There is no wait. Press a key to instantly change the FOMPS to instantly change the ship’s speed. Each key press changes the FOMPS only a little bit so you are limited in how quickly you can change the FOMPS over time.
If I put in a key that just set the FOMPS to 1.0, the dial would instantly jump to 100%, instantly getting the ship moving at its maximum possible speed. That’s just the way the system works. Such a key would never be implemented because gameplay would suffer.
I started down that path in 2009 as evidenced by the layered mountain surfaces on all the planets. I was starting work on a mining system. I decided that even a 2D game would end up involving inordinate amounts of time fooling around with fiddling little issues in graphics and artwork and I have no interest in that stuff. If I hit the lottery, I’ll hire folks to build my vision, and I’d quite likely stick to the 2D version. I can get more gameplay per dollar out of 2D than I ever could in 3D.
Thanks for the clarification. Yes I’d deffinitely like to see player skill having an impact on jumps at the limits of a drives capability.
But as you show in the Basics video at 13:25, the rate of change of FOMPS varies between ships.
I think what @Lomsor is suggesting is the ability to set a target FOMPS and your ship would increase it’s FOMPS to that value at the appropriate rate, as if the W key was being held.
Just a convenience ‘autopilotish’ feature. Please correct me if I’m wrong @Lomsor .
[quote=“hrobertson, post:47, topic:709”]
I think what Lucas is suggesting is the ability to set a target FOMPS and your ship would increase it’s FOMPS to that value at the appropriate rate, as if the W key was being held.[/quote]
I didn’t get that impression from @Lomsor’s comments , but such a thing could be added. I think that’s a first step towards an autopilot: get me on this heading and FOMPS. If you’re just after a player convenience, I’d add a double-tap-to-lock feature for the WS+QE keys.
That’s the sort of thing I just didn’t want to get started on. The ship shape is symmetrical right now, so it works whether you’re zipping along in space or ‘landing’ on a planet. I’d have gone with spheres if players didn’t need directions for a WASD layout. A touch screen implementation could certainly go with spheres that accelerate in a touched direction.
Thanks for the qualified offer, but the textures are just the tip of the iceberg.
The student is only wrong when there’s a test. I’m curious to know where I presented things such that you didn’t get the right impression. The first time it was because I chose the word “power” as my metaphor. I’d like to know where you saw a delay or a waiting process. If this presentation isn’t making sense to you, then it likely doesn’t make sense to some chunk of the rest of the viewers.
I had no problem with the word power. But the lack of visibility what the ship was actually doing. We just saw the reactioms to your keypressses. Not the keypresses themselves. With a software that I’m umfamilliar with it can get difficult to analyze what the user actually did to cause the visible reaction.
When the power bar increased and decreased so fluidly. I assumed you didn’t controll it directly.
I imagine it wouldn’t be difficult to add the qweasd letters in one of the corners and have them light up individually when pressed.
Just an idea if you can be bothered and if you plan to do more videos.
Would that be superior to the Newtonian video that I linked above? I would think that the fake little thrusters would be a better indication of what’s going on. You can focus on the ship instead of dividing your attention between ship and keyboard indicators.
For whatever it’s worth, I modified the prototype to show the ship’s true ‘firing of thrusters’ - the lack of which inspired @Lomsor to observe that turning was not newtonian. After the change, when you press A or D to turn the ship, the turning thrusters fire. If you continue to hold down the key, the turning thrusters continue to fire, but only until you reach the ship’s permitted turn rate. Then they stop firing, but the ship continues to turn because of the newtonian physics. When you release the key, the ship automatically counterfires thrusters to cancel the rotation.
It’s pretty weird after so many years of games where you maintain thrust to maintain a turn, but the prototype’s behavior is correct from a newtonian standpoint. I suppose that if I took off the spin limit, players would find it more intuitive, but they’d do stupid things like spin the ship up to some silly speed and smack into another ship with it, knocking it into the next county. I’d prefer to just take off the ‘thrusters’ and go back to a display where the ship turns so long as you command a turn. In my universe, there is no thruster. It is not the thruster that fires, it is only yourself.
The ship will also continuously counterfire thrusters if you smack into something and go spinning away like a top.
I also went flying around to visit some NPC ships and bumped them with my little Corvette. Naturally, they counterfired to cancel any spin that I could impart in them - which wasn’t much.
I really enjoyed the attention to detail these demonstrations show. This goes a long way of showing us a graphic image of maneuvering in space. While I disagree with some fundamental limitations applied to combat maneuver I feel this is a very good step in balancing some of the issues with real Newtonian flight and gameplay. Explanation was with a easy to listen to delivery. Only a few things were left out as seen by the confusion in the discussion about absence of RCS. I am glad you mentioned the restrictive movement mechanics but feel more time could have been illuminating why this is seen as a requirement, perhaps in the accompanying introduction paragraph. I especially feel that the Jump Navigation of the demonstration was well made. I did only have a few small disagreements but felt over-all this was a good way of visualizing the requirements for a good jump. Kudos JB47394 and team. Good to see some of the discussion on the old forums is reaping some reward.
I am perplexed as it appears velocity changes are being applied in a out of proportion manner in comparison to the direction the demonstration craft is pointed. Normally a ships major acceleration is applied through one axis of a ship (through the nose) only with some minor accelerations being applied through other directions for RCS. It appeared to me that a lot of maneuvering was being performed independent of the ships nose. Perhaps this is not detailed in the demonstration. I don’t much care for godly RCS maneuvers.
I know that this demonstration does not seek to answer why certain game mechanics have been used as this has been discussed some years ago. I feel that the reintroduction of some of the game mechanics might be of use for new forum folks. This of course will spark off a debate on Newtonian physics which goes way beyond some of the discussions in this thread but it is good to refresh peoples memories. I initially was tempted to dump on JB’ because of lack of proper Newtonian mechanics (Note EVERYTHING is in a orbit) but I do remember those discussions so long ago and why the gameplay required it. I don’t fully agree with the limits as posted in the demo but it is valid.
I do love much of the jump demonstration and was quite thrilled to see it. The demonstration gives us a feel for what the requirements of basic interstellar navigation are and shows a fairly well thought through game mechanic. This is relatively close to what I envision with only a few discrepancies. I listed those below as I feel this needs expansion with good, reasoned, arguments.
The first problem is an easy one. Client/Server communications. I brought this up some years ago but never did get a good answer. This problem refers to ‘what is a jump?’. is it a loading screen a mini-game or just a faster method of translating through space? If data from one solar systems is being unloaded and another one is being loaded, it’s a loading screen. this begs the question, can one dump out of a jump translation early? How does effect effect data loaded in anticipation of the destination hat was assumed?
The biggest disagreement I have is for the concept of “velocity” this is a weak mechanic at best and is subject to all sorts of questions such as why? what problem does this game mechanic solve? Why can’t I sit still on the periphery of a star system with “zero” velocity. The other question comes to mind. by what reference frame is this “velocity”? It seems like a weak mechanic with no other reason than the spaceship must flee something to get someplace. I assume some game mechanic awaits to be explained.
I find the depth of the jump explanation to be pretty good otherwise. My preference would be as alluded to in the other demos, the requirement to get away from gravity interference as the only requirement.
Not describes so much as passed over is the notion of “fuel” in the jump navigation. This might be because the notion of use of fuel might be contested by us forum visitors. I hope that topic can be revisited again.
My personal feeling is that this is one of the better attempts at getting a handle on what we forum posters think might be a good mechanic for navigating about in the black depths of space in a sausage shaped spaceships.
Which restrictions are you referring to? A limit on maximum speeds? The proximity restrictions? Either of those would take an hour long video to explain - best demonstrated using software that shows how things would work without the restrictions.
On rockets with strict energy budgets that take months to complete an interplanetary trip, yes, that’s the way it works. On spaceships with unlimited energy budgets where an interplanetary trip takes less time than finishing a cup of tea, asymmetrical RCS makes no sense.
That said, I believe that asymmetrical RCS will be part of Infinity:Battlescape gameplay. Because… rockets.
Where have I violated or left out newtonian mechanics?
You can, barring acceleration due to gravity (those pesky newtonian mechanics)
Your velocity is always relative to something else. So you have many velocities. Which one or ones should be displayed to you is up to you.
It was covered as it was because I had three points to make about it:
It is a limited resource on a ship
It is consumed during a jump
It is obtained for free at a low rate or obtained faster by flying through a star or planet’s atmosphere
In the same way, ships are lozenges because I only needed them to be solid objects with an orientation.
Just a quick question @JB47394, why is the ship not accelerating and your “speed” remains constant when the engine is on? That’s not Newtonian…
/edit
Watching your yet unannounced video, I’m guessing that there is something wrong with the engine indicator. You apply thrust only when the button is pressed yet the engine indicator seems to be on (what you call power)… Only way this makes sense is if that “engine power” setting is really just a velocity indicator relative to nothing, then it is Newtonian.
Yes, both of those could have had a single paragraph encapsulating why the restrictions were seen as a good thing. Not a demonstration but in your introductory paragraph. it’s one of your primary concerns in the demo. It might help new forum visitors to know why this mechanic is being used as I said in my post
On spaceships with unlimited energy budgets where an interplanetary trip takes less time than finishing a cup of tea, asymmetrical RCS makes no sense.
Energy limitations have nothing to do with RCS (Reaction Control Systems for those who wondered, They turn your ship). RCS is important only in that you cannot place the power of the main rockets just anywhere you like without thoughts of tearing the ship in half as well as the pilot. It stands to reason then that a RCS is weaker precisely to NOT tear ships in half when you roll, pitch or yaw. I describe that issue some years ago. It’s a structural limit. Besides we KNOW the models proposed in the game use asymmetrical maneuver rockets.
I assume then that this was just an artifact of the simulation and not a proposed maneuver system?
Where have I violated or left out newtonian mechanics?
For instance, to get somewhere quicker, change orbits. going faster only causes you to enter an escape orbit. This is strict, Newtonian physics.
This was not a complaint as I said game play required interpretation of Newtonian physics to mesh with player expectations. You have a semi-Newtonian model which to me, for the purpose of the demo and game, is valid.
My opinion is that most other criticism is likely going to be levied at lack of understanding of the state of motion on your model, not a disagreement with the model.
Your velocity is always relative to something else. So you have many velocities. Which one or ones should be displayed to you is up to you.
Actually I am speaking specifically to what appears an input velocity required to jump to another star system. The indications on your demo video is that an input velocity was required to calculate and actually move through space. I mentioned ‘reference frame’ in the same paragraph so I think I know what relative is… My question is, do we need an input velocity for interstellar flight? If so, what is the reference frame?
In the same way, ships are lozenges because I only needed them to be solid objects with an orientation.
This is actually a joke in reference to my er, sausage shaped spaceship preferences both on the forums and on IRC and should not be construed as a critique of your choice of simulation models.
That would look great. It would probably require a side view of the ships when landing on the surface.