Wednesday, September 21, 2016

Spellchecking your WIP: instructions, and a question

I've realized that spell checking can be tricky to do for a tester on the other side. It can also trip them up if there are bad typos. So someone I was testing for, for IFComp, asked how I was able to do it for them, for a twine game. This may seem late in the game for such a post, but I think it will give high value for the time it takes. So, have away!
I have Windows, so I run Notepad++. Which is a really awesome app if you don't have it. Worth the install time and not just for this spell check.


Right click to get the source of a twine game, then ctrl-a, copy and paste. Then paste to a document in Notepad++.
Do ctrl-f to find, then click the "regular expression" radio button.
For what to find, type <[^>]*>
This translates to <(bunch of HTML tag stuff)> but nothing outside the tags.
For what to replace, type \n
Replace all

Then I ran the native spell checker in notepad++. ctrl-shift-alt-s.

You may have to also define c:\program files (x86)\aspell\en.prepl as not read-only in windows explorer.

INFORM 7: was a BIG help for me.

Ctrl+F --> go to the Mark tab --> toggle Bookmark line --> Click Mark All. (you want to search for say ")
Select menu Search --> Bookmark --> Copy Bookmarked Lines.

Then you can replace say " with nothing, and \[[^\]]\] with \n, and then spell check as before.

If anyone knows a good text editor this works for with Mac, that'd be a big help.

Sunday, September 11, 2016

Grubbyville Postmortem

Well, it was nice to be able to place, which was my competitive goal for IntroComp. Thanks to Jacqueline Ashwell for holding and organizing it, for so many years.

But what about creative goals?

It's always a bit frustrating to read criticism of stuff I should know, or I thought I fixed or looked at, and realizing--yeah, I didn't quite nail that down. And that's what I got from various reviews. Part of this was picking the project up maybe a week before the deadline, after a lot of on and off futzing, and a few years' failed entry.
So I'm grateful to my testers for helping me cut down a lot of extraneous stuff (enough I won't detail here) and for their positive contributions as well. One bug that slipped through was a special case I could/should have checked for. I'll describe it later. Doing so now immediately after seems like a backhanded compliment to my testers.

It was nice to be on the other side of the criticism, which was civil and helpful. And a note: there was more than enough, but I think IntroComp is a fantastic tune-up for IFComp judging: less pressure, no dreams destroyed, less of a big deal if you're wrong, and because your complaints are anonymous, that can help. Even if it's not a major one, it helps the writer. So I really hope to contribute feedback at the very least next year, and hopefully reviews to push Introcomp as much as I can. Being on both sides of the competition has been very positive for me, for relatively less investment than IFComp. Maybe it can work for you, too.

As for the game: Grubbyville is almost based on a real story. I remember the Valedictorian Wars at my high school. Two years ahead, someone got a B+ in Health, costing them the #1 spot. One year ahead, someone got a B+ in Food for You (no! Really! They apparently smart mouthed the teacher. On a more serious note, they were icky and manipulative to the new #1, and when someone reminds me of #2 that is a huge red flag) costing _them_ the #1 spot.

Friday, June 3, 2016

More on Zarf's testing scripts: automating yes-no, and debugging

One problem with Zarf's scripts is that they hit a loop if there's a pause without a > for a cursor. This isn't unique to them. The IDE can trip up, too. Or maybe you just don't want to remember when to say yes or no.

This is the sort of Inform 6 dabbling that I think helps you understand what's going on without getting overwhelmed. Below is code cut from the Trivial Niceties extension I use for testing.

volume yes-no substitutes

[this lets the programmer skip over yes/no decides]

debug-state is a truth state that varies.

to decide whether the player yes-consents:
    (- YesOrNoExt(1) -).

to decide whether the player no-consents:
    (- YesOrNoExt(0) -).
