While others who have not written games for this year’s comp will start their IFComp 2020 journey by reading blurbs, reviewing cover art, or perhaps just getting in there and playing, reviewing and rating games, I’ve gone for a less useful approach and tried to break down the entries by development system.
FWIW (probably not much), it looks like this:
Custom Web 9
Custom Windows 3
Axma Story Maker 1
C64 BASIC 1
To be honest, I was actually really curious about this exact info. So thank you for this.
for our part, this is a bit complicated – we should really count for half custom web, half ink, or one of both, given it’s a custom web setup with ink stuffed into it.
Super interesting, thanks for pulling this together!
Man, remember when Twine was controversial? Good times.
Back when there were half as many entries, you mean?
I think it’s interesting. It would be great if the ballot listings added this as a sorting filter.
Twine is by far the most popular platform. Is there a correlation to the popularity of CYOA/gamebooks versus parsers, or is it just because Twine is simply the “it” thing right now?
Yes, I missed the Ink stuffing. I derived many of these from a quick view of an in game source page so I’m sure there’ll be errors.
for sure, mostly i just wanted to make sure the inkle crew got their due. ink is a really fantastic system for accessible web IF!
Yes. Could this be the start of a comeback?
Yeah! You could tell the scene was more vibrant because there were fewer entries
Thanks, Mike. It’s something I’ve found myself doing as a warm-up exercise at the start of each comp since the rise of browser-based games. I like to get a feel for the development choices the game designer made when playing a comp game. It also appeals to my obsessive tendencies.
I’m glad it’s of interest to someone other than me.
My guess is that it’s because it’s so easy to make a game in. It’s basically just HTML with if/then statements that barely requires any knowledge of programming, but scales up in complexity with the user if they choose to learn more programming. All of the other options are really intimidating or (without trying to sound insulting) clunky.
I’d say ChoiceScript is probably easier to code than Twine, but it only offers strict CYOA (no link clicking or anything to make each game unique). Ink is the same (if you don’t embed it in a framework), except the code is a lot more intimidating than Twine.
The downside of Twine being easy to code for is that you’ll probably get quantity over quality. The upside is that a lot of writers have a difficult time coding and would never release a game if they only had parser engines to use, let alone spending all of their time writing error messages for why the user can’t insert the banana into the television, because you just know some jerk is going to try that.
I’m trying to help the TADS comeback … but it’ll be for next year…
Nice list. Just curious, which game was written in C64 BASIC?
that would be nick montfort’s game!
That’s me. I chose Twine primarily for its scalability – I’m new to writing IF, but come from a strong programming background. I found working in Twine made it easy to hammer out the writing/narrative part, then drop down into the code to implement some of the more complex or interesting ideas for how the game might actually work.
It does strike me as a good way to quickly prototype an idea, but I can also see how some types of stories or experiences might benefit from a completely different platform/system. And yes, writing error messages for a parser engine to handle every weird scenario didn’t really strike me as the best use of my time for my particular game idea!
The parser based games should keep me busy for awhile.