Why on earth would anyone enter raw Python code into the Spring Thing?

Victor Gijsbers posed this question during his report on Theatre of Spud, an entry in the Spring Thing 2021 Back Garden.

As the author, I clearly have access to one of the possible solutions to this puzzle. There may be others I hadn’t anticipated though.


There’s obviously nothing wrong with Python per se, except that there’s really no great way to package Python programs as executables for desktop OSs, which creates situations like the linked thread. I work as a Python developer myself, and I know and love Python, but I would probably never use it for anything besides server backend stuff. The ecosystem just isn’t there, and it doesn’t seem very interested in getting there.

That said, the main problem with using Python or any other non-standard IF toolchain, is that you have to reinvent the wheel in order to end up with something that almost certainly doesn’t work as well as Inform and friends. That doesn’t mean it’s a bad idea, but like the age-old game development saying goes: If you want to make a game, use a game engine; if you want to make a game engine, make a game engine.

So a good reason to use Python to make a Spring Thing game would be to improve IF tooling in the Python ecosystem. A noble cause!


Yes that is my objective, to improve the options for IF authors who want to use Python.

I don’t think there’s anything intrinsically lacking in the Python ecosystem to achieve that. Ren’Py after all, manages to package executables to multiple platforms, and that’s Python-based.

In the meantime, I’m grateful to anyone who’s willing to tolerate the friction of installing a package or two; user testing is really important.


It obviously only targets windows, but I used to use py2exe to make a windows executable from python source. It works pretty well. Back when I used it I had issues getting it to play nice with OpenGL, but I doubt that’s a concern of yours for an IF project.

Yes, yes, it is possible, there’s just no great way. PyInstaller/py2app can build Mac apps, but you need to actually run them on a Mac yourself to build it, etc.

But many other languages (especially non-compiled ones) have similar issues, it’s not really a problem with Python. What I’m comparing with here is using dedicated IF or game engines, where you usually just click a button to deploy for the web and/or build for all OSs.

1 Like

I guess three common goals when writing IF are ‘I want to demonstrate skill and talent’, ‘I want to push the boundaries of what is possible’, and ‘I want people to love my game and play it a lot.’

Writing in raw Python code is great for the first two goals and absolutely awful for the last. I assume most people don’t have Python downloaded or installed, even among programmers (I know I at least had to reinstall it for the other Python game, which I played first). And Python doesn’t have the nice features of dedicated languages.

But I do think it’s great for the first two goals, and I think that’s how one might evaluate your success.


@tundish, thank you for this thread! (I’m one of the authors of the other Python game in the Spring Thing, “Space Diner” :grin: We were planning to write up some of the stuff below after the festival – if it’s not a good idea to talk so much about one’s own game now while the festival is open, please let me know!)

I think there are three questions here: 1. Why make a game in Python? 2. Why not provide an executable file? 3. Why submit it to Spring Thing 2021?

As for Question 1 (Why Python?), my personal main motivation actually was that I wanted to learn to program in Python (as @mathbrush correctly suspected in his review!), and games are my favorite kind of project. There were other motivations for us as well:

  • The game we wanted to do was basically a sim game, with a bit of an interactive fiction component. For implementing our diner mechanics – recipes inheriting properties from ingredients, human colonists inheriting properties from humans, etc. – Python seemed like a good fit.
  • It’s a good point that Python does not have the features of dedicated IF languages, especially all the existing excellent parsers and world models. On the other hand, Python is a powerful language with many well-maintained and documented libraries. For our specific purposes, it was, e.g., very helpful to be able to use simple functions for doing set operations, or for reading data from yaml files, which we used to create our levels. (However, I have written a game in Inform before, so I’ve experienced that it’s also possible to do almost anything in it, and there are also tons of helpful extensions.)
  • The game runs in the standard terminal, which also comes with some built-in features that we like, e.g., customizability and kind of being forced to use plain text, which I think helped us to improve the accessibility of the game. Also, one main built-in feature of the terminal is auto-completion, which we heavily rely on in “Space Diner”. We found it interesting to experiment with it as a possible alternative to standard free-input parsers for games with a limited set of commands.