[ YesOrNoExt yn;
    if ( (+ debug-state +) == 1)
        return yn;
    return YesOrNo();

Let's go over what this does. First, YesOrNo() is the standard Inform function for getting a yes or no from the player and moving on. If you want to see its details, it's in Parser.i6t in the reserved folder. It's worth a look to see that it's not terribly intimidating.

YesOrNo is pretty straightforward, and you can change the 'Please answer yes or no' message if you want. In fact, I did so in Threediopolis. You can search for EdBlab here in its source, though I may not detail it here. You can also see how to insert Inform 6 source into Inform 7 code. Not that I did a brilliant job of it, but yeah. It's not THAT esoteric if you want to change the default message or cut the player off after X tries.

So what do yes-consent and no-consent mean? Well, yes-consents goes to YesOrNoExt with a parameter of 1. If debug-state is on, it returns 1. If it isn't, it returns YesOrNo--which is 1 for yes and 0 for no.

I also defined a function called switch-consents which means the user can set a flag to decide whether or not to make yes or no the default. And I suppose the yes-no automation variable could be separated from debug-state.

Because I've actually defined debug-state earlier in the extension, and it's useful for other things, such as

to d (x - text):
    if debug-state is true:
        say "DEBUG: [x][line break]";

This is handy for, well, printing debug values when something doesn't quite work, or just making sure you have the right row in a table when the text is constantly changeing. It also is a great way to be sure that the end-player won't see these commands. After a while, typing d has become second nature for me when I've wanted to include diagnostic stuff. As long as we have this sort of section:

chapter debug setting - not for release

when play begins:
    now debug-state is true;

dbting is an action out of world.

understand the command "dbt" as something new.

understand "dbt" as dbting.

carry out dbting:
    now debug-state is whether or not debug-state is false;
    say "Now debug-state is [debug-state].";
    the rule succeeds;
We're okay. The point is that, well, the programmer can toggle debug-state, but the user never can.

This is only the surface of debugging, but I think it's a good start, and it helped me worry less about "what if it slips into the game text" or other issues. I've had it so long I've almost forgotten about it, but...a little I6 can go a long way, so it's good not to be scared, and to explore (if you haven't already) the Standard Rules.i7x file or even the Parser.i6t file.

I felt pretty clever making my first I6 edit to make Inform do what I wanted, and once you have a bit more you want to do, you will, too. Just remember to use the "include" syntax instead of editing the core files.

This can similarly be applied to skipping over narrative breaks, which I did so that the "test" commands wouldn't freeze. Emily Short's Basic Screen Effects needs to be included, but once you do, you can replace wait for any key with wait-key-d, or something even shorter, if you want.

include Basic Screen Effects by Emily Short

volume regression test - not for release

when play begins:
    now debug-state is true;

volume regression test stubs

debug-state is a truth state that varies.

to say wait-key:
    if debug-state is false:
        wait for any key;

to wait-key-d:
    if debug-state is false:
        wait for any key;


Wednesday, June 1, 2016

Applying Zarf's automated testing scripts for Inform

Zarf's script is something I wish I'd tried much earlier. It had the added bonus of helping me learn python. As wonderful as the Inform IDE's "test" command is, it has limitations:

* no undo, which is sort of a problem if you get killed
* only one test run, with restarts being awkward
* can't check the content

I've been tinkering with this in my own games, but I think I've found a sub-script that's flexible enough to share with others. Eventually I'd like to do a whole post on using Zarf's framework from Windows, but for now, here's an idea of how to get things rolling if you have the framework up.

It's one of my favorite axes to grind, fixing the "You can't go that way" generic command. It's always meant restriction more than exploration to me, and changing it helps me develop my world, and I look for it in games I test. So here is my Python script:

This needs a text file in the same directory, labeled reg-noway.txt, to start. I ran this test on The Problems Compound, which had a test file at converted from

You can see the general syntax--just list the name of the rooms, and adjust the binary names accordingly. Obviously, this can be more flexible as I build the script, but the main thing is that it will take a text file full of rooms and spit out a bunch of tests. I like this because insta-death movements are neutralized, and the "undo" means you can try a different direction right away.

I also disabled diagonal directions in some games, which means a lot fewer tests need to be run.

But this only does so much. You want a working walkthrough, with the right clues. So I spruced up and just made sure everything worked okay...and it turned out I had a few typos to look through.

Thus my fears of just doing-over work I already did, and not really getting anything, were misplaced. I even tuned up some double-text I should've seen before. I think just the process of sitting down and creating the test cases switches the focus from "I should've tested this, I think" to "I'm going to make sure I tested this." And if I cheated with some GOTO commands, well, I was able to cover the major walkthrough and check off on more than just "you won."

It's already helped me fix a few trivial annoying bugs, because I could just slip in a test and say "OK, does this work? I'd hate for this to break." And so I've gotten a lot of mileage. And I suspect it'll help you, too, but I'll write more later.

Still, the short take-away is: do it on a game you want to re-release. Or a WIP. It provides a lot of security that stuff you fixed will stay fixed. Or you'll know when it broke.

Three chances to sac my queen in chess

I ran across an old chess game from the past. If the ghost of Mitch Hedberg were around, he would say <a href = "">every old chess game I played was from the past. (I used to like that joke. I still like it, but I used to like it, too.)</a>

Anyway. It wasn't a very good game, but it was much more instructive than if I'd done what I was supposed to and won it quickly. Let's look at the start.

1. e4 e5 2. Nf3 d6 3. Bc4 a6 4. d3 (d4 is a good idea, but...I still just sort of got all my pieces out and didn't try anything crazy) h6 5. Nc3 b5 6. Bb3 Bg4

Black hasn't bothered to get his knights out. Now, I remembered Legal's Mate, but I also remembered that if you did it wrong, you just went down a piece and were kind of in big trouble and your coach and teammates probably thought,  gee, what the heck were you doing? (Note: this sort of thing can get in your way with general creativity. There are things to check off on. But it's a legitimate fear, and one that needs to be dealt with.)

The right move, here, is 7. Nxe5! because of Bxd1 Bxf7+ Ke7 Nxd5#. And it's a weird thing, here. Every chess player dreams of sacrificing a queen for a quick win. But I remember talking myself out of it: well, it's not an ORIGINAL sacrifice. Well, I'll feel dumb if I get it wrong. And I don't know when it happened, but at some point, I stopped trying for cool stuff and started grinding out wins. I was still a pretty aggressive player at this point, but...well, not this game.

7. h3 7... Bxf3 8. Qxf3 Qf6 9. Qxf6? Now I still had a big advantage, and Qe2 or Qg3 keeps queens on the board and also still threatens the annoying Nd5. So I am letting him off the hook and letting him get his knight in the game. Even an immediate Nd5 is rather good, but I don't know--I think I was learning about endgames and so tried to steer the game that way.

9... Nxf6 10. Nd5 Nxd5 11. Bxd5 c6 12. Bb3 a5 13. c3 Na6 14. f4 (this is rather good, giving the rook an open file) b4 15. fxe5 dxe5 16. Be3 bxc3 17. bxc3 Rd8 18. O-O-O Ba3+ 19. Kc2 Bc5 20. Bxc5 (this is where d4 really should have been obvious) Nxc5 21. Rhf1 Nxb3 22. axb3 and I felt I could gang up on the a-pawn and win and I did but it took way longer than I should have. The main moves aren't important here--it's that I'm trading down and not giving a weaker opponent a chance to mess up. As if I was running from the position with lots of pieces where I didn't want to face my chicken-ness.

Now I learned a lot from this game, with the endgame small advantages etc. And overall, it was favorable, though being exhausted may've cost me in the next two rounds. I got a bad position in round 2 then lost a tricky (but again instructional) game in round 3. So, yeah, I remember missing my chance. I remember fearing my (kind of sarcastic) chess coach saying "Mi-i-i-ster Schu-u-u-ltz! What took so long?" and also fearing him asking about why I didn't play Nxe5. The thing's something I wished I'd nailed down. But I sort of let my fears trap me. And I didn't really do much after that.

And so I remember this when I think about missing chances or not going with what I know or intimidating myself into going for the safe route without checking off. But the story doesn't end sadly.

I eventually did get my queen sacrifice later. It was actually a sham sacrifice--in other words, I got the material back quickly. But then a month later I had a chance for the real thing, and I took it, and it was glorious. It was a positional sacrifice! The guy next to me said he was glad I had the guts to play it! The end of the game was ridiculous--I pitched a bishop in a winning position, then my opponent pitched a rook. But--I got my queen sacrifice, and it was my own. Let's not worry about the opening play too much.

1. c4 b6 2. Nf3 Bb7 3. g3 Bxf3 4. exf3 c5 5. d4 Nc6 6. d5 Nd4 7. Bg2 Rc8 8. O-O g6 9. Nd2 Nh6 10. Nb3 Nhf5 11. Nxd4 cxd4 12. Bg5 Bg7 g4 Nd6 13. Qxd4 Rg8 14. Bf4 Bg7 15. Be5 Rxc4 16. Bxg7!? Rxd4 17. Bxd4 f5 18. Rfe1 Qa8 (he really should've played Kf7 etc. It looks ugly but it starts to untangle. King safety first, and ...b5 can develop the queen) 19. Bf6 Nc8 20. d6 e6 21. Be5 21... Qd5?! (...b5 and Nb6) 22. f4 and I'm having all the fun.

The sham sacrifice is below. In this game I went up a pawn then my opponent won an exchange for a pawn, but I had two passed queenside pawns, so I won material back.

I remember this when I talk myself out of something good, or if I think I might be about to. It's a good way to check off. You never know when good fortune is going to happen--but it occurs to me I never gave myself a chance to make another queen sac. I just didn't play aggressively enough. Well, there was 1. e4 c5 2. c3 d6 3. d4 cxd4 4. cxd4 Nf6 5. Nc3 Nc6 6. Nf3 Bg4?! 7. e5 Ne5 8. Nxe5! but that doesn't really count (Bb5+ gets it back.) Still, you take what you can. The only reason I'd return to tournament chess is to get one more queen sac. That'd mean playing aggressively, with confidence, and so forth, and not second guessing, but having fun calculating to make sure of things.

Sunday, May 29, 2016

A 15-year-old question

Yesterday I asked a question on stackexchange's mathematics subsite. It was about a problem I thought up 15 years ago, and I got the basic stuff done, and I got stuck along the way. I wouldn't have remembered it if I hadn't just signed into one site and poked around.

I wondered when you could make a big n-sided equilateral triangle of pennies together from groups of 3 pennies. I suspected the answer was 12x+(0,2,9,11) and proved it worked for them but couldn't find a parity argument for 3/5/6/8. Maybe if x was large enough, there was something.

It was fun to mess with and I even wrote a brute force script to try things out. But I put the problem aside after a few unsuccesssful googles (I got the puzzle where you have 10 pennies and need to flip the triangle moving 3, and so forth) I figured why not.

And got an answer in an hour. Not only an answer, but one that pointed me to John Conway's work. I'd read about him and how important he was, etc., but my eyes glossed over. Here, though, there was a paper based on his work that solved a neat problem I'd wondered about.

I haven't processed it totally. But it's nice to know my intuition was right even if my technique never stood a chance. The basic idea is, you can build the triangle with 3-rows of pennies or triangles of pennies. If you build it with an odd number of 3-rows one way, that is the only way to build it, and you can't build it from triangles. But with an even number, you can. I'd had that idea but had no way to prove it because standard tilings like the checkerboard problem fell short.

There's a small moral here about asking questions and not waiting too long. I can box myself in with the "I should know this" and I've even become more comfortable asking those I should've known. Because in some ways it's not me asking the question but someone trollish from years ago. And once I asked the question I thought, boy I'll feel silly if someone responds quickly, because time wasted, and boy I'll feel silly if nobody responds.

So, on to the next question I've had for a while. Or maybe even one(s) I've forgotten.

Wednesday, May 11, 2016

Fourdiopolis/Spring Thing 2016 postmortem

This postmortem has spoilers for Fourdiopolis and Threediopolis. The TLDR is, I had an idea and waited on it a bit too long, but thanks to Spring Thing's forgiving format and rules, I pushed through with something I'm pleased to have finished, and I wasn't much worried about reviews, posterity, etc. But I'll have to do better preparation to enter IFComp.

Hanon Ondricek pushed me into it at first. His fake review of Onediopolis (we had a nice long thread for fake reviews) in the 2013 IFComp authors' forum got me laughing that it wouldn't be much of a game, and
neither would Twodiopolis.

Fourdiopolis, though? No! It'd be too tough to choose directions! It occurred to me that there were 20 choose 4, or (20*19*18*17)/(4*3*2*1) possibilities. 4845 in total. And teleports, well, they just SCREAM future, so they're perfect for a sequel.

I'm going to go with the technical stuff, first. If you want to skip it, search for the equals sign.

@unusedLetters = ('a', 'b', 'c', 'f', 'g', 'h', 'i', 'j', etc);

for $a (@unusedLetters) (etc)
grep -i "nsewud$a$b$c$d" files.txt | grep -i "[$a$b$c$d]" > "$a$b$c$d.txt"

Where files contains first names, last names and words.

I suppose I could have run a script to track all of them, and see which would've given enough words without giving too many, but I figured I could cut down on them by looking for obvious opposites. Kata and Ana fit the bill, as did From and To. Which way would From be, and which way would To be? And what would their displacements be? And how would they fit on a 10x10x10 cube? Some neat locations were sure to go out of bounds if the teleporters led anywhere interesting! And if they didn't, how were they different from walking?

These obstacles were too big to overcome, so I put the idea aside. But maybe something was there.

Then it hit me. I could make the city bigger in the name of progress and global overpopulation. That's always a good one! I just needed to know how--and the break came when I realized the locations didn't have to go 0, ..., 9, a, b but I could put 000 at the center. I remember Threediopolis slid by with you starting at 444, which is not the center but it said it was, until Jenni Polodna called me on it. I laughed a bit, because her reviews are good for that, then I fixed it. So it felt good to have a bona fide center.

So I felt having i..a 0 1..9 was also intuitive enough. It made things bigger. But I still had to decide on direction names! One thing I let trap me was that Inform wants directions to be opposite. Down/up, in/out, etc. But they don't have to be. I had an idea for a pinwheel sort of direction-collection, but I was just stuck on four moving directions, and rotating four moving directions through three physical directions didn't work. So stuff like +2x-2z, +2y-2x, +2z-2y was appealing, but I felt I needed another letter.

And so I thought for a first try I might have the four teleport directions be +2 x, +2 y, +2 z, -2 xyz. Or with the signs flipped. This was...symmetrical enough.  The most used letter would be the one that took all three directions. But it still felt a bit artificial. I mean, the game's ideas are, at their base, artificial, but it seemed like a pain to remember which direction was which. And how would you sort out the +2x directon from going east twice? And would the -2xyz be too obvious?

So. Teleports that kick you far enough away that they aren't confused with walking, well, at least until it gets hard. And some sort of symmetry. This was a tough one, but it wasn't until I saw a pyramid that I had a bit of an idea. What if each transport leap was at the edge of a regular pyramid? Where would the center be? I still had the idea +2+2+2 would be a good leap, and suddenly I saw -2-2+2 and the three others--well, every one was the same distance!

So I had my directions. I declared pairs (H/I and J/K) as opposite though they weren't. As for not being able to reverse? Well, pseudo science fiction mumbo jumbo takes care of that. Just--what if two people transporting the opposite way ran into each other? Too much risk. So that was solved.

I had trouble with the directions, though. But then I was reading about, well, something. Maybe it was Galois theory and why there's no quintic formula. But I recalled the Quaternions. And cross products, and so forth, and how IJ=K and JI=-K and so forth. I liked them, and both HIJK and IJKL gave a lot of results. They were equally enough matched that I became the donkey between the two haystacks. Well, not really, once I saw L would get confused with LOOK. Not much to do about I and Inventory, though really, you weren't going to HAVE inventory in the game.

I ported the Threediopolis fake-moving code over (did I mention there's only one room in each game?) made sure SID showed an entry and gave you a point, and then put it away til late March. The thing was, I had a vague idea that 100 things to find would be too much until they got too easy. It'd crowd out your inventory, etc.


The story took a long time to get going. I liked the idea of more friends--finding people is good first. And the idea of finding things: who wants what? Why? Supplies--what for? I didn't want some rich random guy telling you what to do, so I decided to go with the opposite route. You needed to escape detection. Doing things with technology was traceable. But I didn't want a super-big table that just sprawled, as that'd be a pain to search through, even if alphabetical listings would make it easier to track the next clue the more you had. Maybe smaller tables could organize things. And I just decided on 20, which turned out to be a perfect magic number.

I also might not have had an idea how to wrap things up if I hadn't grepped my last-names.txt file with nsweudhijk. But once I did, it seemed like a nice evil final puzzle, if you liked the rest of the game.

But all this took a while, even with a handy test file of all the possibilities. There was stuff I could've been doing even when I was deciding this. Okay, I wrote a rudimentary script to make sure a word-path didn't go outside the city bounds, Sorry, "hehheh" and "huhhuh," I need another way to make that Beavis & Butt-Head reference!

Just porting Threediopolis code to Fourdiopolis would've been big, though. Writing random stuff or helper functions or game text in. This doesn't seem big, but it has a way of building up, or making me feel at least I didn't forget (insert basic thing here). And if it doesn't feel inspired, it organizes things so I can just drop any inspiration in. And I brain-locked myself by saying, well, I'd better be working on the biggest thing, but it wasn't clear what it was. I didn't just hack ahead to see it--and I should've had faith I could get it done with steady progress. If I'd used my "off-days" to paint the corners, writing in commands or stubs big or small, I wouldn't have been worried about those details while writing the big stuff. This is non-technical stuff, about doing what you want with the time you have, instead of wasting it with something no longer (or never) fun that's just easier to start.

I didn't motivate myself to work on 4dop at the start, and it all piled up at the end once I realized it may be intimidating but I didn't want to leave it for another year. The result was several days of intense programming. And the stuff I was scared about? It wasn't hard to port from 3d to 4d, because I'd already made the big technical mistakes I wouldn't make again. And it would've been simpler to do so back in January, where if I made a mistake, I could just kick the can to tomorrow or next week with no stress. I had experience, but unfortunately, all I remembered was how long it took, when what I could've remembered was that the code worked, and cutting and pasting would get me 95% there.

Fortunately I'd taken time at the athletic club or on the bus to draw out the big picture: get a list of 20 or so different things, roughly related, and slap them together. Remember "x is a table name that varies." Change it with a save-file. This meant Fourdiopolis would have to be glulx, but eh well.

But given my silly procrastination I was grateful for the things that let me create and fix Fourdiopolis. I gave my testers something pretty, well, awful. One of Aaron Reed's "helper elves" managed to give me a mulligan to fix something pretty obviously broken. Then I started checking off what I could've done. With the few extra days, I even wrote up a script to detect clear errors in the logic document, e.g. if a location was wrong. And I wrote the logic document for more than just friends. Working through it, I realized a certain repetitiveness in the puzzle-solving. But I couldn't do much, then.

I also used bitbucket/source control before releasing, but again, I didn't use it enough. It was extremely helpful for in-comp updates, of which I had a lot. The pressure was off. I could offer a hint here or there. Or just take a feature from Threediopolis. I was aware the logic document was...rickety, but that took a back seat to actual bug fixing.

Still I got a nice list of bugs and features tweaked, and Aaron Reed let me roll in the updates, which was nice. I'm glad I took the time to mark my changes individually. I figured stuff like how to give "almost" clues where maybe you didn't realize there was a plural. I figured I'd have to put headers that listed all your tasks off until post-comp.

But...source control, again. Easy to revert if I made errors. I did some basic stuff for an hour or two, and, well, it looked okay! It looked more than okay! It was nowhere near as tough as for Threediopolis, which had modes depending on which scenarion you were in, and all sorts of toggles. With 4dop, all that mattered was the current table. I even snuck in a fix so the game didn't refresh the header *until* you found something new. This was something I'd have liked in 3dop, and it's going in, in the final release for that. Other things followed--cluing what "kinda far" and "far" meant will also go in, and even the logic document checker for 3dop got a rewrite. I found a few bugs.

So writing Fourdiopolis, which I worried would be frivolous, turned out to help me in a lot of ways: nailing down threediopolis features, really using BitBucket, and also being able to get through a project and not let it hang around. I also noticed the code was more compact than for 3dop--200k vs 120k.

And I think having that stressful week--for me and my testers--was the final straw. I set up things like my nightly build system to make sure projects, new and old, built. I even put my logic document checker in it. Any errors go right to an HTML file, so I know what's fixed, and I'm not worried what needs to be. It's already been a big help for my Stale Tales Slate (fixing bad anagrams and punctuation in my random tables, as well as flushing new random anagrams into the source--I'd written these scripts but they were a pain to remember) and Problems Compound (make sure the EXPLAIN verb tracks everything) as well as just generally making sure I've got no backlog of notes. There are a lot of tests to run, but it's nice to know what's messed up--and even to know that some stuff hasn't broken for a while.

So overall 4dop was worth my time, even though I should've spent that time better and earlier, and it was more than just something to get out of the way to clear my brain for a real game. I hope it was worthwhile for those who played it, whether you just browsed and grokked the idea or tried to solve all the scenarios. Given the bugs in the initial version (even after my helper-elf mulligan,) as well as the level of competition in the main entrance, I'm glad I put it in the back garden. But unlike Dirk, my entry last year which was clearly a joke with no real reason to go into a serious competition--even not a very intense one--4dop feels like it holds up and is a bit more lasting. If I'd prepared it better, I could've put it in the main event.

I feel like I can move sooner than from my other projects. Part of that's due to Fourdiopolis not having a lot of story nuances, and whatever technical nuances it has, I covered in 3dop. Of course, one more run through the logic document. Maybe add some more scenery, too--there's a text file with a few stragglers. But I feel like, once I got started, I knocked things down quickly enough. And writing 4dop wound up being more fun than the things I used to procrastinate it. That's a lesson, there, one I want to apply to my next work.

AutoIt: building in the Inform IDE automatically on Windows

You don't have to know much about AutoIt to do this, but I've found this helpful. You can just create a script like the following in notepad. I called the file ide.au3.

Local $project = "Compound";

if $CmdLine[0] > 0 Then
  $project = $CmdLine[1];
  if $CmdLine[1] == "pc" Then
    $project = "Compound";
  if $CmdLine[1] == "3d" Then
    $project = "threediopolis";
  if $CmdLine[1] == "4d" Then
    $project = "fourdiopolis";

run("C:\\Program Files (x86)\\Inform 7\\Inform7.exe");

WinWaitActive("Welcome to Inform 7");


WinWaitActive("Open a project");

Send("c:\games\inform\" & $project & ".inform!O");

WinWaitActive($project & ".inform - Inform");

This will open up a project and compile it. You may want to change the c:\games\inform directory, or the project name, but I hope the code makes intuitive sense. The CmdLine stuff basically says I could try ide.au3 threediopolis or ide.au3 fourdiopolis or, better yet, theshortcut ide.au3 3d, if I wanted. Awkward code, but I'm too lazy to read if hashes are a Thing in AutoIt, and what I have works.

It's handy for me as it'd be nice to be the first thing to see in the morning, so I do that instead of silly internet browsing. Or if you edit outside the IDE (I use notepad++), pushing the button here can work.

You can obviously tweak this to check for if a window is already open, but this basic script says: build every night, and have the IDE open when you get started.

A script like this may not be profound in itself, but it certainly starts things right. Now I've done it, I feel like I should have a few years ago. These things seem like they only save a few seconds, but when they're more convenient than accessing a time wasting website, they can save a lot more time.

(Note: this was updated for ide.au3 to allow a command line argument as well as shortcut text)

Friday, April 15, 2016

Nightly builds and Inform 7: release builds

This probably applies more to Inform 7 than anything else, but I like the idea of having a nightly build with tests that report success or failure. This came about as a result of me finally wanting to nail down a few things in some old projects. But I know a big trouble fellow writers have had is...they build a debug version of their story okay for months, then ... the release version throws a bug! Usually it's pretty easy to fix, but it's still a bit of panic on September 20th or so.

Now it started as just checking stuff not related to compiling.

# my source code had no [??] annotations -- shorthand for something I should get around to understanding
# test chapters/volumes were minimally annotated e.g.
volume x
book skip
[* this tests ways to skip to certain puzzles. Usage is SKIP NUMBER]
# for the -opolis, making sure the walkthroughs I wrote correspond to the entries in the tables of things to find. This only tests that what we've found so far is accurate.
# for the Stale Tales Slate, checking the viability of certain random entries and also checking for duplicate entries, as well as sorting the tables in alphabetical order etc.
## verifying that the random text is capitalized properly

This is all stuff I ran by hand but it piled up. Finally I put it all into a nightly build and--well, there were a lot of errors! But they were finally organized and helped me see other details. And I knocked things off quickly.

For instance,the capitalization I was able to break down into ALL CAPS, Title Case, Sentence case, lower case needed, and any case being okay. Maybe you have other tests you can run. Apparently linux lets you run tests on a blorb from the command line somehow & that would be the next part of my nightly builds, to make sure nothing breaks.

So, the moral? It may feel silly making a nightly build to track your projects that are "just games" but it helped me take care of a bunch of details I'd let sit for a long time.

Now, how to do this? For those with Windows you can have your Task Scheduler send output to a log file, or even reparse it to an HTML file, every day. Then you can see if release or debug builds work okay. (I don't use the IDE for when I'm writing narrative stuff. I just check what's changed with Git and then test that all in one bunch.)

You'll have to change the name of the project, obviously. And if you are using zcode, you'll want to see the different flags in the "progress" tab of "errors." The below compiles for glulx.

Tuesday, April 12, 2016

A year of Github

So I made my first commit to GitHub a year ago. It wasn't much, but the daily streak eventually helped me to REALLY get going.

Since then, I've

* made documentation and code changes to Trizbort
* made repositories for my 2012-2015 IFComp games
* also merged in my 2013 Spring Thing game with 2012
* created a miscellaneous files archive for all kinds of things
* copied over some of my old RPG map creation files
* made 1000+ changes
* started an almost 5 month + daily streak

This is a lot, and I can't call myself a GIT wizard. I just know the basic commands. In fact, I have a cheat sheet for some of them below the cut.

So why am I posting this to planet-if?

Because many people I know have questions. They wonder how to get started. They think it'll be impossible.

But I think the way to start is to say, okay, I want some sort of backup so my files don't get lost. I'll push to it. I don't care about anything else. Maybe I'll report an issue. And then build from there. That's how I did it. Just pushing trivial changes, maybe even starting with something silly like an EctoComp entry where I needed to clear up typos.

The drawback is that I've neglected bitbucket, which doesn't have that small nudge. But I've done well with modifying my current Spring Thing game as well as my possible IFComp 2016 game.

My cheat-sheet is below. I'm not worried about too much else. Clone, commit and push are all you need to know. I even forget the difference between clone and fetch--but the nice thing is, you can't ruin too much. So go ahead. Make a blank project. Poke around. Start with small changes. You might be happy and impressed what you've come up with.

Wednesday, April 6, 2016

Spring Thing 2016! Go! Play! Enjoy! Judge!

It's good to see so many works in Spring Thing this year. I barely scraped by, and I'm grateful that Aaron allowed a bit of post-April 1 tweaking to shake out an embarrassing bug or two as well as (I hope) latitude for a post like this. (If not, I'll delete this.) Thanks to my testers for putting up with something that must've been frustrating.

I won't say much about my game, but chatter on Euphoria seems to indicate that some authors really love other authors' works. The IFDB already has game info and a few reviews.

So, this was meant to be a post-comp release post-mortem of Problems Compound, but that'll wait. Especially since I found a bug--and then, how I should've tested for it.

I'd like to post reviews post-Spring Thing of works I got to, but I don't feel comfortable doing so now, although Aaron Reed wants to be lenient about author commentary. Go play the games, and don't worry about (not) playing mine. I'm glad it's out of the way, and I think it's easier than Ugly Oafs.

I plan to submit a post-comp release of my game along with Threediopolis.

Wednesday, March 30, 2016

Problems Compound Release 2 is out!

I had some great testing during the comp and after, and now that I've been able to fix the big bugs, I think I have a good, stable release.

Thanks to Neil Butters, Wade Clarke, Joey Jones and Juhana Leinonen for testing new features and old bugs. I know my games are tough to test, and everyone found and worked through a game-killer.

I had a lot of organization to do, but thanks to GitHub, I fumbled a lot less than previous releases, and I got a lot more done! I even got a test environment working which may pay off down the road. So I'm very happy.  I'll have more ideas in a more detailed write-up.

An example of how it helped is here. If you want, you can view the previous commit, but you may notice one change I was able to make quickly because I was able to review the source code. Okay, I could've reviewed it before committing, but I was able to notice pretty quickly that

  1. "SHORT" didn't toggle short descriptions at all
  2. "WHO" had the wrong test case
  3. I forgot to tell the player they could THINK
It was originally a small fix to see if it was easier for the player to see who they were talking with, and I wound up being able to look at the previous commit and fix some obvious things so testers or players might not run into it. And that's a big help--of course, you want to be careful, but you don't want to be bogged down.

There are minor issues--I wanted to get something out before month's end after JMac's post-- but Jacqueline Ashwell at ClubFloyd has been kind enough to let me send them an updated version beyond this one, with a few more fixes. I'm also not sure the end puzzles are user-friendly enough...but they're a lot better than they were.

Now on to release 3. There are still some issues but they're not game breakers. They're more looking at Inform stuff I never did before.