Re: Just wanted to provide an update on Max-Lib

@8 Generally agreed with you, though I think your categorizations here are a bit simplistic. I guess by your reckoning I'm in category #3, though I prefer to think that the way many of us are doing things here is a bit wrong. We have the blind gamers' pool, which we seem to keep separate from the sighted gamers' pool. I understand why this is in large part--it's significantly easier to build an audio-only game engine than it is to bolt accessibility onto Godot or Unity or whatever. On the other hand, we have a few sighted folks trying to build games for us. Maybe their prototypes or final products are terrible. Maybe they start out at 50% good, then over long and elaborate iterative feedback things get to 80% or 90%. I generally don't fault them for this since it's a very hard problem. But look at the navigation systems behind, say, Papa Sangre and A Hero's Call. The former is very simplistic[1] while the latter is much more intricate. I think it's fair to say that the former was designed mostly if not entirely by sighted developers, while the latter was mostly if not entirely created by blind developers. As an aside, in the department of Research I'll Likely Never See But Wish I Could(TM), I'd like to see how cohorts of early and late-blind players interact with and assess the difficulty of navigation systems like those in Papa Sangre/Somethin Else and A Hero's Call. I suspect late-blind players may in general have a harder time with the latter, but of course could be wrong.

My point is, if we want more compelling games, they need to be for-us-by-us. Falling Squirrel shouldn't have to lob a prototype over the fence every few months. They should be able to bring on a blind developer or two to hammer on the combat system such that, when it finally reaches playtesters, it's at 70%-80% rather than 40%-50%. Then maybe their next iteration gets them to 95% rather than 70%. But that couldn't happen even if they wanted it to, short of me or some other developer having very limited access to Unity, having to hack together scenes to test every single system rather than just loading up and dropping into one, etc.

And yes, before AudioQuake/the recent Doom mod get trotted out, I know about those. They don't reflect my intentions, which is why I think your category system is a bit simplistic. I think there's a huge realm of accessibility possibilities between, say, Shades of Doom being accessible at one end, and the recent Doom remake being inaccessible at the other. Audio-only game engines get us partway there, but the next step is some level of developer accessibility to more mainstream engines. We may not be able to create the next fast-reaction multiplayer FPS, but there's plenty of space in between to have blind and sighted players and developers playing in the same pool. Not every online multiplayer game requires fast reaction times or is competitive. Hell, not every game is online, multiplayer, or competitive. So what if some game has a slightly easier accessibility mode but otherwise compelling systems and rich access to those? If your goal as a developer is creating an environment where all players can have fun, rather than wracking up the most points, there are even *more* possibilities of games that could be both accessible and shared experiences.

Having said that, I do agree in general that the work described here is ambitious and not well-scoped.

1. While the movement system of Papa Sangre/Nightjar were simplistic, I think the mechanics had you contemplating and putting a larger amount of effort into every motion, which arguably is how good stealth works. One of my long-term game ideas is a more complex tactical roguelike with stealth, and I could see myself using a Papa Sangre-style motion system that simplified the controls and made sneaking something you *really* have to work at and think about. Up against a wall? Better turn veeeeeeeery slowly to keep the noise down, and only take a step forward when you're mostly through that turn as to not make more sound than necessary.

-- 
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
  • ... AudioGames . net Forum — Developers room : defender via Audiogames-reflector
  • ... AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector
  • ... AudioGames . net Forum — Developers room : daigonite via Audiogames-reflector
  • ... AudioGames . net Forum — Developers room : daigonite via Audiogames-reflector
  • ... AudioGames . net Forum — Developers room : daigonite via Audiogames-reflector
  • ... AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector
  • ... AudioGames . net Forum — Developers room : defender via Audiogames-reflector
  • ... AudioGames . net Forum — Developers room : defender via Audiogames-reflector
  • ... AudioGames . net Forum — Developers room : defender via Audiogames-reflector
  • ... AudioGames . net Forum — Developers room : brad via Audiogames-reflector
  • ... AudioGames . net Forum — Developers room : nolan via Audiogames-reflector
  • ... AudioGames . net Forum — Developers room : daigonite via Audiogames-reflector
  • ... AudioGames . net Forum — Developers room : daigonite via Audiogames-reflector
  • ... AudioGames . net Forum — Developers room : daigonite via Audiogames-reflector
  • ... AudioGames . net Forum — Developers room : brad via Audiogames-reflector
  • ... AudioGames . net Forum — Developers room : Ethin via Audiogames-reflector
  • ... AudioGames . net Forum — Developers room : Ethin via Audiogames-reflector
  • ... AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector
  • ... AudioGames . net Forum — Developers room : daigonite via Audiogames-reflector
  • ... AudioGames . net Forum — Developers room : daigonite via Audiogames-reflector
  • ... AudioGames . net Forum — Developers room : daigonite via Audiogames-reflector

Reply via email to