Alpha Report: Nothing Remains The Same
Development progress on The Garden Path has been steady since our last report. As I close in on finalizing the key highlighted points from testing so far, I’ve found some time to begin rolling in some new features and content that’s been in the oven.
The two most important points have been interaction and performance. As we discussed last week, I’ve rebuilt the world loading system to allow assets to smoothly load in and load out as the player moves through the map, rather than the hard loading from before that was causing major stuttering.
The game actually now becomes smoother the longer it is played, as assets that have already been loaded into the game’s memory can simply be re-used.
This is fine for now, but could be a point of failure as more and more assets get introduced to the game. This is not only because it would take longer for the player to process all the different assets, but also because there may come a point where too many assets are in memory than what’s reasonable.
The solution for the former would be simple – elongate the initial loading screen, loading in all the assets before the player begins playing the game. It’s a trade-off, some players would prefer to jump into the game as quickly as possible, and suffer a small bit of stutter as they start off. Others might be glad to be a little more patient, and have the heavy-loading out of sight and out of mind. The answer is probably somewhere in the middle. I could ensure the most important and more frequent assets are always preloaded, whereas the more unusual assets are left to load in as they are needed.
The latter? Who knows. I’ll just have to keep an eye on memory and cross that bridge should I ever come to it.
The interaction system is based on code I wrote a couple years back, and it became clear pretty quickly that it would need to be re-thunk.
For instance, if the player was stood by some flowers with a pair of secateurs, but a tree is technically closer to the player, the game would assume the player wants to interact with the tree, and return no action. This lead to a lot of dead inputs, especially in dense areas with lots of overlap and conflicts between all the different props.
The previous system actually pinged everything that was on the map at the time, reporting which one is closest, which, while not completely impractical, is still overkill. Now the game only pings the props that the player is stood in the area of – if the player happens to be in range of some flowers and a tree, it will ping those. It also pings those props directly, where previously it functioned by emitting a signal to any and all props in the hope one would answer.
The new system also introduces a priority system, where the game can make a guess from what the player has equipped, what they might want to be doing. So, even if a tree is closer, if a player is facing some flowers with secateurs, they likely want to cut the flowers, instead of do nothing to a tree.
I spent the last week or so restructuring the map saving system to be more comprehensive. The map data now saves separately to the player data, which makes things more manageable. Map data can get quite large and complicated, so it only makes sense to have it controlled in its own little pocket, away from simple things like ‘what hat is the player wearing’. It also means that tinkerers, should they want to, can swap gardens with one another and load in their own player character to that map.
The goal was to have a map that updates itself on-the-fly as the map changes, instead of recording all the changes all at once.
This is for two reasons – the first is so that we get as close to a permanent world as possible. Meaning, if the player makes a mistake, or makes a weighty decision, or gets an unlucky outcome, that’s all part of the game, and it shouldn’t be circumvented by simply closing the game without saving. The second is to hopefully take the edge off the saving system. By not having to write the entire map each time it should (in theory) keep things running smoothly. All of this goes hand-in-hand to create a game the player can boot into and forget about their save file, and feel more like they’re entering a persistent environment.
It seems tiny saves still lag the game out a bit, which I haven’t yet been able to solve. It’s currently not realistic, unfortunately, to save the map file every time the player makes a cut into a tree, for example. My research has lead me to believe this could just be the nature of the beast, although I wonder how other games manage background saving in they way they do. I imagine I’ll either need to save the game during times when it’s less obvious (although this could be exploited), or ensure the game is always saved on exit (also exploitable, but less so).
I think it’s important not to get too hung up on preventing players who would go out of their way to exploit certain aspects of the game. There’s going to be a point of resistance where ‘cheating’ simply isn’t worth the know-how or time for the average player, and that’s probably the sweet spot.
Fishing and errands will be the two biggest feature introductions in 0.0.3. While errands is somewhat by-the-by, fishing will likely need a very close eye in order to ensure it’s a satisfying system that’s fun to play.
After all, if you can’t kick back and enjoy some fishing, why play at all.