Re: List of Ways to Make AudioGames
@9
What you want doesn't exist. Audiogames are almost exclusively made by new programmers, including the "engines". Those of us with experience won't use libraries as easy as you want it to be. Everything you'll find that's not Unity or Unity-like is going to be more complicated than you're hoping for, I think. Even Godot has a lot going on for small games.
Audiogames are simple in the sense that you can do space invaders or whatever on the weekend, but what everyone forgets is that games themselves are one of the harder varieties of programming, and often libraries don't work because your game is too specific. Consider as an example Factorio, a popular sighted game that's basically Wayfar but graphical and much, much bigger. They had to write their own physics from scratch because they needed it to be perfectly deterministic so they could get networking working. A lot of Unity is basically a giant plugin system that swaps pieces, but you still have to write a lot of your own code--being unique isn't compatible with grabbing lots of off-the-shelf things that plug into each other.
I'm not saying "the list isn't useful". I'm saying that on the one hand there's nothing to put on it, especially with your new criteria, and on the other hand the list can contain everything that exists if the criteria is "someone made an audiogame with it". I think that there's a misalignment between what you perceive the complexity of games to be, and what the complexity of games actually is. As a sighted programmer, it is easier to make a giant web site thing like Yelp that will scale to at least 1 million concurrent users than to make a small FPS.
So the answer is--yes. It is that hard. Not because people haven't tried, but because it actually is that hard. There is a reason that most audiogames are of low quality and buggy: you need a great deal of experience to pull it off well.
@10
I'm going to break the API again, too. The final answer w.r.t. Rust is going to be reference counting. Part of why I want to take it over is that I know what's there but also what's coming, and post 0.9 things are hopefully not going to break again before 1.0 either.
being as I plan to use Rust, figure I might as well be the one to break it.
@13
Yes, there's the JS engine by ShiftBacktick, but the problem with WebAudio is that it's buggy as hell and horribly inefficient in some contexts, and last I checked their engine didn't work on Firefox. I'm not so optimistic about JS as you because I actually tried it, and audio there was no end of headaches and "haha this doesn't work on this browser" and other stuff like that. Then you get to the screen reader bugs/differences and so on, the electron system requirements (it's heavier than Python by far), the asset packaging issues if you want to make a browser game that does anything nontrivial (because half your players have crappy internet and can't just download everything on page load). It's surprising that WebAudio isn't super stable and efficient. Libaudioverse is basically 75% of it and I'm one person; you'd think Google etc. would do a better job. But even if it were fixed, I'm not so convinced that the web is a super viable platform, and I'm saying that as someone who tried pretty hard. Maybe, if we could reasonably expect blind people to have good computers and good internet. Being able to assume that is why it's reasonable for the sighted, but also there's enough sighted people that if you say "haha, sorry 20% of the U.S. we're busy monetizing the other 80%" there's a pretty big 80% to monetize.
TLDR: system requirements and bugs ruin what could otherwise be a really nice thing.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
