I think that's a relatively universal metaphor. In that meat is generally considered to be the treat and vegetables are generally considered to be the chore.
I mean... if you averaged out my enjoyment of both meat and vegetable products - I would say that I enjoy vegetables a little more than meat, but my inability to subscribe to popular culinary opinion shouldn't lead us to scrap an entire metaphor.
So in the context of this blog and the development of Cube and Star (A Love Story) - vegetables are 'saving and loading' and meat is 'weather effects'.
You see? The former is a little dry, technical and overall... painful - and the latter is fun, visually-appealing and unlikely to break everything.
There are few things that kill my development momentum faster than the need to implement saving and loading in a game.
It's a wicked combination of high technical complexity, high possibility to introduce errors and low-to-no tactile feedback; in that... the player can't really feel a saved or loaded piece of data... but they can certainly feel a bouncing tree.
It's an interesting conundrum, I think... the saving / loading proposition. While other facets of game development become easier by the day (lighting, physics, audio, cross-platform development - kudos to Unity) - the saving / loading process remains relatively low-level.
It's one of those tasks that becomes easier with experience (as you design from the beginning with the inevitable need to save and load objects) but is never 100% smooth, pleasurable or easy.
But here we are! I think I've done it. I think I've done it.
World-persistence is core to the whole Cube and Star (A Love Story) experience. It's got to be massive and it's got to be permanent. I want it to feel like an enormous, lush, living canvas.
|Side-by-side: The scene itself, and the scene with Unity Gizmos overlaid to illustrate the save/load approach. And a little rain. Do you see? Tiny blue cubes. Naturally.|
There is a lot of data to save and load in the world: the color of the ground, the colors and locations of the trees, objects and entities.
And this data changes every few seconds.
We obviously don't need to save every few seconds (that's insane) - but we need to strike a balance somewhere between the amount of data kept in memory, the freshness of our saves and the amount of data we are saving at any one time (to avoid frame-stutters).
At present - I'm saving to Unity's PlayerPrefs (this is wrapped in a class - I'll change it later); every piece of data that needs to be saved is converted into a short sentence... like:
Which translates to:
This tile is colored Red: 1.0 Green: 0.5 Blue: 0.75 and has no object on it.
When the game needs access to an object - it is loaded (or retrieved from memory, if it has already been loaded) - and added to a library of data.
All of the data in this library ages over time. When it becomes old and has not been accessed for a while - it becomes stale - at which point it will be saved and removed from memory.
In the screencap above - you can see this in action: green cubes are fresh, red cubes are growing stale, yellow spheres have not been modified (so will not be saved).
Thus far the strategy strikes a nice balance between freshness, memory usage and performance.
Vegetable course completed. I'm picturing broccoli. I don't know why it (broccoli) gets such a bad wrap. It's one of my favourite vegetables. I think it's got to do with Commander Keen 3.5 (Keen Dreams).
Next episode: Meat.