Read post 46 of this topic
https://forum.audiogames.net/topic/3074 … fl/page/2/
If the shitty attitude of some people on here is not the cause as to why she doesn't come here anymore, then I wonder why.
Read post 46 of this topic
I'd rather be told no than get jerked around. There's a sense of closure to it.
It's very easy, if you see a topic about BGT, simply don't reply to it.
If you're thinking about creating a topic about BGT, just don't.
Doing these things will cause all such topics to sink to oblivion.
Lets send a link to this topic to the developers. Shall we?
Remember guys: This is an official forum, where everyone can read, also without having an account.
#54 (edited by connor142 2021-04-16 10:06:21)
@50 go check when ea-accessible (the account that Carin used to run btw) last posted, then come back and tell me they haven't left.
I find it really hilarious that people who have absolutely no knowledge in software development and computer programming are claiming that making a game accessible is easy and isn't hard at all. You guys have absolutely no idea what your talking about. Absolutely none. People like Camlorn and I have experience doing this kind of thing, and if we say it might take hundreds to thousands of hours, that's most likely true, if not an under-estimation of how long it would take. We can't just snap our fingers and boom, something's accessible. So stop acting like we can. Cut it out with the entitlement as though you somehow have a god-given right to be able to play these games: you don't. Its a privilege. Get over it. And the more you blast out this entitlement bullshit, the less likely developers will take this community seriously. Frankly, the fact that we have accessible mainstream games at all is astonishing given the amount of entitlement you guys display here.
I want to try to understand this a little bit, because I don't have very much knowledge on the subject. I don't mean to bash or blame anyone with this question; this is something I am genuinely curious about.
I know that developing game accessibility is costly, but why? What are the things they have to pay for and a rough estimate of the prices for each thing they need to account for? Again, I don't mean this in bad faith. I really want to understand this better.
it's hard to articulate this if you aren't already a programmer, which is why nonprogrammers throw these estimates around and think they know what they're talking about. For a concrete example, I just spent 6 man-hours changing 100 lines of code to tweak something about how we do permissions and something like a day tracking down a small bug while also dragging in half the company periodically.
A game isn't one piece of software. It's like, 100 pieces of software each handling an event. Stewie effectively had Slay The Spire's source code because java decompiles easily and the modding community for STS is actually pretty far along. If it was just hook a couple menus up then fine, whatever, it'd have been done in a week. But it was literally "and then we have this one random event that uses a different code path" over and over. And this is typical. That's just how games are written. Games aren't about "every button looks the same", they're about building atmosphere and stuff, and that means that maybe you literally wrote a special kind of button from scratch because you wanted it to be an animated beating heart with weird lightning particle effects--a button that now has to be handled separately from every other kind of button when making it accessible.
Your GUI framework may not even have keyboard support. That right there is at least a couple days if it's possible at all. In the worst case you'll have to throw it out because if your GUI code assumes a mouse in all cases you may not even have a concept of keyboard focus. There are entire programming languages where all the off the shelf GUI options are inaccessible and you can't make an accessible GUI even as a blind dev. It's so bad that my MMO thing is literally planning to use two programming languages--one for 99% of the code, and one for an accessible UI. That's actually not that unusual--you see that kind of abstraction in e.g. most big cross-platform apps--but doing it for accessibility is basically the wrong reason.
This puts you in the realm of self voicing, which means going through your code and making sure that all your menus and whatever know how to announce everything. That's not centralized. It's a review of every line of your codebase to see if it's a line that should speak.
If you miss a spot that's a bug. No one on your team is going to be using a screen reader which means that every step of this process is incredibly tedious. It's not always possible to take the game and be like "magic cheat code to get to step 20 of this event". So that's manually going through everything and making sure it's self voicing, and maybe having to play big segments of content to get to the thing that's buggy. And of course, god help you if the bug doesn't trigger every time. You don't have someone blind on the team because if it was accessible you wouldn't be doing the work. Yes, I have seen the EA thing, but frankly if you go blind enough that you need a screen reader you're not going to be coding for at least 3 years or so, so I'm pretty sure that was an advisory capacity only, and most small studios don't have the resources to let a blind member of the team stay around while they work all that out.
and okay, fine. You did all that. Now how about the events based on color? Anything that uses drag and drop? Anything that is basically a deluge of information that can't be represented in audio? Things based on 3D rotation? here's a good one. Quick time events are basically random rhythm games, which is fine, except that doing a sequence storm style thing is actually a huge coding effort *and* will leave you unable to pay attention to the rest of the event thus removing any value from the cutscene. maybe there's exactly one thing in the entire game that relies on the position of the sun through a window, which requires you to remember it and go add something for time, and an extra hint or something so that we know that that's the puzzle. However many these are, you're reimplementing these parts of the game for the blind one way or another. If this is bad enough maybe you have to redesign the game from the ground up to be playable by both--there are entire genres that can't be made accessible, though this isn't one of them.
Then after all that, because no one in the company can test it, you go through round after round of bugs. And every time you add something new you have to do all of this all over again. Triage alone costs multiple man-hours a week (my minimum work meeting overhead is 3-4 hours a week for just general company things, usually more, and we're a very streamlined tech startup). just having a new group of players producing lots of things to go through your support system will bog that down, and anything done here is a big source of bugs, so that'll definitely happen.
or you say "okay, let's do unit testing", but unit testing something like a game requires twice the experience/skill and that's twice the salary, and then half your time goes to writing tests instead of chasing bugs plus you've doubled the cost of the company. It's a lose lose situation. It's not just blindness. This is how building the game worked in the first place. That small arcade game from the appstore took someone months to start with. No one is just going and doing a game over the weekend and selling it and making a year's worth of money. I mean not literally no one, John Carmac is a legend for a reason, but you're not going to get a John Carmac to be like "yeah, blind accessibility, let's do that" at your small studio because if you had a John Carmac you'd probably not be small anymore.
And--well. There's this idea that the indie studios writing niche games are rich. They're not. They're usually running with pretty thin margins. It's not like games are some sort of giant money-making opportunity in sighted land. And you can't lower the salaries of your programmers because if you do that they'll just go work somewhere else. Programming is a skilled profession in the sense that you can't just wave your magic college education wand and get more. I don't expect there to ever be enough programmers, so the cost stays high. The amount of software that needs coding is still expanding at a tremendous rate, and the sort of mentality you need to want to code isn't universal. Game programming requires the best of the best, especially if we're talking about the kind of people who can be like "I rewrote half the code for blind people in 2 weeks".
100 man-hours is under 3 weeks of full-time work for one person. Hundreds of hours for anything is actually pretty low. A few hundred hours sounds like a big number, but most things in any job--not just programming--will take multiple man-weeks. That's just how this goes. But to be frank my $50/hour figure is actually kind of low, if you talk about somewhere like Silicon Valley, and anyone who can do this stuff can just go there instead. Plus you've promised deadlines to your customers and maybe your investors, so having those slip is a cost that's kind of hard to quantify as dollars, but it hurts a lot if you go for a funding round and you say "we were late" and they say "why" and you say "well we decided to not make money and help blind people instead", because that shows that you'll just go chase things. So there's also that factor as well.
But look, frankly things like building accessibility and getting braile menus for restaurants and whatever else are also more expensive than you think. It doesn't matter what arena we're in. Accessibility costs money. In other arenas like crosswalks, it's reasonable to say "well I can't cross the road, that's a problem". That accessible crosswalk you got put in probably cost $10000. that accessible wheelchair ramp probably also cost at least $5000. There's a reason Ada trolling was enough of a thing that we tried to modify the ADA a few years back--it's literally cheaper to settle massive lawsuits than to fix this stuff in most cases, and it was (and maybe still is) literally a viable business plan to sue people and offer them a settlement. Game-related stuff is bad subjectively, but $20000 is actually a really low number as these things go.
@57, thanks for posting that, I wasn't sure where to begin or how to describe that because I don't have job experience yet.
I've made several things accessible over the years. I've made a couple GTA trainers accessible; one was a collaborative effort and the other was one I did on my own. Both took me nearly a week to just make accessible and then another few weeks to test. The collaborative one was a failure in the end because the guy I was working with was a dick, but the point I was getting at was, for a game like GTA V where the game was never built with accessibility in mind, its primarily guesswork to figure out where to put the code that makes it talk or print braille or whatnot. If you put it in the wrong place, the code gets looped at the framerate of the game because the game is continuously calling taht function. Or you might put it in the place that seems right but it turns out that that code is hardly ever called. And so on. The more complicated a project is, the longer it will take to be made accessible, and the more money its going to cost. My UEFI accessibility effort is probably going to take at least 2 years at minimum. We might get a basic UEFI shell accessible but then we'll want setup utilities accessible, and so we'll do that, and then someone is gonna come along and give us an app that uses weird UI mechanisms and doesn't use the built-in user interface elements and so we'll have to figure that out too. Or we'll get a ton of feature requests asking for more additions to the audio subsystem. And so on and so forth.
The primary point that Camlorn, Liam and others are trying to make here is that this forum is far too impatient. We have ignorant people who say "Well just make it accessible, god damnit!" and they don't realize just how much they're asking for. And so when a company balks at the request and goes "Hell no, we can't do that", we get people raging about it. And that kind of atmosphere is going to put a lot of potential studios off -- they'll ask themselves "Why the hell should we cater to these people?" After all, they've already got the shareholders and investors breathing down their necks asking them those questions, and this atmosphere of entitlement is only going to make them turn around and say to their investors, "Hey, we saw all of these entitled assholes on this forum, and if that's the kind of shit we can expect from blind people, then we're not even going to bother."
Is this something we could possibly code a large neural engine for at some point in the future? After all, AI is advancing pretty quickly. 20 years ago we didn't have complicated AI like that, but now we've got AI that can synthesize a human voice from as little as 5 seconds of audio data, and we have AI that can rip stems from music. Albeit, the quality isn't amazing, but it still managed it decently. Maybe if we could provide an AI with examples of games with and without accessibility and we manage to perfect it over time, developers won't have to spending all that time working on it. This is just a thought of course. I know things aren't that simple. If it was, almost every game under the sun would be accessible by now.
@59, how? In order for an AI to learn something you have to provide it with input data. A game that isn't accessible vs. a game that is isn't really something you can put into an AI training model to teach it how to make it accessible. At most you can get away with AI-done OCR, but that's not enough.
Yeah. AI isn't some magic bullet, and the game accessibility problem isn't just labeling buttons. I'm not sure why these discussions always inevitably turn into "why don't we just label the buttons" Maybe because most of you haven't played sighted videogames and audiogames are basically in the gaming dark ages, I dunno.
That's not exactly what I meant, but OK.
AI isn't there yet, and probably won't be for a long time. Look at AccessiB. Web accessibility is just purely easier than game accessibility, and AccessiB still fucks it up.
@63, the major problem with AccessiB is that the people who run it just don't know what they're talking about when it comes to web accessibility.
I've come up with two conclusions here.
1. Things are stupid expensive and cost a lot of money not because they -actually cost money, but because people have decided that they do. In practical, everyday terms, there's no difference. But if a programmer who didn't have to worry about putting bread on their table told you that they were willing to make your project accessible for free, technically nothing is stopping them from doing it. Of course, in the present day, virtually nobody does that, because they can't afford to.
2. People like Daniel Lemon, who apparently made his entire game go from being inaccessible to like 99.94% accessible by himself, is an absolute fucking hero.
https://www.dropbox.com/s/z8ls3rc3f4mkb … n.txt?dl=1
I wouldn't say that it's expensive just because people want it to be. People forget that programming is engineering. To provide more color on this, here is the gist of what goes into a small feature at a small, fast-moving startup (say, any organization over 10 people).
First, customer says "I want the thing". Support puts it in the "maybe we should do the thing" bucket, with priority based off how big the customer is or how many people are asking, and also goes back and forth a bit to find out why and get the underlying cause. Call this a couple hours per potential feature we might do.
Next it goes through sales/marketing, and product manager, who will decide "yes we should do the feature" and "yes we can afford the feature", before it even lands on engineering's plate. This may sound really stupid, but even if you only have 3 features Bob is probably working on this unrelated thing, and Jane on that other unrelated thing, and so on. Since programming is a high context thing, the loss of yanking people off to do these steps in the planning process is incredibly huge. The only effective way to get anything done is to make sure that these steps aren't put on the dev team, so someone has to handle them and get basic product requirements. It's hard to say how long this part takes because it really depends what it is and how much people spend debating/refining/whatever before they go ask engineering for something.
Next, we've decided we're doing the thing. Now we have to get every dev on the related teams aware that we're doing the thing, and in agreement as to the estimate of the thing. This means sketching out a basic design of it. Not complete, but enough to say "yes we can and it will take x weeks". This easily eats at least a man-day, but usually much more than that.
Then everyone agrees on the requirements and success criteria, cool. Then you figure out what the real design is, code a prototype, maybe, or whatever. This is going to involve somehow making sure everyone stays in sync because if not then you end up in situations where only Bob can maintain the critical thing and then Bob quits, so it's really not optional even if we disregard the bit about needing to allow for teamwork. This will produce a bunch more documents and some code, and maybe an MVP. It'll drag everyone in at one point or another, off whatever they're doing. This gets worse for large codebases and old code in a nonlinear fashion because it's very much the case that only this one person at the company who's very busy knows how some piece works, and you spend forever not even knowing that the piece exists until they happen to hear about your problem and come in and are like "why didn't you just" after you spent a week on it. That exact thing literally happened to me at a smaller scale this week, and even happens at Google-level orgs.
Aaaand now you're at the coding. Except you're a company trying to produce reliable software, not an indie dev working in the garage, so you're also at the code reviews (a second dev checks your work) and the testing (you write a bunch more code to prove it's correct, then get users to try it), the bug squashing (customers or internal reporters), the beta period...
I wish I could be detailed about what I spent the last 3 days doing because honestly it's a perfect story of this kind of thing, however it's work so I have to speak in generalities. But the end of it was something like 15 lines of code. A 1 line change to the codebase and a 14 or so line test. It took 5 people to figure out what needed to happen and why, and even which component it lived in: the person talking to the customer, my manager who coordinated all the pieces, and me plus two other developers all of who owned different parts of the codebase to figure out which piece it was in.
Now imagine this but it's "we are going to touch every line of the codebase and change how we do everything going forward". And we haven't even talked about e.g. how it takes up to a month to roll an app update out to the appstores. It is very, very hard not to fail at this--the common failure mode is we're 6 months late, we aimed for a hammer but ended up with a stove that can hammer nails but also it catches fire and killed the cat. This is exaggerating, but much much less than it sounds like it is.
Like, I dunno. People just forget programming demands a high salary for a reason I guess. Looking in from the outside, I get it. The above sounds like a bureaucratic nightmare. But it's really not, that's the minimum of process if you want to maintain sanity and have stable software. Synthizer is the length of a novel, if printed. Work's codebase would easily fill a whole bookcase. Windows, printed, would probably fill your entire house. You can argue that we're overpaid, which would be fair except that I would argue everyone else is underpaid, and there's definitely societal things there, but honestly I would think about software more like building a bridge or something rather than the sort of popular science view of it, or the view you'd get from hanging out here. It's one of the few careers where going to college and/or having your 5-10 years of experience actually counts for a ton. You can't just plonk some juniors in front of accessibility work because you wanted it to be done cheaply. It in effect has to be your most senior people.
Things like Sequence Storm happen easily because if you're one dev you get rid of a lot of the bureaucracy, you're probably more skilled than the average if you're able to take on all aspects enough to get a game in the first place, and you're probably already doing it as a labor of love because it's very rare that single devs make any real money off their games. And yes, he probably did put in at least weeks worth of work to get us Sequence Storm.
But I'd be very careful before you attribute societal problems to why programming is expensive. I'd look at the programmer salary differently: we're not overpaid, we're paid in line with being someone who does a finite amount of work which provides our employer with near infinite value. It's more that for whatever reason programming has avoided the thing where someone like Mcdonalds goes "we are making thousands of times what we pay our employees. Let's see how low we can push those salaries". Mostly this is probably that it's very hard to manufacture programmers and we're just still an employee's market.
But also my dad was a high school teacher and the quality of life of the average programmer is what you could manage on high school teacher pay in the 1990s. Programming is a harder job than that--I have worked 48 hours straight a few times, and waking up at midnight because work's servers are down is totally a thing--and yet that's roughly where my calculations put the average salary. Sure, some of us make a lot more than that and go get our islands and whatever. I won't dispute that. But the cost of somehow getting the salaries to go down here is programmers get paid like shit like 99% of the other jobs that are out there, rather than a wage that allows for a high quality of life, which I guess is good if you want cheap accessibility and to feel good that there isn't someone over there making more, but in the end just means that you've knocked down another career path to the "why am I even bothering, I will never get all the things my parents have because the world sucks" level that almost everything else is at right now.
Don't get me wrong. It sucks that accessibility can't just happen like that, but at the same time it also really annoys me that there's this complete failure to understand what programming actually entails here, and yes it's making me rant a bit at this point. We aren't just wasting time. In terms of making processes as fast as humanly possible and avoiding overhead and whatnot--yeah. We've done that. There's nothing left to do there. The only thing left is to figure out how to drag the salaries down across the board. Otherwise someone does need to pay for it. Those are your options. There are no other levers left to pull on.
#67 (edited by Lucas1853 2021-04-17 04:50:21)
@64: Yeah, sure, But my mile-high view of AccessiB, having never actually dealt with it or read up on it, is that they want devs to be able to basically tell some AI stuff "make the website accessible" and it'll make the website accessible. If that can't be managed, which I think that even if they knew more about web accessibility it would still not be perfect, then it's a long way before we have a magic button that makes every game accessible. That's my point.
So, basically it depends on the game, envirrommend and few other things if it's easy or not to implement accessibility. Based on my experiences when working with developers on game accessibility it is totally bad idea to say stuff like everything is easy or everything requires hundrets of hours as it is not true. Mike Z implemented accessibility to the fighting game in two days and after that We're just balancing / updating stuff (mostly cleaning). Very oftne adding a screen reader isn't that big deal but again, it depends on few things. The problem appears if the whole game mechanics must be rewritten to be accessible and in my opinions these simulators could be made accessible without that much of a time (I just know few people from polish indie studios who were or are working on these projects).
The problem with the developers is something different though and at the end We have general answers like: "This is too much for us" or "We never realise blind people could play video games and We will think about that in the future" etc etc. Accessibility is still an eye-opener and believe me or not, you can do literally everything or most things with the games even the completed ones. Starting from the going back to the projects and changing / adding something (like We did with Lab zero games in Skullgirls) or mod the game even, if it's not that open for modifications.
Every game and project needs to be consulted precisely as it is inpossible to judge everything by using just one term. This is what I learned when working with the developers.
Canlorn, I feel like you might have missed my point.
I'm not trying to point out that programmers are overpaid; in fact, I agree that far too many fields are currently underpaid, since that's the main MO of capitalism (pay workers as little as you can so as to maximize profits and keep them depending on you).
What I'm trying to say is that if we're being literal, the only thing which makes programmers (or anyone else) charge for their time is capitalism. If you had fifty million dollars but still wanted to work, you could very easily decide that you did not require payment for your time anymore. Likewise, if we were dealing with a form of government where everyone had their basic needs met, the requirement that all goods and services must cost the customer money would be virtually eliminated.
So given that we're stuck with capitalism, it's sort of a moot point. However, I raised it because I think there are a lot of people out there who don't understand that work itself, time itself, do not cost money. Basically, when someone asks for payment for goods or services or both, what they're saying is, "I spent this much time and this much material creating this for you, so I need a return for it or else eventually my time or materials will run out and I will starve". So this isn't me bitching about programmers charging too much money (some do, most don't). It's me saying that capitalism fucks over virtually everybody.
https://www.dropbox.com/s/z8ls3rc3f4mkb … n.txt?dl=1
@65: What game are you talking about here?
If you say you never lie, you're a liar.
As many times before, I didn't even want to touch this pile of flames with a long, barbed pole, however I think the fire died down enough for me to interveen without being scorched to ashes.
So, whoever still thinks what camlorn, ethin and some others said regarding accessibility is wrong or overexagerated, I don't think my post would open the dors more than those posts would, but maybe it'll open it a tad more untill maybe a bit of sunlight would shine through.
Before I delve deeper into this, please take this with the knowledge that it's the first time undertaking such a type of project, and given what I have to do, I DK if what I'm doing is good or not. However, through all of the following, the most important message here is, don't ever underestimate the work that needs to be put for accessibility, regardless what field we're talking about, since it goes from easy to hard very fast, games being kinda at the top of the ladder here.
So, a month or so ago, I was contacted by a forum member, which shall remain annonimous untill they say otherwise, to ask me if I can help make something accessible, a tracker he called it. Back then, I didn't really know what a tracker is, but as the leader of the UI design team at the company or whatever making the Deflemask software wanted to make it accessible, then fine, I agreed to help.
This is a really complicated endever, since we aren't talking about controls that are only slightly inaccessible, imagine more like the entire freeking app is inaccessible. The controls aren't made with qt and the dev forgot to enable screen reader support when he was building it either, it would have been simpler this way, at least basic accessibility could be done and then tackle the other inaccessible things that remain. Nope, the problem is much, much worse, the UI is completely drawn, no native controls at all, just images with events when the mouse clicks on them, a good first step towards accessibility, huh?
I said I was going to do my best, so I explained the man what he should do to make it accessible, with some psudocode examples of the structures and whatnot. Now that I'm talking about it, I'll also explain how I thought about going with this.
So, as he said he wants to integrate with other screen readers, I recommended tolk, at least for windows, since I DK other sr libs that can be used from c++, that's what the tracker is made in btw. I then went explaining that through libs like tolk, the programmer can't just pass some structure or whatever to describe a control and it would suddanly be made accessible, in stead tolk only accepts strings of text to be spoken as you all know already.
Then, I told him how we have to inplement uia or jab or whatever by hand in this case, how we should define a tree structure representing a virtual, in-memory representation of the UI, along with some ties to the real gui elements on the screen and things, so that when a key is pressed, the accessibility service is notified and corelates info from that virtual representation, then builds the required text sending it then to tolk. When I told him this, I said it's like what the guys at kodi had to do to inplement ksr, and that wasn't an exageration. Surprisingly enough, he didn't bog at the prospect, neither did he backpaddle away as fast and as far as he could from the topic of accessibility, he just said OK, we'll try to do it. What do you think, ignorance, underestimation, or just a very strong desire for accessibility?
Anyways, actually the idea came from how android implements accessibility, as well as how it has support for making views made with opengl or similar accessible to talkback through their api's that, if used right, can extend the accessibility tree with descriptions for the controls drawn on the canvas too, so tb can read them as well. Well, we don't have this luxury in windows, linux, or mac OS land, so we have to roll our own.
So guys, maybe a game doesn't require such complex refactorings to be made accessible, but they have to worry about how to make some, if not all, puzzles accessible as well, since what's an accessible menu and interface if the gameplay isn't so? So, next time you think people are exagerating, think again to all those posts here who contradict you and then wander a bit why it's so, before making such intitled affirmations, for the good of the community at least.
If you're in C# you totally can do an Android equivalent in Windows. That's what UIA/IA2 is. In C# you just have to inherit from the main window and start implementing IAccessible. Microsoft has a ton of guides on doing UIA from C#. Not saying it's easy, but it's not harder than Android is in this regard. You can totally fake virtual controls and if it's C# you have reasonable support from Microsoft for doing it. Now if you're saying "on Android they'd use Java and we wouldn't be doing this" sure, but if they'd also rendered from scratch on Android it's the same level of effort and the same exact way of doing it.
Also Tolk etc. don't work for textboxes.
#73 (edited by bgt lover 2021-04-17 21:19:05)
Nope, it would be good if it was c#, I'd have some knowledge about it at least. However, the devs are using c++ because reasons, plus they use
for rendering the UI. Just saying, I DK how much I could be able to help with that, however I certainly won't give up trying, unless the dev does, that's it. Yeah, they use java for android development, as well as obj-c for iOS.
Btw, for anyone who is interested,
https://medium.com/google-developer-exp … b8d577be53
is a good example driven article on how to make such things accessible on droid.
Yeah, at the C++ level it's kind of not worth it in the sense of getting it done quickly. You still can but it requires a whole thing about responding to WM_GETOBJECT (which you may or may not have enough access to do, though there is a way around that I believe) and implementing COM interfaces. It ends up being the same idea as C# or Java but there's a lot more boilerplate and some manual refcounting hoops. Not cross platform obviously but I don't think the C# way is either, so meh.
You can look at Osara for examples of this. Not full-fledged ones but some.
camlorn: Thanks for the amazing explanation in post 57. Big thumbs up for being really good at explaining things. I think you would be good at writing tutorials.