I say part one, because for now I’m wrapping up Navigation to work on other issues – namely the one’s thrown up by working on navigation, as you’ll see when you watch the attached video (yes Cornflakes_91, I finally produced a video 😉 ) I’ve managed to get some time (about 3 hours over the past two weeks) to move this feature ahead a little.
As it stands, the navigation (being plotting a course from A ->B via C, D and E) is working with one bug, which has a known cause which will be addressed later when the games galactic database is tweaked. It’s certainly adequate enough to allow navigation across the galaxy, which was the overall aim 🙂
The video shows the course plotting in action for the in-game g-drive, which (if you recall from this post) has to weave its way between gravity wells, the distance it can travel is determined by its power and efficiency. It is range limited, so to travel across the galaxy it has to go ‘stepping-stones’ style, from star to star, each star within range of the drive itself.
I didn’t want to punish the player by forcing them to keep star hopping, popping up the galactic map, choose the next star, hop again ad nauseum just to travel from one side to the other. You can simply pick any star you like, and the nav-com will plot a route, from star to star, all the way to your destination – taking into account your current g-drives capabilities and range.
It will also do the same for Wormhole drives, jumping as far as possible before requiring a recharge before the next hop. But right now, Wormholes let me hop anywhere for dev purposes 😉
Once you’re happy with your destination and route, simply engage the auto-pilot, sit back, and relax…
The issues are pretty clear – lots of scene flicking, which is to do with orientation inconsistencies, and the ‘moving through space streaks’ pretty much pack up half way through the journey.
Other visual things I’m not concerned about for now – that’s polish for later on.
Part Two will allow you to manually plot your own course, or edit the one created by Nav-com.
Archievement unlocked: annoy an indie game developer into submission xD
LOL – you only get that once mind… It’s a unique achievement 😉
managed it once, can do it again 😛
the stutters/lags when switching scenes is not that awful as you made it sound like.
i’d also like to point out that 3 minutes to cross the whole game universe might be a bit too quick, but i assume that this is because you used a cheaty proof of concept drive and not something balanced?
Never sir! 🙂
These are the ‘improved’ stutters and lags 😉 I did my best to iron them out enough to show WIP at least.
As for the transit time, you’re right. It’s a Cheaty Drive 🙂 Every single transition (leaving local space, leaving planetary space, leaving stellar space, interstellar transit, entering stellar space, etc) is set to something like 10 seconds I think… just for dev purposes.
The final experience will depend on your drive system, available power, state of repair, etc. And of course, a hefty amount of game-play balancing…
is that transition time always that “hardcoded” aka precomputed from your movement speed or will you do it “properly” aka deriving the scene transitions from your position?
because precomputing transition times seems to me like its incompatible with free flight drives like your c+ drive.
*scratches head*
Aha, a good question… these transition times are only for the pre-computed ‘course’ the autopilot is following. You will be able to turn the AP off/on at any point during your journey – it will drop you back to stationary, and then resume the course all on its lonesome. Or you could take over and assume free-flight. Your choice.
Free flight is truly free, and both the AP and freeflight are (will be) restricted only by the drive system, power et al.
Transitions will then occur when either a) I leave a scene or b) when I reach the minimum ‘speed’ to move about a higher scene.
ie. in local space, I accelerate until I’m moving so fast I start to noticably move in planetary space, and so on.
This is still WIP at any rate, but the overall goal will always be to allow free movement at all times.
And darn this stupid WordPress/theme plugin for comments… this layout is ridiculous! 🙂
it strikes me as unelegant to have 2 systems which do the same
why not always use position/speed based transitions?
*scratches head*
we could just stop to “reply” to each other 🙂
Darned good idea!
It’s one system under the hood, with functionality layered on top. I’m no fan of redundant code or duplication of effort. The NPC’s will also have autopilots and be given preordained courses. What I want is a sat-nav like system. But, you don’t have to use it as the player if you don’t want to.
on a related note: will there be a “mobile” local scene for interactions between ships at high speeds?
for example 2 ships flying in close formation at ftl speeds, can they see/interact with each other?
You know, I’d love to have this in. As it stands, you could see another ship in the same planetary ‘sector’ you are in, but only as a remote dot. You could still fire at it though with lasers 🙂 (gameplay balancing pending of course 😉 )
The concept of wingmen means you should see them in formation even in FTL. However I’d not considered the implications yet. I’ll need to don the old thinking cap 😉 so thanks for pointing that out! I’ll actually add this to the public Trello board…
Dont forget the lemons for the thinking cap 😀
after a bit more thinking a question about ftl “local” bubbles popped up:
Would it even be noticeable?
With ftl speeds smallest course deviations would lead to very fast relative movement, so it would be almost impossible to stay in the bubble with manual flight.
So any ftl close flight would already have to be on autopilot, and then you can start to pull tricks which you couldnt do with manual flight…
Something would be workable – ie. your wing would all have synchronised autopilots allowing close quarters FTL flight.
I’m more intrigued in FTL interedictions and/or combat though – the prospect of an attack during FTL and the potential consequences of being spread across several parsecs has a certain appeal… 🙂
But for separations of several parsecs you dont need FTL moving local bubbles, though.
You can use your normal interplanetar/interstellar scene and other known ships are bracketed dots and dont have to be handled as full objects
LOL – no, I meant the result of a potential FTL conflict – the debris would end up being smeared across quite a large volume of space 🙂
But, I know what you mean. That’s precisely how the current system will handle it – you’d see another ship ‘in-system’ travelling in FTL as nothing more than a dot on the scanner. You will then be able to target it and follow/chase it down if you wish.
I’ll pin this chat to the Trello card for this bit of gameplay/work – and when I get to it, I’ll see what works/doesn’t work and so on.
Well, for the debris you dont need a mobile local bubble either, if the debris drifts with 2km/s or is static doesnt make a difference