How strange. Most feedback i have gotten has told me that the sensitivity of the rotation is to slow/sluggish. Were you perhaps playing with timewarp without being aware of it? If you press T the time goes 5x faster but its harder to manuever like that. ( The current timewarp speed is displayed in the bottom right corner )
There is a VOD of another jam contributator playing the game https://www.twitch.tv/videos/1677028317?t=00h43m30s
If the issue was not time warp, would mind having a quick peek at the vod and tell me if the experience looked simular or totally different to your? I would love to know if there is maybe a bug causing your experience.
Thanks in advance!
I watched the video; this is not like what I experienced: He is able to stabilize the rocket more easily.
After some investigation, I cannot guarantee that the problem is not related to my hardware (which is not very powerful). I tried it a few times and every time the experience was slightly different; sometimes better, sometimes worse. Perhaps it takes to long to process the key presses, which are than interpreted incorrectly as a consequence.
I tried playing with and without timewarp on; it made no difference. I could easily spin the rocket in both modes unintentionally .
In my opinion, it is not a bug in your game; more likely that the system dependent input latency plays an important role here. Perhaps a way for the user to adjust the acceleration combined with limiting the maximum rotation speed as well as a different ease-in ease-out design would prevent this problem. This could also solve the complaints about being to sluggish.
I had a similar problem with my last Godot game: I got a lot of complaints that my main character would be way to slow. Partly, this was intentionally and by design. But after watching the streamer's footage, I realized that my game behaved quite sluggish on his system (even though his setup was way more powerful than mine).
If I may ask: On which operating system did you run your Chromium? Because for the testing, I was using the Manjaro flavored Chromium build under Manjaro/Archlinux. I had this issue with my last game that on some operating systems, it would run with Chromium and on others (with the identical Chromium version) it would not.
Thanks again for taking your time to test.
I had only been trying on Windows until now. I have manjaro on a different drive so i booted it up and tried both Chromium 108 and Firefox 107. Firefox was laggy as all hell for me but Chromium worked more or less than expected. Why would they perform differently i dont understand but ill see if i can upload a windows and linux executable tommorow. Thanks again!
Regarding the performance, it's way better on the desktop version as we actually get more than one CPU thread which matters in this game. If @moralywrong hasn't uploaded desktop builds when I get off work I will.
I personally run and developed everything using EndeavorOS (Arch basically) and it ran fine for me using latest Firefox Developer Edition (can't recall exact version). Though I have a pretty beefy computer. I will try ungoogled chromium as well after work out of interest.
Thank you very much for your many efforts. Now I am more than tempted to check out Endeavor OS, because the desktop build refused to start at all... Seems to be an issue with the Manjaro flavored mono build (unfortunately not the first time I encounter this)... It still could be the old hardware though; but if Manjaro refuses to open it on my Threadripper machine...
For completeness (I am no C#/Mono Expert), here is the error log:
Unhandled Exception:
System.TypeInitializationException: The type initializer for 'System.Random' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Sys' threw an exception. ---> System.DllNotFoundException: System.Native assembly:<unknown assembly> type:<unknown type> member:(null)
at (wrapper managed-to-native) Interop+Sys.LChflagsCanSetHiddenFlag()
at Interop+Sys..cctor () [0x00000] in <02071a39c8a34187bdd1f58e4be38764>:0 --- End of inner exception stack trace ---
at Interop.GetRandomBytes (System.Byte* buffer, System.Int32 length) [0x00000] in <02071a39c8a34187bdd1f58e4be38764>:0 at System.Random.GenerateGlobalSeed () [0x00000] in <02071a39c8a34187bdd1f58e4be38764>:0 at System.Random..cctor () [0x00000] in <02071a39c8a34187bdd1f58e4be38764>:0 --- End of inner exception stack trace ---
at SpaceExplorer.Scripts.Actor.Player..ctor () [0x00036] in <b6760ce72c3f4c88bbc4c0268582e59c>:0
Regarding Manjaro vs EndeavorOS. Everyone will run the distro of their preference, but I can say I personally switched from Manjaro to EndeavorOS and I am not looking back. ;) So many fewer issues with all AUR packages. Kind of miss pamac, which while is possible to install is not really recommended. But `paru` works suprisingly well for all repository/AUR packages. :) Just snap/flatpak it doesn't manage like pamac can, but I rarely use them so it's fine.
Thank you very much for the new build. Now it runs natively, no problem. The input lag is way better now!
The game is now actually playable on my weak old laptop :-)
Good to hear that you have success with EndeavorOS and AUR: Good AUR support is vital for me, since a lot of the software I use is built directly from AUR. I use some Flatpacks (e.g. OBS), because Manjaro Community Editions did not work or had missing features, so will be interesting to see if I would even need them with EndeavorOS... Definitely will try it in a VM before committing to it, but EndeavorOS might also be a good alternative for me. I am really tired of having to reinstall software after almost each Manjaro Update and not always succeeding in doing so...