As for Question 2 and Victor’s request for executable files, that’s a very reasonable and fair point. Executable files is what we tried to do initially, but we did not find a good way to produce them; it didn’t work reliably on all of our testers’ systems (see Tobias’s points).

What we ended up doing was creating a Python package, which makes it a few steps quicker to install and run the game. (This doesn’t solve the issue that Python needs to be installed first on systems that don’t include it by default, though.) After the Festival, we want to host it on pypi.org, so that the game can basically be installed with a single command directly from the repository. @tundish Maybe that would be an option for your project, too? Making the package was not trivial and also a learning experience for us, but the documentation was helpful (Help · PyPI).

As for Question 3 (Why Spring Thing?), I think it’s an interesting coincidence that there are two Python games this year, with some overlap but also some differences in the motivation behind the projects. To us, the Spring Thing’s Back Garden with its invitation to submit things from IF-adjacent areas seemed like a perfect way of getting feedback concerning the question what works and what doesn’t, especially with respect to the aspects that are different from games written using IF frameworks; I really appreciate the nuanced way in which such things are discussed in this forum and in the reviews. So I am very very happy about the discussion here :grinning:, I’m learning so much. We are grateful to anyone who tries our game out! (While also completely understanding if you decide not to; the decision and the risk to use a non-standard format is of course on us!)


Just to be clear, I wasn’t wondering why anyone would use Python (be my guest, please give me some Prolog games next year!) or why you would enter a Python game into Spring Thing. I was wondering why one would enter raw python source code into Spring Thing, rather than accompanying this with an executable. Of course, I was operating on the assumption that making an executable would be easy; a single command to gcc or something like that. Little did I know that, well, gcc doesn’t contain a python compiler, but in general, I understand from this thread that compiling to useful executables is hard. So that’s something I’ve learned!


I for one love Python but am always sceptical towards excecutables, so you have my support for this release! In my experience, the smoothest way of helping get a python program to run on someone else’s machine is with a pip requirements file:



Victor, thank you for the time you’re taking to try out all our games.

This topic is here so as not to hijack your review thread which I’m sure you’d like to keep separate from the technical issues you encountered.

You asked a very important question; why is Python not in 2021 a solid choice for a piece of Interactive Fiction?


Oh… I didn’t even think to mention this, but since renpy was mentioned earlier, that’s actually a valid way of making a distributable. Renpy runs straight python code, not just its own script.

I once made a fighting game engine in python and I was able to drop it right into renpy and compile an executable. I just had it fire off the fighting game as the first line of its game script. Easy peasy.


When it comes to “Why would anyone enter raw Python code into Spring Thing?”, my instinct is to answer “Because they can”. People will be creative with any tool at their disposal. If someone looks at Python and thinks, “Yes, I can think of some fun interactive fiction to do with this,” and proceeds to create some IF eligible for Spring Thing… …it seems only natural that a raw-Python-code IF would be in the Festival. I can certainly think of worse things that have been done under the premise of “Because they can”. (I can’t assess exactly how good an idea it was to release Theatre of Spud as raw Python code, for reasons that will become apparent).

Can confirm @tayruh 's statement about Ren’Py running Python as well as its native dialect; there are some single-line Python code snippets in Budacanta, particularly for the numeric states and randomiser function. One of the reasons I picked Ren’Py rather than any of the other options for programming a game was to try to learn some Python (a common beginner’s programming language that is nonetheless used by some serious programmers), after more direct methods of learning it had failed, and perhaps oddly, it’s working for that.

I have to admit that when I got to Theatre of Spud in my playthrough list (18 games to go, and I haven’t put reviews out because I’m not sure it would be in the spirit of the festival), I considered putting it into the Ren’Py environment to extract distributables. Unfortunately my computer can’t run Python 3.9 to do that with Theatre of Spud.

I will see if I can use the technique with Space Diner. Ren’Py is in the middle of the Python 2/3 transition. I don’t know whether it will work just yet (Space Diner requires Python 3 and it might need the upcoming Ren’Py 8 as a result), but I will have fun trying!


@tundish, I had some trouble getting the game running. I’ve posted a review: Theatre of Spud - Details

but I feel like I could definitely improve my review (and play experience) with a walkthrough. Do you have a walkthrough available? This must have taken a ton of work!

