Re: Just wanted to provide an update on Max-Lib
@9
High contrast, subtitles, etc etc etc. are solved problems and games already do them. keyboard navigation is a solved problem because any game that wants to support a gamepad needs it. Anyone who wants to make a little in-game screen reader can with little to no effort by just making things speak when they get focus, and we can't make a multi-framework option because 99% of the time the UI is private to the game anyway. The rest of accessibility is specific to the gameplay. But in general, everything but blindness is already solved and you can just get Unity plugins for it if it's not built in by default.
We would have better games if we had better tools. People here don't even know trig. People keep explaining things like how to update the game with a delta every tick. If I (as a new programmer, not as myself) sit down and want to make Shades of Doom I have to start with math that I only learn as a high school senior at best, and often not at all because I'm blind. What tools exist can't be debugged, are inaccessible, etc etc etc. While on the one hand you're right that there's an attention span problem, it takes an order of magnitude more effort than it should to even get to the point of "My character can walk around and I can save the game". "My character can walk around and I can save the game" could and should be 30 to 50 lines of code and no math learning. The real problem with attention spans is that this takes an ecosystem and only a few of us here know how to even start building one, and it takes a manual and tutorials, which have to be written by someone who has a full understanding of the concepts involved, and if you try to do it from the ground up you're going to spend months until there's something worth showing.
@12
If you read my post again, I sort of carved you out as your own category. I don't think you'll succeed, but you've picked a reasonable avenue of attack on an actually open source engine that we have enough control over and have said reasonable things about the scope of what you want to do with it. You're basically the only person who has talked about this from the perspective of being able to propose something that's at least this side of possible, and also from the perspective of having some understanding of the coding effort. Almost without exception, every other time someone has started this discussion ends at "and then big corporations have to care and give us access to Unity" or similar (and that includes this thread, honestly).
I still think you fail in the end, either because it's such a long project that something pulls you and/or anyone else with the skills to do it off, or because it turns out that really most sighted people don't care even if the pieces exist. I think in the end probably a mix of both. But you're not proposing something infeasible, there's a difference between infeasible and multi-year personal software project, and it's not like your chances are concretely worse than the 90% or so of other multi-year personal software projects that have failed.
You've been around less long than me. The thing is that there have been so many iterations of this discussion over the years that I can't count them. It's recently become more popular, but "what if all the sighted games were accessible" is the audiogame equivalent of the "what if I go become a firefighter, blind people can totally do anything" attitude. I think you'd be more impactful if you wrote an engine for audiogames, by my measure of "do we have good games". But you have a different metric of productivity than me here, which is fine, it's not morals. And also it's not that I think it shouldn't be done either. I may not jump on the bandwagon, but if someone lays out a possible strategy and has sound technical/social reasons as to why it might be possible, go for it, I'm not going to shoot it down.
But the problem is, you're the only one who has. Everyone else in this category just sort of spins their wheels on it, flails around, and thinks they're making progress, or pines for it and doesn't do anything realistic instead.
@13
I don't even know where to start on this. Reinventing all of UI, then hoping that everyone is going to jump on how you reinvented all of UI, and somehow this is going to solve accessibility and make an endlessly customizable game engine where everyone can swap the components for their accessibility needs? And also game engines are going to make accessibility laws to shut each other down? No, that's not going to happen. Also, frankly, Discord probably cares about accessibility for the educational market, not because games have to be accessible. Things like the CVAA hit games because the requirements just happened to include them, anyway, not because the goal was make games accessible--your XBox is covered because your XBox also does things like let you watch TV, not because it's to do with games.
If big game companies want to shut smaller game companies down, they don't need accessibility to do it. Going through congress to get laws that you can wield over others by sacrificing accessibility on the altar of tyranny is a long way to the same end. You can just patent something actually important and use that, it'll cost $1000 approximately and take around a year at most. But unlike many other industries, mostly game companies don't want to do that because you usually finish a game and buy another one, and also Unity, the big console makers, etc. want more game companies, not less.
And cross-platform is trivial enough, you use C# or C++ or something and call it a day. If you need a message interchange format you use protobuf or cap'n proto and call it a day, or corba, or dcom, or...
It's probably not worth my time, but you're proving to me and probably also to everyone else here that you don't understand the social side of this. Also, you probably don't understand the technical side of this either. What are you going to do, for example, when someone wants to get a combo system going for mobility-impaired players? Are you just going to let anyone who wants turn on all the accessibility, and get to the top of the scoreboard because the thing that lets a mobility-impaired player do combos just made it trivially easy for someone who's not to do it right every time? Not to mentioned that navigation for blind players requires bespoke solutions.
There are a lot of blind people who try to play sighted games, yes, but that doesn't invalidate my point or really even matter to my arguments. I'm not saying it wouldn't be valueless to have sighted gaming accessibility of some sort, I'm saying that what you're proposing is infeasible, that you don't understand the social side of it, and that it's not going to happen at scale because it costs them more money than they make to do it.
But also trying to claim that me saying audiogame unity means that we should go make unity accessible when I clearly mean that we should make an alternative, in a post where the entire rest of the argument is about how we couldn't make Unity accessible if we wanted to, is very disingenuous. And you're not actually refuting my points with anything, you're just responding with more aspirational stuff that's the kind of thing a tech CEO would try to say if they're trying to get investors. You're on a forum for programmers, talking like a tech CEO trying to get investors isn't going to really tell any of us anything we care about. But then I'm pretty sure that once you share the details, any of us who understand the problem more fully than you are going to have a hell of a lot to criticize, so it's probably working to your advantage not to, I guess.
And I do have to agree with @11, a lot of what you're trying to get out of this already exists anyway, and I am not so convinced you understand audiogames either. At the end of the day at least 75% of this, probably more like 90%, exists and people are just choosing not to do it.
But hey, it's your time to waste.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
