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.