Some time ago someone observed that your ship’s turning radius appears to depend only on the frame rate. I had been playing SS only on my laptop, whose graphics chip is not terribly impressive (it’s a five-year-old Macbook Pro; I don’t recall exactly what it has); yesterday I wanted to try a fresh character for Diamond without losing my existing save, so I installed the game on my desktop. Now that doesn’t have a terribly impressive graphics card either (again, about five years old and I don’t remember exactly what it has) but it does have more GPU grunt than the laptop.
On my laptop, the ship turns very, very slowly, and I had always assumed that was intentional, and I recall complaining here some time ago about how it’s difficult to get out of Van Horn Harbor or Port Cecil without hitting the far side of the bay unless you cut the engines immediately after undocking. It also meant that "sail backward and plink" was the only viable combat strategy for things that can’t be snuck up on and killed in one hit.
On the desktop, the ship turns on a dime. I can go to forward speed ‘2’ immediately after undocking at Van Horn and still make the turn without running aground. I haven’t gotten good at it yet, but I can also see that combat will be much easier and more sophisticated strategies will be viable. It’s such a dramatic difference that I suspect poor frame rate may be the #1 cause of people having trouble with the new combat. (I note that several people have said they can’t turn fast enough to keep up with the zee monsters.)
This is a serious, serious bug. The simulation clock should not depend in any way on the frame rate, and your ship’s performance in particular should depend only on in-universe characteristics of the ship.
N.B. Van Horn should still be changed so you undock facing open water. ;)
I’m not a programmer, but I can’t see how turning radius can not be based on frame rate, after all, it’s only when the screen refreshes that the graphic can be updated, and while it’s irritating when the game goes down to minimum frame rate and your choices are reduced to forwards, backwards, and prayer. I think that depending on the ship, the turning radius should certainly be reduced (or in the case of some, increased), to reflect the nature of the ship. Some of the truly huge tankers on the lanes today have a turning radius of two miles, but most of the fast clippers can spin it in around two lengths of the boat when not moving at flank speed. I like the idea that combat vessels should have some mobility to them (not the dread, that’s a weapons platform, maybe fit some more gun options on it instead), whereas the steamer and the cruiser should be straight liners at the best of times.
And Van Horn needs to stay how it is, how else do you get people to not want to go there…
How about measuring how much time passes between screen refreshes, and adjusting based on that. The game obviously already does that for movement speed - otherwise computers with worse turn rate would also have slower forward movement, and there would be no “can’t make a turn because there’s no room for it” difficulties. Everything would just be slower.
Extrapolating for unidirectional movement is a different beast. If the zee were littered with, say, pass-gates that required you to stop and wait for them to open, people with low framerates would suffer then as well. The problem isn’t that the speed of turning is slower with low framerates, it’s that low framerates = low responsiveness, which is not something you can fix with extrapolation.
Slowing down the game’s entire internal clock, I don’t know the technical feasibility of that, but regardless, that’s different from the usual method of preserving unidirectional speed across different framerates.
Fixing this should be quite simple, technically. Indeed, I’m pretty sure the game is already using the correct algorithm for non-player ships, zee-beasts, and linear motion. There is, or should be, a simulation clock that advances at a fixed rate of (let’s say) 60 ticks per realtime second. Everything that moves has its position and orientation updated every time that clock ticks. Turning rates are defined as so many degrees per simulation tick, speeds are defined as so many map (not screen) pixels per simulation tick, and so on.
Independently of that clock, the screen refreshes at whatever rate the graphics card can keep up. Suppose that’s only 20 frames per second, then only every third simulation update will make it to the screen; that’s fine. (It is probably a good idea for the refresh rate to always be a whole number of simulation ticks; that will make any jerkiness less obvious.)
Oh, and for responsiveness the important thing is to make sure the game polls control state every simulation tick. That shouldn’t be a problem; there is far less variation in input hardware and driver capabilities. edited by zwol on 1/11/2015
It’s exactly the same beast with different equations. You probably don’t even have to figure them out yourself, it’s been done many times before.
When the difference is between "turns very, very slowly" and "turns on a dime" (presumably both while telling the game to turn as much as possible, and at the same speed otherwise), that’s not a matter of responsiveness.
What kind of framerates are we talking about, anyway? 60 fps on the top end and 10 fps on the low end? 50/20? 100/1?
(because, yes, there will "probably" be responsiveness problems below 20 fps … disirregardless of how the ship turns)
[quote]
Slowing down the game’s entire internal clock, I don’t know the technical feasibility of that, but regardless, that’s different from the usual method of preserving unidirectional speed across different framerates.[/quote]
How did you even get that from what I wrote? That was a "I don’t see symptoms of X, therefore I am ruling out X" …
ETA: zwol appears to know exactly what I mean edited by xKiv on 1/11/2015
I was skeptical that a bug this big would still exist, but sure enough if I load up Sunless Sea on my old laptop my turning radius just about doubles. Yikes!
What is my turning radius actually supposed to be? Using my newer laptop (2014 13" MBP, SS V0.6.4.1810, Mac OS X 10.9.5.) and the steamer with default engines, if I go directly east out of London at full cruising speed and do a hard port turn just as I pass the red light, then by the time I’m headed due west I’ll be about one boat width north of the last straight section of the dock. How big a turn are others making? If I switch to the cutter I get almost the exact same radius, and the corvette actually has a slightly smaller radius, presumably because it’s going ever so slightly slower. Is there supposed to be a bigger difference between different ships? It’s very hard to notice any difference in speed and handling in normal play.
Unity3D actually has two clocks you can use for simulation - one dependent on frame refreshes and one not. Assuming that FBG are simply using the former, to fix this bug they just need to switch to the latter.
However, not having seen the source code (obviously), they may already be using the latter and this is caused by something else, or switching to the latter may cause other problems, etc.
I’d like to confirm that turning radius is based on frame rate, if I have background programs running or the few times my game has glitched with the new storm effects my turn rate dropped hard.
And the solution to make it frame rate independendant in unity c# is turnRate = turnSpeed * Time.deltaTime
That is an incomplete solution, a true solution would be a simple implementation of a PID algorithm, with keystrokes as input.
The PID is a control program used on real ships that takes into account not only current error but past rates of error and rate of change as well, in other words, an integral of the past error and the derivative. It sounds scarier than it is, implementing it would not take much time, although i’m not familiar with the unity engine, or whatever they are using to write SS.
Well… i mean, if you want to let players control their ships better or not.
I mean, I guess you could just be satisfied with making the turning rate independent of frame rate. Yea, that would be easier. edited by nameless on 1/14/2015
Edit: Also, it would somewhat defeat the purpose of the game, because then the player couldn’t control the ship. But maybe you could use it on AI ships or something? edited by nameless on 1/14/2015
[color=#3399CC]Hey folks! Thanks for all the feedback regarding this issue. The short (and positive) answer is that this was a problem, some of code was Time based some was not which meant that your Turn speed would vary depending on frame rate. However there is now a fix that will be released with the next update.[/color]
I’ve been down the PID route before. It’s a great idea in theory, but it can be very hard to translate into something that’s fun! It depends on the context, of course. We also found it very hard from a pure implementation point of view as well.
I am actually quite thrilled with the responsiveness and openness of the development team in this. Bugs and system issues will always be an issue in any new project but so far Failbetter has dealt with these issues beautifully and they’ve really made me a believer in the company.
I am actually quite thrilled with the responsiveness and openness of the development team in this. Bugs and system issues will always be an issue in any new project but so far Failbetter has dealt with these issues beautifully and they’ve really made me a believer in the company.
Thanks again, fellows.[/quote]
Yeah, this was one I was worried would be too difficult to change, since it’s been that way since back in early early access. Very very happy as this should make the game playable again for me without constantly suiciding my captain.
[li]Oh thank heavens, I thought my brother was just magically better at this game than I was, I’ve been being beaten up by jellyfish while he’s been murdering pirates all over the place, and he’s at half the number of captains I have - this update can’t come fast enough, I’m looking forward to being able to actually fight!
