Adventuron port of Swigian available on Also, my experience with Adventuron as a noob

Swigian by Wildbriar_Games (

In 2017, I made a minimalist IFComp game called Swigian, which was attempt at pulling a hoax on the IF community /doing an experiment (for more info see here: Swigian - An Epistolary Postmortem - IFComp - The Interactive Fiction Community Forum (

After playing the game, Marco Innocenti offered to make some lovely graphics for it. I wrote some javascript code to incorporate the graphics into a version of Quixe, but I was disappointed with my own code.

Now that Adventuron is available, and suited for pixel art, I decided to try to port it and see what Adventuron is like.

My experience: Getting started
I was confused at first because I thought that Adventuron Classroom was a tutorial, with the ‘real’ Adventuron available elsewhere. But it turned out that the classroom is the actual coding area. I didn’t realize at first you could hide the left sidebar by dragging it over; that improved things immensely.

I went through the basic tutorial, and found it useful. However, I found it difficult to discover advanced techniques. At first, I used the quick reference at the end of the tutorial, then I found the Adventuron documentation (Adventuron User Guide) and the cookbook, which has more advanced techniques. However, there were many important techniques I could not find in those two documents but discovered through helpful adventuron experts, so I suspect some other source of documentation is out there. I think it would be great to have a giant sheet listing every command or flag possible for the code.

My experience: Inform vs Adventuron

I’d like to make it clear that I am fairly proficient at Inform 7 and very noobish at Adventuron. So, I won’t be describing what Adventuron is capable of, only what I was able to do with it.

Adventuron is far better at handling pixel art graphics than basic inform. Vorple can do fancy things, now, but it requires some effort, and Adventuron makes adding graphics smooth and easy.

The very largest difference between Inform 7 and Adventuron for me is that Inform 7 is about systems, while Adventuron was easiest for me to program case by case.

In Inform 7, creating a verb for one object generally creates it for all objects, and you define default behavior for it. Conversely, creating an object immediately defines basic responses for all several-dozen default verbs in Inform 7.

This creates a subtle pressure to create ‘mechanics’ in Inform games, where similar verbs are re-used over and over (for extreme examples, see Eat Me by Chandler Groover or Take by Katherine Morayati). It also makes it easy to enable clues where using the right verb with the wrong object nudges you towards that object.

Adventuron, on the other hand, introduces authors to parsing at the full command level. While it seems capable of some larger pattern-matching (the advanced features are very advanced!) the documentation, tutorials and sample games tend to code responses for specific verb-noun combinations.

This, I feel, creates more pressure to make one-off situations, where each verb is tied to one spot, to avoid situations where the player is trying a command in many areas and it doesn’t work.

Inform’s separate treatment of verb and noun takes into account if an object is present. This is generally useful but causes big problems with scope if you have, for instance, a room with a transparent window to another room where you can see but not touch objects.

Adventuron doesn’t have this problem, but it created other problems for me. Since command parsing doesn’t automatically check to see if an object is there, you have to manually add in “if (is_present “object”)” everywhere. My mistakes with this caused some fairly entertaining bugs in my port of Swigian (such as an invisible snake). However, I see this as making some scope-based problems (like those of Inform) almost trivial, which is really nice.

Some things should probably work in Adventuron but I just couldn’t figure out. Every object you create has the message “you see…”. Often I wanted to change that default, but couldn’t figure out how, so I sometimes got around it by not putting an object in a room and then adding some text to the room like ‘In front of you is a crypt’. Since Adventuron code doesn’t require an object to be present, I thought it was easier. Probably a bad idea of mine.

Another small issue is symmetric exits. I had two ledges that I wanted to have the same DOWN exit from, with no UP exit leading back to it, and I couldn’t figure that out.

I wasn’t sure how to change dynamic text outside of the {boolean ? first_text | second_text} format. This led to pretty silly stuff of mine like:

 ask_others : string "ASK OTHERS to ask about the others";
 ask_fire : string "ASK FIRE to ask about fire";
 ask_hrothgar : string "ASK HROTHGAR to ask about Hrothgar";
 ask_help : string "ASK HELP to ask about help";
 ask_beowulf : string "ASK BEOWULF to ask about Beowulf";
 ask_text : string "{others_asked ? true_fire : ask_others}";
 true_fire : string "{fire_asked ? true_hrothgar : ask_fire}";
 true_hrothgar : string "{hrothgar_asked ? true_help : ask_hrothgar}";
 true_help : string "{help_asked ? ask_beowulf : ask_help}";
 true_thirsty : string ". You are thirsty, hungry, and tired";
 thirsty_text : string "{said_thirsty ? nothing_text : true_thirsty}";

Now that I’ve actually finished the game, I see that there actually is a ‘set_string’ function in Adventuron’s documentation, which makes me feel quite dumb as that would have been intensely useful and saved me headaches. This is why I think that a master of Adventuron could do pretty much anything.

My experience: Time

I originally wrote Swigian in one long day, then spent a few hours testing it. I was already experienced with Inform 7 at the time.

Learning Adventuron from scratch, porting the game, and testing, I spent probably 10 hours on this port. Overall, I don’t see a clear advantage either way.

My opinion: Capabilities

I believe that at some level of proficiency, Adventuron can do the vast majority of things Inform can do, especially in the hands of someone experienced and practiced. The difference is in what’s easy to do in one versus the other. I think Adventuron is better for games with strong senses of place and an inventory-focused puzzle system, and/or graphic intense games. I think Inform is easier for games with a strong focus on mechanics. But really good authors like Errol ( Errol - are making mechanics-based quality games as we speak.

I think overall, I will stick to Inform and that I generally prefer the style of Inform games, because that’s what I’m familiar with and comfortable with. However, I’ve loved the recent adventuron games that have come out, and I hope to see some entered in Parser Comp and/or IFComp.


I just played the intro until I could safely eat my meal.
I like it. Minimalist words and moody graphics work together very well.
Very fast pace (because no Xing), but maybe that changes when I encounter puzzles. Will definitely play this.


There’s also a Display Side Documentation item in the menu. It is selected by default. Click it to hide the left-hand tutorial documentation.

Everyone has a problem with that. There’s a longer tutorial, as well, but both of these are aimed at beginners. For advanced techniques, a few things are covered by the user guide and cookbook, but the best source of advanced info are the various forums at past Adventuron game jams, here, Telegram and now Discord. The Discord server is very active at the moment.

I couldn’t agree more. I keep my own notes, but it’s hard to collect the info in the first place and just as hard to keep it up-to-date, as Adventuron is constantly changing.

You can do the same thing in Adventuron, but it’s a lot more work, as there is no standard library. The most technically sophisticated example of this is probably my own game, ‘Santa’s Trainee Elf’. This includes a full-sentence parser, generic action handlers, some implicit actions and fully-functioning supporters and containers, amongst other things.

In my experience, scope is one of the biggest issues in Adventuron. This is because of its heritage. It started out as a souped-up adventure authoring tool that worked much the same way as the older 8-bit authoring tools such as The Quill, PAW, GAC and DAAD. These tools are not object oriented. Everything is in scope by default. You merely do pattern matching and then it’s up to you to work out whether an object is present, carried etc. Now that Adventuron is getting more sophisticated, it gets confused about scope. If you have two or more objects that share the same nouns, it often gets the first object that it encounters, even though that object is not in scope, and the rest of your code succeeds or fails when it should actually be the other way around. You can’t have two systems working side by side. It really needs to ditch the old system if more generic parsing principles are to succeed.

You can change the styles of the object list, exit list and most of the system messages in the theme{} section. You can include an object in the room description, but not include it in the object list by using conspicuous = "false" in the object definition. (This is equivalent to the scenery attribute in Inform 6.) The default conspicuous = "true" is equivalent to the static attribute in Inform 6.

Exits are two-way by default. Personally, I find this very confusing, so I use one-way exits exclusively. To make a one-way exit, just append ‘_oneway’ to the direction, e.g. room01, down_oneway, room02.

You don’t have to. That’s the whole point of dynamic strings. The logic is contained in the string declaration itself. When the string is printed, all the logic in the dynamic string is worked out and the resultant string is printed. For example, here’s one I use for printing the score in the status bar: header_score : dynamic_string {(score + "/100")} And here’s one I use for printing ‘is’ or ‘are’, depending on whether the object is singular or plural: is_or_are : dynamic_string {(s1_has_trait "plural_t" ? "are" : "is")}

Not anything, but there are very few limitations. It might take a little effort, but that effort is far less than in most other languages. For now, authors have to complain if something doesn’t work the way they want and it will get fixed very quickly. Usually.

Me too.