Version 0.9.11 is out.
Version 0.9.11:
---------------
* General:
* Work around bug in Wesnoth 1.11.17 that could cause units to be deleted
from the game by units moving during cutscenes.
Iris
Those who have followed me these last five years or so are probably aware that I designed and coded this site’s layout on my own in an effort to learn the basics of Web design. Thus, shadowm.rewound.net has been redesigned no less than eight times since its inception.
Dorset6, the last iteration prior to this day, was first deployed on May 11th, 2011. Since then, it has only received minor incremental updates addressing bugs and minor practical concerns that cropped up later, since I found the overall design to be pleasing to the eyes — at least until I got a new screen where the lighter blue colors turn out to be purpler than intended, oops!
The last maintenance update to Dorset6 was Delta 24, deployed on April 26 2014.
The underlying template engine, Poison Ivy, has not seen any architectural changes all these years since it was first deployed in 2010. In the meantime, however, I have learned more about API design from my experience with various other projects. It can be very disheartening to look back on past practices and realize you were doing things completely wrong in production software!
During this time I have also heard all the hype surrounding HTML5 and CSS3, and got to experience the results firsthand as large websites started making use of the new technologies. On top of that, support for Internet Explorer 6 is finally dying off, and Windows XP just reached its definitive end of life last month; software and Web developers everywhere rejoice as they no longer have to give support to grossly obsolete products from the early 2000s.
I have actually made use of CSS3 and forward features in shadowm.rewound.net since Dorset6, but right after deployment I decided to aim for leveraging more of their potential in the next iteration, Dorset 7. I promptly begun throwing around style and layout ideas. However...
A load of WML errors (Part I)
WML is the primary source code language for all add-on and mainline content for Wesnoth. Creators like me write large amounts of WML to instill life into their user-made projects. Our wiki has a rich reference section for the various dialects of WML understood by the game in different contexts. Tools like wmllint exist to make sanity-checking and porting tasks easier for the few people who can tolerate its obtuseness us. There is a whole forum section in Wesnoth.org dedicated to assisting people with their WML endeavors.
With so many resources available, you’d think WML is the most fun thing to work with, right?
1. The problem
One of the most annoying aspects of add-on development is that whenever something goes horribly wrong with the WML document’s well-formedness, you may get a barrage of file paths thrown at you in a superdense text-wall format, particularly so if the error site has been subject to file or macro substitutions, which is the case with pretty much every add-on that has more files than its top-level _main.cfg. Trying to find the relevant portions of the substitution trace to debug the issue can be frustrating at best.
When more than one add-on fails to load, though, the results can be even messier.
The report is displayed on the screen by calling a generic GUI function that creates a new instance of a generic message dialog with the specified contents, which are also printed in stderr. Since the only formatting option available for the dialog is to rearrange the text with a combination of whitespace and newlines, the same thing winds up in stderr in the same format:
20140216 10:50:12 error config: error reading usermade add-on '/home/shadowm/.wesnoth-1.11/data/add-ons/After_the_Storm/_main.cfg' 20140216 10:50:12 error general: The following add-on had errors and could not be loaded: /home/shadowm/.wesnoth-1.11/data/add-ons/After_the_Storm/_main.cfg ERROR DETAILS: Found invalid closing tag [/unit] for tag [side] (opened at ~add-ons/After_the_Storm/episode3/scenarios/13_Epilogue.cfg:98 included from ~add-ons/After_the_Storm/base-loader.cfg:20 included from ~add-ons/After_the_Storm/_main.cfg:174 included from ~add-ons/After_the_Storm/base-loader.cfg:108 included from ~add-ons/After_the_Storm/_main.cfg:174 included from ~add-ons/After_the_Storm/episode3/scenarios/13_Epilogue.cfg:101 included from ~add-ons/After_the_Storm/base-loader.cfg:20 included from ~add-ons/After_the_Storm/_main.cfg:174 included from ~add-ons/After_the_Storm/base-loader.cfg:108 included from ~add-ons/After_the_Storm/_main.cfg:174), value ']' at ~add-ons/After_the_Storm/episode3/scenarios/13_Epilogue.cfg:94 included from ~add-ons/After_the_Storm/base-loader.cfg:20 included from ~add-ons/After_the_Storm/_main.cfg:174 included from ~add-ons/After_the_Storm/base-loader.cfg:108 included from ~add-ons/After_the_Storm/_main.cfg:174 included from ~add-ons/After_the_Storm/episode3/scenarios/13_Epilogue.cfg:112 included from ~add-ons/After_the_Storm/base-loader.cfg:20 included from ~add-ons/After_the_Storm/_main.cfg:174 included from ~add-ons/After_the_Storm/base-loader.cfg:108 included from ~add-ons/After_the_Storm/_main.cfg:174
This issue affects mainline and UMC developers alike, and yet, it has gone unsolved for a whole decade of development, even while other usability issues have been and continue to be addressed. Perhaps the very fact that the problem has existed for so long has silently perpetuated a misguided notion of impossibility — because, surely, if fixing the relevant code was that easy, somebody would have already done it? Or maybe, just maybe, everyone is afraid of altering code that lies deep within the core of Wesnoth’s WML processing pipeline; because it is an indisputable truth that the WML preprocessor and parser aren’t the most accessible modules for inexperienced contributors, and changing functionality that constitutes the circulatory system of the game engine is obviously a risky thing to do.
But wait! Wouldn’t it be possible to just sort of... make the error report presentation nicer without meddling too much with the implementation details?
2. The solution
While the basic proposal sounds simple and the results of my two-day-long coding effort made it into Wesnoth 1.11.10 (a.k.a. 1.12 beta 1), it turns out that there are many more factors to take into account, and in the end I did have to mess with parser and preprocessor implementation details to a greater degree than I feel comfortable with.
Against what one would expect, there is only one exception object class in existence for parser errors, and it is extremely generic. Callers have no way to tell what just happened when WML parsing has failed, other than asking the exception object for an error message... which is both stored and delivered in plain string form. The error type, the error site, and the WML preprocessor substitutions that led to it; these are all provided to the caller in an atomic string that may contain portions translated to the user’s language beforehand. This means that we (the parser’s callers) can’t reliably scan the error message to choose the format in which we are going to present the error to the user. All we can do is grab that big-ass message string and throw it into a dialog.
The dialog used to display the report in versions up to and including 1.11.9 is part of the GUI2 framework, but the particular dialog class in use is a plain generic message box. Naturally, it is not optimized for presenting WML error messages to the user — or displaying overlong strings in general, really. It is for this reason that the first part of this little project of mine consisted of designing a new dialog class (gui2::twml_error) for presenting this information to the player in a more useful fashion.
3. The dialog
Because the Wesnoth config manager will try to load all add-ons at once, the first thing that the dialog needs to do is to display a list of add-ons that caused a parser or preprocessor error when attempting to load them. The 1.11.9 approach is to hastily concatenate a newline-delimited list of paths to the files Wesnoth attempted to load, which are nearly always the _main.cfg files. This can be quite misleading in most cases, and newbies might try to look for the faulty code in the listed _main.cfg since it is the very first thing displayed in the error message.
gui2::twml_error instead displays the user-friendly name (1) of the add-on that was stored in a special file (_info.cfg) when it was first downloaded from the server — failing that, it makes its best guess by replacing underscores in the directory name with blanks. If multiple add-ons failed to load, they are shown in a nice bullet list.
Where there used to be more plain dialog text, there is now a pretty scrollable box with the report contents (2). The report itself contains the list of errors found when loading the affected add-ons, but it is no longer all thrown at your face at once — the error log for each add-on is followed by an additional empty line, so telling them apart should be far easier than before. Finally, right above the report there is a button (3) to copy it to clipboard so players don’t need to take a screenshot of the whole thing to give to the add-on maintainer(s).
To be perfectly honest, the only reason that copy-to-clipboard button even exists is that I find error message screenshots irritatingly cumbersome to work with at both ends. It doesn’t help that I’m usually on slow Internet connections where downloading a screenshot of a Wesnoth instance surrounded by some fancy window decoration and taskbar and (occasionally) desktop wallpaper can be excruciatingly painful. Furthermore, as a forum administrator who has to keep an eye on how people use attachments, this preposterous waste of disk space can be quite annoying.
⁂
But replacing the error report dialog and the presentation of reports as a whole is not enough to improve the WML coder’s experience. gui2::twml_error would still display the text wall-like errors if it were asked to do so by the config manager. Even though I hinted at the essentials above, the muddy implementation details screened by gui2::twml_error would still fill up a whole blog post on their own. Thus, I am going to leave that story for another time.
Wesnoth UMC Review: Shadows of Deception
For very long, there have been only two (2) campaigns in the Wesnoth add-ons server that follow the “shadowmcanon” established by Invasion from the Unknown and After the Storm; the campaigns in question are Invasion from the Unknown, and After the Storm. Yes. That’s it. The only other campaign whose author has consulted plot matters with me and followed the shadowmcanon correctly (as opposed to blindly extrapolating from IftU and AtS and making grossly wrong assumptions about things that are left unspecified or presented in a deliberately vague fashion) is The Silver Lands, but it was abandoned far too early during its development cycle.
But the status quo has just changed with the release of version 0.5.0 of Shadows of Deception (NX-RPG), a campaign by vultraz for Wesnoth 1.11.6 and later. So far, six scenarios out of the first set of 12 have been done; the goal is two episodes.
Of note is the fact that vultraz has been a member of my After the Storm internal playtesting and prose reviewing team for a couple of years.
Per the description found in the campaign’s forum thread, Shadows of Deception (SoD for short) is “a half-RPG, half regular style Wesnoth campaign, incorporating several custom gameplay elements as well as your typical battle scenarios”. What does half-RPG mean? Damn if I know — I don't even know what a full RPG would be. Having playtested SoD prior to the release myself, though, I can say that the campaign places a fair amount of emphasis on the story while experimenting with some unusual gameplay mechanics.
The story
The protagonists of this campaign are the elvish enchantress Niryone, and her apprentice Elynia. If you have played IftU or AtS, you are definitely familiarized with Elynia’s game-breaking abilities and power. You will not find any of that here. SoD is a distant prequel that takes place during her apprenticeship days circa 1081 YW, back when she was far even more useless younger and entirely ignorant of the sequence of events that would lead to Wesnoth’s political reorganization and changes echoing throughout all of the Great Continent. Thus, the real protagonist for most of SoD Episode I is her adoptive mother and mentor Niryone, whose existence was repeatedly alluded to throughout AtS.
The story is derived from Late History: Irdya before the Fall in the wiki (full of SPOILERS, in case it isn’t obvious), which I originally wrote back in 2008 (and revised some months ago) along with the rest of Future History in order to provide additional backstory for some IftU characters (e.g. Elynia, Argan) and events (e.g. the Fall). But what I wrote back then was not quite the story narrated by SoD; my text was essentially limited to an overall outline enumerating major events and characters in the broader context of Irdya. All characters and events in SoD are written according to vultraz’s own interpretation of the outline, with some input from 8680, Zerovirus, and me. In that regard, for characters other than Elynia’s younger self, I have only provided very rough characterization guidelines without going into details that could constrain the creative process too much. Elynia’s interpretation is purely vultraz’s, and so far I’d say he has nailed her character.
Without going into too much detail about the plot, I think that it features some unique ideas that I haven’t seen used a lot in any mainline campaigns — or IftU and AtS, for that matter. The great thing about the campaign is that it stands on its own as a product, and you don’t need to play any other campaigns to understand what’s going on. Of course, knowing some mainline lore always helps when it comes to identifying locations such as Wesnoth and Elensefar, but in the worst case you’ve got a massive map of the “mainline region” of the Great Continent in the game’s titlescreen.
The gameplay
To elaborate upon my previous statement about SoD’s design, resources throughout the campaign are rather limited, thus you won’t be building a massive army like those seen in Northern Rebirth or classic IftU — unless your intention is to repeatedly run into inconvenient negative budget situations. Au contraire, your focus should be on managing as few units as possible and utilizing the spells mechanic with your two leads. Disappointingly, this first release of the campaign only implements one (1) spell for Niryone, and a secret spell hidden somewhere decidedly secret. Your starting spell, however, should be quite useful to get your units out of sticky situations; in fact, it can be so useful, it borders on being a game-breaking mechanic, an issue which should hopefully be corrected in upcoming releases along with the overall lack of spells. On the plus side, this is better connected to the story than your typical Wesnoth UMC gameplay gimmick, as illustrated soon enough during the first few scenarios. The same can be said for the inventory mechanic; it is not particularly useful due to the current items shortage, but it does come into play for advancing the storyline at one point so far.
Perhaps more important than how often these features are used throughout the campaign in its current state, is the fact that the author has clearly put a lot of thought and effort into them. Both make use of custom Lua-based GUI2 dialogs, a Wesnoth engine feature that is very poorly documented and quite sadly underrated, even by the GUI2 developer himself. The UI design done for the sake of these two gameplay aspects alone makes the campaign fit seamlessly within Wesnoth’s framework, a courageous feat to behold and respect given GUI2’s status as an undermaintained and eternally moving target. That said, much like AtS’ (very sparse) usage of the GUI2 Lua bindings, it is quite probable that this kind of thing will break for users on display resolutions lower than the minimum supported by mainline, which is 800x480 absolute (not Retina) pixels. For now this isn’t a problem, since there are no unofficial ports of 1.11.x to mobile devices, and maybe by the point Wesnoth 1.12 is out everyone will be on devices with 8K full-HD or whatever. Yes, that’s a hyperbolic statement about 1.12’s unending development cycle, in case you could not tell.
Visuals, units, et cetera
Map design in SoD is generally good, portraying lush detailed environments from the Great Continent as it was during the mainline epoch, as opposed to the ruined wastelands seen so often in IftU or AtS. However, they are interspersed with underground scenarios, which may be somewhat of a letdown for those who dread dungeon crawling-style gameplay in the style of the aforementioned campaigns. To make up for it, SoD also features varied recruits and new enemy units to break the constant destroy-all-undead-and-kill-all-orcs cliché seen in so many, many other campaigns.
The art for the two protagonists was provided by some random nobody, who I have heard was basically forced by vultraz to make sprites within exceedingly restrictive schedules to the point that he or she had to sacrifice quality for the sake of getting a releasable product in time. I have also heard that this situation has become kind of a chronic issue for that person.
Some of the new unit art that features in later scenarios was provided by everyone’s favorite prolific pixel artist, Zerovirus. I am fairly sure Zerovirus fans will be able to spot his art as soon as it begins appearing on the game map, but it’s important to note that some of the art was actually created or edited by vultraz as well.
Other than these few points, there is not much else to talk about regarding SoD’s art development. Much like AtS, which was started and finished with a budget of exactly $0.00, portrait art for original characters is completely absent in this campaign. Nothing that can be helped in the short term, given that the author doesn’t work with portrait artists at this time, and seriously, good portrait artists generally don’t have much time to spare and would only be willing to contribute under commission, reasonably so.
To conclude
Shadows of Deception is a bold attempt by vultraz to develop a product that can join the shadowmcanon (IftU and AtS) while working as its own campaign without requiring the player to be familiarized with the rest. It is an early work in progress with only six scenarios complete out of 12 for the first episode, but it already shows a huge amount of dedication on part of the author in all areas that make up a good Wesnoth campaign: art, story, map design, you name it. Some of the new gameplay aspects introduced aren’t used as much as they should probably be to make them enticing to newcomers, but this situation may change as time passes and player feedback is provided. Because, you are obviously going to provide the author with that precious feedback while the add-on is being developed, right?
I think it is a promising campaign. I for one am eagerly looking forward to playing the rest, assuming it doesn’t get abandoned like the aforementioned case of TSL. That would make me sad. And nobody wants to see a sad shadowm.