Thursday Report: Aligning The Stars
This week has been mostly bug fixes and finicky programming on item ids, so I’ll be going through some little pieces that I’ve neglected to mention from the last couple of weeks.
The star menu is coming along nicely, transforming from a concept to something that’s actually starting to function and be fun to use. The main challenge is navigation. Stars won’t be in such a rigid grid as, say, an inventory screen, so the game needs to know which star it should move to when the player pushes one of the four directions – up, down, left, right.
One possible solution was to assign each star up to four other stars that the player can move between. Which star the game should select if the player hits ‘up’ for example, would be predetermined and selected. This would ensure that things would feel as natural as possible, at least as attuned to my personal expectations. The first problem I immediately noted was that there could be well over 100 stars, so this would require a great deal of arduous work. I wouldn’t mind that, except the other, larger issue: flexibility. Unless I were to decide the entire constellation before hand, moving any star as an after-thought would mean not only having to re-input the directions for that star, but also all the stars around it. That could be exponentially time consuming.
So I wrote in something to select stars automatically, based on their relative location. The easy part is selected between two stars on a clean axis – if there’s a star to the right, and you push right, you want to select that star. But what if the closest star to the right (scanning left to right) is also way, way up high? Then you’d probably rather select the star further to the right, but on the same horizontal plane. What if there’s two stars, equally distanced to the right, and equally horizontally apart, only one is above, the other is below?
Which star would you expect to be selected when moving left to right?
Well, in that case you might not get the one you want, but certain numeric thresholds can help disregard stars that are tangentially too far away.
As a bit of added ‘juice’ I implemented a simple three-layer background parallax to give the scene a real sense of depth. This was done by simply layering three different PNG star sheet sprites and assigning them different distances. The game finds the distance between the two stars selected, and multiplies that distance by 0.2, 0.5, and so on. The effect is quite satisfying!
I’m also considering looking into giving each individual star it’s own depth, to make certain unlockable stars feel more or less distant. But that opens up a whole new can of worms that I’m reluctant to tackle at the moment – I think this works fine for now.
To the likely chagrin of some PC Gamers, I have decided that I will be developing The Garden Path with a gamepad first and foremost. I think this makes sense.
I recall when I first picked up Stardew Valley, which was first released on PC, I wanted nothing more than to kick back with a controller to play the game. I think it was a mistake that Stardew Valley was developed as a Mouse+Keyboard game first. Latter ports to console have a virtual mouse that’s clumsy at best, and weren’t well received.
That isn’t to say their aren’t benefits that come with a mouse. Everybody knows inventory menus are easy to navigate with a mouse, which is why I’m not striking out the possibility in the future, but it won’t be a priority.
My highly sophisticated control map reference.
Hollow Knight is still immensely popular on PC despite essentially requiring a gamepad. And while you would have to be some kind of masochist to attempt the game on a keyboard – the option is still there for those who aren’t fortunate enough to have a gamepad of their own. The key point here is where you center the game’s control philosophy, not what can and can’t be done. The Garden Path is about comfort, and controllers are a more comfortable way to play for many people.
So I’ve made a start by restructuring the character’s movement as analogue rather than digital. Now you can move in all 360 directions, and adapt your speed based on how far you push the stick. It feels good, and it feels how it’s meant to be played. Digital inputs, like WASD, can still be made, but they are translated back into analogue absolutes.
Zooming is now also done with the right analogue stick, allowing much smoother and controlled camera movement. The combination of the two makes everything feel much more slick.
I’m still figuring a way to have the player perform a walking animation when the stick is pushed just slightly, but things aren’t quite working there yet.
Godot put out a call for game devs to submit footage of their game for their 2019 showreel which will be releasing soon. This gave me an excuse to clean up a few things in the game before submitting. I finally got round to filling out the player character’s ‘side’ view – ie. giving the player their tools in their hands or on their back. Previously everything disappeared if the player turned.
I think the video does the game justice in it’s current state. I wanted the video to appeal to those unaware of the game, so while those who have been following me will have seen Augustus and Tellstone a hundred times, they’ve routinely been my most popular characters when shared on social media, so it makes sense to feature them.
I decided to feature a music piece I’d recently finished that I’m quite proud of, although I’m fairly certain all sounds are being replaced with a selected track for the whole showcase. I guess you never know.
So fingers crossed we get featured. I got an email back from Juan Linietsky, Godot’s lead developer, with some kind words – that meant a great deal. The last showreel has over 100k views, and interest in the engine is only growing, so hopefully that’s a good number of fresh eyes that might be interested in learning more.
And of course, I’m looking forward to learning about more games being made in Godot myself!