Comp games reviews

Do authors who update their games put a note in with the update (version) number?
If they don’t I suggest that they do so in the future and that people writing reviews also write what version number they are reviewing.
I haven’t read that many reviews of the games yet. But I can imagine the “confusion” if there are, say, 4 reviews of a game covering 4 updates. Which on is the “player” to go by?
I’m sorry if this has already been covered, it was just a thought over my morning coffee.

My update of A Killer Headache is Release 2. I may add a Release 3 before the comp is over.

Authors probably should. It’d be good practice and it’d be nice to have an outline of what to do. But I think ifcomp.org and ifarchive.org do a lot of this automatically. I think there are a few solutions to see what version you’re playing.

If a game is an Inform game, you can always, or should always be able to, type VERSION to see the compile date of the game. Not everyone can be expected to know this, though.

The files at the IF archive also have a last-updated date, which can help. That in combination with the update posts here by Sargent can isolate which version of the game you played.

And even if you don’t intend to vote in the competition, it looks like each game at ifcomp.org/vote/ has a “last updated” date with a change log you can use as a crib sheet.

This is making it sound like detective work. (I spend enough time and frustration as it is trying to figure out whether authors have credited testers anywhere.) Update numbers in reviews would be primarily a benefit for authors rather than players. If authors aren’t diligent about it, they can’t expect reviewers to be.

I agree that it’d be good practice to include version numbers in reviews. But until authors as a group start including easily-accessible update numbers consistently, it’s too much hassle to make it standard practice. I suspect that they won’t do this unless it’s required in order to be allowed to update.

That’s kind of pissy, I suppose. I suppose that next time around I could institute a rule along the lines of: if I can find your version number in-game and within ten seconds, you get a version number with your review.

Oops. I meant to make it sound like there should be a few simple ways to check, and people often just don’t know that they’re there. And I am probably looking at it from a programming perspective.

I mean, there are certain things I didn’t know about, or to look for, until I had them pointed out, and after a few times through it seemed automatic. Like how the serial number (which is just the date, YYMMDD) should appear in the header in Inform unless the author has Done Something. But yes, it is one more thing for a reviewer to look for.

And while it isn’t required to be in ABOUT/CREDITS, I’d agree that adding a note to either command is helpful to the reader, if the author modifies something. This may be a decent compromise–reviewers concerned about the version # can check these commands (and most of them concerned with version # will be checking for beta testers, which is even more important.) So I guess the authors can definitely meet the reviewers more than halfway.

However, I’d more generally state that any robust programming language should specify binaries for the built executable file/XML file or whatever it is and let the player reference them. It seems that this would not be hard to add to a default INFO command–or a start screen–and while it doesn’t add fun for the player, it can help give some background to the review if the game is tweaked in the future. But then, we aren’t programming for anything super-serious here that millions of people rely on.

Though metadata in a transcript can help a tester/programmer say “Oops. This is the wrong build.” pretty quickly, thus not wasting time testing something that doesn’t need it.

I automatically try VERSION in Inform to see what extensions the programmer uses–I can often learn a lot even without the source code. But I don’t know any way to let a more casual reviewer know that, and I agree, it’s not something I hunt for in non-Inform games.

Still, if a reviewer asks this question, I suspect they are motivated to take a bit more time to look at a game & I think authors can do something. Some sort of guidelines at the IFComp site might be useful e.g. adding documentation in ABOUT/CREDITS is recommended but not required for in-comp updates.

So it looks like my idea is more natural for someone who writes or tests games. But I think a reviewer who is curious about the differences enough to start a topic here can track things down or will want to.

Contrariwise, maybe IFComp.org could post a spreadsheet of what got updated with which update. That’s more work for the organizers, but it could help with some confusion e.g. if a game is reviewed 10/16 and updated for the first time 10/18, we know which version it is.

Even with information about what games were updated and when, you’ve got no guarantee about a review. In your example, a review posted after 10/18 could be of the updated version, or it could be of the old version that the reviewer downloaded at the beginning of the competition.

Maybe the best thing would be for authors who have updated their entries to email reviewers asking them to clarify which version they reviewed.

IMHO A lack of version tracking for both authors and reviewers is a travesty. Conventional fiction tells you on the cover and title page if the work is a second edition or a revision, and its reviewers mention it as well. Why not IF? I think that the version number should be on the title page of games that have a title page, or in the About/Credits section for those that don’t. Also, if the work is a second addition or a revision, that information should be in the file name and/or game name as shown in the download area or the archive. Let’s save the detective work for the game and it’s puzzles, eh?

It is. That’s the standard behavior for Inform, and I think for TADS (possibly?)

Good idea! Oh, wait, half of the reviewers don’t have contact information on their sites…

Yes, this is a very common beef of mine with blogs per se.

As what maga was saying, atm there is a lot of detective work involved in following up and reporting versions and version numbers, and all the relevant parties (authors, reviewers, the IFComp site) are doing different things in different ways, and not all of them are strongly involved with each other. So while there may be best practices to advocate for each group, I don’t think they’re likely to gel in a consistent way in the near future.

  • Wade

I wonder whether it might be a useful Parchment feature – if Parchment is logging transcripts of your game anyway – to have ::waves hands about UI:: a button or something on the page. Press the button and it spits up a perma-link to your logged transcript, which you can then paste into your review somewhere. That way the author and all other reviewers would be able to view the raw file of the experience you were reviewing, with the minimum effort to record that transcript, host it yourself, email it to the author, etc. (I’ve sometimes done those things, but sometimes I forget or am tired or not in a good space to handle it.)

This solution wouldn’t deal with download games, non-Inform files, etc., but maybe it would make things easier in that sub-area?

I don’t know whether this is a practical request.

To say something constructive, I’m always posting a screenshot of the game’s splash page with my reviews which for almost all games states the revision or serial number. Don’t know if people find this particularly useful with a text game, but for this specific case, it helps.

Perhaps reviews should come with an info box of some kind which would include the version.