Skip to main content

Browse GamesGame JamsUpload GameDeveloper LogsCommunity
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
moralywrong2 years ago

Hi. Thanks for trying it! 

Regarding the trajcetories, the sourcecode is written in C# but if you want to take a look at it you can find it here https://github.com/Heartstop/SpaceExplorer/blob/master/Scripts/Actor/Trajectory.cs

TLDR is that we implemented gravity force and used the same code to predict  were the ship was going to be in the future :)



One of the things that we failed to do was telegraph to the player that after their first and second upgrade, they can zoom out more. It sounds from your difficulties that maybe you tried to aim for the Icons instead of the planets? Correct me if im wrong :) 

Thanks for letting us know that the game didnt load for you... I am on Chromium 108 and it works for me but maybe its safer to upload a executable to be sure that the game can be played.

Thank again!

Reply
dsacre2 years ago

Thank you for linking the source code. It is very interesting how you did that!

If you mean by icons the "home" icon or "brown dot" for the brown planet, than yes. But neither that nor the zoom was necessarily my problem: Even with the shortest press of the "A" or "D" button, the ship started to spin uncontrollable. Counteracting this with pressing the opposite button did not help, because one would overshoot.

Reply
moralywrong2 years ago (2 edits)

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!

Reply
dsacre2 years ago

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.

Reply
moralywrong2 years ago

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!

Reply
philipborg2 years ago (1 edit)

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.

Reply
dsacre2 years ago (1 edit)

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

Reply
philipborg2 years ago

I made a new build that was built for, from and by Linux. :) Maybe works better as I used what I think may be a more appropriate export configuration.

Reply
philipborg2 years ago

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.

Reply
dsacre2 years ago(+1)

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...

Reply
AboutFAQBlogContact us
Copyright © 2025 itch corp · Directory · Terms · Privacy · Cookies