Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(1 edit)

I think this game has a lot of potential. I like that you have realistic navigation in space with conservation of momentum and gravity. As I played a lot of "Kerbal Space Program" I am probably a bit more skilled as the average gamer when it comes to navigation in space - and still I had problems controlling my flight. My main problem is that, when entering a system, the planet, moon etc. are so close together that it is very hard to swing into a stable orbit without colliding with a suddenly appearing moon. Then I bounce and its hard to quickly adapt to the new flight direction and figure out how to thrust to get into a stable orbit again.

Things that might mitigate this issues:

- Move moons and sattelites farther away from the planet to reduce the probability of random collisions

- Do not bounce of objects but just continue on the trajectory, taking damage while "inside" an object. That would allow to adjust slowly an incorrect orbit, but would not reset it completely

- Show the current flight trajectory on the minimap (as in Kerbal)

Thanks for trying Bling Hustle.  You certainly aren't alone in your navigation struggles.  I'm always looking for ways to make it easier on new players.  That said:
1. Moons/satellites have a very limited window for stable orbits, outside of which they will get gradually pulled out of their planetary orbits into a solar orbit.  If I want a bigger window for placing moons, then the planets have to be proportionally farther from the sun, and the whole system gets very sparse very quickly.
2.  I just really don't want ships to fly through planets.  It takes too much away from the feeling of physical realism.
3.   This is my preferred solution by far.  I definitely WANT to do that.  I'm good enough at physics to program my game engine to determine where things will be 1 frame in the future with good enough accuracy to make the world work, but AFAIK there isn't a general solution to predicting the positions of N gravitating bodies at arbitrary points in the future.  The best I could do is simulate the universe for maybe 12,000 frames (about 3 minutes), and then plot the player's future positions based on that.  This would need to be done every frame, and thus increase the computing requirements by a factor of 12,000.  Also, the projected players position wouldn't be very meaningful, because the all the other things are also in motion, so the projected path wouldn't be in the right place relative to those other things.  Anyways, it's hard, and I don't know how to do it, but if I did know how to do it, I absolutely would do it.

For the prediction of the trajectory you could do this:

The path of all your gravitational bodies should be deterministic. i.e. you could calculate them in advance for N frames and put their positions into a ring buffer. On every frame you then pull the positions out of this buffer and calculate the positions N frames into the future. In this way you only need additional memory but no additional CPU cycles.

For the player trajectory you can basically do the same thing as long as the thruster is not used. If the thruster is used you have to invalidate the ring buffer. As soon as the thruster is turned off you start calculating the trajectory again: maybe add 100 future frames on every frame, that should be possible as you only have to calculate it for one body (the player ship) and you can take all the gravitational information from the precomuted buffer for all celestial bodies.

(1 edit)

That sounds very viable, although it's going to be very frustrating to implement in javascript, which doesn't copy objects without a fight.  I like the fact that it's calculating the trajectory gradually, I actually think that could be a fun in-game upgrade factor.  Maybe your ship computer starts out being able to project 2 future frames per real frame, but you could upgrade that ratio in-game to much more so that you can more quickly see your projected trajectory.  This has the added benefit of gating a potential performance bottleneck behind optional upgrades, so even if I can't afford 100 frames / frame of prediction on some devices, it's only an issue if a user on a slow device chooses to heavily upgrade that particular stat.