Cutting Down on the Verb Explosion (Tales of the Test Book)
I discovered that I had way too many verbs in my latest WIP, Seasons. Now I don’t mean player verbs, but rather testing verbs — the verbs that only I (and maybe beta testers) would use. You know those verbs: the secret ones that give you points, move objects around, or whatever, so you can test a particular area of code. While reading through the IDG on the consult verb, I hit on something. Why bother with consult when you can do the same thing, only easier, with parse_name?
So instead of having twenty testing verbs, now I have one:
Verb 'Test'
* noun -> Test;
But I also have a test book:
MyObj testbook "" hldclz
with
space 1,
weight 1,
realword "",
parse_name[;
self.realword = NextWord();
return 2;
],
invent[; print "testbook";
],
react_before[;
Test:
if (self.realword == 'ak') {...}
if (self.realword == 'mans') {...}
];
What this does is make all of your abbreviations or mnemonics synonyms for the book itself. If you were to pick it up, you could type ‘get ak’. However, since you don’t care about manipulating the book, only testing sections of code, the physical aspects of the book are immaterial; you can call it anything you like, and as long as what you name it doesn’t collide with any real objects in the game.
This may not be strictly necessary, but it makes for elegant code that can easily be turned off when debugging is over, with the usual #ifdef DEBUG / #endif; wrapper.
Expressivity of Logical Constructs
Concise code becomes more and more of a necessity the longer the project becomes. While you can wade through inefficient code when there is only a small amount of it, doing so when the project is immense is something you do not want to do. The latter wastes time and makes the code difficult to understand, which impedes finishing the game and makes debugging a nightmare. To cut to the chase, to make long games, you must use concise code, and to make concise code, you must leverage the expressivity of logical constructs.
Now, to make concise code, you must first notice something about the expressivity of the logical constructs provided to you by the language that you are using. INFORM and many others provide booleans, which can take two possible states. Booleans are easily readable but not very expressive, for that reason.
Integer variables are multi-state; that is, they can take on the range of values that belong to integer numbers. These variables can express far more than two states, which makes them more expressive. However, some readability is lost when using them. Compare two implementations of a wand that must be turned, expanded, and charged prior to use:
turned false,
expanded false,
charged false,
react[;
if (self.turned && self.expanded && self.charged) ...
!-- 1 = turned
!-- 2 = 1 and expanded
!-- 3 = 2 and charged
state 0,
react [;
if (self.state = 3) ...
Let's leave aside the difference between the two, where in the boolean example the states can be wholly independent of one another and in the second, they are presumed to be part of a sequence. I've found that a sequence generally mirrors the real world of objects more closely than a situation where everything can be done in any order at all. For example: driving a car. You can't put the key into the ignition before you get in.
However, note that the integer variable is less readable. This loss of readability may be why languages such as C, C++, Java, and so forth came up with enumerated variable, which allows you to define the states that a variable can take. I really wish INFORM had this.
The only thing you can do in INFORM to approximate enumerated variables is to define constants for each value in a range, and then use that range ONLY with certain variables (or at least use them where there is no confusion amongst variables). For example:
Constant red 1;
Constant blue 2;
Constant green 3;Object button "button" nowhererm
with
name 'button',
color 0,
description[;
if (self.color == red) "It is red.";
if (self.color == blue) "It is blue.";
if (self.color == green) "It is sea-green.";
];
You still have to unpack the meaning of self.color for the user, as the language has no concept of green, blue, or red, except as integer values.
The language should handle these difficulties, rather than making the programmer program to fit what is simple for the parser or interpreter. For INFORM, I wonder if the enumerated type is something that could be bolted on to the language, but defining constants comes close enough for now. I suppose that a regular expression pre-processor could be written to handle such things, and that could be part of the build process, too. INFORM 7 has something like enumerated types, and it’s just a preprocessor for INFORM.
Textmate Inform Bundle 2.0 for Inform 6
Ever since I downloaded TextMate, I’ve been living in coding Cloud 9. Coding DEX = Coding DEX + 5! I even bought the product. That’s how awesome it is.
However, the Inform bundle was way out of date and rather limited. I sure wasn’t going to stand for a regress in my working environment! Must have syntax coloring. Must have function listing/navigation! So I went to work, delving into the madness of regex and fiddled around a bit until the power of the Inform bundle exceeded the power of my old BBEdit Inform bundle.
Now the TextMate folks have this in source control, so it may be a while before it passes their process and becomes official. However, if you want it now, pssst…over here! Unzip this to your ~/Library/Application Support/Textmate/Bundles directory and enjoy!
All Projects Status for December 2011
It’s time to sum up where I’m at on my IF projects, mostly for my own sake so I can remind myself to get off my lazy hump.
[W] Brickhouse – ALAN
[M] Burn the Koran and Die – I7
[D] Marelithia – RenPy
[M] New Cat – I7
[D] Occupied – I6
[W] Seasons — I6/Glulx
[M] Zegrothenus – I6
The chart measures state and intensity of effort, with brighter colors regarded as more intense; green is working; red is blocked; brown is design; blue is maintenance; grey is stasis (no active development). My development process goes from design -> working -> maintenance. Stasis is a state for projects on the back burner or projects that I’ve decided not to update any longer.
Individual project comments:
- Brickhouse — Yeah, I need to get back to this.
- Burn the Koran and Die — I have some feedback I’ve been avoiding (mostly because I expect it to be obnoxious), but I doubt there’s anything left to do on this one.
- Occupied — This will be a lot of fun to write. It’s going to be a political satire of the Occupy movement. *rubbing hands together in glee* This should virtually write itself.
- Marelithia — Medieval dating sim. Ren’Py has come a long way. The big holdup for this will be the graphics, because my drawing skills are rudimentary. But I figure if I do line art and then apply a sepia filter to it, it will evoke the middle ages the way that the Avernum series does (the first four games, anyways).
- New Cat — I probably will update this again someday, but right now I don’t feel like it, due to an obnoxious review(er) on IFdb. New Cat took a good six months of my life, had no beta testers (despite several calls for them) and now the complainers show up to berate me? A hearty “screw you” to all such unhelpful people — especially when the contact info is in the game. Private emails I do a reasonably good job of responding to, but public humiliation doesn’t motivate me in the slightest.
- Zegrothenus — I have some feedback from a while back that I’m churning through. Now that I have some vacation time, I can put some effort into it.
The Frankenstein Diaries
Lately, I’ve been feeling like Dr. Frankenstein, while working on Seasons. Not to mean that I’ve been busy visiting graveyards at midnight (although that would be cool), nor that I’ve been busy stealing the dead, but rather that I’ve been hooking up all matters of distinct parts to one another. Some parts don’t match as well as I thought they would. Others must be attacked with a circular saw. Others must be finely-woven at the very depths of OR Library hackery. I’ve even found myself customizing the compiler, due to the way that I6 presents status messages (another annoyance: there’s only one way, and it includes a carriage return at the end, which prevents you from continuing status messages on the same line).
I guess that’s a common experience when you craft a large game or you craft many games, this feeling of being in an operating theatre, focused on the details. Hopefully the end result will turn out more attractive than Frankenstein, but because the effort is so gargantuan, I’ll be satisfied if it moves, talks, and can see! Along that same line, I’m up to the 21st internal revision of the code, with probably 40% more to go. And like Dr. Frankenstein, I’ve often lost heart and threw up my hands (not my lunch) in frustration. There was a period of time where I didn’t even touch the code for a year and some months.
Still, I will succeed, and it looks like probably the end of 2012, Seasons should be ready for the world. I have no idea how the beta-testing will go, but I don’t place much hope in there being many volunteers. Then there’s still the site to create, the music, the sound effects, and the hint guide (with all those lush illustrations I see in my mind’s eye). Whew. Just thinking about it all can be tiresome.
Along the way, I’ve had to heavily customize and/or create my own tools, which is more effort still, although that effort makes the remaining work easier. Hopefully some of these mods will be released when Seasons is, if not before:
- Compiler: Inform 6.3.2 patch to allow compiler messages to continue on the same line as the previous message
- Library: English.h – allow listing of just the objects on a supporter with no other verbiage
- Library: Parserm.h – allow turning off inference messages
- OR Library: Combat – a quick and dirty combat system with healing, AC, and weapons of variable damage
- OR Library: Messages_Off – ability to turn off the compilation messages for OR Lib modules
- OR Library: Physics – a harnessing of the physics extension
- Working example of Glulx game that doesn’t use Blorb
Well, back to work!
Glulx: Graphics and Sound Annoyances
It took me some time to puzzle through how exactly to create graphics and sound in Glulx for Seasons. I’m using I6 + ORLib + Gwindows which makes me insane already, right? Anyways, it turns out to my benefit that graphics and sound really aren’t touched by any of those aforementioned libraries, so there weren’t any weird conflicts to puzzle through. However, neither do any of these really cover or describe how to do sound and/or graphics (Gwindow’s optional GSound is extra-bulky and really doesn’t explain what it’s doing). So, I’m left on my own, trying to figure all this out. Long story short: I did, but not without running into five annoying things along the way.
Annoying discovery #1: MacGlulxe (for OS 8.x-9.x) does not support sound. Although that initially enraged me, I quickly accepted it as typical. I already knew that it didn’t support Unicode. I guess the designer just figured to skimp on something as unnecessary as sound, too. Sigh. This means that my design platform must be OS X, to be specific OS X 10.5, on the fastest 17″ iMac that Apple ever sold. What can I say? I <3 the screen size and the form factor.
Annoying discovery #2: How you name files is critical. Yes, I’d read Roger Firth’s Glulx page, and Doe’s Glulx for Dunces, and even Emily Short’s Glulx page (I was desperate), but it still took me a lot of trial and effort to figure this out.
In short: if you are not going to Blorb your game on the Mac, the filenames must be EXACTLY like this: PIC# and SND#, where # is a number. Also, you must start with number zero for whichever resource you use first. On Mac OS X, this means that you must do a Command-I to remove the extension from the file. On the Mac side, the resources cannot have extensions! Roger Firth’s advice was dead wrong.
As for sound, I had read that the only files supported are OGG, MOD, and 8-bit AIFF files. AIFFs definitely work, although I think that all Glulx interpreters downsample all AIFFs to 8 bits. Even if that is happening, it sounds good. You still have to do Command-I to remove the extension, though. Going forward, I’ll probably use OGG to save space.
Annoying discovery #3: Zoom doesn’t support sound. This one blew my mind. Zoom was my favorite interpreter, due to its interface and design. However, none of its Glulx interpreters support sound. Why? I don’t see any reason for Zoom to be crippled this way. That resulted in me switching over to Gargoyle for my interpreter of choice. It’s the best cross-platform interpreter out there, and it will make distro of Seasons a bit easier as well (one interpreter to rule them and all). In short, the interpreter designed for the Mac does not support Glulx sound, but the cross-platform one does. Weird.
Annoying discovery #4: No-one gives an example of a Glulx game that is not Blorbified. Yeah. Everyone assumes that your first intro to Glulx means that you will be going through all the extra steps to create a RES file and Blorb things up. Geez, people, why just not assume your intro to Calculus means that you’re playing around with Fermi’s equations, too? Talk about infuriating.
PEOPLE DO NOT LEARN by choosing the most difficult task in a new area. If you present information this way, they give up in frustration because they simply don’t have the experience or the knowledge to get anywhere. People learn by mastering smaller tasks, which gives them the confidence and understanding to master the difficult task.
What I’m going to do is to put the sample game that I created out on the Web complete with a sound/graphics resource so that you can compile it to Glulx and it will run — no questions asked. Then you can see exactly what you have to do to make it work.
Annoying discovery #5: The best Blorb tools are Windows-only. There is no tool that allows you to give your resources names other than SND# and PIC# on the Mac side. The only reasonable tool that I found for creating Blorb files was gBlorb. It does work and it is cross-platform, but your source code still can’t use identifiers like “autumn_sound”, like Doe does in Just a Dream. Sigh.
Now someone will say, “There is source code available!” Yes, and if you’ve ever tried to compile source code, then you know the nightmare that awaits you. You can spend days setting up your environment and building the thing only to have it fail due to an assumption in the code that prevents it from compiling on your platform. I’ve been there many times, which is why those words don’t work on me!
Still, I threw a few minutes at it. iBlorb needs dos.h, which is a collection of DOS functions that can’t be ported to other platforms, unless “porting” = “write equivalent OS-dependent code from scratch.” Loverly.
That leaves cBlorb, which as part of I7, is wholly undocumented. I guess I’ll see if I can deduce how it blorbifies a game with pictures and sound and go from there. Sigh.
You are Obsolete
Reading this, I’m reminded of some of the most passionate yelling in a song ever — Project 86′s Breakdown in 3/4: “Now so obsolete!” I wasn’t aware that a locked door was necessarily a (ooh, cue trendy word!) trope, or that score itself was a trope. I’m no stranger to IF, either, so I’m looking at this with mouth agape, slack-jawed wondering. I guess this is one of those moments where I’m a guy amid a wasteland, holding his head together with his hands, because nothing makes sense anymore. “You were so right to write me off.”
Perhaps score is a crude indication of progress, but progress is foundational to narrative, because narrative begins in one place and proceeds to another. Even circular scripts like Chinatown deposit a limn of understanding, a realization, a weary knowledge that you have learned something in all your trials. I don’t understand the war on score.
I’ve never been the kind of guy to just redo what others have done in some mindless-slavish imitation. My words are my own; my worlds are my own; those I admit to them are just visitors, people who probably shouldn’t be there, like visitors in a museum after it has closed. There’s an unsteady relationship, I admit.
Nevertheless, I don’t feel like Inform6 was a caterpillar and Inform7 is a butterfly. I think of Inform6 as an old rifle, that you had to pack with gunpowder: potent, complex, and rife with the possibility of self-injury. Inform7 I think of as Voyager, only I am the alien, and I am looking at these tablets and hearing this tinny voice repeating words that I have no possibility of understanding. The documentation is like reading the self-justification of very small tree mites who live only on the leaves of trees and imagine themselves conquerers of the world. Maybe it makes sense for a certain kind of game written by highly intelligent and strangely thinking people, but as for programmers, it makes no sense at all. “Obsolete, obsolete, we’re so obsolete.”
The Brittleness of Inform 6
One thing that hit me this week was how incomplete Inform 6 really is, and how unfinished it still is, years afterwards. Here are just some of the problems that made me spend hours and hours in providing workarounds, when I really shouldn’t have had to.
Objects automatically generated from a class. Really, Graham? So if I leverage these, there’s NO WAY to tell them apart unless I cook up some wacky global variable scheme? If I want to have six empty flasks in a game, what do I do? Create six almost-identical objects by hand and then test for them each time? Or create the same nearly-identical items but make them part of a class and test for the class? If it’s the latter, then there’s really no value in having a class that autogenerates items, except in a very, very restricted context. (You try and have six autogenerated objects that the user can add things to, and then try to figure out which item the user wants to get. It requires so much time that it’s basically impossible. I gave up.)
The verbs. I ended up touching an incredible number of verbs in order to handle silly situations like taking items already carried by the player, referring to items that were inside of other items, and so on. That leads straight into the next two issues.
Did you know that there’s a bug that’s seriously hobbled the Inform parser for four years? I didn’t. What happens is that if you try to verb noun 'filler'/'preps'/'here' noun and don’t specify the last noun, the parser naturally asks you ‘with what’? If you provide a ‘what’, the resulting re-parsing request doesn’t fill in the noun as you’d expect. Oh no. It adds in the noun ‘it’ and tosses in the noun, which ensures that the request fails. And there’s no real solution to the problem.
The total number of words per grammar line issue. Apparently if you have a grammar line like: verb noun=routine 'filler'/'preps' noun, the total number of words in this line MUST be greater than the total number of words in your object’s names. If it’s not, the line will fail and you’ll end up with some weird error coming from a multiexcept or whatever else is further down in your grammar. I didn’t see that one coming, either. So what you can do is make sure that your nouns have short names that are always two words or less, and expand your filler preps to three or so.
The brittleness of Inform really annoys me. Heck, even that wouldn’t bother me IF the people that maintained it actually responded to bugs, fixed them or allowed others to, or generally cared! Seeing as they won’t and apparently never will, all I’m left with is my angst.
Maybe I’m just not good at designing classes (which is possible but even that goes only so far), but it seems as objects are added linearly, the work involved in making the game realistic rises exponentially. Each new object has the ability to interact with all other existing objects, and even relying upon standard responses from the classes of each object leaves the world feeling threadbare and spartan. The language itself does not help you in this regard; and there are no tools to handle this. It’s like all Inform authors do one of three things: 1) write very small games 2) take forever to produce a game 3) write spartan games. Each of those three positions is a retreat into substandard authoring. Yet, that’s been the way Inform has been for years, without any letup in sight.
So where do I go from here? I have one more project using Inform 6, Seasons, which is another epic kind of game, so I wonder if it’ll ever be done. I had read some time ago about how TADS requires a steeper learning curve, but it can handle larger games better because of its ability to handle the complexity explosion, whereas Inform degenerates into a sea of particulars. I don’t know to what extent this is true, because that issue can only be handled so much by the language; some of the complexity is just the nature of IF itself. All I can say is that there’s some evidence for the degeneration, based upon my experiences above.
I don’t want to throw all my work away and just move on to a new language; I really don’t operate that way, but I’ve had an eye-poking-out festival of pain with the parser that makes me never want to do that again. The only options I see are to move on, or to rewrite the parser to do what I feel it should. People have done the latter, in Platypus, but even Platypus is dead. So do I throw more time after the time I’ve already spent in creating some custom solution? Although it appeals to the tinkerer (ok, geek) in me, I just don’t think that’s a good use of time. Others have done a better job at writing parsers than me, so shouldn’t I just leverage their experience instead?
That leaves TADS, Alan, and Inform 7. I’ll be exploring each of these more in the games ahead.
Zegro is Submitted!
Yes. After weeks of 5-hour coding marathons (and holding down a day job, of course), Zegrothenus is submitted. Note: I didn’t say done, but it does all of the following:
- Compiles
- Runs
- Can be won
- Has a list of commands that enable it to be won. Gah, a walkthrough? Yes, my first, but it’s part of the submission requirements. I’m so glad I used the REPLAY command!
- A 200×200 game badge. This one I whipped up at 12:06 AM, and submitted separately thinking that I might still hit the deadline. Then I re-read the submission requirements and found out that I have until TODAY.
Anyways, it really chaps me that I underestimated the amount of time to work on this. I still might fiddle with it some today, but I’m sooo burnt from it all that I don’t expect to be doing much IF anytime soon. (Sorry about that, my games-in-utero).
Maybe it’s Inform6, maybe it’s my hyper-attention to implementing basics of nearly every object after having been burned on that in Building, but sheesh — this was way more effort than I expected. In the end, I had to cut the size in half, and strip out all of the in-game help that I was going to do just to make the deadline. I’m not a newbie, either! I used the scaffolding for Seasons to jump-start me, and I know how to organize the files and such.
Still, I totally didn’t foresee my laptop taking a dive a week or two from the deadline. I lost two days of work and was only able to restore it today, one day out. Thank God that the Diskwarrior got here at all, that it worked, and that BBEdit had a nifty compare tool. On that last one, who knew?
But what I’ve learned is the following (in case anyone wants to learn from me and not do things the hard way):
- Whatever amount of time you think a game will take you, double it, just to make sure you have enough time for beta (oh, that’s another thing. Zegro had NO BETA period. Uhm. Let me shuffle away into the shadows now!)
- Reduce the number of files that you have to work with if at all possible. The reason for this one is that you can fit multiple files on a screen easier if there are few of them. Also, it makes looking for that object or routine a lot, lot faster, especially if you think that finding it is right around the corner and you manually hunt through files first.
- Don’t play around with your hardware setup during a game. Seriously, resist the urge. If it goes wrong (and it probably will), you’ll lose valuable time and maybe some irrecoverable bits of sanity. I got the wild idea to make my laptop computing completely silent by running off of a CF card instead of a hard disk. Somehow the master boot record got hosed and I had to order software in order to fix it. In the meantime, the laptop was DOA and days of work vanished into the ether.
BBEdit Inform Tools 2.0
Merry Christmas! While working on my latest game, Zegrothenus (or Zegro as we call it in house), I realized that one of the things left unfinished in the BBEdit Inform language module was a listing of the functions. Armed with a week of vacation, Starbucks coffee, and not bothered by any outside interruptions, I went to work. The fruit of this labor is BBEdit Inform Tools 2.0.
So what’s in the new release? First of all, a function listing! Yes, it finally works, with a few caveats. The functions only display if you set the preferences to display them alphabetically. Also, the “show current function” erm functionality doesn’t work. Fixing these requires access to code that as far as I could determine, does not exist. All the existing language modules don’t state how to obtain the values that BBEdit requires, so it will probably never work like the built-in language modules. Oh well. The important thing is that now you can quickly jump to that odd-named method without having to scroll through the entire document or using find to find it. Second of all, the comment coloring works correctly (yeah, alliteration!). The standard ! works for comments; you don’t need to use my !- idiosyncrasy anymore. Lastly, more keywords have been added, primarily action_to_be and lockable.
Unwrap the present here. (For BBEdit 6-8.x, Mac OS 8-9.x).