Hi Brian,

Thanks for taking time to try out Theatre of Spud, and for persisting through the technical issues.

I don’t have a walkthrough right now. And I think your existing review is entirely fair when you say; the main game concept seems like it could work, but I can’t proceed right now.

In terms of the story; it’s an assembly of real historical events smashed together for conflict, with a guest appearance by a old-school film villain (hence the pun in the title).

Only two Acts are implemented. The first is intended to be a simple tutorial and a very basic light puzzle to get started. The other Act occurs later on in the story, when there are phone calls which are intended to create increasing tension and peril.

Not only is this my first attempt at a piece of parser IF, I also chose to implement it in my own IF framework. So, very ambitious, and no surprise that at the moment the game doesn’t really deliver.

You’re not the only one to have installation issues. A key package dependency (docutils) was updated last weekend which broke any fresh installation. This happened after the SpringThing submission deadline, so neither I nor @aaronius spotted it. I should have frozen the package requirements at that point but sadly I didn’t.

I am committed to finishing this project. I’ve learned a great deal over the last few weeks, and would like to thank everyone who has given their time to trying it out.

I’m sorry if I’ve wasted anyone’s time, or lost any potential friends. I needed to get this thing out into the open to make it real, and the Back Garden seemed to be a good place to do it.


I appreciate the work you put into this!

The nice thing is that every criticism people have of your game right now is something easily fixable and not really about your personality. 100% you’ll be able to iron out stuff like timing and installation and giving players nudges. So I don’t think you’ve lost any friends at all. In fact, the glimpses I’ve seen of the actual game show a lot of sophistication when it comes to ‘flavor’ text and humor. I have no doubt you’ll be successful as an author in the long run, and look forward to your next game.

Edit: It reminds me of that one story from (googling…) the Prose Edda where Thor has to wrestle an old woman and everyone laughs when he gets knocked down onto one knee, but later he discovers he was really wrestling Old Age herself, and was the only one who could put up a fight at all. Trying to roll your own parser in Python is much harder task than just making an Inform or Twine game, so the standards of success are different!


I really appreciate the ideas in this thread. I had let Spring Thing pass me by, but I’ll have to go back and give another look.

Because I had a coding project (understand classes much better) that led to an actual fun game that seems worth sharing, maybe in IFComp, and how to share brought up some general questions.

As for why someone would share raw code? Well, I know I didn’t think to look for a py2exe or pyinstaller until I felt I had something worth sharing. I know I’ve had this problem a lot … I’m having so much fun with details, I don’t see the bigger pictures. For instance, with games on itch.io, I’ve had trouble with the web interface.

(This doesn’t solve the issue that Python needs to be installed first on systems that don’t include it by default, though.)

I think Python is a pretty good language for IF.

Sometimes I’ve thought it would be nice if cross-platform IF interpreters (such as Gargoyle) embedded a Python interpreter. The Python-based game could use Glk for UI like the other backends. This would make it more convenient to use a well-known language for parser IF, without having to build the entire user interface from scratch and the mess with platform-specific installers for distribution. (That leaves writing a custom parser and the game itself which is a big enough project in itself :smile: )

That said, as the web appears to be the primary platform nowadays, if I were to go the custom parser route, using Javascript seems lower-hanging fruit (It is possible to run Python on the web through Webassembly, but it involves so many moving parts…)

1 Like

There’s no supported way to sandbox Python, is the thing. If an interpreter included Python, an IF game file would have the same risk profile as any random downloaded .exe – it could delete documents, install viruses, etc.

This would be a huge shift in how we think about IF games. I don’t recommend it at all.


I agree, there have been a few attempts to sandbox Python over time, but the language is sufficiently complex that it’s virtually impossible to make foolproof.
(I guess compiling the entire thing to WebAssembly and making use of browser’s sandboxing would be one way though, e.g. like the RustPython interactive demo :slight_smile:)

That one tab made my browser freeze for 5 seconds or more while trying to load it. According to chrome it takes 280mb of ram. Meanwhile my Discord tab is using 190mb, this tab is 87mb, and my JS game engine is using 27mb. So… RustPython needs work, IMO.