Insignificant Little Vermin - Filip Hracek

This is more of a technology demo than a full-blown game. Seems like it would be a fitting entry for IntroComp.

So I guess I’m going to review Egamebook first.

  • It’s definitely nice that it’s designed to work well on mobile.
  • I suspect that the “infinite scrollback” feature won’t work well once the game history gets a little bigger, e.g. it’ll negatively impact old Android devices once the scrollback gets long enough.
  • I tested it on iOS Voiceover and it didn’t work. I wasn’t able to navigate past the first die roller animation.
  • When I refresh the page, it restarts. That’s too bad.
  • Offline support with service workers would be nice.
  • My feeling is that the die roll animation is nice but not cool enough. The goal of a die roll animation is to build tension and look great. Compare with Tin Man Games’ Fighting Fantasy series, where they have 3D animated rolling dice. This animation looks nostalgic (why is the X pixelated but the heart isn’t?) but doesn’t make anyone say “wow, that’s cool.”
  • Seems like you’d want to offer a back button. Maybe with a limited number of uses? (That’s kinda what stamina does.)
  • Why is there a little loading bar after success/failure? At first I’d assumed it was doing work on the server side, but DevTools says it’s not making any network requests on success/failure. So why the loading bar? Or, more to the point, why is it so slow that it needs a loading bar??
  • Repetitive text-based descriptions of battles are surprisingly boring. When you watch a spiky-haired protagonist swing a sword at a troll and the number “73” pops up over the troll’s head, it moves fast; feels tight. “You swing your hammer at the troll and do 73 points of damage” is just not as fun, especially when the text is repetitive. ("… and do 48 points of damage" “… and do 87 points of damage”)
  • Seems like the game might be more fun with a character sheet, experience points, upgrades, etc.

Overall, this tech demo plus the home page doesn’t convey to me Egamebook’s “unique selling points.” Why would an interactive fiction author prefer Egamebook over Twine, ChoiceScript, or Undum/Raconteur?

I sense that the primary answer to this question is: “It’s written in Dart!” I do not approve of that answer.

From time to time, IF enthusiasts come to the table with alternate IF authoring systems in which authors can develop IF in a “real” programming language, typically one of the top 20 languages on the TIOBE index or at least a language that ranks highly on StackOverflow’s “most loved languages” list. … and-wanted

But none of the most popular IF systems require authors to use a “real” programming language. Instead, since most IF authors see themselves as writers first and coders second (if at all), all of the most popular systems use a domain-specific language for IF, ideally one that makes it easy to write extensions in another “real” programming language (typically JS).

And, ah, if you’ll forgive my bringing it up, Dart appears more highly on StackOverflow’s “most dreaded” list than on its “most loved” list.

Having said that, you’ve still got a shot. The language of your IF system is arguably the least important factor in making it popular. The most important factor is to implement an entire complete “admirable” game. Most people decide to use an IF system because they see a game that they admire, and they say, “I want to make a game just like that! Whatever system the author used to make it, I’ll use that system, too!” Admirers don’t seem to directly care about any of the details of the system, except that if it’s too hard for them to learn the system and finish a game, that’s a major factor in achieving true popularity.

So that brings my attention to the game itself. It feels very much like generic Fighting Fantasy. The story has some hooks, but little/no narrative payoff in the game itself. Despite that, if you make an entire finished game, people might try to emulate it. From there, you know what to do: write more gamebooks, talk to authors, and refine the system to make it easier for you to do what you need and easier for authors to pick it up.

Emily Short has a good blog post on IF Tool Development in general; it covers much the same ground. … n-general/

Hi, thanks for the feedback. I’m the author of this game.

I’ll address just a couple of points here — the ones that I think are easy to answer quickly. The other points are at least as interesting, but will need a full blown article each (which I plan).

There’s no work on the server, the whole game is client-side (executed on your computer). But there’s a lot of work on the client-side — for example, each paragraph of text during combat is at least 3 actors planning their moves at least 3 moves ahead. Not simple planning, either, more like playing chess with 3 different chess computers where outcome of each move is non-deterministic. (STRIPS planning — probably worthy of an article in itself.) So, none of these paragraphs is pre-authored. The actions in these are dynamic and then programatically stringed into a (hopefully) interesting prose. All of this is computationally expensive, and so you see the loading indicator.

Sorry to hear that, and I don’t agree (otherwise I wouldn’t be submitting it). There is polish I’d love to add, but I wouldn’t call it a tech demo. Of course, I’m biased. :slight_smile:

Accessibility is definitely one of those things I’d like to add, hopefully soon.

That’s why there is none of that “73 points of damage” in this game. You get prose like this (I just played to get a fresh paragraph):

You hurl your spear at the orc. The spear rams into the orc’s shoulder. The orc yells in pain, and looks at the goblin. “Now that is practice,” he says to him. He lunges at Briana and she sidesteps him. He falls to the rough floor. The goblin kicks Briana’s shin. But she doesn’t budge. “You don’t understand,” the orc growls. “No matter how many of us you kill, there will be more. And when we get you, we will eat your face alive.” He smirks. “You mean nothing.” Briana punches the goblin’s jaw. He staggers off balance.

So far, testers have enjoyed this. There’s much room for improvement, of course. But as I said, the above paragraphs are not pre-authored, and there’s a very small chance you will see the same paragraph as I just did. And there is no “you get 73 points of damage, he gets 20 points of damage” kind of grind.

Not at all. The actual technology and language doesn’t matter (and I admit I’m talking about Dart too much on — I got too excited when I was writing that page). What matters (to me, at least) is that you can build a simulated world and have it described procedurally, automatically. AFAIK, that’s not what you can do with Twine, ChoiceScript, or Undum/Raconteur.

My goal here is to enable indie “Skyrims” in text. The submitted game is not Skyrim in scope, of course, but I really believe it’s a step in that direction.

In other words, ChoiceScript (which I know is your project) and Egamebook are two different beasts. I think most IF authors will pick ChoiceScript, and rightly so. It’s excellent. Egamebook is more for game developers who would normally try to express themselves in 2D or 3D graphics. Now they have the option to go with text. You do need a programmer to build this kind of game, though.

This particular point is important to me, and I will definitely be expending it into a full-blown article.

True, but there is there is something of a “procedural oatmeal” issue here–I think we’ve had this discussion but here is a link about the oatmeal problem. Even if you’re very unlikely to see the same paragraph, the paragraphs feel pretty samey.

That said, this is definitely something I’m interested to see continuing to develop. (A thought I’ve had about this is that it’d be interesting to do something where combats are infrequent and often avoidable. For the first combat you get a blow-by-blow description. The more the PC fights, the more the descriptions get shortened to something like “You snap the guard’s neck”–as the PC becomes increasingly sociopathic and inured to killing.)

The oatmeal problem is definitely something I’m thinking about a lot.

Traditional (video)games are based on repetition. From Pong to Tetris to Elite to Skyrim, it’s about throwing similar problems at the player in rapid succession, and letting them learn from their mistakes, becoming better. To play is to learn. (This is not my idea, of course. It’s nicely described in Theory of Fun by Raph Koster.)

This creates a fundamental problem for text-based games — not just procedural ones. I’m going to write down my thinking on this one of these days but the simplified version is that you can make it work but you cannot use the usual attack-attack mechanic of traditional videogames, you have to have a lot of variety, and you have to interweave other prose. In this respect, procedural generation doesn’t make it easier for you to create content — but it makes the content unique and very responsive to user’s choices.

That’s a really neat idea!

I played this this afternoon, and enjoyed it a lot. It worked well on my iPad, and I enjoyed the sword and sorcery theme, and the battles. I suspect it’s probably a bit kind to the player overall, given how I got on. I’m not sure I should have fared quite so well given some of my choices! But I had a lot of fun, and definitely enjoyed it as a game experience. For me it was far more than a demo, especially considering some of the previous things I’ve seen like that in past years of IF Comp.

I’ve posted a review this game here: … le-vermin/

  • Jack

Hi All. I try to avoid reading other reviews before posting mine, so I have just come up to speed on this thread. I am pretty much on the same page as Dan, but am in awe of his practical experience in bringing an IF platform into a public-facing production setting.

I’d like to address one comment by the author – the focus on simulation, e.g., that between mélée rounds moves for each character, a deep analysis is performed, the equivalent to projecting moves a few turns ahead in chess. If that’s not too difficult and doesn’t use a lot of resources or take a lot of time that’s certainly welcome, but relative to other parts of the game system, my advice would be not to spend disproportionate effort on it.

My goal when DMing tabletop games is not accuracy but drama and fun. I know that some players would find this anathema, but when I roll dice behind the DM screen, sometimes I don’t care what numbers come up. Translating this to IF, what matters is what the player sees rather than the math under the hood.

If there is ever an IF re-imagining of the Seventh Seal, then a good chess engine would be appreciated, but if I am facing off against an orc who doesn’t have two neurons to rub together, I don’t think anyone will complain about a simpler algorithm as long as it outputs fluent, dramatic descriptions of the battle.

I am looking forward to seeing this system evolve and playing more games in it!



Thanks for the review, Jack!

For the record, I talked about a chess engine only in relation to the internal planning algorithm. I’m with you in terms of simulation vs fun. (For example, I had to tune how the orcs value their own life because otherwise they’d be too relatable in their fear of death.) What I’m going for with all this simulation-complexity is freedom for the player. One player told me the other day that he has replayed the game 15 times — which is clearly 14 times too many but it makes me excited anyway.

I’m glad you’ve mentioned DMing tabletop games because this game is in large parts influenced by my DM sessions with 8-15 year old kids.

Hi all,

In case anyone is interested in the in what’s behind the game, I just published this video:

In it, I show some code and change the first situation of the book by putting a sword on the ground.

Postmortem of sorts: … 99548ab2c4