So, yeah, this may not be the most momentous thing to post to planet-if (I'll probably lump the other games I didn't test in groups of 2 or 3--or maybe all 5)--but seriously, IntroComp is worth looking into, if you haven't. You have about two more weeks. There are some good games. Even those that aren't, can be good.
I've been busy releasing Threediopolis and getting close to Shuffling Around thanks to some great work by Sean Shore...it's taken a lot out of me, and in fact I even forgot to bump back my post-dated IFComp review index, but I find re-releases worth it, to get rid of obvious bugs and trip-ups.
I hope IntroComp authors find it in them to release something post-introcomp, even if it's not fully complete. It'd be nice to see results, small or bing--I know Akkoteaque had some good bug fixes and believe it will get done, and get done well--and speaking from experience, it's nice to know I've fixed bugs and worked to improve something I wrote, even if the bugs were dumb in the first place.
Like the header says, I'm going to start with David Whyld's Tales of the Soul Thief. It's more serious than most of his efforts. He entered Best Laid Plans last year, and I was hoping he would finish it, because it was amusing and had a lot of things to do, and a lot of places it could go, too.
Spoiler: this is a bit harsh on him as he has the talent and work to improve the game, but as it stands, there was a lot to struggle through. While the game was paced well, and the world was believable, the technical side comes up a bit short. Still, I'd be interested to see how, where and when you can use your skill--for good or evil. Even allowing both, or having a Cliff's Notes at the end for those who don't want to replay, would augment the story greatly.
In the game you play a soul stealer, someone with an amulet that can take other people's attributes from them. Then you can use them wherever. This starts with alternate solutions for an early puzzle, and it goes on. You can steal others' souls, some of the time. There's a cool instadeath, and there's some soul stealing that doesn't matter.
I got frustrated in several parts here. The implementation is okay, but not great. Zacharias, the old man, can't be referred to as an old man--but you aren't told his name when you go back. He doesn't stand out in the room description, though it is cool to try to steal his soul. The construct guarding the museum, well, I tried everything but walking past it, until I said "Oh, that probably can't work, but why not." It wasn't immediately clear to me if I should keep hanging around in the tavern, and I thought for a bit that I needed to impress the men by stealing the bard's soul, but I hit a dead end stealing it before I talked to them. With 18 rooms, there's a bit of a walk-about, but no real super tricky puzzles. In theory, you should be able to poke around and do what you need (e.g. pray in church.) But some of the deaths--like the final bit where you are nailed by a magic trap--don't give quite enough clues.
Being an experienced ADRIFT programmer, David seems to have made the transition to Inform pretty well, but there are a lot of holes. Some of that is due to inexperience with the power Inform has, but I think he would be up to it if he completes his game. I'll note a few things, just because they're useful in general. I'll also get into Inform coding, hopefully to show that some of my requests aren't *too* hard to integrate.
1. HINTING. Synonyms help=hint are nice, and there is an easy way to test this.
volume basic stuff
debug-state is a truth state that varies.
section xyz - not for release
debug-state is true.
every turn when debug-state is true:
say "DEBUG HINTS: ";
try hinting;
You can, of course, have a separate command to flip the debug-state boolean in a NFR section. You can use debug-state elsewhere to print out text.
to d (myt - indexed text):
if debug-state is true:
say "[myt][line break]";
Bingo! Debug text you don't have to worry about seeping into the release build. And do you see what the first code does? It lets you pick off your own hints. You can, if you want, use your players' commands to see what their hints would've been. More complex code can print these hints to a file. At any rate, you can just use a TEST command to spin through the game and check hints any move, even without playing through by hand. There is a lot to be found. My games would be even buggier without this.
So obviously I think hinting is very important, not just to make sure players have a way through the game, but because it's a great way to vet yourself. Have I made this puzzle sensible and logical, etc.? Have I covered everything a player can do? You can not only make sure the player is guided through, but you can anticipate mistakes and converse with yourself and even try to sidetrack yourself to get bad hints.
This game had some hints, but too frequently it gave blank text, and while fixable, that's no fun for a frustrated player. For instance, I tried HELP by the construct and got something blank--a simple "say [if player has token and east-room is unvisited]You can walk east[else if east-room is unvisited]You don't have an item that will move the construct[else]You can walk in and out freely[end if]." works. Even "The X is not relevant in the intro." is good. Yes, you're going to change that. No, that doesn't mean it should be blank now--it's a good check to make sure that, if you want to complete the game, you search and get rid of text like "not relevant."
2. FLEXIBILITY
More synonyms are always better than less. New verbs like EQUIP should also be handled a bit better. EQUIP (nothing) would be better giving a list of what to equip. Even the annoying disambiguation would work here, and maybe even being able to use initials (E INTIM for EQUIP INTIMIDATE) would help.
INVENTORY should, ostensibly, list your soul skills. This is tricky, but Sand-Dancer has been go-to source for me and would help with this. (I recommend the Sand-Dancer code in many, many ways.)
3. DEFAULT/ERROR RESPONSES
The RULES command allows you to see what default responses are hit. Inform's error messages are generally vanilla and non-offensive, but they are not one size fits all. For an intro game, it's probably not possible or practical to cover them all, but all the same, you should try to copy the most prominent ones. It is an easy way to give the game character, and you can look it up in the IDE (Index:Actions) or text searching Graham Nelson's Standard Rules. The one I always harp on about to my testees is for the blank line.
Rule for printing a parser error when the latest parser error is the I beg your pardon error: [blank command]
say "Something other than I beg your pardon."
Not that these should be the first thing to attack--but MAN, when you have a bunch of potential small things to do, and the main ideas are dragging, the polish works here.
On balance, though, I'd like to see more of the game. The descriptions are adequate to good, and I'm left wondering what the other people are for, and how to get beyond them. What's the eye in the alley for? Perhaps there are a few stock characters like the slaver, etc., but the potential for alternate ways through is nice. Will you be able to give people their souls back? Do you lose power after a few hours, as (for instance) the bard gains his? Will you face someone you drained? Will you irreparably harm them? What about the ways you can't quite go yet? The game leaves enough for me to be interested, but more in a hm, if there was a walkthrough I'd definitely read it, though I'm not sure if I'd take the time, way.
However, I'd rather see Best Laid Plans, first. It felt better directed and like something the author was more comfortable with. There were even funny rejects for trying stuff that didn't work. And they weren't flippant, more the sort of "oh, I get it" humor.
I know it's tempting to rush forth with That Next Big Idea, or just to have fun with the next competiton. In fact, I wanted to for this IFComp. (I won't be. Ohai, 2015!) But I'm generally pleased with the ideas I refined in my re-releases of 3DOP (featuring a riff on the original area--now with 80 annoying pieces of scenery, but better organized hints) and (imminently) SA, also featuring better hinting and direction and, oh, bug fixing too. I learn what ideas work, what I can do, and where my weaknesses as a programmer/storyteller are. I can see how to rely on testers to help fill my blind spots, and I can see stuff I'm repeatedly reluctant to try, and instead of saying "Oh, that's how it is," I sit down and tackle it.
And unfortunately, moving from project to project may not help create the sort of detailed world people remember and love and use as inspiration to create their own. It steers the author away from the sort of details he should be noticing in his own world, the one that make readers smile and (if they're the writing type) even be a bit jealous the author found so much good stuff and want to try that themselves. Otherwise, all the writing you can do may get no more than "oh, yeah, good job."
No comments:
Post a Comment