Hey, folks. I’m new to the IF scene, so I thought I’d come by and say hello with my first entry into the medium.
I grew up playing IF, but it only recently occurred to me that I could actually write some, if I wanted to. So in a prodigious, week-long coding binge, I taught myself Inform 7 and wrote two games. The first one was just a fun demo for myself and some friends so that I could learn the language, but this one, “Trouble in the Workshop”, is a full-on release that I’m rather proud of. It’s a Steampunk-inspired adventure game that primarily focuses on discovery and problem-solving.
In this game, you play the laboratory assistant of the brilliant and eccentric Doctor Edgar von Winterstein. However, when he leaves you alone in his workshop for the first time, things go awry. Will you escape with your life? Or will you make a discovery that will change the fate of the world? It’s up to you!
As I’m a newcomer to the IF scene, I would really love to hear what some veteran IF players think of the game. I believe I’ve ironed out all (or almost all) of the game bugs, so I don’t particularly need playtests, per se, just feedback on enjoyment, play style, command usage, difficulty, etc. Does the game feel polished? Do I need more custom messages for various objects? Is it engaging? Stuff like that.
Thanks, and I look forward to, erm, interacting more with the IF community! =)
One of the pieces of advice that we repeat a lot: always test your game, even if you think it doesn’t need it. Other eyes are going to catch things that you’ve missed. And crediting testers is a signal that you’re taking your game seriously - that it’s not a coding exercise, a game jam/speed-IF piece, or a joke. Given how many half-assed games there are in the world, that’s useful information.
Good points: you establish the important stuff right from the outset. We know what the PC’s role is, what’s at stake, and what they immediately need to address. Poking around at things gives you a good idea of what kinds of things you want to be trying. So that’s good.
The kind of game it is doesn’t really jive with my personal tastes: I tend to like things that are a bit more reliant on character and prose style, while what you want to do seems to be a straight-up puzzle game with utilitarian writing. That’s okay; there are people who are into that kind of game. But it does mean that I’m probably not the ideal person to talk about how enjoyable it was.
I think you need more synonyms for a good number of things; ‘car’ for ‘automobile’, for instance.
It would also be helpful if more wrong-but-reasonable attempts gave a little more feedback; that sort of thing is hugely important to make a game smooth-playing. (Testers are absolutely the best way to do this.) Things like trying to enter the car or looking through the telescope are reasonable things for a player to try, even if they’re not useful for the solution.
When you say ‘equipment’ and then list a bunch of stuff in the room description, the player’s likely to think that that list is of all the useful pieces of equipment, when in fact there are some other things that you won’t notice unless you examine EQUIPMENT. It’s probably better to either list all of the equipment up-front, or none of it.
First of all, thank you so much for the feedback! I love getting feedback, and I absolutely don’t expect all of it to be positive. It would be pretty pompous for me to come into a new medium and expect my work to be above reproach.
Now, to the meat.
Indeed. I tested it pretty exhaustively, but when you’re the writer, it’s hard to step outside of your own mind. That’s why I enlisted some friends to playtest, and they helped me catch most errors. I didn’t know that it was common to include playtesters in the credits, but if it is, I’ll make sure to include them in the future!
Thanks! It’s always good to hear some positive reinforcement, particularly when just starting out in a new medium. And yeah, you nailed it pretty good… This is most definitely a “game”, rather than a “story”. That may be a problematic distinction, as I’m sure there are plenty of stories that are games and vice versa, but you probably get the idea. This game isn’t really about the prose or the characters, but about solving puzzles/problems. I understand that this won’t appeal to everyone, and that was a conscious design choice on my part. =)
Yeah, this is something that my playtesters didn’t really catch, because they aren’t text game veterans. They don’t know what’s expected of the genre, and what level of quality I should be shooting for. Someone actually just messaged me privately with a pretty detailed list of these things, and I’ve already gone through and corrected all of them that I could find. I also added quite a lot of synonyms where I felt it was necessary, including ‘car’ for ‘automobile’. =)
However, just because someone beat you to the punch doesn’t at all make you any less right; that was totally an oversight on my part, and I appreciate it being drawn to my attention!
I was conflicted about that, so I’d like to hear your further thoughts on it. The reason I decided to do it that way is because the game only takes place in one room. While if there were multiple rooms, I know that that would be too subtle for most people. However, with only one room to look through, it gives players more time and inclination to try looking at pretty much every noun they see mentioned. With those things considered, do you still think it should be changed?
And in case I haven’t said it enough yet, I very much appreciate the feedback! =D
More specifically, of course, I meant that I wasn’t asking for line-by-line corrections or bugs or whatnot, but just general impressions of the game. =)
Yes, it’s very much an expectation in the IF world that you’ll credit your testers unless they specifically ask not to be credited.
Well, I did end up finding it, so there’s that. I think the deciding factor is that you present the prominent equipment items as a list: in IF, there’s the assumption that if a list-like bit of writing appears, it’s a literal contents listing. You know, if you saw “On the table are a pair of secateurs, a taxidermied fairy, a pair of vintage culottes and your dear old mother’s skull”, and then later it turned out that there were a couple of crucial things on the table that weren’t hidden, but didn’t get mentioned unless you examined the table… that would be pretty annoying. If the objects were presented in less list-like writing, it wouldn’t be such a big deal.
And there’s not any special reason, as far as I can see, why certain equipment pieces get mentioned and some don’t. If you wanted things to be encountered in a particular order, that might be a reasonable justification; I can’t tell whether that’s true yet. But there are ways to do that that don’t mislead the player.
Hmm. I just looked through a number of the contest entries for last year’s IFComp, and I didn’t see any credits for testers or anything. Are those typically listed at the end? Or the beginning? Or should there be an “about” command, or something?
That’s actually an excellent point you raise, about intentionality. Or utility, if you will. I hadn’t really thought about that, so it’s likely that I’ll go ahead and make some changes to it.
The convention is to credit the testers in the ABOUT/HELP command text, or via a separate CREDITS command mentioned in the about/help text. It’s generally treated more like the acknowledgements in a book than the credits of a movie/videogame - just a simple paragraph or two of text, like this example I picked at random off IFDB:
I can’t help but notice that an “about” command isn’t built into I7… Do I need to write one from scratch, or is there an extension that people tend to use? I literally just learned how to use I7 in the last five days, so I apologize if my questions seem a little noob-ish.
I very much appreciate the assistance, though, and would be happy to credit anyone here who helps me. =)
It’s the sort of thing that’s so simple to write from scratch that an extension would be redundant, really; you make a new action out of world that does nothing except a say statement.
But some people prefer to use menus, if they have a lot of different stuff in the about information that they want to deliver. For that you’d use the built-in extension Menus.
Since you mentioned it, I figured I’d take this opportunity to learn a bit about menus, so I went and included one. Thanks for the suggestion!
I’ve now updated the file on Parchment to include credits (in which you all now figure), as well as fixing the room description issue that you mentioned, Maga. =)
You can have a walkthrough in the game as a command WALKTHROUGH/WALKTHRU or menu option. Games distributed as archives sometimes have the walkthrough in a separate text file. For an online game you could have a web link.
A walkthrough is simply a list of commands required to finish the game. If the game is very long you can place multiple commands on a line by separating them with periods e.g. “E. W. GET STICK. E.”
It’s helpful to subdivide the bare list with context headers (it’s easy to lose your place in a long list) e.g. if the location changes, the name of the location, or if a subgoal has been accomplished, the name of the next subgoal.
There’s no hard standard for including hints, help and walkthroughs. If your game is at least moderately puzzly, it is definitely a good idea to include something when the player asks for help, and this goes double if you’re entering your game into a competition. A lot more people will actually finish your game that way. But most games are released with no walkthrough, including games by highly-respected authors. A hint system is often a better choice than a walkthrough, but many games have no hint system either, and that’s not invariably a problem. It all depends on how likely the player is to get stuck, and how annoying getting stuck is going to be.
As a result, I’ve gone ahead and included some hints in the help menu. I’m not certain how many hints are appropriate, but I tried to strike a good balance between helpful and not-too-spoilery.
Does anyone have any suggestions as to where to go from here? Is there somewhere that most games get published? What’s the normal life cycle for a text game, these days?
The I7 manual has a chapter on this: see Publishing.
The standard places to put IF games are on IFDB and the IF Archive. IFDB is a reviews-and-ratings system; people can leave reviews, give your game star ratings, link it into themed lists, apply tags to it to help with searches and so on. If people want to find a game and work out what other people think about it, the usual place to look for it is on IFDB.
Games don’t get stored on IFDB itself, however; it just links to places where the games exist. The main repository of games is the IF Archive. People don’t actually use the Archive to browse for games all that much; but it does ensure that your game will always be available if people really need to find it. (If you just host it on your own site, that might go away at some point. The Archive isn’t going anywhere.)
Another good place to list your game is on the IF Wiki. It’s not quite as active as IFDB, but it’s still a useful information thing.
All that said, none of these sites is a guarantee that your game will get a lot of attention, reviews and so on. If your game is particularly good or does something particularly interesting, it may gradually pick up steam through word of mouth - but this is a lot easier if you’re a well-known author with an established reputation. If not, you may be greeted with a resounding silence. Most new authors find that the easiest way to get a lot of feedback soon is to release their game in a competition. Basically all comps require that your game be previously unpublished - that is, that you’ve only shown it privately to testers. (So Trouble in the Workshop wouldn’t be eligible. But you’d probably want to enter a game that you’d spent more than a week on, in any case.) The biggest competition is IF Comp, but there are others, both annual (Spring Thing, Introcomp) and one-off.
