Lots and lots of progress made this week, despite a weekend’s worth of development time lost to Stardew Valley. Oops! I suspect some of you are in the same boat.
Nevertheless, let’s get on to the good bits.
Mostly this was an engine-development week, though the narrative got some attention as well, mostly in proofing and editing. So, not really anything in the way of new narrative, but I’m feeling better about the existing narrative.
In the Argus engine, a couple new classes have been created to help mediate access to certain configuration options, so that I can have fast-access to boolean and integer configuration items (barely any longer than a straight variable check), while still having the in-memory configuration-store properly updated when changes need to be made.
Ultimately, this allows values in the configuration-store to be directly tied to onscreen widgets.
Going a bit further down the rabbit-hole, I then looked at how onscreen widgets are actually defined. I’m pretty happy with my recklessly polymorphic widgets, and the widget-manager, but actually creating each widget at startup was an annoying chore, requiring between about 2 and 10 lines of code per widget.
I knew, at some point, I was going to have to bite the bullet and simplify that considerably, especially as game-options and load/save screens loomed closer.
This week was the week I got that done.
I actually started laying out a prototype game-options screen before the pain-in-the-arse that was creating and defining all of the widgets crossed the threshold of fix-it-already.
Here’s an image including the prototype and some of the code:
I know, right? That’s not pretty. Even for a partial prototype. It looks cheap and it looks shoddy, and it’s can actually be demoralising to look at, as a developer, because of how far that is away from the vision.
So I brainstormed up a new way to create/define widgets that takes a lot less effort.
Less effort means less time having to strain to get the things on screen, and more time thinking about how everything looks.
Thus, we now have screens that look like this instead:
Now, that‘s an improvement! This is what I’d been hoping for, the whole time. All of this works, except for the Load and Save sections.
Loading and saving certainly work, but there’s been no interface for them, so they just Quickload/Quicksave at present.
There’s still one or two tweaks I’d like to make to the way the screens provide user-feedback. Just polish items, really. They’re quite usable as it is.
What’s good, though, is that making this took me less time than than creating that first partial prototype. A massive time-saving!
Pontification: It’s actually okay for it to look terrible, at first. It’s okay to produce crappy stuff that works, if you’re going to refine and improve on it. Almost nothing comes out great on the first pass. Get used to that, and know that you will do it better on the next iteration.
To help prove out the audio system, some place-holder background music has been added. Nothing, alas, that I could ship the game with, but something to at least provide a bit of a feel for the sort of thing I want in the final product.
It’s place-holder everything, at the moment. Place-holder location images, place-holder character portraits, and place-holder music. The few sound-effects, at least, are final, or semi-final, at least. Probably.
Lastly, amid some ruminations on screwing up, the week caps off nicely by discovering that apparently that kerning information that I had to work around last week is already going into the latest versions of the SDL_ttf API, and thus that particular bit of inspiration is just going to get thrown away in another week or so. Such is life.
As long as it’s right and it works, we’re all good, though.
So, as far as development goes, it has been a very good week indeed – even if some time was lost to Stardew Valley. Taking time out to step back, de-stress, and refill the creative well by playing someone else’s game(s), is something you shouldn’t forget to do.