As a fully sighted person, imo there was no real need for tile-based movement at all, instead you could just have provided options such as “go to tavern”, “explore forest” or “go back to town”. Which is to say, this is could have been a pure text rpg. The tile-based environment requires more input to accomplish basically the same, at least in terms of gameplay.
With enough rucksacks, you can draw your entire deck, then avoid ever having to end your turn and only ever play rucksacks and attack cards, keeping all other cards in your hand.
I gave it a quick try! Very nice game! Mechanics are simple and enjoyable. And it's great to see an accessible roguelike! Would love to see this concept fleshed out.
One thing I picked up is that the card description for silver says it's worth 5 copper, but the screenreader just says it can be traded for goods and services. Might want to add the 5 copper to the read description.
Other than that, it seems to work great with NVDA. I've sent it to some blind friends of mine to try out, and I'll let you know if they have any comments.
Also, as a programmer and amateur game creator myself, I'd love to see how things are implemented. Do you have some source code available somewhere? Are you perhaps accepting pull requests? Is there an offline-playable version available?
Glad you enjoyed it. Nice catch on the Silver card - I'll try to get the fix up this weekend.
As for how things are implemented, well let me tell you, it wasn't easy. The ARIA spec just doesn't seem to be cut out for interactive experiences like a game. It's best for the more one-sided "I decide how to navigate and consume largely static content" paradigm, and rather poor for other situations.
From a technical perspective, what's going on is that I'm using an aria-live region to speak things to the player and basically trying to structure things so that such a fragile speaking context works with the mechanics of the game.
One big problem is that you have very little control over what the aria-live region speaks, and in particular, you have no guarantee that it will speak anything, so you cannot reliably inform the player of anything! It interrupts itself all the time, which is great for contexts in which most people use web browsers, like tabbing through items on a page; you don't want to have to sit there listening to things when you've moved on. But in a game, the game needs to be able to exert information of its own. It's not a passive thing you browse (generally), and that model isn't really supported with the ARIA spec.
As a result, you need something that, at any given time, is a browseable, static reality that WILL work with the ARIA spec, which basically means: turn-based. I structured the game like a conversation – the game prompts you to make a decision, you make it, it tells you what you need to know to make the next decision. This runs counter to how screen readers treat just about every other page on the internet AND you're fighting the learned conventions of the person playing the game, but at least it's workable if you can convey some concepts to the player on how to navigate it. So the game has to establish some conventions of its own, and then hope that the ingrained behaviors of the player aren't so strong that they render them useless.
Because of the above, I came up with the concept of a "sentinel page" that explains some of this stuff on the front end, and some uniform conventions like always being able to type some keys for a recap of the current situation and context-sensitive help, but ultimately, there's not a lot of guidance out there regarding how to implement stuff like this. What's here was cobbled together from reading lots of articles about more mundane screen reader support cases, which usually boil down to "how to make your web form accessible", which only gets you so far.
If you're interested in still more details, the code is unobfuscated; just use the developer console in your web browser to check it out. You'll have to open the iframe itchio puts the game in and then browse the sources for accessible-game-framework.js, which is the heart of the game.
Just keep in mind this was all made in 48 hours one week for a game jam (the #7DRL), so it might be a little messier under the hood than it otherwise would be!
Ah cool, thanks so much for the explanation! And thanks for the tip to check out the code.
Haha, wow your code is so clean for a game jam! Comments and separate functions and files and everything! I feel a bit like this XKCD: https://xkcd.com/1267/
And yeah, I know how tricky getting things accessible can be. For my own attempt at an accessible game I just made a text area with an assertive aria-live property, and then I append all of the game's text there. Then the rest of the game is made with buttons with additional aria properties, and text areas and things.
I've downloaded all the js files and I've been playing around. It's a really nice and logical framework! I've managed to add two new flowers: roots and herbs which give 1 energize and 1 health respectively, a new herbalist hut who will buy roots and herbs from you for 1 silver each, a new enemy type: Ogre that spawns similar to a Hobgoblin, and modified the junk piles in the dungeon to have a 5% chance to find silver and 1% to find health / energy potions. It was all really easy to do!
I can see now what you meant with the messiness - a couple of funny naming conventions (e.g. thing_flower.js is more like thing_pickup.js, and thing_goblin.js is actually thing_enemy.js and so forth) and there is a bit of repetition that could be extracted into common functions, but otherwise it's super nice and clean and I had no trouble at all figuring it out! Did you really manage to make all this in time for the 7DRL?! I'm honestly super impressed.
I wanted to ask, if you're not continuing with the project, could I please get permission to upload the modified game as I expand it? I will give you full credit as the system designer and a link back here etc.
You can email me at chimes.mark@gmail.com if you want to talk directly, and I'd be happy to email you the changes I've made so far, or else upload them to my github directly so you can see the modifications if you're happy with that.
Did you really manage to make all this in time for the 7DRL?
Yes, but it's hardly my first game jam rodeo, so I have experience turning things like this around quickly. Also, I had been looking into HTML5 accessibility specs before the game jam as part of my day job - that's what gave me the idea to try to make a screen-reader game for 7DRL. It always helps when you already have some facility with the technologies you're going to use!
Also a correction: 7DRL was sevendays, not two days like I said before (hence the name, "Seven Day Roguelike"). Sorry - most of the game jams I do are two-day game jams, so I had that in my head when I wrote 48 hours above. So, no, I didn't actually do it all in 48 hours! But I did do it in a week.
I was hoping to get more content into the game, but I ran out of time. Originally, I was planning on a "stronghold" in each of the four compass directions in the forest, and you'd have to defeat all four bosses to win. But I only got in the one.
As for repurposing / republishing, I feel like the "right" thing to do would be to open-source it, create a GitHub repository for it, set up version control for it, and start handling pull requests. That would keep it all in one codebase and any edits either of us make would improve the same product.
But to do that, I would have to also devote the time to be a proper steward of the repository, which I shouldn't take on if I'm not confident I'd do a good job. Which I'm not.
So yeah, you have my permission to make derivative works and publish them with the following caveats:
Give your version a new name, to avoid confusion. If you'd like to use some variation of "Battle Weary" to retain the connection, propose something.
Non-commercial activities only.
Attribution back to this page, in the credits for your version and the web page is fine.
Also be aware I reserve the right to continue developing this myself, make sequels, give other people permission to use the code, etc. This is in no way an exclusive deal.
If the above is cool with you, have at it. Looking forward to seeing what you come up with to flesh it out.
I enjoyed this- Particularly how consistent and simple the interface is. The stated goal of being able to play without seeing the screen has clearly informed the rest of the design.
Is an expansion/followup planned?
Also; I noticed that 'Wraith Wail' doesn't actually set player.defense = 0 when "You lose all your defense." Was this a bug?
No expansion or follow-up is currently planned, but you never know. The game hasn't gotten much traction so it didn't seem like there was much interest in it.
As for the Wraith Wail, yeah, that's probably a bug! For now, just imagine a spooky wail and I'll see if I can get it fixed sometime this weekend. Thanks for taking the time to report it!
I just installed the screen reader NVDA to test this. First it sounded quite awkward until I realized that the voice-settings where set to German language which is not beneficial when reading English text! ;-)
But now I changed it to English and it perfectly works.
I find it exemplary that you enable people with visual disabilities to enjoy your game. Well done!
For people interested I can recommend Roguelike Radio episode 48 about "Designing for the Visually Impaired".
The game mechanics are also quite well-considered. I like how you combine a roguelike with a deck-building game.
By the way, is there a key to quit a game once started? Pressing arrow keys move the character, while pressing keys like tab, q, or keys not used by the game will say "bad key". In the end, I close the browser tab in order to quit.
There is no explicit, built-in key to quit the game. I assumed that users would either reload the page or simply navigate away or close the browser window when they were done playing, but if there's a convention for quitting browser games from a screen reader context, let me know and I'll see if I can implement it.
Nice! Thanks for letting me know how it works. I haven't been able to test it with NVDA - only VoiceOver - so it's good to hear it's working on other screen readers.
Well done, and the mechanics are really interesting. Thanks for making it and I hope you can get feedback from some differently abled folks to see if you did well on the accessibility front!
I still haven't heard from anyone who primarily uses a screen reader. I really hope it works and I'm not overlooking some glaring, obvious problem with the way I approached it!
← Return to game
Comments
Log in with itch.io to leave a comment.
Please add the downloadable version
Can you make a downloadable version of the game that would be amazing
Great game. Two bits of feedback:
As a fully sighted person, imo there was no real need for tile-based movement at all, instead you could just have provided options such as “go to tavern”, “explore forest” or “go back to town”. Which is to say, this is could have been a pure text rpg. The tile-based environment requires more input to accomplish basically the same, at least in terms of gameplay.
With enough rucksacks, you can draw your entire deck, then avoid ever having to end your turn and only ever play rucksacks and attack cards, keeping all other cards in your hand.
After some days playing.... Great game, really! Loved the system as a whole.
Nice work defeating the Necromancer!
Glad you enjoyed the game, thanks for playing, and thanks for taking the time to say so.
I gave it a quick try! Very nice game! Mechanics are simple and enjoyable. And it's great to see an accessible roguelike! Would love to see this concept fleshed out.
One thing I picked up is that the card description for silver says it's worth 5 copper, but the screenreader just says it can be traded for goods and services. Might want to add the 5 copper to the read description.
Other than that, it seems to work great with NVDA. I've sent it to some blind friends of mine to try out, and I'll let you know if they have any comments.
Also, as a programmer and amateur game creator myself, I'd love to see how things are implemented. Do you have some source code available somewhere? Are you perhaps accepting pull requests? Is there an offline-playable version available?
Once again, thanks, this is very cool!
Glad you enjoyed it. Nice catch on the Silver card - I'll try to get the fix up this weekend.
As for how things are implemented, well let me tell you, it wasn't easy. The ARIA spec just doesn't seem to be cut out for interactive experiences like a game. It's best for the more one-sided "I decide how to navigate and consume largely static content" paradigm, and rather poor for other situations.
From a technical perspective, what's going on is that I'm using an aria-live region to speak things to the player and basically trying to structure things so that such a fragile speaking context works with the mechanics of the game.
One big problem is that you have very little control over what the aria-live region speaks, and in particular, you have no guarantee that it will speak anything, so you cannot reliably inform the player of anything! It interrupts itself all the time, which is great for contexts in which most people use web browsers, like tabbing through items on a page; you don't want to have to sit there listening to things when you've moved on. But in a game, the game needs to be able to exert information of its own. It's not a passive thing you browse (generally), and that model isn't really supported with the ARIA spec.
As a result, you need something that, at any given time, is a browseable, static reality that WILL work with the ARIA spec, which basically means: turn-based. I structured the game like a conversation – the game prompts you to make a decision, you make it, it tells you what you need to know to make the next decision. This runs counter to how screen readers treat just about every other page on the internet AND you're fighting the learned conventions of the person playing the game, but at least it's workable if you can convey some concepts to the player on how to navigate it. So the game has to establish some conventions of its own, and then hope that the ingrained behaviors of the player aren't so strong that they render them useless.
Because of the above, I came up with the concept of a "sentinel page" that explains some of this stuff on the front end, and some uniform conventions like always being able to type some keys for a recap of the current situation and context-sensitive help, but ultimately, there's not a lot of guidance out there regarding how to implement stuff like this. What's here was cobbled together from reading lots of articles about more mundane screen reader support cases, which usually boil down to "how to make your web form accessible", which only gets you so far.
If you're interested in still more details, the code is unobfuscated; just use the developer console in your web browser to check it out. You'll have to open the iframe itchio puts the game in and then browse the sources for accessible-game-framework.js, which is the heart of the game.
Just keep in mind this was all made in
48 hoursone week for a game jam (the #7DRL), so it might be a little messier under the hood than it otherwise would be!Ah cool, thanks so much for the explanation! And thanks for the tip to check out the code.
Haha, wow your code is so clean for a game jam! Comments and separate functions and files and everything! I feel a bit like this XKCD: https://xkcd.com/1267/
And yeah, I know how tricky getting things accessible can be. For my own attempt at an accessible game I just made a text area with an assertive aria-live property, and then I append all of the game's text there. Then the rest of the game is made with buttons with additional aria properties, and text areas and things.
I've downloaded all the js files and I've been playing around. It's a really nice and logical framework! I've managed to add two new flowers: roots and herbs which give 1 energize and 1 health respectively, a new herbalist hut who will buy roots and herbs from you for 1 silver each, a new enemy type: Ogre that spawns similar to a Hobgoblin, and modified the junk piles in the dungeon to have a 5% chance to find silver and 1% to find health / energy potions. It was all really easy to do!
I can see now what you meant with the messiness - a couple of funny naming conventions (e.g. thing_flower.js is more like thing_pickup.js, and thing_goblin.js is actually thing_enemy.js and so forth) and there is a bit of repetition that could be extracted into common functions, but otherwise it's super nice and clean and I had no trouble at all figuring it out! Did you really manage to make all this in time for the 7DRL?! I'm honestly super impressed.
I wanted to ask, if you're not continuing with the project, could I please get permission to upload the modified game as I expand it? I will give you full credit as the system designer and a link back here etc.
You can email me at chimes.mark@gmail.com if you want to talk directly, and I'd be happy to email you the changes I've made so far, or else upload them to my github directly so you can see the modifications if you're happy with that.
Glad you're having fun with the code.
Yes, but it's hardly my first game jam rodeo, so I have experience turning things like this around quickly. Also, I had been looking into HTML5 accessibility specs before the game jam as part of my day job - that's what gave me the idea to try to make a screen-reader game for 7DRL. It always helps when you already have some facility with the technologies you're going to use!
Also a correction: 7DRL was seven days, not two days like I said before (hence the name, "Seven Day Roguelike"). Sorry - most of the game jams I do are two-day game jams, so I had that in my head when I wrote 48 hours above. So, no, I didn't actually do it all in 48 hours! But I did do it in a week.
I was hoping to get more content into the game, but I ran out of time. Originally, I was planning on a "stronghold" in each of the four compass directions in the forest, and you'd have to defeat all four bosses to win. But I only got in the one.
As for repurposing / republishing, I feel like the "right" thing to do would be to open-source it, create a GitHub repository for it, set up version control for it, and start handling pull requests. That would keep it all in one codebase and any edits either of us make would improve the same product.
But to do that, I would have to also devote the time to be a proper steward of the repository, which I shouldn't take on if I'm not confident I'd do a good job. Which I'm not.
So yeah, you have my permission to make derivative works and publish them with the following caveats:
Also be aware I reserve the right to continue developing this myself, make sequels, give other people permission to use the code, etc. This is in no way an exclusive deal.
If the above is cool with you, have at it. Looking forward to seeing what you come up with to flesh it out.
Yes, thank you, that's perfect! I'll post a link to the github repo here when I've made it.
I enjoyed this- Particularly how consistent and simple the interface is. The stated goal of being able to play without seeing the screen has clearly informed the rest of the design.
Is an expansion/followup planned?
Also;
I noticed that 'Wraith Wail' doesn't actually set player.defense = 0 when "You lose all your defense." Was this a bug?
Hi, thanks for playing! Glad you liked the game.
No expansion or follow-up is currently planned, but you never know. The game hasn't gotten much traction so it didn't seem like there was much interest in it.
As for the Wraith Wail, yeah, that's probably a bug! For now, just imagine a spooky wail and I'll see if I can get it fixed sometime this weekend. Thanks for taking the time to report it!
I just uploaded a new build that fixes the "Wraith Wail" bug. Thanks for bringing it to my attention!
Pretty cool, almost feels like playing a MUD
I just installed the screen reader NVDA to test this. First it sounded quite awkward until I realized that the voice-settings where set to German language which is not beneficial when reading English text! ;-)
But now I changed it to English and it perfectly works.
I find it exemplary that you enable people with visual disabilities to enjoy your game. Well done!
For people interested I can recommend Roguelike Radio episode 48 about "Designing for the Visually Impaired".
The game mechanics are also quite well-considered. I like how you combine a roguelike with a deck-building game.
Great game. Want to play the next version for sure.
I really like the game so far. I play using NVDA screen reader on Windows, and it work very well. Thanks for creating this cool game.
By the way, is there a key to quit a game once started? Pressing arrow keys move the character, while pressing keys like tab, q, or keys not used by the game will say "bad key". In the end, I close the browser tab in order to quit.
There is no explicit, built-in key to quit the game. I assumed that users would either reload the page or simply navigate away or close the browser window when they were done playing, but if there's a convention for quitting browser games from a screen reader context, let me know and I'll see if I can implement it.
Nice! Thanks for letting me know how it works. I haven't been able to test it with NVDA - only VoiceOver - so it's good to hear it's working on other screen readers.
Neat!
Well done, and the mechanics are really interesting. Thanks for making it and I hope you can get feedback from some differently abled folks to see if you did well on the accessibility front!
Glad you liked the game!
I still haven't heard from anyone who primarily uses a screen reader. I really hope it works and I'm not overlooking some glaring, obvious problem with the way I approached it!