Python Based IF authoring

Hello to all the amazing people keeping Interactive Fiction alive (my first love)

I’m still perusing the boards here, as I’m new, but I cannot get the answer I’m looking for.

Is there a presently maintained python based authoring system?

I have seen something called PUB, and something called Pyf, but they appear to be long abandoned projects. I do see that Adrift, Inform and TADS are the big players but I just feel something more familiar would get people involved more.

Thanks for any help ;0)

There’s no presently-maintained Python system for parser-style IF. As far as I know.

For choice-based stories, Twine is written in Python. I don’t think Twine authors get much into Python coding, though.

Curveship is an authoring system built on top of Python, although it’s not actively maintained. It’s heavily focused on narrative variation but you can ignore that and just use the parser and world model.

Judging from how you say “more familiar” I suppose maybe your question can be generalized to other languages than Python. We talked about this in another thread but I’m not sure anybody got much wiser really.

The “use a standard programming language instead of some weird homebrew system” appears to make a lot of sense, but in fact all attempts to do this so far seems to have bombed, with the exception of javascript for choice-type IF (like Undum and the recently announced Dedalus). There are (AFAIK) no pure javascript parser IF systems (i.e. where you use javascript to write the story - there are javascript terps like Parchment, but that’s not using javascript as an authoring language).

Are there any particular reasons for using Python or is it just a language you know and love?

Some programming language popularity charts:

For choice-based stories with a historically character/relationship focus, there’s also Ren’Py.

There’s something to be said for this idea. On the other hand, most conventional programming languages are not very well suited to the particular needs of IF programming.

For example, stringing together a text output with some alternatives (based on the values of variables) is easier to type in an IF-specific language – and in a typical game, that will save you a lot of typing! In object-oriented languages like C++, you typically have to declare your objects in one place and then write the specific code for them in a different place – a cumbersome situation compared to languages like Inform 6 and TADS, which let you declare an object and code it in a single location.

I actually don’t know Python very well. I’m more famliar with Delphi and Ruby, maybe even Java. I’ve done very minor scripting with Python, but I do recognize how widespread it is and how many people do know it. Also, it appears in use by younger people. I feel that would help draw in new game designers that can just use a familiar language.

I spent last night learning TADS 3. I like it enough, seems simple. I’ll be making an adventure or two in it I’m sure. With that though, I still feel a more recognizable language would attract more interest in the genre of IF and deter less that may leave just due to having to learn yet another language.

Python being object oriented and having so many libraries does seem very fitting for this, especially when compared next to what I’ve seen in TADS. Class and multiple class inheritance would all be very similar. And all the existing Python libraries in the world could be used or modified to enhance it even more. Especially if you choose to advance them in such ways as Beyond Zork did with mapping features and other graphical components. (I’m not personally a fan of those but maybe others are)

I feel any IF contests or projects would get far more attention with more familiar territory.

Also, with tablets and smart phones bringing back older style games (probably mostly due to limitations in the hardware) IF could be poised to make a comeback. Sitting with iBooks on the iPad, could just as easily be navigating an IF adventure with a lot more mental interaction and problem solving. (think of the kids! :slight_smile: )

Well there was my reasoning sorry for the “verbal” blast :slight_smile:

I feel that this has not been a big factor, over IF’s history. Learning a new programming language is a small part of getting into IF; most of the work is learning the API and library, which would be just as true in Python or Javascript as in Inform or TADS.

I’m all for that.

I’m not an expert in Python, but TADS’s object model (although seemingly similar to traditional programming languages) have some important differences under the hood. Short summary is written at the bottom of http://www.tads.org/t3doc/doc/techman/t3oop.htm. But that’s not only the OOP model, but also whole language and virtual machine has a lots of tweaks in its design to make them especially useful for IF programming. All those things makes quite a difference in practice.

I just read that, but still think Python/Ruby cover as much as needed where that would be useful.

A good Python based authoring engine might even be a great way to learn Python. I’m unsure mostly rambling :slight_smile:

TADS so far has been easy to use though. And the tutorial is not bad.

I’m sure that would be a minority reason to want to have an IF library in an established general-purpose language, but I would be one of the minority. I spent a couple years trying to learn Inform 6 when I was a kid, and now I’m barely competent enough to stumble through Hugo code after having been using it for three years. It would be awesome if all that effort could have had a payoff beyond IF.

