Can we split IFComp into two categories?

I attempted to do something similar to that, but after a lot of time invested in it, I realized that it was a lot of work that goes completely unseen. In fact, the end result actually looked worse to me than faking it with conditional statements and flags because I had better control over the output.

1 Like

I’m curious about the extent to which “world” can be distinguished from “state.”

Naively, many demarcation attempts in these conversations distinguish parsers from CYOAs by proposing that CYOA’s lack “state”…there’s no “notepad” or “tracker” keeping track of properties. (I think this distinction is obviously pretty silly because lots of classic CYOA’s track state).

Skybreak has no objects, nor does it have room connections. There is a large and fairly complex “world”, but substantially all of the world is variables…of course, all any world is is variables if you think about it.

4 Likes

I think that classifications don’t have any real existence, and it’s all a tool for organizing human thought, and should be discarded when not useful.

4 Likes

To me, it’s like the difference between practical effects and green screen in movies. If you can’t tell the difference, does it matter? Sure, practical effects are cooler, but at the end of the day… who cares, ya know? The viewing experience is what matters, not the behind the scenes.

Infocom definitely popularized “interactive fiction”, but it was apparently coined by one Robert Lafore.

2 Likes

I don’t think we should slide all the way to “it’s all the same”, which tends to be the lazying result of any topic like this that goes forever. Let’s take a non-detailed step back and remember some basic differences. If I compile a default Inform game, put a table in a room and an apple in another, I can go around taking and or leaving the apple in any room, eat the apple or do other things. They’ll have default responses but they’re doable. Depending on how I set the table, I could drag it around and stand on it in any room, etc. This is already a high degree of world modularity that CYOA won’t do out of the box, and isn’t suited to do if you build it up… but (a) it’s also a thing a CYOA primarily isn’t interested in doing because it has other strengths and (b) back in the parser game, it will need to be put some use to have its effect. We don’t help ourselves with all these "isn’t necessarily different"s. There are default degrees of difference that are real. We can say we can get a parser game and make it all choices (I was writing an extension that does this) or build up a big world model in a CYOA game and then be inundated by too many clickable links and lists, but these aren’t the core strengths of either model, are they?

-Wade

Is there any actual point to this amount of hair splitting though?

I think the vast majority of players are going to consider typing commands to be the most significant detail that defines a parser game.

Laugh… after this many posts, I think there are only hairs :slight_smile: I’ve read, I’ve posted, and now for my own productivity I must commit to not add to the topic any further.

-Wade

I’ve been watching the responses with interest. It’s amazing how the original suggestion was distorted and the discussion got diverted onto completely unrelated things. Let’s try to get back on track.

Just as a memory jogger, the original suggestion was “Given that IFComp 2020 has exceeded 100 entries, isn’t it time that we split the comp into two categories…What do others think?”

Thanks to those of you that gave well-considered responses to the original suggestion. Based on those responses, my conclusion is as follows.

Executive summary

The majority of games are clearly parser-based or choice-based, but there are some games that don’t clearly fall into either category, so categoristaion is difficult in those circumstances. For this reason, it is best to allow all games to compete against one another.

Given that there is such a large number of entries, there is a need for better filtering of games, so that players/judges can concentrate on the games that are more likely to be of interest to them and they can therefore judge them more fairly.

Details

If we had two categories, then authors could choose to enter parser-based, choice-based or both. Prizes could be donated to parser-based, choice-based or both. Players could select parser-based, choice-based or both. And there would be separate prizes for parser-based and choice-based.

My rationale for the original suggestion was twofold. Firstly, there are too many games for anybody to judge them all. As you only need to play and judge a minimum of 5 games, you need a simpler way of finding the games you want to play and judge. I thought that a categorisation of ‘parser-based’ and ‘other’ would help to solve this. We already have key-words, but you can’t currently filter or sort on those key-words.

Secondly, parser-based games have always won the competition except for once, when the winner was a blend of parser-based and choice-based built on a custom game engine that is parser-based at its core. I feel that this is unfair to the choice-based community, as they are not competing on a level playing field. If they had their own category, then the awards would be more equitably allocated. The choice-based respondees have made it clear that they don’t care about that and are happy to always be runners up.

