I missed last week’s development blog post due to the pressure of other things, so I’ve got two weeks to cover.
On the narrative side, I’m nearing a long-awaited story milestone. The prologues are complete for each of the eleven protagonists, and all but two of them are written through to the end of the rather dense and complicated first day of the story proper. Once those last two characters are written through, that will represent a major milestone.
That brings us to (today), 88 scenes and 232,814 words. That’s more than Dune (the book), or Neverwinter Nights (the game) [This isn’t a competition!], but we’re not really into the full swing of things yet. That will be in the second Act, which is where the bulk of the narrative technology should start to shine (I hope!).
The code and interface have been getting all sorts of polishing, and there’s a proper (if slightly crude and not-quite-complete) game-options screen for controlling aspects of the engine.
Creating widgets is easy. Getting them all laid out where you actually want them and connected to the right code takes rather more code (and for the layout, empirical tinkering) than I’d really like. In one sense, it would be nice to make screen layouts with an HTML WYSIWYG editor, and use that to define widget types and positions, but I’m skirting around that, because an XML/HTML parser would probably be considerably larger than the entire game-engine at this stage.
Of course, I could maybe just apply all of that at compile-time, but that would significantly complicate the build-pipeline. For now, I’ll muddle along with doing it manually.
As far as the main-interface goes, there’s a new text-prompt, progressive-text rendering, and – when that is enabled – punctuation pauses (progressive rendering pauses slightly when rendering certain punctuation, like commas and full-stops, etc, which gives progressively-rendered text a satisfying rhythm).
Basically dozens of little polish-items in the UI code each of which is probably individually too small to notice, but it all adds up.
Which brings us to kerning.
Problem: Kerning is handled more or less automatically, if I’m outputting more than one character at a time, but I can’t actually do that and get the text effects that I need!
Kerning is the spacing between characters. So-called monospaced fonts have the same spacing between any pair of characters. It’s okay, but it isn’t the sort of character-layout that you see in a book, or in a web-browser. Those generally use variable-width characters, which are packed together with sensible spacing (or kerning). ‘i’ is narrower than ‘m’ and gets less onscreen space.
Regrettably, while I can get a ton of information about widths and heights of characters, generating good kerning seems to be difficult, since the kerning information in the font itself isn’t exposed to me by the font API.
That means that I actually can’t tell 100% how much space any two characters need to have between then, and that made things look a little odd.
So I tinkered.
A whole hell of a lot.
It looks better now, but really, a lot of it is purest empiricism. There are still cases where the spacing between characters might look slightly weird. For now, I’m just going to have to live with that.
One of the things that has given me pause is that the story, with its variances and branches, is impractical to portray as any kind of graph or chart.
That’s not to say that you couldn’t represent it that way (I have a big-picture chart, using Twine, which just shows interconnections between scenes), but if you actually did chart every narrative branch/variation, you’d wind up with a diagram that would be utterly useless for comprehending the narrative flow.
I simply can’t come up with any kind of a visualisation of the narrative that is any more comprehensible than the source-text of the story. This has implications for what visual-novels normally call “skip-mode”.
In skip-mode, you can advance the story rapidly, until you reach a line of text that you haven’t seen, or reach a decision point. That doesn’t work here, since we’re not just switching tracks between pre-written blocks of text. Instead the narrative output is altered dynamically in a number of ways based on previous events, character knowledge, choices, and the like. What is ostensibly the same line of narrative might come out in several different ways.
So, traditional “skip-mode” or voiced-narrative is pretty much out. Many lines of narrative cannot be easily predicted on any given play-through.
I do have a “skip-mode” which allows the reader to fast-forward through the story. While it is handy for testing, it might be too fast, though.
It’s currently clamped around 60 narrative chunks per second (the engine itself can handle over 3,000 per second – the engine can handle things amazingly quickly!). I expect the final version will need further clamping before it is practical in end-user situations.
Primary testing is done with Windows 10, x64 – and everything works well there. Some alpha-testing has been done on other 64-bit Windows systems and it should operate as far back as Windows 7. Possibly it might just maybe run on Windows XP+x64, but I wouldn’t hold my breath on that, if I were you.
A closed Alpha-4 demo build should be going out to testers in the next couple or three weeks. I’m going to write through the couple remaining narratives up to the milestone, and package it all up in the new installer after a bit of polishing.
Then there’s the Linux-x64 build.
It works. It seems to work pretty well, but there are some… issues.
The primary issue is that gcc/g++ doesn’t seem to have kept pace with language standards, of late (although the same could be said of most compilers, perhaps). I am using language features from 2011, and 2014, which are simply not well-supported (or not supported at all!) in gcc/g++ 4.x.
That means that the minimum compiler and libraries version that I can use to build the code under Linux is g++ 5.0 (I’m currently using 5.2.1). Even then, there are finicky ABI issues. Without -D_GLIBCXX_USE_CXX11_ABI=0 the objects simply won’t link at all.
What does any of that mean in end-user terms? It means that I can build and run the code, and it works nicely – but I’m not sure how to distribute it to you. If you’re a Linux user, you’re likely running on a system with 4.8.4-era libraries all over the place. 5.x hasn’t made an appearance in most Linux distributions that you’re probably running day-to-day.
So, there’s a working Linux build, but my testers probably can’t run it. Not yet, anyway.
Lots of polish, lots more words, better text output, game-options screen, new alpha-demo coming soon for testers, and lots of superfluous technical waffle.
Thanks for tuning in. Back next week!