Making “Catch and Release” Accssible

I just released “Catch and Release” last week. I’m really happy with it, and you should go play it right now! One thing that I’m proud of is that this is the first game I’ve made where I’ve tried to include accessibility options. To play around with them yourself, click the little gear icon in the top left to access the options menu.

Settings menu for a video game. Showing options to remap keys, increase text size, and change difficulty level.

I decided to include these options so more people can play and that AAA shooters aren’t the only accessible games. Because this is a game about dealing with chronic pain, and not just to show what that pain looks or feels like, but rather to give tools and practice and perspective to live with that pain easier. So to exclude a large portion of people living with chronic pain would be wrong and foolish.

I hope it makes sense from a business / development time / ROI perspective, but I honestly have no idea. The nice thing is that I have no idea if anything I’m doing right now makes sense through that lens! So it makes just as much sense as anything else. And it’s impossible to know without trying.

I consider myself able-bodied, but chronic pain plays a large part in my life. It’s a part of me, and it’s a part of my game-making. I want to build games and a business using my whole self. I want to create a community of players and creators who can connect over these issues where each community member is important and where they’re treated with care and kindness. Excluding people from this community is harmful to the business.


I got started by using AbleGamers’ incredibly useful and straightforward Includification guide. These were my initial development goals:

  1. Game playable only with mouse
  2. Playable only with keyboard
  3. Difficulty levels
    1. Coins easier to collect
    2. Blocks easier to avoid
    3. Slow down the game
  4. Text size adjustment
  5. Pause
  6. Save game
  7. Changeable fonts

These are pretty much everything that’s necessary to reach Level One on Includification’s developer guide. Some of those weren’t necessary because Catch and Release is either web-based or windowed on the desktop, and some I just didn’t have time to work out. My final implemented list was the following:

  1. Game playable only with mouse
  2. Game playable only with keyboard
  3. Difficulty levels
    1. Coins easier to collect
    2. Blocks easier to avoid
    3. Game slowed down
  4. Text size adjustment
  5. Minor colorblind help

I think it’s eminently possible for even small or solo game development teams to include difficulty and input options in their games. Adding keyboard controls for a mobile game may be impossible, but for desktop things, I’m pretty convinced that it’s doable to make nearly any game playable with one hand. It just takes time, but if you’re creative and committed to it, it’s doable. It’s really just a decision on the developer’s part. The same is true of difficulty settings.

And worrying about your game’s message being diluted or misrepresented if the difficulty or input scheme changes seems foolish to me. I’d much rather my game be accessible for people even in a slightly different way than my original “intent” than be completely walled off. At the very least, I think this is a question that is worth asking yourself as a small dev.

Of course, it does take time. Some tasks ended up taking longer than expected, and some didn’t work out at all. For example, providing alternate and customizable keyboard configurations for the web-based version didn’t pan out. This was a bummer because I was really proud of my solution for them, and they were working really well on the desktop versions. So the lesson is “always test on your target platform!” (Side note: I’m going to be switching away from GameMaker because of the discrepancies between its desktop and HTML5 deployments. It’s just too annoying.)

Also, in GameMaker, UI and a settings menu takes a lot of time. There’s no real GUI framework for GameMaker that I know of, so I had to build all my buttons and menus and naviation from scratch. It took wayyy too long. Changing the size of text in the game was easy enough, but then positioning objects around the resized text took some work. I’m still not 100% satisfied with my different solutions, and if anyone has any good strategies for doing this in general, I’d love to hear them so leave a comment, please.

For the most part, things generally worked though, even if they took longer than expected to implement.


Unfortunately, this is really all theory at this point. My play-testing protocol is pretty minimalist at this point for my games in general, and I wasn’t able to get any feedback specifically related to the accessibility features during development. I hope though, that this is an “If you build it, they will come,”-type scenario. And thanks to twitter I’ve already gotten some good feedback on how to improve going forward.

That said, I can draw a few conclusions about implementing accessibility features. Ultimately, with a finite amount of time and tools, it’s impossible to do everything to make your game 100% accessible. But something is better than nothing! And something is definitely possible It’s a learning process, and this was the first step and a bite-the-bullet experience for me. Hopefully next time will be easier and more comprehensive, and I’m excited to keep going and working on making my small, personal games as accessible as possible.

Leave a Reply

Your email address will not be published. Required fields are marked *