There once was P.A.W.S., but viewing its homepage, it looks like the last update was from 2008. So, nothing presently maintained.

After going through Inform 6, Hugo, and TADS 2, I can say it paid off for me…sort of. Especially when I got into a job where the programming environment used looks pretty close to what you’ve been using for IF. :wink:

But certainly some of the skills you learn coding/designing/writing IF should rub off on you, if you intend to get into jobs related to software development. IF, for me, combined 2 of the things I was into when I was a kid: programming and writing.

Oh, and here is Cloak of Darkness in PAWS: http://www.firthworks.com/roger/cloak/paws/index.html and in my eyes it quite well illustrates the difficulties one must face in most general purpose languages.

For example you can’t make object directly, but must make a class first and then instantiate that class into an object which leads to optical separation in the source. You must define methods on the class, but you are setting properties on an instance. You can also set properties in class through the SetMyProperties method (btw. this is only way you can inherit them), but that way you can’t set every property to refer to any other property, only to the ones already introduced in source code earlier. So when you are connecting two rooms together you must define this connection after both rooms have been defined in source code. This leads to even greater optical separation which typically means that you first have a declaration of all classes in the source code, than all instantiations of all objects and definitions of properties on them and then afterwards connection of the whole map together.

Specialized languages such as TADS can have some useful shorthands such as templates, macros and + to create a hierarchy of objects so you must not write several properties and methods in full (StartingLocation, SetDesc,…) but just their values. Definition order of objects is also not significant in the sense that you can refer any symbol from anywhere regardless if the symbol is declared before or after in the source code or even in different file.

So while I can’t hope to convince you definitely, I at least try to make a point that there are many little useful things in specialized languages which make coding easier in this particular domain.

Some of these disadvantages could be overcome by using more features and idioms of Python. If most objects in a game are singletons, a simple framework could maintain references to these singletons, allow references to them by string name, and instantiate them on first reference. A hypothetical naive translation of CoD I6 to Python syntax that assumes a library with these features (non-PAWS):

class Foyer(Location):
    name = 'Foyer of the Opera House'
    description = """
    You are standing in a spacious hall, splendidly decorated in red
    and gold, with glittering chandeliers overhead. The entrance from
    the street is to the north, and there are doorways south and west.
    """
    s = travel_to('Bar')
    w = travel_to('Cloakroom')
    n = """
    You've only just arrived, and besides, the weather outside
    seems to be getting worse.
    """

class Cloakroom(Location):
    description = """
    The walls of this small room were clearly once lined with hooks,
    though now only one remains. The exit is a door to the east.
    """
    e = travel_to('Foyer')

class Hook(Scenery, Supporter):
    def description(self):
        return ("It's just a small brass hook, " +
                "with a clock hanging on it."
                if self.has_child('Cloak')
                else "screwed to the wall.")
    aliases = ['small', 'brass', 'hook', 'peg']
    is_in = 'Cloakroom'

# ...

This would still allow inheritance and other forms of instantiation and instance references. Decorators and property descriptors are other ways to make the game text more succinct and intuitive, though I didn’t use them above.

I tend to favor domain-specific languages for stuff like this, but it’s interesting to think how close Python can come.

– Dan

that example was exactly what I was hoping to find. or close to it.

don’t even know if you need to make a class with each.

Probably could just do

foyer as a new Location
then
foyer.name
foyer.desc

and wlil already have all the events and what not tied to it.

Unsure about Python but in Ruby you can also manipulate the original class on the fly too.

Ok, that’s a nice trick. It’s much closer to an ideal in the terms of source code readability. It won’t work for a real class (non-sigleton), but that is much more common in library than in user’s game. Another possible little trick would be to simplify entering aliases by writing something like aliases = ‘small, brass, hook, peg’ and let the engine parse it into an array internally.

My Python skills are pretty rusty, but in Ruby you can do something like this:

honnef.co/posts/2009/10/dynamica … e_in_ruby/

Looks like the Pyf engine written in python uses XML files to help create locations and perhaps objects. I’m unsure that would be necessary or really add any gain though. You will still need to program the game logic, so you will still be in code anyway. May was well just define objects in the code. Much less writing than the XML anyway. And I’d think YAML would be more appropriate than XML for readability, though I suppose YAML was not in wide use at the time.

Well, at my house, coffee is black and data is JSON. Other versions you need to ask for. Just sayin’.

well i do like cream :slight_smile: maybe thats why :slight_smile: