Hi! I’m blind and have never coded before but want to learn to code IF games. Are some systems more accessible than others?
Welcome @ErinN !
I’ve gone ahead and split your post to a new topic since this is a good subject for discussion.
I found one older legacy topic which may or may not be helpful. The link to the legacy topic follows:
2 Likes
I wish I knew what works well for blind authors (I’m not blind myself), but we do have a few authors and players on this site that may chime in. @blindHunter @Mewtamer @Unseen_misfit16, for example.
For the time being, I would say you’re best bet is Twine. It has an offline and online editor that offer the same experience (so try the online version first). One trick to know is that Twine is not a story format, it is an editor that offers multiple formats (each with their own different language). By default, you will be using Harlowe within Twine, but here is an example comparison of the major, pre-packaged formats that come with Twine. (Avoid Snowman because it’s for advanced programmers.)
SugarCube is the most popular story format among Twine authors so you’ll find more people to help you with coding solutions. It apparently has good Aria HTML structure for blind players to parse game content too. You’ll have to change the story format in Twine to use it once you create a new story.
FYI, you’ll be making single file HTML games with Twine that any browser can run. So you can easily host your games for others to play or share them as attachments wherever you want.
I personally prefer the Chapbook story format because it’s even simpler in structure and purposefully limited to very basic programming concepts (everything you’ll ever need, in my opinion). I feel like Chapbook should be easier to parse the game code with a screen reader.
However, my gut tells me that you should start with SugarCube and when you get comfortable with the whole experience of it, try Chapbook out and see which you prefer before you make your magnum opus. (Chapbook was made by @klembot, the fellow who made Twine. He might be able to shed some light on my claims here.)
To author a game requires a really good understanding of the basics of Twine games, which requires you to read up and hold a lot of foreign concepts in your brain. This will be the biggest challenge until you have that “aha” moment and you begin to just build, instead of struggling to know what to do next. Initially, you just have to know that Twine makes choice-based games that present new passages of content when links are clicked. That’s it. Master that first.
Your first game project should be a short linear or branching story. Feel comfortable with that, then start introducing dynamic content that displays differently based on story variables that a player can change based upon their choices in a game. We’ll be here for when you get to that point. It’s not as scary as it sounds.
One of the nicer, most complete SugarCube references is here and was made by @manonamora. It’s a bit verbose, but scan the index links and you’ll find topics of interest.
Just remember, we’re here to help. You can even get people to test your game here. 
Welcome to the community and good luck with your first game! 
1 Like
Hi ErinN,
I don’t have personal experience with this, but I did find these posts from 2021:
I actually have a Computer Science degree, and learned C++ alongside learning to use a screen reader, but hit road blocks with every attempt to pick up an IF-specific language. When coding in C++, I write code in the nano text editor and compile using g++ though I do have to crank up espeakup’s punctuation level to max for it to read lines of code heavy with notation in a way that saves me from having to go character-by-character to find syntax errors and I’ve developed a habit of following closing curly braces with a //end [codeBlockType] comment to keep track of where blocks end and which block is ending.
I did try teaching myself Inform(not sure if 6 or 7, which is an important distinction as Inform 6 is more like a traditional general-purpose programming language while Inform 7 is built around the natural language principle) some years ago, but as I recall, the Inform editor was a non-option as at the time I was using a Linux setup that didn’t allow for launching arbitrary GUI apps(I had an accessible TUI menu, the ability to launch Firefox like running it on a kiosk or dropping to the Linux Console, but no full desktop environment) and the command line compiler for Inform was so vague in its output that I couldn’t get anywhere(not even compiling a single room game with nothing but a room description, basically the Hello World of IF)and that was years before I learned of this forum… More recently, I thought to give TADS a go and downloaded frobtads but couldn’t get it to compile and there wasn’t any package available for my distro.
Checking aptitude now, the only pre-built packages for inform I have access to are the Inform6 compiler and standard library and a package to add Inform 6 support to emacs and the only TADS package is qtads, a GUI interpreter built using the Qt toolkit.
Maybe I should give Inform 6 another go now that I have access to a place where folks can help me troubleshoot.
I like coding in C++, but as far as I know, no one has made a C++ library to handle the heavy lifting of all the things that are baseline for a parser game, and trying to write all that from scratch seems daunting and way beyond any personal project I’ve produced thus far… doesn’t help that I kind of prefer tinkeringg with mechanics over interface.
1 Like
I agree with Hal9000 that SugarCube is a good starting point, but wanted to add a few observations of my own. Neither SugarCube nor Harlowe have a particularly steep learning curve. Right out of the box you can write simple branching stories (CYOAs) with either. Add in variables and conditional tests, then you can write a complex game with either.
The advantage of Harlowe is that it provides better graphical interface tools for beginners, mostly used for text formatting. How will those graphical interface tools look on a screen reader, I’m not sure. The advantage of SugarCube is that if you want to go farther, SugarCube provides better integration with JavaScript, allowing for more customizable forms of interaction. For me, SugarCube has been the better choice.
Twine itself is largely a visual interface platform. The individual “passages” of code (think of them as rooms) are contained within boxes on the screen, which by default are generated in rather random screen locations. I don’t know how this would appear on a screen reader either. But there is an alternative. Twine code can also be written as Twee code, which is a purely text based coding system. There are several applications that can be used to write Twee code in Visual Studio, which is Microsoft’s popular coding platform. The version of Visual Studio I have installed is free. (but sorry, I am not familiar enough with Twee code to advise you which Twee code add-on to use.)
1 Like
Twine is good for beginner programmers, but as Doug Egan mentioned above, the Twine editor puts a lot of emphasis on the visual interface and mouse drag-and-drop, which might be difficult to manage. Doug also said you can use Twee to get around this, which is true, but in my experience Twee is very beginner-unfriendly to someone who’s never coded.
The Twine community puts a lot of importance on visuals and colors. Since Twine is HTML-based, it means the experience of a blind vs. sighted person, when it comes to playing the same Twine game using a screenreader and keyboard vs. just clicking around the mouse, are vastly different. I imagine a lot of Twine games, depending on how they’re coded, won’t even be accessible to people using the keyboard if they rely on mouse actions or links that can’t be followed with Enter on a keyboard. This shouldn’t matter so much for making games, though, and people should give grace if they know a dev is blind.
And on the other hand, parser games can also be very beginner-unfriendly to someone who’s never coded, especially if you’re not familiar with parser games. I wouldn’t recommend trying a parser system without playing some parser games first and familiarizing yourself with the mechanics of parser games. Twine’s accessibility report doesn’t look that bad. I think it’s worth a try, at least.
1 Like
In my usual hummingbird fashion I keep switching what system I want to use.
I’ve actually started looking at ChoiceScript again, and other than the requirement for manual compiling and testing from multiple files, the code for it is text-based with no graphical branching interface like Twine (outside of the text-only Twee method.) ChoiceScript is quite simple, but can do powerful things if you know how to leverage it. I’m using CSIDE which is a community-created IDE for ChoiceScript that really helps with the multiple file organization. It’s essentially a powerful text-editor specialized to write ChoiceScript that also runs the brute-force testing routines, allows side-by-side play testing, file handling and organization, and handles exporting a playable completed HTML file. Choice of Games titles made with ChoiceScript are also outputting just text with a few graphical stat bars on the statistics screen, so likely also quite potentially accessible for screen reader play.
I’ve also been experimenting in Storyfall which probably isn’t good for visually-impaired coding since it’s a no-code IDE with drop downs buttons and scrolley-slidey windows and gizmos everywhere, however one interesting thing in the development is it has the capability of automatically generating recorded text-to-speech spoken narration for almost any game text and choices automatically, so it may be a solution to create either IF “audiobooks” or potentially accessible audio narrated adventures.
What makes this not quite useful yet (Storyfall is useable and had a game jam but is still in development) the game system does allow typing in a number to select a choice instead of finding and clicking it, however the auto-generated narration doesn’t tell you what number a choice is. I suppose an author could incorporate that into the the choice text so it gets narrated. It also has a “tap spacebar to speak the text of your choice” which is interesting in theory, but when I tried it it had trouble understanding what I spoke because you can’t just say the first few words - it only seemed to work if I parroted back the entire choice text verbatim, which is tedious even when you can read it from the screen. Narrated numbers, or recognizing a choice from the first few words the player says only might potentially make voice-choice workable.
Beyond that, the narration doesn’t work for input-strings; if you have the player input their name, there’s no way for that to be voice-generated. Similar with random or cycling text variation, although it will generate different clips for hard-coded “if this, say/show this, otherwise say/show this” types of passages.
Storyfall (hopefully once it gets more feature-complete) could develop into a good system that actually is useful to create both “audiobook” IF as well as a potentially accessible spoken-language narrative game as long as it doesn’t get too complicated in structure.
1 Like
I don’t use a screen reader myself, but some people use Dialog via a screen reader, and we try to make the language and tools as accessible as possible for that. By default, though, everything runs in the terminal, which may be a plus or may be a minus depending on your level of experience with that.
2 Likes