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.
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.