Designing for accessibility can increase the reach and audience of games. But how hard is it, and where do we start? Greg Lobanov, lead developer on Chicory: A Colorful Tale, talks with us about wet sounds, boss fights, and colorblindness, and how designing for accessibility improves a game's overall design.
Designing for accessibility can increase the reach and audience of games. But how hard is it, and where do we start? Greg Lobanov, lead developer on Chicory: A Colorful Tale, talks with us about wet sounds, boss fights, and colorblindness, and how designing for accessibility improves a game's overall design.
Mark: Welcome to Game Dev Dialogs. I'm Mark Ivey, a software engineer on Google Doodles. Our guest today is Greg Lobanov: Indie game developer and lead developer on the game Chicory: A Colorful Tale. Thanks for joining us.
Greg: Yeah, thanks for having me.
Mark: How did you get started in games?
Greg: When I was a little kid I used to make board games with markers and--and scissors and glue and stuff. I just always thought it was really cool. I made like card games and--sold them. And I got really into webcomics when I was, like, 12 or 13. And I was drawing a webcomic that was really bad. And then I wanted to make a fighting game based on my webcomic. And so I did a Google search for just like, I don't know, game maker or something like that. And I found GameMaker, the software that I still use today to make games. But that was my start, I just found software to do it. I've always done it sort of as a hobby for fun. I never thought about it as a career option until, you know, I was getting kind of to the end of high school.
Mark: We're gonna talk about accessibility and games today. To start with, could you tell us what accessibility means to you?
Greg: Sure. To me accessibility is about adapting your game in a way that makes it playable for as broad an audience of people as possible. And that can include people with, like, motor disabilities, but also people who have for example, sensitivity to flashing lights, or, you know, just taste for certain kinds of sounds, or whatever. There's a million reasons why someone might not be able to play a game. So accessibility is about looking for those opportunities to make a game playable for people who otherwise wouldn't be able to.
Mark: Chicory has a surprising number of accessibility options for a game from a small indie studio. How big was the team that made Chicory? Am I right that it was small?
Greg: So our core team was about five people, maybe six. But we also worked with a publisher. We had a lot of localizers. And we worked with a series that did the console port. So depending on how you count it, you could say five, or you could say, like, 100.
Mark: Okay, sure. I was going to say, I'm looking at it in contrast to things like Forza Horizons or The Last of Us and so on, that also get press for having accessibility options. But those are from much larger teams.
Greg: So compared to them, especially when we talk about, like, technical and design stuff–I'm the only programmer or designer on the entire project. So, definitely a difference there in terms of our scope.
Mark: There are a lot of accessibility features in this game. There's options to change the control scheme, to disable controller rumble, to use toggling of buttons instead of holding buttons, modifying joystick dead zones. There's multiple options for difficulty. On the visual side there's options for controlling flashing effects, screen shake, text scroll speed, text animations, readable fonts, color tint. How did you make this happen? Did you know from the beginning that you wanted lots of accessibility features?
Greg: It was something that we knew we wanted to do. Whenever the game comes out I always learn about something that I didn't think of, that was a problem for somebody who played it. So I always just make a mental note to address that on the next one. Every game basically starts with--the options menu is, you know, like a copy and paste of the previous game. And then I'll add five more things that came up since the last one. So at this point I've just built up a really big rolodex of problems that people have had, that I am now aware of, that I'm trying to address. And I do think that there's a difference in knowing early on that you're going to try to have an option in there, because it changes the way you approach it. It's way easier to know in advance like, you know, this is an effect that will be able to be turned off, as opposed to coming in at the very end and realizing that, you know, "Oh, half these effects need to have an option to turn off”--kind of thing.
Mark: Do you have a list of these features sitting somewhere? Is it just in the options menu, or do you have a notebook or something?
Greg: Yeah, I don't have a notebook. I just look at the options menu from my games and copy from there. If I saw an option in another game that I thought sounded interesting or practical, I would write it down as a note-to-self to actually look at to do later.
Mark: So it sounds like, coming into this project, you'd already picked the features that you wanted to have.
Greg: A lot of them. Yeah. Although a lot of them were added in later on as well.
Mark: How did you pick which features to have?
Greg: The evaluation that we basically have to make is: how complicated is it to do something and how many people does this affect? Or how reasonable is this? Or is there an easier way to address this issue? It gets increasingly complicated to create options for people to avoid certain things. The benefit gets lower. But in a lot of cases, with text shaking, for example, or screen shaking, that's, like, a thing where there's only one point of contact in the game code, where the code that makes the screen shake, it's just one place where you can add a check that's like, "Hey, is this setting set to that? If so, then don't--don't do the effect here." It's turned off everywhere. So those are easy to do.
Mark: The menu has a very light-hearted tone to it. You know, for screen shake, it's not just enable/disable. The choices are yep, nope, and a bit.
Greg: Yeah.
Mark: And there's another option called wet sounds. And the choices are love them or let's not. Was this an intentional choice?
Greg: To be honest, it was like something that I started out doing because I thought it was funny. I was just writing out the text for on and off and I just thought, "Oh, there’s a different way to say on and off for this one. And then a different way to say on and off for this one." And then two years of, three years of development go by, and you've added so many options. And every time you go to add one: could I not repeat? Could I think of a new way to say this one? And so they got weirder and weirder as we added new ones. There wasn't a lot of practical thinking when it came into that. I was having fun, and then--then it became a challenge.
Mark: It fits the tone of the game very nicely. But it also made a lot of these things seem a lot less clinical. You know, it wasn't like, "Oh, do you wanna turn the option to, like, ameliorate this condition?"
Greg: Yeah.
Mark: I wanted to skip back to something that you mentioned earlier. Some of the suggestions for accessibility features turned out to be harder to do. And I wondered--do you have some examples of that?
Greg: The absolute hardest one to do is having custom controls. It just hits so many different control points throughout the game. Like, there are so many different places where that's relevant. Especially, I guess, for the way that I make my games, where a lot of different parts of the game are very bespoke. There's a mechanic that's only in this one screen, that works this one way, and it never comes back again. And the fact that controls can be customized makes each one of those an extra challenge, an extra check, an extra point of failure.
And then it also was really problematic for console certification stuff. Which is so, so boring. But consoles have a lot of really specific rules about the ways that you display, for example, like the icons. So we had issues where, like, our game actually got delayed because, you know, if your controls are set to a certain way, and then the user goes to a certain screen where the controls are set that certain way, then the icon that shows up to press that button for this input is too small on the screen. But only because it's a higher detail button or something, right? So it's like because they're in custom controls and they went to the screen and they saw that button icon and it's too small, we fail certification and we have to make a bigger icon.
It was totally a nightmare, and not fun at all. But it's super, super standard to do that. And I stand by the importance of doing that. I'm glad we put that work in. Some of the ones that people really liked a lot for our game, like content warnings, or like turning off the wet sounds or whatever. Those are things that not a lot of games do that we got recognition for. Those were super easy to do by comparison.
Mark: Yeah, that sounds about right. I had to implement custom controls for a doodle last summer.
Greg: Mm-hm.
Mark: And I had a similar experience of: This should be easy. Everyone does it. And you start digging into it and just the menu to make it work is, like, really rich and complicated and took way longer than expected.
Mark: Were there any other features that were sort of the flip side, where you thought they would be hard, but it turned out then that they were actually easy?
Greg: Yeah. The wet sounds one is I think is actually a really good example of one that… So we got feedback very, very early on, when we were just putting out the first trailer for the game, and I was getting feedback from people. And somebody mentioned to me, not a close friend, an acquaintance that I’d sent it to, he mentioned to me like, "Hey, so I actually have something called misophonia. Like I can't even listen to your trailer because all the sounds in it are really wet, and that disturbs me." So--
Mark: We should back up for a moment here. This is a game about painting. The wet sounds that you're talking about, can you just describe those briefly?
Greg: Yeah. So it's a game about painting where the player is just splashing paint around and painting on things. So it's just a lot of sounds of paint slathering on different surfaces and splashes of liquid and whatever. And actually every sound in the user interface like the menus and stuff was also made from chopped up recordings of paint. Everything is kind of built out of squelchy wet sounds. So yeah, we got feedback from somebody saying that, "Hey, like, I can't listen to your game, 'cause it sounds disgusting to me." Right?
And I brought that feedback to our audio designer and we talked about it and we were like, "Well, I mean, we're making a game about painting. This is probably feedback that is just not addressable for us, because our game is about that." Right? So I just got that feedback, and I immediately gave up on the idea of even trying to address it. And then when we were closer to coming out there was a week where I didn't know what I was working on. I think we were waiting to get back some QA testing or localization or something. And I remembered that feedback that we got.
Now the entire game is done, I know all the sounds we have in the game. How hard would it be to just tag them and turn them down? And it took me less than an hour to just go through all the sound files and be, "Oh, this one's wet. This one's wet." I added the tag to all those sounds, and then I put in the option and just all the sounds of that tag get turned off. And then I was like, "Wow, that--that's an option in the game." Like it was that easy. It was probably the one option in the game that we got the most surprising recognition for. People had never seen an option like that before, and it made the experience so much better for so many people. And I just feel silly now that I gave up so easily on it the first time. Right?
Mark: So that option is how I found out about the game. Someone on Twitter posted a screenshot of that option in the menu, and it just stood out as like, "I've never seen that before. That's really cool."
Let's see. We've talked a bit about the start of the process and the middle of the process. Let's move on sort of towards the end. How did you test that the features worked for the intended audience? What did--what did the QA process look like for this?
Greg: At the end of the day, you don't really know the full span of everybody who's gonna play your game. That's one of the horrors of QA. That's why there's always bugs when a game comes out. We didn't necessarily try to find the full range of all different kinds of disability to test the game. We were basically trying to think through what cases we were trying to handle with our features. And we made sure that on at least the technical level they worked and that they did what we expected them to do, and that they did what the options say they do. That's the most important thing.
We did end up testing with people who had sensitivity of flashing lights. We did test with people who were left-handed. We tested with people who have misophonia. We tested with people who were colorblind. That all happened I guess organically, because we just knew people who had all that kind of stuff. And I think that that basically covered the range of people that we were trying to cater to with our options as well.
The problems had more to do with just weird interactions that broke things that we didn't think about. Like the button icon is a good example. Those are the big issues we found through QA. And there's a lot of combinatorics with that, like, different things that can make stuff. We actually just found a new bug when the Switch version came out. Tens of thousands of people had played the game already, but it turned out that there's one puzzle in the entire game–a side puzzle on one screen doesn't work if a certain setting is turned to a certain level. We still find things like that. Right? Because we worked with a publisher, Finji, and they have really, really great QA testers, actually. They found so many things that I never would have found myself.
Mark: It is amazing to work with good QA testers.
Greg: Yes. Yeah. This is my first time working with a proper QA tester and I don't know if I'll be able to go back. I've never launched a game that had so few bugs. We definitely had, you know, more than zero, but I've never launched a game that had such a stable one. And I'm really, really happy with that, because it also was, like, the most technically ambitious game I've done.
Mark: Near the end of development, how did you keep accessibility a priority?
Greg: It definitely wasn't like the first thing I thought of when I was thinking about the game coming out and all those different things. You know, I was thinking about a story, making sure that landed; critical crash bugs, I was super worried about those. So it's a core value of mine, but priority’s maybe not exactly the way that I would put it.
I'm really grateful that we got so much recognition for it. And in fact, like I think it goes to show, I guess how much room there is for people to think about this stuff. I didn't think of us as an exceptional case. I actually felt that in some ways, like we were doing what I felt was kind of like a bare minimum. We were playtesting all the time. We were always getting feedback on it. And there were a lot of things that were added in, towards the end of the development, that were basically accessibility focused, because we were thinking about everyone's experience playing the game in that final testing phase. Like the wet sounds option that I added in that very end phase is a good example of a thing that didn't get in until quite near the end.
Other examples, like the skipping boss fights is something that we didn't add until actually quite late. It wasn’t until I was testing with a friend of ours. She was having such a great time. And then she got to a boss fight and was like, "I just hate this. I don't wanna play this." For so long it's just been in the back of my mind like, "Oh, maybe we should make a way to skip these." We had options to make them easier or whatever. And I was telling her, "Oh, you know, you could just turn--you could give yourself infinite health or, you know, you could make it so that, you know, whatever. You could make it to slow them down." Right? 'Cause those options were there.
And she was like, "Sure. Yeah. But I just don't wanna even see this. I just don't wanna be here. I just wanna go back to the story. I'm gonna go back to painting and stuff." And that's what really just hammered home for me. I was like, "Okay, we should just have the option to skip these." Which we--we’ve heard before. Right? But it was like seeing somebody actually having a bad time with the game was enough to make me realize how important that was..
I think for a game like this which is about painting and player creativity, the boss fights are a great example of a thing that does not really fit with the rest of the game. And for some people those are absolutely the highlight. Right? That's their favorite part. But for some people like that is just absolutely the low point. It's not what they're here for. And so recognizing that there's different things here for different people and how to surface that, and give people the option to basically get the version of the game they came to play out of it–I see it as design. Right? I see all those things as kind of mixing together.
Mark: As playing through the game, it's like this very chill experience until the boss fight. And then this frantic, almost rhythm game thing going on. I found it enjoyable, but it's a very different experience. Allowing people to skip boss fights is surprising. I can't think of many other games that do that. Did people just accept that?
Greg: Yeah, people just seemed to accept it. I resisted it a lot. Like, it was one of the first things that came up when I said there were gonna be boss fights in the game. There were people on the team who were like, "Well, so you can skip them, right?" And I was really resisting it because to me it was such an important part. The fact that it is such a surprising tonal shift is why I wanted it to be there, right? I thought that this is a way the story's gonna express itself. That is so important to the experience. This is one of the most surprising things to me that came out of it: When players actually do skip it, they know that a boss fight happened, and that they skipped it, and that's all the information you need.
Because you still see the characters going through the fallout of that and coming to terms with what just happened and you know, all the conversation that happens about that. And so you still understand what just happened, and you don't really miss anything. You don't miss any of the important context in the story. You don't miss any of the emotional catharsis or, like, the character arc or anything. So I was actually surprised at how much it, you know, didn't subtract anything from the experience to have the option to skip those. I'm really grateful that we had that in there. Yeah, another thing where I resisted it for so long, finally saw the light and saw I had to put it in. And then felt so silly when I realized that the game was just completely fine without it, you know.
And it's such an easy thing to do because that's not a thing that has weird combinatorics. It's literally like, just set the trigger that the boss is defeated and move on to the next cutscene. It's super easy to do and easy to test.
Mark: Do you have any way of knowing whether allowing allowing players to skip boss fights and not gating the game on difficulty had any effect on game completion rates?
Greg: I don’t have any data on that cause we don’t track the use of those features. I would have to assume that a lot more people got through the game because of that. So I know that even in my personal circle of friends there was a person I tested with, would not have beaten the game if not for that option. So I know at least she got through the game thanks to that. So presumably lots of other people did too, but I don’t have data on that.
Mark: It's really interesting. In this conversation with you, you haven't been referencing things like Xbox accessibility guidelines, but instead it almost sounds like every feature in there, every accessibility feature came from a personal story with someone that was playtesting the game.
Greg: Yeah, and I think that's accurate.
Mark: I learned about this very recently. I don't make Xbox games, so I--I had no idea right? They're very detailed and very rich, and I think they'd be--they look like an excellent resource for just, like, learning about the different types of accessibility. And I think they have a rating system. Like if on the store you want the little badge that says that your game is accessible to people with this condition, then you need to satisfy the following criteria.
Greg: Oh, I had no idea about that.
Mark: I--I mean, I only learned about it very recently in the past, like, month or two.
Greg: Huh.
Mark: But it's interesting that you've come up with a very different approach which is have lots of people try the game, and listen to their feedback and then do something about their feedback.
Greg: I mean, it seems so simple when you put it that way. But, yeah. I mean, that is--that is essentially the approach I guess. Yeah.
Mark: What's been the general player reaction to having these accessibility features?
Greg: It's been, I mean, very good. It subtracts nothing from the experience if you don't even look at the menu. Right? Like if you're not looking for those, then you don't need to know that they're there. But there's a lot of people who I think were able to have a really good experience of the game who otherwise wouldn't have, because those options were there. Especially because this is a game about, you know, creativity and--and, you know, painting and stuff. Like that's an experience that is very universal to the human experience. Like that's something that people of all ages can enjoy, right? You don't have to be like a gamer to see the appeal of that. So it really, it feels right to me that this game should, you know, be able to be fun for anybody who's like interested in going on an adventure and drawing right? Like those are the two--those should be the only two criteria to enjoy this game.
Mark: Yeah, that makes sense. Was there any negative feedback at all? I can't imagine, but was--did anyone complain?
Greg: Not about accessibility. No, I--I don't--at least not to my knowledge. If--if we got complaints, it would be about specific implementations which was actually helpful. For example, we had a lefthanded control scheme option. Our musician Lena is lefthanded. But she plays a lot of games, and so she's actually just used to not even having a lefthanded option. She just plays, you know, as if she's righthanded when she's playing games. But we had a lot of lefthanded people who were actually really excited about having the option, and they tried it out and then there were like, issues with it in certain sections of the game that didn't work as well with it. And so we got good feedback on that. And I did actually make changes after it came out.
Mark: How have other game developers reacted to Chicory?
Greg: Very, very positively. Our--our hugest success rate is with people who review games and probably people who make games are. This is a game whose story is all about making stuff. Making stuff is, it's a huge passion of mine. So to have this kind of like game that's kind of about that conversation. It's like a game that's really about the things that I just wanna hang out and talk about already. Yeah, I like that. It feels like making friends basically when people play it.
Mark: What games do you admire for accessibility? You mentioned earlier, you know, when you play games, you take notes on--on their menus. Do any stand out to you as being good examples?
Greg: One that stood out to me while we were working on this game was Ikenfell and that was made by a friend of mine, Chevy Ray. And he worked with some really talented accessibility designers I think who actually looked through the game and--and helped him kind of find some stuff. That was where we got the idea to do content warnings, which is, was another one of the big wins I think for this project. That game had like a really, really robust set of accessibility options, and ways to adjust, like, the difficulty of the game as well. It's like--it's like a really cool story RPG, but it's also got kind of like a hardcore difficulty in some places. Like it's got a lot of strategy to it, and so they did a really good job of kind of making that game accessible to people who were kind of looking for more story and not so much the gameplay stuff. That was really cool.
One that came up recently was Webbed. This game came out last year. It's a game where you play as a spider, and they had an option where you can just, like, turn your spider into a different creature. Which I thought was like mind blowing. Because they were like, "You know, if you're afraid of spiders don't worry, you can just be a ball or something instead." And I thought that was so I guess on the same level as our wet sounds thing where it's like –that's the whole point of your game, and you're just gonna turn that off." I mean, it must have made the game accessible to so many more people to have that as an option.
Mark: For sure. It's incredible to work in a medium that is so flexible.
Greg: Yeah.
Mark: Like I can't imagine, you know, starting up some movie on Netflix, but at the beginning saying I don't like spiders so just change all--in all those scenes change the spiders to dogs.
Greg: I really do wonder if someday that's gonna be a thing because especially nowadays, like when you think about movie effects and animation, like a lot of 'em are done in a very procedural way like games. Right? Like it's--it's a render key. Right? It's a 3D render scene with lighting and stuff. How crazy would it be to have, like, certain lights or colors or, like, after effects layers or whatever, right, that are just turned off, you know, when certain flags are set. And just have like just render the movie twice, 'cause they do that already for different resolutions or whatever. Right. So--or like 3D or whatever, right? So how crazy would it be to have, like, a no flashing effects version of the film or something? Right. It seems like it wouldn't be that hard, but I haven't made a Hollywood film before. So–
Mark: Right.
Greg: It just seems like something that could--could be such a cool win for accessibility if that was ever an option.
Mark: Looking back, which of the features from Chicory are you planning on pulling into your next game?
Greg: Some things will probably stay and some things won't. Every game has really different needs. There's basic things that like flashing effects, screen shake, like font style. Those are the things that I've learnt that basically, apply to any game that are always good to have. But things like turning off wet sounds like the other games I do might not even have those, but it might not really be relevant to them, for example. Because Chicory has such a specific style of combat and boss fight, a lot of those specific options are probably not gonna be relevant, but I think carrying through what kind of experience we're trying to give to people and making more people have access to it -that's basically what I'll be looking at.
Mark: If there's one thing you could--you wish you could see in games or in a game what would it be?
Greg: I had never seen content warnings before Ikenfell. We added it to Chicory and it was one of the ones that was actually quite easy to do. And I actually think like that's something that would be a really easy win for a lot of games to have. If you don't want them then you don't have them, but for some people like it's so useful to have that as an option. Something else that I would probably highlight is the ability to skip cutscenes. I've heard of games that have had content warnings, but no ability to skip cutscenes. And that makes no sense 'cause then they're just saying, "Hey, you're gonna see something horrible. Okay. Here it is."
Other than that, yeah, I guess like accessibility for color blindness is something that like a lot of games are thinking about more so now. Like with Chicory there was a lot of conversation about like how we made this game colorblind accessible, because it's a game about coloring. In our game even though all you do is draw we just made it so that the player never has to distinguish colors to solve puzzles. Even if you have perfect color sightedness it's just not fun to try to distinguish like a slightly different red from other reds. I think it'd be great for games to just never do that. 'Cause every time I've--I've like run into something where I'm thinking about doing that, and then I find another way to do it. I just always end up with a better designed game anyway, or--or thinking about how to add other signals like audio cues. Or--or like symbols or-- direction --or just use anything to kind of indicate what we're trying to indicate without just using color has always made the design better.
Mark: Yeah. It's interesting in Chicory because hearing that it's a--a game about painting, the color question comes to mind. But as soon as you try it it's like, "Oh, the game just cares that I painted. It doesn't care which paint I used."
Greg: Again, not an accessibility thing. It's just a better design. Right? That, you know, it's a game about creativity, so we let you choose what colors to use. And we never tell you like, "Hey, you have to make this thing blue. Or this wants to be red or something." That just never happens because the--the whole point is that you choose what color it is. Right. And that's what makes it fun.
Mark: It's interesting from this conversation. One thing I'm taking away is that none of this is really rocket science. None of it has, like, a secret trick or anything. It's more just like Chicory got the way it was by you just slowly over the course of several games, building up a list of accessibility features that people had asked for, and implementing those features. And then getting feedback from play testers and implementing their requests.
Greg: Yeah.
Mark: And the end result is that long list of features that we went over at the beginning.
Greg: A lot of it really does feel like kind of common sense. I never would've thought of myself as like an accessibility wizard or something, right? I never thought people would be asking me questions about how to do it, because people don't like wet sounds, so I made a thing to turn off wet sounds.
Mark: Sure. It's not magic. It's just work and the way you get it done is by doing it.
Greg: Yeah. Yeah.
Mark: That's--it's very reassuring. Right?
Greg: Yeah.
Mark: Where can people go to learn more about your work?
Greg: Right. So on Twitter, I'm @GregLobanov. Spelled L-O-B-A-N-O-V. You can follow me there to learn about my future works. My website is greg.style. I don't know how up to date it is, but that's basically the main two ways that you can kind of look at what I'm doing next. We have not announced I think anything about it really. But we are working on something that we're really excited about. So yeah, I would love for people to check it out.
Mark: Thanks so much for coming, Greg. This has been Game Dev Dialogs. Thank you all for listening.