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:
Twine 44
Glulx/Inform 24
Custom Web 9
Unity 5
Z-Code/Inform 4
Ink 4
TADS 3
Custom Windows 3
Quest 2
ADRIFT 2
Undum 1
Axma Story Maker 1
C64 BASIC 1
Z-Code/Dialog 1
TOTAL 104
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.
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?
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.
–Steve
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.
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!
