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.
Sunday, May 29, 2016
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.
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.
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)
Local $project = "Compound";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.
if $CmdLine[0] > 0 Then
$project = $CmdLine[1];
if $CmdLine[1] == "pc" Then
$project = "Compound";
Endif
if $CmdLine[1] == "3d" Then
$project = "threediopolis";
Endif
if $CmdLine[1] == "4d" Then
$project = "fourdiopolis";
Endif
Endif
run("C:\\Program Files (x86)\\Inform 7\\Inform7.exe");
WinWaitActive("Welcome to Inform 7");
Send("!O");
WinWaitActive("Open a project");
Send("c:\games\inform\" & $project & ".inform!O");
WinWaitActive($project & ".inform - Inform");
Send("{F5}");
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.
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 story.ni 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.
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 story.ni 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.
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
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.
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
- "SHORT" didn't toggle short descriptions at all
- "WHO" had the wrong test case
- I forgot to tell the player they could THINK
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.
Subscribe to:
Posts (Atom)