Contrary to the presumptions made by others in this thread, I’ve played quite a few choice-based games and I tend to get bored with them very quickly. There’s too much to read and very little to do other than follow a pre-determined path. In fact, I don’t think I’ve ever finished one. For that reason, I won’t consider playing choice-based games in the competition. I figure that it’s better not to play them at all, than to play them and give them a low rating because I don’t like that style of game. I don’t like RPG games, either, but that’s just me. I’m trying to be fair, so let the choice-based fans judge choice-based games.

5 Likes

Doing of yourself an “only parser games judge” sounds like a very sensible thing to do, so… thank you.

Even there’s nothing stopping you guys from making lists of “the parsers games of ifcomp 2020”. Even, I think all efforts in taxonomy and filter games are doable because they help to spread the word on games that might need more judges. So., al this seems like a good idea to me. Parser only judges.

Even, one year I judged only games that could be played on mobile… so, please, do it!

OT as genre: seems that you describe Trails of Cold Steel series :smiley:

IT as debate: the JRPG quoted above manage to give its deep lore (between one and two million words…) without NPC talk menus… basically the equivalent of TALK TO

Best regards from Italy,
dott. Piergiorgio.

Reading and reading this debate, I begin to be firmly convinced that a Legend-type interface (having all but one: sizeable text window and input prompt, icons mated to parser commands, but non-clickable pictures) with clickable picture element and menu-driven conversation, mated to the relevant parser command (ex. you select, keyboard or mouse don’t matter “4) Mr. jones, you see, you telled me about mrs. smith being at the diner the day before, but what about her hat found in Ashton’s house’s lounge yesterday ?” from menu, and the menu element pass “ASK MR. JONES ABOUT MRS.SMITH’S HAT”; Personally, I think that how one say things is more important than selecting topics)

Dunno if someone can code this and what language is more indicated for this type of engine, but seems that type of engine can strike balance between the gamut of different opinion here.

Best regards from Italy,
dott. Piergiorgio.

Choice-based is quite the misnomer, isn’t it? A parser too gives choice - and usually more of it.

I’m guessing the merits (or rather lack of) this suggested split would be clearer if the category definition was clearer.

SO yeah, that’s my primary objection.
It’s either gonna be on the Comp, or the Author, to choose the category their game falls into. Both present potential drama flashpoints.

obviously if I’m a proud 'drifter and the comp “mis-categorizes” my entry as “choice based”, I’ll be miffed.

but it’s equally true that if I get to make the decision for entry, a mis-categorization on my part will annoy a lot of people. (“this is obviously a parser. Look, I type my choices”) If one looks at previous comps, one can easily see instances where calling a game one, versus the other, would have dramatically raised the performance of the game (eg from 15th to 8th place, or something).

Absent some really clear definition, these categories are illegible and therefore bad for a competition.

3 Likes

‘Choice-based’ and ‘parser-based’ are fairly well recognised categories and these categories can be chosen by the author on their entry page. You will notice that most games include one or the other. ‘Choice-based’ is also known as ‘multiple choice’ or ‘CYOA’ (for ‘Choose Your Own Adventure’), but the latter is a trade-marked term.

The longer we talk about the differences between parser and choice-based, the more I’m tempted to spend the next year figuring out how to write a choice-based Twine that I can submit to the parser competition. It’ll be fun coming up with the most willful misinterpretation of the definition of “parser game” that I can.

1 Like

Almost sounds like trying to annoy someone deliberately.

I know people have written multiple-choice games in Adrift before, but I have another curmudgeonly way that creates a fairly effective separation: I don’t play games in a browser. If I can’t download a story file and play it in one of Gargoyle, SDL Frotz, QTads, or Hugor, I’m not playing it.

1 Like

I know, and why would I ever want to annoy the parser-only crowd?

There are also text transformation stories, where the user’s interaction adds, removes, or alters text that has already been shown to them. Most I’ve seen have been made with Twine, but others exist also. I wonder how text transformation and parser or card input could be combined…

What immediately comes to mind is The Space Under the Window, which I always think of as a proto-Twine. It was all of the relative ease of doing font swaps and text blinking and stuff like that which attracted me to Twine in the first place – obviously there are also plenty of parser games that use colors and effects and stuff (Photopia and that one where all of the punctuation rebels and you have to get it back, I don’t remember the name, are coming to mind here!) But yeah, I am all in for the blending and the blurring!

2 Likes