carrotcake Blog 🍃

official devlog for carrotcake written by Louis Durrant

Thursday Report: Saved by the bell

Posted on Jun 6, 2019

Sometimes I find myself in a rut, unsure what to work on next. What this looks like is me dipping into many pre-existing elements of the game, and making a few tweaks here and there, but never having the guts or the drive to commit to anything significant.

I think that’s okay, and I also think it’s natural. I do the same with illustration; sometimes I’ll know the piece isn’t the best it can be, but I’ll reluctantly go through, making tiny adjustments to shading or lines, until I realize what’s actually missing.

Because, often, the only thing keeping me from making inroads is some piece of knowledge, usually in the form of a decision. Typically I don’t know what I don’t know, so these little probes takes the form of mining at a rock, until eventually a little chip falls apart, bringing with it an entire chunk, and you can keep on mining and mining the soft earth until it becomes hard again.

So to speak.

So last week I’ve made probably the biggest (at least, the most sudden) inroad since I started working on this project. I always had in my notes the two behemoths of coding that I would be dreading: map generation, and a save system.

Map generation, as you might remember from my last blog posts, wasn’t too breezy, but is – as far as I can tell – functional enough to enjoy the game.

A save system was still hanging over me – I knew it would require somehow writing data to the user’s disk, and I didn’t even know where to begin in that regard.

Turns out, following just a couple of tutorials, I had the schematics of a fully working save system in just a couple of hours. And I had completely underestimated how important a tool that system is. I only wish I had committed to figuring it out sooner.

By capturing a saved state, I’m able to then go into the data, and make tweaks directly – however large or small – and then load into that new scenario. It feels as though I’m no longer in a sandbox, but actually playing the game live. That’s a whole shift in perspective.

This has allowed me to start shaping the ‘New Game’ experience. This is something that’s been mulling in my head for quite some time. My philosophy is to have the most minimal introduction as possible, while still immersing the player into the game’s world.

As discussed before, I want no character creator screen, but I don’t realistically see a way around having a skin-tone selector before the player starts the game. It’s rigid part of a person, and something that should have no ‘default’. I’ve shared the skin-tone selector before, and I think it’s an acceptable singular menu that appears before starting the game. You select the skin tone, and then you’re in.

If anything, I’ve grown to appreciate something placing itself between the main menu and the game world. It neatly bridges the gap as a menu itself, but is the very first stepping stone as the first choice the player makes.

A five second cinematic then plays, subtly zooming away from some overgrowth. The player can be seen emerging from the overgrowth, and the game begins. This will be followed by some subtle tutorial guidance hinted by the world itself, but otherwise the player will be left entirely to their own devices.

(Don’t worry, it’ll look better than this, but you get the idea.)

The other big mechanic that save-files allow me to begin working in is time. ‘The Garden Path’ is real-time, meaning if you play the game at 4pm in the real world, it will be 4pm in ‘The Garden Path’.

This comes with its own problems. It would be wrong to design a game around people who work 9-5, and also wrong to lock certain content at 3am. There will be systems to allow the player to shift sunrise and sunset to a certain degree, but another simple solution is to simply give the players the option to completely shift the game time in relation to their own time – twelve hours either side. Even if they work a night shift, they can still hop in after work and have the sun rising in the game.

Would players just use this to time travel and exploit the game? Not if they can only do it once – one of those ’tutorials’ will be a sundial (or similar object), that will allow the player to change the time, but will become only decorative afterwards.

Can’t players just adjust their system’s time to exploit the game? Yes. That’s on them. If you sell a kid an action man and he wants to pull all the limbs off, that’s up the kid.

There’s a number of appealing components of a real-time game. It helps players respect the world, it prevents burn-out, it gives players something to look forward to each day at a slower pace.

That slower pace can sometimes become stagnancy however. Winter’s last long enough in the real world, and sometimes we might want to escape to somewhere where it’s spring.

As such, I’ve decided the game will have it’s own calender. Very simply, each week will be its own season. That means (roughly), every month the player will see spring, summer, autumn and winter.

This not only helps with things being stagnant, but also helps speed up the gardening process. In this way, a tree growing in a few weeks makes sense according to the game’s logic.

I’m inching closer and closer toward being in a position to start building real content for the game.

There’s still so much work to do, but for the first time, I feel like I can start to smell it.