For more than a year I have been actively avoiding the web browser that all the cool kids use these days. I’m obviously talking of Google Chrome.
For all its excellent performance and ease of use, I kept being bothered by its insistence on breaking the mold and looking like a completely different thing running on my Linux system, instead of behaving like an application blending with its environment. I think it was this big annoyance that kept me from adopting it as my regular web browser for all this time. But compared to Mozilla Firefox, I think there’s just no matter of dispute anymore. Chromium/Google Chrome keeps getting better, and Firefox is stuck in the noughties, much like an evolutionary dead end in the history of fail web browsers.
Back in January, I posted my initial plans for Wesnoth 1.12 in the developers’ mailing list to gather some feedback and hopefully motivate other developers to do the same with theirs. Guess what, that didn’t work, so here I am back at home cooking up code and user interface changes in solitude. In fact, it’s all almost ready for 1.11.0.
1.11.0 is getting closer, but it’s still a little too far; this is mainly because the map format and editor changes in trunk have not been finalized yet and loose ends abound. Thankfully, I am not the one responsible for that mess. My mess is much prettier, practical, and necessary; and it is this mess that my post is all about.
Since the first three scenarios of After the Storm: Final are already out (0.8.0), I can now talk about my plans for the campaign to ensure we are all on the same page later.
This episode’s final scenario count is preliminarily advertised as twelve in the campaign menu entry, but the number may change as I see fit. More importantly, the final seven scenarios will be published as an atomic batch instead of separately. In fact, it’s very likely they will not enter the SVN repository until they all are finished.
For now, two more scenarios are expected to land in SVN trunk during the upcoming months; Outpost of Hell (E3S4) and Pass of Sorrows (tentative name for E3S5). Anyone who has been paying attention to the story and dialog sequences found in E3 so far will be able to predict the events taking place in E3S4 and E3S5. However, these scenarios (E3S4 in particular) require new units for gameplay and story reasons, and—since I am the only dedicated ‘artist’ working in the campaign—this part may take some time.
The campaign’s overall structure has resulted in decidedly slow storytelling and I don’t regret this design; basically, if you don’t like this, this campaign is not for you. However, things are going to get far more complicated after E3S5 as we approach the conclusion. Getting the finale right—in regards to code, prose, and art together, but especially art—may require a greater amount of energy than anything done before for AtS; hence, once E3S5 is out you may rest assured that unless a miracle occurs, the rest will take a large amount of time to be properly finished and released as After the Storm version 0.9.0.
Writing the finale is not a big deal per se since I’ve always known where the characters are going. The problem is making sure it’s worthwhile to play and read. I’ve always been flexible to plot changes in that regard since I resumed work on E1 last year; after all, this is a game, not a novel. The execution of the plot is also a touchy subject since the matter of the campaign doesn’t really fit neatly in a turn-based strategy game, and compromises must be made.
As usual, art is an ever-present issue as well. The finale requires more new units, props, and terrain graphics. When it comes to unit art, I have always been able to manage by reusing previous assets, making minor modifications and calling it ‘new’; but terrains and props are uncharted lands for me, which is why I fear art will take up most of the production time for the finale. And this is all not taking portraits into account; ideally at this point all major characters from this campaign—as opposed to those introduced in IftU—would have their own portraits, but that just hasn’t happened yet and is unlikely to happen in the near future.
In any case, this has been a very interesting journey. I hope it comes to an end soon and Final can be completed before the end of the year, but I’d not be surprised if it takes longer than that.
Version 0.8.0 is finally out, 16 days after the original deadline. Oh well. At least it didn’t take half a year like the last time I failed to meet a release schedule.
This version will most certainly not be exempt of flaws. It introduces the first three playable scenarios of Episode III (Final), plus two cutscenes; the playable scenarios haven’t been tested very thoroughly by my dedicated QA team or myself, and thus might be full of balancing issues, especially on difficulty levels other than Normal.
I guess I might as well take this opportunity to mention that Normal is, in fact, the only difficulty level I actually test.
There’s also a few bug fixes in this version, but nothing too important other than a voodoo fix for crashes affecting Mac OS X users at the end of Episode II (previously described in the forums). Somehow, I managed to forget to mention this item in the changelog this time; I feel this isn’t the only thing I forgot to do before releasing. Ah well, it probably isn’t my fault seeing as how I have to take care of so many things (cough art cough) for this campaign.
UPDATE: The immediate implication of this fix is that you will need to run Fate (the final cutscene scenario of Episode II, not the whole episode) again if you want Anya’s and Durvan’s stats to carry over to Episode III.
The changelog for this version follows:
Version 0.8.0:
--------------
* Scenarios:
* Mal Hekuba now wears purple TC as he did in IftU.
* E3S0 - Opening (Within):
* New scenario.
* E3S1 - Beyond her Smile (A Light in the Darkness):
* New scenario.
* E3S2 - Return to Raelthyn (Reckoning):
* New scenario.
* E3S3 - Amidst the Ruins of Glamdrol (A Path to Follow):
* New scenario.
* Units:
* Balancing:
* Increased Chaos Hound's recruit cost from 18 to 20.
* Increased Shaxthal Razorbird's recruit cost from 18 to 19.
* Decreased Shaxthal Runner Drone's ranged attack strength from 8-3 to 7-3.
* Fixed invisible Chaos Longbowman and Heavy Longbowman units due to missing
graphics.
* Fixed Elvish Trapper and Elvish Prowler disappearing during animations.
* Fixed NPC bird code deleting the previous on-map unit when moving a
I’ll start by admitting that there was a severe schedule slip again, induced by both personal and technical difficulties. After the Storm: Final scenario 3—which was supposed to be the last scenario introduced by the 0.8.0 update—was only completed a couple of nights ago, despite scenario 2 being completed well before the last week of April.
That said, E3S0 through E3S3 are complete in SVN trunk as of this writing. The problem is that I might still delay 0.8.0 for a while so I can deal with two pending artwork issues (for E3S0 and E3S2, respectively) and perhaps do some additional balancing.
In the meantime, Mac OS X users need to be aware of a certain crash issue affecting the last release currently available, 0.7.4.
I might delay 0.8.0 even more in order to include E3S4 in it. That scenario, however, requires more new artwork that the previous ones combined, and—since I’m not an artist—I can’t guarantee an output rate that would allow for a prompt release this month. I advise patience for the time being.
That is, assuming anyone still cares about this thing!
It’s only been a week since version 0.7.3 of After the Storm came out. As I said some time ago, I’m not announcing minor releases in my blog anymore since they can get on occasion a little too noisy for my taste. However, today’s release, version 0.7.4, is special in a few ways.
After some recent changes in Debian testing’s PHP 5 packages triggered an alarm—namely, breaking my laptop’s own Serendipity installation used for testing—I did some research, and found out that due to my severe laziness, when I originally configured the respective s9y installations I chose to use the SQLite 2 backend using some deprecated (now gone), built-in PHP functionality, instead of using the newer and better SQLite 3. Of course, given the situation when I did the configuration for shadowm.rewound.net it’s also possible I didn’t have a choice.
For this reason, I just finished casting some magic enchantments on this site to convert the blog database to SQLite 3. Evidence indicates that a mere dump suffices for this end, and the schema matches a fresh installation with SQLite 3 save for a few inconsequential bits.
None of this means there was an immediate problem, but I opted for not fixing tomorrow… later today, what I could fix this early morning.
Everything seems to be working fine, although I grabbed a backup of the previous configuration just in case. I’ve heard that SQLite 3 is faster and more space-efficient. The latter does seem to be the case, but since I’m limited to a crappy, high-latency mobile broadband connection to browse the web, I am unable to verify the former for the foreseeable future.
Gna! server did not survive a reboot while upgrading its main OS. It should be fixed and replaced by new hardware if needed by Friday 10 feb.
Sorry for the inconvenience.
I think this Gna.org system administrator puts it better than anyone else ever could.
From what I read on their IRC channel, an upgrade from Debian lenny (oldstable) to squeeze (stable) went wrong while there was nobody around with physical access to the host to fix the problem and make it boot again. Why one would perform an operating system upgrade in such circumstances is beyond me, but I can certainly say the Wesnoth bug and patch trackers, and the Subversion repository won’t be available until that’s fixed.
I for one am glad to use git-svn.
UPDATE (2012-02-11): According to the admins, the machine didn’t power on again after the upgrade, so it’s not just a software issue. Any needed repairs will have to wait until Tuesday, February 14th.
Maintaining Wesnoth add-ons of the size of Invasion from the Unknown and After the Storm isn’t a small task by any means. Over the years, I have had to rely on user feedback to detect critical problems in a release, because testing becomes cumbersome and tedious as the scenario count increases.
My usual release procedure simply involves—at least since I acquired the habit of testing before releasing—running the game, starting each episode of the campaign with the medium difficulty level and making sure the WML preprocessor and parser don’t throw any warnings or errors. Before Wesnoth 1.9.x, the preprocessor didn’t abort when encountering a missing macro or file during a brace substitution, so I had to pay close attention to stderr to ensure nothing is wrong.
The WML preprocessor in Wesnoth 1.10 became more strict, aborting on the aforementioned situations. It was also exposed for command-line usage (for testing or debugging) through the -p or --preprocess switch, also explained in detail under PreprocessorRef in the wiki.
At first I thought that wasn’t very useful beyond diagnosing complicated preprocessor issues, but today I realized I can also do this:
This can be easily accomplished with a simple shell script here embedded in the AtS Makefile. The only major shortcoming is that it doesn’t cover every possible problem because it’s merely running the WML preprocessor, which doesn’t consume and produce WML — all it sees is plain text mixed with some preprocessor directives. The task of reading actual WML (which is potentially found in the preprocessor’s output) is left to the WML parser proper, which creates internal objects in memory corresponding to the internal representation of WML handled by Wesnoth (config class objects).
UPDATE: After investigating the issue further with timotei (who exposed this functionality through --preprocess in the first place), it turns out the preprocessor output with --preprocess is indeed parsed — the real problem is that the preprocessor and parser use different logging facilities, and the former doesn’t even throw errors directly, so a preprocessor-only failure will make the game exit successfully (exit status of zero), while a parser error (potentially induced by a previous preprocessor error) causes a more appropriate non-zero exit status. This and other jarring inconsistencies make add-on test automation rather difficult, to say the least, so things have been simplified in the Makefile as a result.
It would be nice to be able to run the parser unit on the --preprocess output to detect syntax issues like missing end tags or unterminated string literals in the future, as part of a fully automated test suite. For now, it seems I’ll have to stick to my primitive and inelegant manual method before making new AtS releases, plus the unbelievably clumsy wmllint.
I think I rarely discuss the more subjective/emotional aspects of working with the crazy folks at the Battle for Wesnoth Project, so this might be a good opportunity to do so given we are currently on the threshold of the first release in the new stable series, 1.10.
Since a while after joining the project, I’ve been wanting to make deeper changes to the add-ons server software (campaignd, by legacy). Some of those desired changes would benefit me directly as a user-made add-ons maintainer myself (previously Invasion from the Unknown, now After the Storm); other changes simply seem very convenient to have, such as some kind of authentication support and the ability to ban people without dirty system admin hacks.
Yesterday, I unveiled aspects of my not-so-modest proposal to replace campaignd with new code. You can find the pastebin link within my post to the developers mailing list.
Even though I have some of the basic ideas and I’m still collecting previous information (such as Mordante’s proposal), I am terribly hesitant to proceed with the larger project because it will take time and dedication I cannot really promise at this point. But why?
