@tundish, thank you for this thread! (I’m one of the authors of the other Python game in the Spring Thing, “Space Diner” 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 , 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!)