Meld, by David Whyld

I always seem to take more energy on a David Whyld game than others. Even the mistakes he makes are fundamentally interesting. He'll overuse a joke I've heard before, but then he'll do a joke I thought I heard before just right. He'll provide a mechanic that's not fully fleshed out, but there'll be a couple spectacular examples how each works.

Meld certainly caught more of my time than any of the other IntroComp games, for better or worse. And I think he's found some pretty good territory to farm: big ideas people have put aside that are maybe a bit unpopular or not scholarly enough, but they can be, in Un-'Merican English, ripping good yarns.
 
Nevertheless, Meld feels on the sloppy side, and I think the main problem is that David never really established the logic of the mechanics so that I could understand things by trial and error.

Unfortunately, the number of possible combinations = (# of meldable items squared - # of meldable items) / 2. So while part of me wants to see the game expand and where it goes and have new options to create things, the other says--uggh, that'll get too complex!

Without some sort of logical ordering, or a meta-verb to note everything that's changed so far, or some way to shorthand things, or even a recipe book, I'm in a bit of trouble here. I stumbled across STATS by accident, but that's only because I spray my favorite verbs.

I guess the writer of Ugly Oafs can only complain so much, but a game like this does help me ask questions about my own works. And seeing omissions in others' efforts helps me establish a checklist for my own. Not of stuff I better do or stuff I have to do--but stuff that'll help the main theme out when I'm stuck on the main theme.

The plot, though--it works for me. On an abstract level, you have people blocking you from getting to certain areas, and once you've melded an item, it's not bad to see what to do with it. That's a pretty big "once." There are a few fools in there for comic relief, and if Talbot feels a bit overdone (he could afford to clam up about how bad gambling is) and you have the seedy coffeehouse, bar, etc., and even an odd alcohol-reversing pill where the humor doesn't quite work, I came away with a big-picture, yeah, this can work. Only it doesn't.

I'd add a few specific things, not to harp on the game, but to mention the sort of things we as authors should look for:--MELD X once we know X can be un-melded into Y and Z. (shorthand)
--UNMELD IT refers to "it" -- defining the pronoun is a slightly obscure Inform trick and one I spray to authors I test for. I've used it so long, I forget who told me. Climbingstars? But I'll print it again, here. It's that worth it.

after melding (a - a thing) and (b - a thing):
  set the pronoun it to the after-prod of a and b; [wher after-prod is what you get when melding a and b]

To set the/-- pronoun it to (O - an object): (- LanguagePronouns-->3 = {O}; -).

--somehow mention how meldable something is. Maybe it feels less squishy the more successful melds you make? Or it feels hotter, or colder? These feel a bit artificial, but the player needs guidance.

There's a lot here. But if someone doesn't know that off the top of their head, they should make an effort to ask these tough questions. David's experienced at this, if not in Adrift, then in Inform.

So I think it's important to learn how to ask these questions, or where to look for stuff. Or to have testers who will push you to do this, so your great game in theory becomes a great one in practice.

(Tangent: I really do wish there was a list of neat Inform 6 stubs. I have a bunch, but I love being able to find more, because it unlocks the mystery of I6 for me...and it also is just neat not to be restricted by I7's conveniences that do 95% of what we want, and we should be grateful. But being able to do stuff goes a long way. I do recommend looking at the auto.inf an I7 build produces, or even drilling down through the Standard Rules to stuff in the I6 directory, but it'd also be nice to have a knowledge base.)


And at the end, I think Meld has both the bad and good features of taking on such a significant technical task. There's clearly scope for a lot to happen. But this game did cause me to slow down and worry another game might be even close to as sticky. (They weren't.) And when the walkthrough makes me think, ok, how does this WORK? I think the author needs to sit down and provide better explanations or guidance, whenever, wherever.

Still, IntroComp is the place to do this sort of thing, and while I think there could've been a bit more on the technical side, the story part is interesting, even if I'm not sure 100% why things are happening.

The guts of the mistakes, etc., are reserved for a transcript. My guess is that the game was a bit light on rigorous testing, but that's something that can be fixed post-release. But now I've mentioned that, I think it's only fair to add I've been in David's position, finding it hard to ask for help, or even asking a tester "Can you test this? I don't have time/I can't change gears." It's a tough question to ask, especially as anyone with any conscience can picture "Why don't you do it? It's your game. You care more about it." But with the work David's put in, it's a valid one--the point being that reciprocity for testing games is a thing, and a very good one, and if people have a certain assignment list and pay attention, they may turn up other things, too.

A valid parallel to me is walkthrough testing where people just use the walkthrough and then say "I bet this might break" or whatever. But this is a step beyond and tougher to ask for. Even though I've been able to help other people smooth stuff off and point out the potential Murphy's Law areas, it's still--man, what if I really screwed something up? I'm worried I'll piss my testers off.

And I don't have a response to that, and it's cost me, and it probably cost David a bit here. Because if everything is explained, I think this game is a prohibitive favorite to win IntroComp 2015. There's just too much of a cool world. But the technical issues never got resolved.

And I don't think it's due to a lack of will. Fortunately there are resources to help this out, and I must recommend that David get a BitBucket account and make a private repository. Don't bother to learn Git, even. Just report issues, bugs, enhancements, etc., and look at it a few minutes every day. Close what works. You may not be as fast as the author of another IntroComp game that got done, but the organization from just writing issues is free and intuitive and nontechnical. And you don't have to worry about if an issue is too big or too small.

(Note: this is not just for David Whyld. Whether it's bitbucket or github, it's worthwhile.)

Still, on balance, I'd still rather see David complete his Best Laid Plans, his IntroComp 2013 game, before creating another one. But I am more interested in this game than the 2014 game, Soul Thief (which is still worth finishing.)

I'd like it enough that I'll help test, like I just noted above. So, David, whether it's stuff you know is probably broken, or stuff you probably should've checked, or whatever--find testers who'll help you to finish the cool stuff you want to. Tell us what you're worried is broken, what you didn't have time to check, etc. It's a lot to ask, but enough of us would be up to it.