2019-01-15 12:39:53

Hello.
I don't know whether this will help or not, but I published the following:
https://feedback.unity3d.com/suggestion … y-impaired

2019-01-15 17:23:44

We tried that a few years ago, it never happened. I doubt this will either.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.
My Github

2019-01-16 02:46:37

I was able to make the error log and compilation status speak, but those inaccessible dialogs are ... you know.

I don't speak as good as I write, and I don't listen as good as I speak.

2019-01-16 04:24:23

Unfortunately, the unity project doesn't give a fuck about blind gamedevs. After all, why should they when they only care about the money? Companies like Unity Technologies and Epic Games wouldn't even consider adding accessibility to their engine, not when they can add a snazzy new graphics package or whatever for far less cha-ching. Sorry if I sound harsh as hell, I'm just sick of mainstream devs not giving a fuck, even when it would be absolutely worth it, in the long run, to make things accessible.

#FreeTheCheese
"The most deadly poison of our times is indifference. And this happens, although the praise of God should know no limits. Let us strive, therefore, to praise Him to the greatest extent of our powers." - St. Maximilian Kolbe

2019-01-16 05:27:49 (edited by Ethin 2019-01-16 05:28:59)

The difference though is that Epic Games' unreal engine is actually, uh, open source. Unity's isn't. So it might be possible sometime to add accessibility (for windows at least) to the editor at least. Either way... the big question is, is the audio games community actually ready to develop games using mainstream tools? Its not as easy as writing all your code in a few files, you know. You have assets, textures, blends, and so much more that the audio game development lifecycle just can never prepare you for.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.
My Github

2019-01-18 22:00:06

We're long due for these kind of updates, though. I really need to get back to that whole Godot project. We need a proper engine around here. BGT has run its course, and besides, we need something that isn't just writing scripts. At the minimum, something for managing assets and mapping in a way that isn't just having to recreate a a game map system every time a new developer wants to work on something, or a developer is moving onto a different type of game.

I have a website now.
"C: God's Programming Language
C++: The object-oriented programming language of a pagan deity" -- The Red Book
"There, but for the grace of God go I"

2019-01-19 18:23:17

I contacted godot developers and they told me that Someone else already asked them for accessibility and since they had to change a bit lots of stuff they said it'll take a lot of time if we do it and never seemed to do it. They gave me the same answer so no hope from that point. Although godot is open source

---
Co-founder of Sonorous Arts.
Check out Sonorous Arts on github: https://github.com/sonorous-arts/
my Discord: kianoosh.shakeri2#2988

2019-01-19 19:22:28

Ugh, what a frustrating situation. I started trying to make Godot accessible. Began working on a pseudo screen reader in GDScript, but it needed more signals and richer information. Submitted a couple PRs to do that work, but they got caught up in what felt like bureaucratic process. No one knew what was needed, and when I told them I was happy to show them, they dragged their feet. At least, that's how I perceived it.

Anyhow, I gave up on, ahem, waiting for Godot. Currently evaluating Amethyst (Rust) which eventually wants to have both an editor and framework use case, and AFrame which is VR-centric but offers high-level primitives and the ability to create them in HTML.

Think I might try throwing together a simple top-down game example in AFrame, packaging it with Electron, and blogging about the process. If it fails, well, we've then discovered another way to fail. smile

AFrame is a little like a game engine in that you can build scenes in static HTML documents, complete with spatial audio, but then leverage JavaScript and the DOM APIs to add dynamic/programatic behavior. Remains to be seen whether packaging the result in an Electron app and making it work with screen readers is too much of an adoption barrier.

2019-01-19 19:46:58

Yeah, I've begun finding the programs necessary for building Godot. Just need to figure out what I will need to get things to work. Honestly, I believe the UI elements are well organized in the C++ code. The trouble with this is that if we implemented the accessibility directly from C++, we'd have to implement the stuff for the game itself separately. Ideally, rather than recreating a psudo-screen reader, we should try to interface with what already exists, it's just that, I am not entirely sure what would be the most efficient way to go about it. Then there's the matter of the editors and what not. Anyways, I'm going off on a tangent, now.

I have a website now.
"C: God's Programming Language
C++: The object-oriented programming language of a pagan deity" -- The Red Book
"There, but for the grace of God go I"

2019-01-19 19:57:59

I feel like we've probably encountered each other on one or more of the relevant GitHub issues. smile In any case, I still think that bridging Godot accessibility to the platform has some limitations. Namely, you'd have to do it everywhere unless you only care about Windows, which is a bit of a letdown for an engine that can export games for just about any modern platform. Making a pseudo screen reader not only gives you access to the editor, which itself is a Godot game that just creates other games, but also lets you work on any platform. You'd have both engine accessibility, and something like the Unity Accessibility Plugin that grants access to augmented Unity games.

