Re: Just wanted to provide an update on Max-Lib
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.
Have you actually built a game before or are you just saying this stuff? A lot of people forget just because its not part of the dev cycle. There is a real material element to bringing a game to production and a lot of that is what leads to basic "simple" accessibility fixes being lost in the wayside. This is again another reason why you can't rely on developers distributing UIs.
Like look, just because ian hamilton gets paid to guilt trip developers into remembering this shit doesn't mean it actually works as an effective means of accessibility.
Can you explain in a basic way for those of us who don't get this what exactly it's going to do? From my understanding, a dev can take your tool and make their up coming game accessible, is that right? But if that's so, why use your tool when they could build there own speaking menus etc?
I think an analogy for people with no real technical understanding would be like this. Take me (sighted) and you (blind). The game is outside, where there are physically things that are happening that we interpret, I have a sighted interpretation and you have a blind interpretation. Outside is still consistent but we're organizing that stuff differently because your eyes dont work and mine do. We both have unique subjective ways of understanding the same world, and because of this, we interact with it in unique ways too.
In a game, you have environments or UIs that have information literally in memory chilling out. What Max does is it makes it really easy to rearrange how that information is accessed, via a UI, and also changes how you interact with it - a lot of people think that a UI is just how you navigate/interpret these environments but it's also how you physically interface back to the game itself. So then you develop this back and forth response similar to the back and forth response you have when using your senses to navigate the real world. And just like how I'm sighted and you're blind, two different UI modules will cause a game to react differently because it's reading the movements slightly differently.
Building anything in a game can take a lot of time; which is part of the reason why accessibility is neglected in the first place. Expecting devs to take care of this is inefficient, and as I stated previously there are a lot of problems with a privately owned boxed solution like an accessible Unity/UE4.
Actually now I think on it, why would a blind dev want to use your tool? Surely if they were making an audiogame they'd already have the skillset to make that game and wouldn't need your app? I'm quite confused.
This is actually a really good question that I think I should talk about more.
First, most of the same reasons that a sighted dev would want to use Max (open source core, moddability, multiple language implementations, cross compatibility). But also, because Max is designed to be agnostic with how it manages its resources, audio game developers can build a game that sighted people can later mod and add graphics to or change the topology to, making audio games more accessible to the general public; while still containing the core original UI. It also allows both audio game devs and sighted devs to focus more on producing a preferred UI because it can simply be changed out for a different one.
Also, Max enables accessibility for other disabilities as well. If you were to make a game with Max, you could feasibly make a blind-sighted-deaf pipeline without enforcing a UI.
the problem with your agnosticism comparison between operating systems and actual games/game engines is that an operating system provides critical services and functionality required for a game -- or any executable binary, for that matter, in some executable format like ELF or PE -- to be executed and to function properly. It does this through abstractions like system calls and other mechanisms to abstract away the underlying physical machine from the programs that actually run on it. A program does not need to be aware of, for example, how a pixel is drawn onto the screen because the GPU drivers handle that for the program, and abstract away the underlying complexities and mechanisms of how the GPU operates. All the driver has to do is expose a system call or two. The problem arises when you try to slip in max as the supposed "operating system" abstraction layer. You can't. That is the hard, cold truth. The only way your going to get this to work with mainstream game engines that may not even have plugin support is to write a kernel-mode driver that intercepts graphics calls. Max will not be what you think it will be. It cannot be an agnostic mechanism for any game engine to use because even if you were to make it agnostic, a game engine will still have to implement its facilities. You can't just drop Max into (say) MK 11 and expect it to work out of the box; MK 11 has to be able to support Max, to detect it even exists, and to utilize it. That is why Camlorn said that this was such an infeasible goal. The comparison between OS and Max being some kind of plugin just doesn't hold -- an OS is about a million times more complex, and far lower level, than Max is. And making it agnostic through a kernel-mode driver will be a very, very non-trivial task, because every kernel-mode environment is different on every operating system.
We are literally doing this tho lol. What makes you think we're just messing around? The C# layer is a layer to allow C# devs to interact with the lower bits. The whole reason why I refactored this project was because I got access to an extremely talented C developer who is absolutely willing to take on these tasks while I develop the front ends. We are writing Max in a way where we could slap it on any machine, IDK if I would say its as low level as an OS cuz I don't think you could just slap this on a machine and have it boot but its directly interacting with the IO.
I understand that you can't drop Max into a currently existing game, it needs to implement Max - the goal is moving forward to try to integrate Max into as many systems as possible as an environment that can link to other engines and pass its components through to it.
Also, even if we couldn't get this working in literally anything (and thats bullshit cuz I know I could at least get this working in game maker based on our designs) I'm still building a dev tool for RPGs and any game produced with this engine would be automatically blind accessible.
I'm perfectly willing to waste my life trying to figure out a solution to this; we're making good progress thus far and I really think the theoretical model holds water. Listen, I'm a bigger fucking loser than any of you lot so if anyone's going to figure this shit out its going to be me and my bud.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
