Thoughts for prospective IFComp authors?

Competitions
13

Think about your cover art in advance. Even if you decide not to have covert art, make it a deliberate decision. You will feel silly if you forget that art is a thing until the day of.

If you know your game has bugs, or if you haven’t given your beta testers enough time to properly test your game, pull out of the competition. No matter how much it hurts. For every bug you see, there are others you don’t, and there’s no harm in holding the release until next year.

(Yes, I learned both of these the hard way.)

14

This is only gonna be useful for artist/writer types, but here goes: what matters with cover art is good design, NOT good art. If you have to choose between showing off what you can do as an artist and making something basic, but well-designed, go for the latter.

15

Cover art should be square, and 300x300-600x600 is a good size depending on the complexity of the image. (The IFComp site will automatically scale your cover to a uniform size.) If you use inform, the Small Cover should be 120x120. Simplifying the logo for the small cover isn’t a bad thing instead of just shrinking it, especially if it becomes unreadable.

At minimum, just the title with a well-chosen font is better than no image at all.
A good resource for easy logos is cooltext.com

If you wish to edit the image and don’t have a your own software, Sumo Paint sumopaint.com/home/ has a free browser version, is easy to figure out, and is powerful enough to make a quite suitable logo.

16

Good advice, but in balance with this, the blurb shouldn’t be a novel. The blurb is not the place to explain the entire setting of your story, nor to relay background information the player needs. You want to entice the player to open your game and give them the goods inside.

Do not “talk” to the reader in your blurb or apologize for any perceived deficiencies. Do not tell the reader what didn’t make it in the game or disparage your story. Don’t announce this is your first attempt at writing or plead for leniency.

Here are some examples of good blurbs:

These are each only one sentence, but also very concisely infers the characters, the setting, and the main obstacle in the story.

I personally don’t want to spend more than 15 seconds reading a blurb. I’m actually a fan of the short cryptic ones with some type of hook, those are the kind I write, so take whatever salt with this advice as appropriate.

17

Hi. I’m Wes Lesley. You don’t remember me from The King And The Crown, a stupid pile of crap I submitted with love and immature jokes to IFcomp and I had a blast.

Everybody’s so nice and helpful and best of all -CREATIVE-. (( anybody remember my PLUS and MINUS reviews ? ))

My favorite part of competing in IFcomp wasn’t having people play my game (for only few seemed to get it for the in-betweener it was) but rather getting close® with all the fine people who put in actual work.

At it cost me nothing. Not just talking money. It cost me no effort, everyone was so great, I had the time of my life.

You should totally get in on that. Yeah, YOU.

… Then again, what do I know? [emote]:)[/emote]

18

I know being able to trade works with other IFComp authors for testing helps a lot. Like was pointed out above, we can’t see our own bugs no matter how hard we try, and also I found it makes me worry less about competition. If I won’t be winning, I can be a (relatively) small part of a game that does well. It still gives me nice kick when some small feature I suggest is pointed out in a review.

I also agree about walkthroughs being more than just typing in a string of commands. Give the player a chance to say “Oh, yeah, I could’ve seen that!” I’m pleased with my flowchart walkthrough from last year, and I want to use the format again.

Also I’ve learned and enjoyed a lot from all the post-comp work I’ve done on my games. I recommend it to others, as it’s fun to make should’ve into things you are doing or did.

And yes, don’t pre-censor yourself by worrying in advance what people may think. I did so, and tried too hard to avoid things without going after what I really wanted to do. And I wound up, well, having to make a post-comp release or two.

I also encourage people not sure if they’re ready to test another game. It’s rewarding to see that you enjoy a game even with bugs, which doesn’t mean they should be ignored, but it gets rid of some of the perfectionism, and it helps you realize that a trade of ideas can work.

I also think giving clear instructions to testers is a big help. Make sure their time is being used well. Let them know it’s okay if they’re baffled somewhere, or even if they don’t get far, and give yourself the time to straighten out a puzzle/scenario into what it needs to be. And, yes, get testers with different styles. Walkthrough-bashers and people who concentrate on introductions. If possible, give them commands to jump to what might be their favorite places. They’re doing you a favor!

I also like keeping a log of bugs that are changed, just to boost my spirits that I am indeed fixing things. Some testers find it useful and fun to see, yeah, I contributed to that and tipped off a new idea.

It’s so tough to sort out bugs vs small holes. I don’t think you want to put a game off for a year because there’s a small plot hole. And I think reviewers will be more forgiving of plot holes than bugs, even if a bug turned out to be esoteric. I tend to be forgiving of bugs because I know how easy they are to make and it’s cool to figure why they happened, but most people don’t roll like that.

Also, be prepared to lop off one big idea you’d really like to have fit in but didn’t have time to implement fully. It might even be something that helped you start the game, but you may have to perform triage a week before on something that just doesn’t work. The bright side is, it may be something you can dump in post-release.

I do think that playing the game or doing something every day is valuable, simply because you will get sick of trying the safe-and-known stuff that’s not going to break any more. On balance I’d say people’s suggestions have helped me improve games a lot more than if I’d held them.

Also yes the author’s forum is very valuable for trading bugs, hints for preparation, and so forth. But it’s best to see what you can do beforehand.

I’ve wrote something like this in different forms before so I hope it’s not too rehashed or reheated, but there are some things worth saying again and again.

Oh: the big things for Inform programmers? Don’t just run the debug build (F5 on Windows). Build: build for release regularly, to make sure the thing compiles. That will prevent nasty shocks a few days before release. The debug build is not the release build!