But that train has sailed for me. Merging PRs felt more like a popularity contest than a process ran by some sort of reliable governance, and I just didn't have the time or patience to be annoying enough to get anything done. I'd love to see it happen though.

2019-01-19 23:22:21

That makes sense. Yeah, what I would like to get done with Godot has the unfortunate downside of taking several people to do, and by that token, we might as well take the underlying important engine stuff, and recreate the UI and related tools. I don't know. In any case, I would like to finally see an engine around here that isn't just pure script writing. Something that doesn't require re-inventing where ever possible. I guess if we got enough people together with enough knowledge to do so, we could all try creating our own engine. LOL!!!

I have a website now.
"C: God's Programming Language
C++: The object-oriented programming language of a pagan deity" -- The Red Book
"There, but for the grace of God go I"

2019-01-20 02:27:08

Btw, what are the reasons you want to use mainstream game engines? Mobile support? VR audio? Collaboration with sited game developers? Other?

I don't speak as good as I write, and I don't listen as good as I speak.

2019-01-20 03:14:33

Actually, interesting you should bring up collaboration with  sighted game developers @12. That is another reason why I've taken a major interest in the whole accessible game engines thing. Another major goal, in particular for my current line of study in university, is to start bringing blind developers into the "mainstream" fold for lack of a better term. I am mostly certain this can work, though the trouble of 3D graphics and the like still kind of stumps me.

I have a website now.
"C: God's Programming Language
C++: The object-oriented programming language of a pagan deity" -- The Red Book
"There, but for the grace of God go I"

2019-01-20 05:34:22 (edited by Ethin 2019-01-20 05:40:25)

I tried adding accessibility into Godot once... got rejected, if memory serves. They said they wanted it in GDScript... and I had integrated it natively (which was, to me, the logical thing to do at the time).
About the blind community integrating with mainstream developers: while its a very cool concept, and would be interesting to do, I don't think the blind community is even close to ready to develop with mainstream developers. The process is not what the community is used to, where you write all the code in a few files, and you have sounds; the process involves animations, assets, textures, surfaces, and a hell of a lot more that I can't think of. Take Unreal Engine, for example. If you want to make a basic FPS, and you want your player to be able to walk and wield weapons, you need an animation for the player walking, an an animation for the player walking and holding a gun, an animation for the gun itself, and that's without armor, and with only one weapon. Add in armor, and you then need an animation for the armor, an animation for the player walking without the armor, an animation for the player walking with the armor on, an animation with the player wielding the gun with the armor on, and so on. Its pretty much the same for many other titles.
As for things like menus, that's also very similar: you need an animation for each menu item as well as (possible) an animation for the menu background. The speed of being able to scroll down menus is controlled by how fast the game can render the frames and animations, not internal timers. But if your going to develop games that are mainstream, use Python, use a framework like SDL2, and begin with timers to cap the amount of events received so your not (for example) scrolling to the end of the menu with a single press of the down arrow. That doesn't account for joysticks, which are extremely touchy: if yo udon't moderate how fast the game can navigate a menu, or how fast the game processes events via either FPS caps or timers, and you don't set a dead zone (which you need to do, at all times), your joystick is going to be sending events to the game almost constantly. Just by picking up a joystick you are most likely going to cause one of the axes on the joystick to move. By even gently touching he left stick, you are generating a joystick axis motion event (or whatever your framework calls it). You need to make your game ignore motion movements below a particular value. That's your dead zone. For DirectX, the default dead zone may be sufficient (7849 for the left stick, 8689 for the right stick, and 30 for the trigger threshold). For SDL2 though, you'd need a dead zone that's at least 5000 (though it should probably be 10000-15000). But 'll stop now, I've gotten off-topic.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.
My Github

2019-01-20 06:16:14

For now, I'm concerned with making it possible. The nature of someone learning the requisite skills comes later. That sort of thing is difficult to learn if it's not even possible to do in the first place, after all. Actually, @Ethin, that repository you gave me, I can't recall, was that the GD-script attempt, or the native attempt?

I have a website now.
"C: God's Programming Language
C++: The object-oriented programming language of a pagan deity" -- The Red Book
"There, but for the grace of God go I"

2019-01-20 07:31:12

It was the native one.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.
My Github

2019-01-21 01:59:48

The main reason for my interest in mainstream engines is the ease with which some allow for prototyping. With Godot, for instance, you can easily combine a 2-D tilemap, 8-way controller, audio listener, sound nodes, and assemble an audio scene in a matter of minutes. Sure, you can eventually code all of these things, but often the best code is the code you don't have to write, and it's nice to build with higher-level primitives like these and focus on the game itself, not on picking the best data structure to represent large tilemaps, integrating physics for collision detection, mapping sounds to higher-level game objects, etc. And I'm a software developer by profession, so the thought of building audio game support into a project that will continue to exist even if the audio game developers lose interest is a nice one for me.