Development Progress Report, week 64

Feedback is awesome! Seriously.

Managing to get a couple of people to give the game a try was incredibly energising and very informative!

Knowing what people are confused by and what is poorly-understood (or misunderstood) is extremely valuable to the development process.

You, the creator, understand it all, of course. That bit of backstory that you’re developing for later in the narrative. Setting details that have gone unspoken. Unique turns of phrase that may be misleading.

Your audience isn’t in that privileged position. You don’t have to “dumb things down” for your audience, but you do have to bear that knowledge-gap in mind. Knowing where those places are an issue helps you manage presentation, and lets you know when and where to manage expectations.

In my case, a number of aspects of the setting simply weren’t clear enough from the outset. Quite a few of those have been addressed now. And there were other things that I simply hadn’t considered at all.

For example, since you can play any of eleven different characters in SNAFU, the game starts with a selection-screen that presents each character by name, with a short blurb that tells you at least a little about them and their situation at the start of the story.

What hadn’t occurred to me is that you could consider those to be spoilers. Once you’re playing, you know at least a little about those other characters, and waiting for them to appear in your narrative can be like waiting for a shoe to drop.

For now, the solution has been to add an extra option at the beginning to allow “blind selection”. If you want to jump in with a minimum of possible spoilerage, you can simply ask the game to pick a character for you at random, so that you know nothing about the others at the outset.

If you choose not to do it that way, the game lets you use the manual selection system instead.

I’ve also added a preliminary tutorial for players who are unfamiliar with the usability-grammar of visual-novels and interactive fiction that walks them through some of the basic controls and concepts. Probably every word of that tutorial will need revisiting and polishing, but it is there, and that’s a good thing.

It turned out to be surprisingly easy to add in, as well, since I was just able to drop it in as an initial scene within the story (actually a sub-scene of the startup scene, but the idea is much the same).

I had to do a little technical work underneath with the concept of a “live character” (that is, the character that the player is currently playing) since the story definition has not previously known or cared which one that was. As far as it was concerned, all of the characters were playing simultaneously – indeed, that’s how the story is handled.

All of the characters are playing the game/story at the same time. One of them just happens to have a human connected who is making that character’s choices.

In any case, the “live character” now has a special flag that can be used in scene-casting and tested for in the narrative. Perhaps some interesting uses will develop for that beyond the tutorial.

Testers also found some places where things didn’t work quite right. Some UI issues, and some story problems (eg: One place, I bungled testing a flag and a block of background text came out twice, if the player made a certain choice).

There have been whole bunches of fixes to UI elements and in the narrative.

I also ended up writing my first particle-system! It’s not something I’ve ever needed before, and while I was aware of the theory, I’d never put it into practice. With a little component-based programming thrown in for good measure, I can toss thousands of particles around, if I want.

Before that actually becomes useful in the ways that I want it to, there needs to be a proper structural framework created so that particle systems can be created, called on when required, and then discarded. Considering how many moving parts such a system has, I need to give that some real thought before proceeding.

I think I’ve finally blasted my way through practically all of the kerning table. The text looks better than ever, though probably there’s still a couple character-pairs that need attention that don’t come up very often.

I also finally know why the kerning data from the font isn’t showing up.

SDL_ttf uses libfreetype to do a lot of the heavy-lifting with regards to fonts. The problem is that there is more than one type of kerning table in fonts. The newer (and more versatile) “GPOS”, and the older “kern”. It seems libfreetype is unable to read GPOS data (at least not the version that I have). If that’s where the kerning information for your font is, well, tough. You’ll have to do your own.

Lastly, I’ve gotten good feedback on the linux build.’s Butler tool doesn’t really like .deb packages, so I stopped building those quite some time back, which meant that I got slack on the dependencies.

Making sure the whole thing actually runs properly under linux is kind of important, though, and something I’ve been meaning to take care of.

I’ve gotten some excellent feeback and information on that, and I am hoping to rebundle the linux builds in the coming week to make them more standalone, so you can just download and play.

And that’s all I have time for, for this update. It’s going to be a busy day of wearing pants and being an adult.