Also, you can/should have a walkthrough testing script or two, and it’s worth reading the transcript to tease out any big bugs. Twine authors, I imagine you have something similar, and if not, it should be coming soon, because Twine does have the use base to support it now.

19

I think the golden banana is a good way to mitigate some of that. It’s an achievement (of sorts) that does not rely on as many people as possible liking your game. I find that if I’m unsure what people will think about an element that I feel is important, I think “hey, maybe I can get the Golden Banana?” [emote]:mrgreen:[/emote]

1 Like
20

While that is somewhat true (IF Comp judges are, by definition, people who are motivated enough to play at least five entries and rate them), it is still a pretty diverse audience with diverse tastes. The more important point is that the IF Comp voting system, by averaging scores, rewards entries that have a broad consensus appeal, rather than those that strongly appeal to a large minority. (SpringThing and the XYZZY Awards have voting systems that reward the latter type of game.) On the other hand, there is also the Golden Banana award for the most polarizing entry, if that’s what you’re shooting for.

1 Like
21

And don’t forget to credit your beta-testers! More generally, it’s a good idea to have an ABOUT command or link, available from the start, that includes credits, background context, and other information useful for playing the game. And how to contact the author, if you want to find out quickly about bugs that your beta-testers didn’t catch…

1 Like
22

I would dispute that. You may well get one or two offers, but in my experience, that will be about it. Maybe people with a good track record and a high profile around here will attrack more testers, but if you are not well know, you may find you struggle. Posting requests on other boards is another option, as is offering to help other with their beta-testing, if they will test you game.

23

Being able to get 1-2 offers fairly reliably is still pretty good, especially if you’re just starting out. Of course, it depends on how many you need, I make fairly uncomplicated Twine games and can get by with a couple, but I imagine someone making a very deep parser game would like more.

That raises a good question, what IS a good number of playtesters to have?

1 Like
24

I’m used to RPG books, which often have two dozen playtesters listed. But that strikes me as both impractical and unnecessary for IF, which does not, like an RPG, require more than one person to do a single play-through. On the other hand, in writing ordinary fiction, I’m used to asking for a single beta reader if I’m just looking for help with typos and flow, or 2-4 when I’m asking for broader feedback on a longer piece. I am also, given the way of the world, used to asking 3 people for each 1-2 that gives useful feedback on time.

So I would say that IF should aim for at least 2 playtesters giving useful feedback, but this may require asking 4-5 of them. And having feedback from 4 people would be even better. But unless the game is unusually complex in a branching sense, I would expect diminishing returns after the 4-5 point, because they’ll be running into the same things.

25

I usually try to have 5-10 playtesters. But I have (repeatedly) made the mistake of exclusively leaning on friends and family for playtesting. The problem is that my friends and family aren’t veteran parser players, and although they turn up important bugs, those bugs aren’t the same ones that veteran players turn up.

Get a variety of playtesters. It helps.

26

Make sure you understand the beginning, middle, and end of your story (and any variations) well. Don’t get caught in the loop of changing your story based on play-tester feedback. that will lead to an incoherent and wildly unsatisfying experience. Stick to your story and your vision. Allow play testers to really only focus on bugs, grammar, and small insights.

1 Like
27

This is a great primer; thanks for writing it! Everyone’s contributions to this thread is wonderful as well.

This is also my 2nd year in IF Comp; I did The Speaker last year. Here’s to a great comp. [emote]:)[/emote]

1 Like
28

Well, there’s changing your story, and there’s adding major things such as a help-verb, or even having 3 people say “this part of the story doesn’t work.” If one person says, wait, this doesn’t work, then yeah–see what you can twiddle. But if several do, that’s a sign something needs to be cleaned up.

29

Something I haven’t seen mentioned (though admittedly, I may have missed it), and applies far more to Twine (and Twine specifically, as opposed to hand-rolled CYOA systems) than parser:

Give some thought and time to basic design / CSS. I honestly hadn’t realized how many judges look at a default-formatted Twine game and think, “oh, this is beginner level stuff”. If I’d known, I would have taken some time to do something–even something small but deliberate, something which showed I was capable of making and executing a conscious decision about the look of my game, would have been better than nothing. For example, if you have links which do one thing (e.g. cycling/cosmetic) and links which do another (e.g. forward propulsion), changing the color on one is a really intuitive way to get your reader to notice and pick up on a difference (Swan Hill, admittedly not a comp game, does this well). This was one of my biggest “I wish I’d known this going in” moments, because it wasn’t something which was on my radar when I first found the community.

30

Re: Playtesters. I’d say for a comp game (small-ish), one or two solid and fanatical testers is excellent. For larger stories, you’ll want a series of testers throughout the process, but not necessarily the same ones front-to-back. But it’s also important to understand how to test things yourself. Using automation and regression tests and add anything your playtesters throw at you into your regressions. There is a level of programming skill needed to get your playtesters focused on the story and not on your implementation.

31

Be really, really careful with that last-minute idea… far too often, the last-minute change adds brand new bugs/typos/etc.

The private author forum is probably the main reason I’m entering (again) this year. It’s incredible. It was also handy when companies approached IF Comp authors to write games (for money, yay) and we wanted to figure out if they were a scam or not (it wasn’t, double yay).

If you want a lot of reviews fast, start your title with an “A”. Or go the other way if you want to be eased into the review game. The alphabet is a harsh mistress.

And, like so many people have said, write the best game you can (which includes using beta testers, and in some cases waiting until next year).

32

Unless it got changed, the IFComp site lists in “pure” alphabetical order, not “library” alphabetical order.

My title “The Baker of Shireton” was back with all the Ts instead of the Bs.