2014-07-10 16:59:40

Hello audio gamers!
I've been browsing the forum for similar questions to mine; but they seem to be half answered. Most likely because it’s not exactly my question. But hear goes, hopefully it’s in enough detail:
I have been programming for a few years (started out with html as a lot of people do). I was really interested, so I looked into advancing my skills. Since I have completed many projects which includes SndUp (currently being rewritten), my radio station Grenade Radio (the website was written from scratch, and the automation software is also a powerful scripted streaming tool). I have also written a few smaller scripts to help with my day-to-day computer use and helped others out in programming also. I have used languages such as AutoIt, bash, php, small amount of python, played with bgt, also working on a project in lambda moo and a few other languages. I would now like to advance my skills into actual audio games (not just text).
So here is my question(s).
What kind of games are people looking for?
Also, What programming language best fits creating audio games, with 3d sound.
I was recently using bgt to see if I could create a sort of map you could walk around and turn around (360dg) in. However, I struggled when it got to changing sounds depending on where the player is facing as the bgt gaming engine was not able to use 3d sound. I could turn and have the sound quiet and lower in pitch depending if you were facing away or towards the object on the map, but this could also be confused with weather you are behind or in front of the object.
If anyone has got any tips, please let me know.
Thanks,
Josh.

2014-07-10 22:30:49

What kind of games are people looking for?

All of them. Short of space invaders and casino games, there isn't really a single genre that Audio Games couldn't use more of. And, heck, if you've got an epic space invaders/casino concept that blows the vanilla stuff we've had for aeons out of the water, go ahead and give it a try.
But mainstream-style RPGs, action/adventure, sports, 2d 3d or otherwise, fantasy/sci fi/realistic, whatever; it'd still go over well if it's designed well enough.


Also, What programming language best fits creating audio games, with 3d sound.

3D sound has been pretty hard to reach for years, now (blame the XBox for convincing Microsoft to drop support for hardware acceleration in favor of consoles with surround sound setups). Camlorn is working on bringing us back up to the futuristic standards of 1999, but in the mean time, 3D sound is a function of how much effort you're willing to put in to making something like OpenAL or fmod do what you want (and Camlorn found some flaws in OpenAL that encouraged him to just build his own from scratch).

I was recently using bgt to see if I could create a sort of map you could walk around and turn around (360dg) in. However, I struggled when it got to changing sounds depending on where the player is facing as the bgt gaming engine was not able to use 3d sound. I could turn and have the sound quiet and lower in pitch depending if you were facing away or towards the object on the map, but this could also be confused with weather you are behind or in front of the object.

3D sound is one of the most commonly requested features for BGT, but it's nontrivial to implement. THe sound_pool class uses a slight pitch decrease to indicate behind-ness (you can adjust the magnitude of the decrease), but it's not quite the real thing. I made a modified sound pool that supports rotating the listener, and makes an attempt at vertical sound but it's nothing resembling impressive.

I usually make the behind pitch decrease a little on the bigger side (like 5% or so) just so it's easier to distinguish, but that's not the best solution by a long shot.

看過來!
"If you want utopia but reality gives you Lovecraft, you don't give up, you carve your utopia out of the corpses of dead gods."
MaxAngor wrote:
    George... Don't do that.

2014-07-10 23:06:57

yeah. OpenAL is very, very, very bad.  Very.  It looks really great at first, but it's a fight between specs being the documentation and programmers not implementing them, everyone having abandoned it like 5 years ago except one guy who insists that his programming library must act exactly like a fake sound card, and it missing the infrastructure to build advanced features.
What it basically boils down to is this: you can get cool 3D audio but only if using OpenALSoft and if the user fiddles with some magic Inis (in all honesty, there's my fork that allows you to force options, but it's what's called a quick hack really), there are ridiculous limits that stopped really being an issue around 2000, and you have to write higher level stuff yourself, for example audio decoding, file caching, and the like.  It will work for simple games, but as soon as you want to do something a little complex it fails hard.  In my case, it was accurately playing footsteps and having the sound change properly with the terrain.  O, and that INI?  If you edit it wrong you'll just break things, and no you can't distribute it with your app-there's one system-wide file and that's it.
So I'm writing my own, as I finally managed to learn DSP to the point of being able to do so.  I can't call it useable yet, and I must confess that it will be commercial for closed-source projects.  Outside of my work, though, there's nothing I can find.  If you care only about mac and don't mind Objective-c, you can use Core Audio which looks really nice, but this is probably not the case.  As for BGT, it probably won't happen--I am hearing that BGT does not have the ability to be called from C Dlls, which means that writing a complete binding for anything that uses a callback function is impossible (and you really, really want callback functions).  This includes mine.  There's also some recent work by Microsoft to make personalized HRTFs using a Kinect, but this isn't available yet (and who knows when/if it ever will be).  Creative has not officially stopped caring, but they've taken down most of their web sites related to it.  Unfortunately, while they did still care, they took out everyone else working on 3D audio via patent trolling of some sort or other.  I could rant further, but it would probably not be useful as the rest of it has to do with the atomicity of OpenAL error checking and the absurd need for a thread for everything (also, I've written it elsewhere).
As for programming language, I am personally fond of Python.  I would stay away from C++ as debuggability is a killer and productivity will be low.  BGT will get you going quickly, but getting beyond the BGT ecosystem (which is basically a spec of dust compared to what you get if you invest a bit of time to get set up with something in another language) is clearly not something doable from inside BGT.  I'd stay away from the JVM, not because it can't be done but because you're going to end up then requiring anyone who doesn't have the right version to download a 200 MB package and install it.  Other languages that might be good include C# (everyone has the .net framework these days) and I really can't think of anything else at the moment.
Since you're not able to get 3D audio yet, picking something you know that's capable of playing sound and getting keystrokes is a viable option.  And whatever you do, never underestimate game programming tutorials aimed at the sighted-you don't care about the graphics, but all the rest--those parts about how you should react instead of act, including all the code on setting that up, proper control handling, collision, how best to do time--apply to you too.  I think that underestimating such tutorials is why we don't have a new game from someone every week: if you adopt the practices that sighted game programmers figured out for you and also adopt the everything is a library mentality, you end up with a bunch of pieces you can just reuse again and again.  All we need is for someone to open source enough of them.
hope this was helpful, though I can't notice that really it's primarily depressing on the audio front anyway.

My Blog
Twitter: @ajhicks1992

2014-07-11 01:35:18

Here's my 2 cents:
I've used both DirectSound and OpenAL for 3D sound, both are free.
OpenAL is nice because it is cross platform.
People say that DirectSound has problems properly representing 3D audio in Windows Vista and above, plus it only works on Windows.
Then there's a number of paid 3D audio libraries like FMod, Bass, Irrklang, WYSE, etc.
Some of those are free if your game will be free.
They also offer audio decoding which OpenAL does not.

If I were advising my earlier self I'd say go with OpenAL, and more specifically the OpenALSoft implementation of OpenAL since it ensures everyone supports the same set of features.
That's probably good advice for people with little money and lots of time and technical skill.
If you've got money to spend or are willing to keep your games free you should consider one of the paid solutions as they'll probably make life easier and save you some time.
OpenALSoft is written in C so you can access it's functions from almost any language, but the API looks a bit odd at first.

These 3D libraries support placing objects in 3D space and having their pitch, volume, and stereo adjusted based on the listener's relative position.
Then most of them support either EAX or EFX environmental reverb options, for doing things like echo-ey caverns, etc.
They also support low pass filtering for simulating hearing things around obstructions or through walls, though detecting obstructions and choosing how much low pass filter to apply is left up to the programmer.
Then some support HRTF.

I personally use C#, but everyone has their own preferences when it comes to programming languages.

Back to OpenALSoft.  Camlorn's point about needing to do the audio decoding and file caching yourself is true, and a pain.
I've also had trouble getting it's HRTF to work on other people's machines, though it works fine on mine.
I haven't had the problems he outlined in his blog, probably because I stay single threaded.
Well technically OpenALSoft runs on it's own thread, but that is internal to the library.
If this is your first game I recommend staying single threaded, it makes life so much easier and still gets the job done.

Then as CAE Jones mentioned there are ways to hack in the volume, pitch, and stereo adjustments into BGT.
Depending on how much time you want to spend that might be a good option.

Just my 2 cents of course.

~ Ian Reed
Visit BlindGamers.com to rate blind accessible games and see how others have rated them.
Try my free JGT addon, the easy way to play Japanese games in English.
Or try the free games I've created.

2014-07-11 02:33:44

Warning.  Incoming rant of anger, with extra helpings of anger and rantiness. 
If you delve down into OpenALSoft, that is you write no intermediate abstraction, it's fine.  Not great, not at all, but fine.  The specific issue I had with threading was that, in order to implement streaming without requiring some sort of library tick function, you have to use a thread.  This thread can error but OpenAL can't deal with thread local error info at all, so you don't know which thread caused it.  Unfortunately, there are a few resource limits that you can exceed, and the only way to know is to capture and read the error codes.  There are thread local contexts which sort of solve the problem, but this then involves somehow making sound objects that live completely on another thread and all sorts of insanity to actually make it look like it's not; and if you want to play long pieces of music and the like, grab from the web, or any such thing, this functionality is not optional.  Going further, getting a simple this-sound-is-done callback is impossible without threads.  So yes-as I said, works in simple cases.  To clarify it also works if your software deals with it directly.  But it's almost impossible to abstract into something usable and simple.  I should know: I spent a year trying.  I could have written a game with it, but I didn't want a game, I wanted a reusable and simple sound library.  I'm not going to reimplement sound for every game I write.  OpenAL cannot be bent into this shape reasonably.  Possibly not at all.
It's also not true that it ensures everyone has the same features as the enterprising user can edit that Ini, suddenly doing things like setting the source limit to 32, turning off Efx, etc...and I don't suggest OpenALSoft because it's not long until people get the particularly bad idea to copy their game's custom Ini over yours, and then it's "game x is not compatible with game y because game x is broken and takes OpenALSoft with it".  At least one thing that some will wish to change is the source limit: stopped and paused sources take no CPU, it's easy to use the one source is one sound mentality and there's no downside, to doing so.  Yet the only way to raise it is the system-wide ini.  Hope your users are feeling charitable, and also technologically capable.  I'd really strongly suggest staying away from OpenAL unless you're a good enough programmer to figure out how to put the pieces together and also a good enough programmer to figure out how to write a sound scheduler, as most action games and most rpgs are going to want more than 256 (I believe this is the default) loaded sounds.
As for HRTF, that's the INI trouble.  The only way to get OpenALSoft to play HRTF is if the system playing the audio is configured at 44.1 khz or all of the following are true: you provide a hrtf dataset for all sampling rates, instruct users to edit the Ini file to point at the HRTF database, and provide the support required for those users who do not know how to do so.  The default ini is configured to turn hrtf off, so you need to edit it for that too.
And god help you if you're dynamically linking via the Creative proxy: it's now hard to get, isn't developed, and also means that some users will no doubt have an outdated OpenALSoft.  And yet OpenAL Soft is it as far as hrtf goes.  I really want 3D audio, but OpenAL Soft is not worth my time.
If you know of one of the commercial tools that has hrtf and is blind accessible, let me know.  So far as I know, only Wwyse may have it, and not until recently.  Most if not all of them now rely on heavily graphical studios--i.e. great for sighted artists, not great for blind people.   Clearly, the state of all of this has made me extremely bitter.
DirectX will play sound, but post-xp you get no 3D from it and might as well just use BGT.  If you're not in BGT, there's Bass which abstracts it nicely and works somewhat on other platforms.  Python has Pygame.  But all of these have two things in common: no good hrtf and no good environmental reverb. If you want to talk about post-xp audio from Microsoft, you're looking at Xaudio2: the direct sound stuff is now emulated.
So basically hrtf but you get to implement all the things you need to actually have an audio engine instead of what is, essentially, a convolver-or no hrtf but you'll get somewhere tomorrow instead of in 6 months.  Your choice.  My personal opinion is that if you need to ask the question "where do I start coding games?" you're not ready for all the crap OpenAL thinks you should have to deal with.  Maybe I' wrong.  I'd go so far as to say that OpenAL is the worst API I've ever seen, save perhaps for how IA2 and MSAA work and why they're hard to implement if you're using a Gui library (that's yet another rant of mine but is off topic for this one so...).  The problem is that OpenAL is deceptively friendly at first, or I'd have started Libaudioverse a year ago and might actually be somewhere by now (or not, as some of the other shortcomings of OpenAL--there are indeed more--taught me what Libaudioverse needs to look like).
And I'm done ranting.  I will refrain from ranting on this thread anymore.

My Blog
Twitter: @ajhicks1992

2014-07-11 07:20:18

It would be interesting to have this in another thread! Sound libraries is kind of a near and dear thing to most audio game developers for some strange reason and I always thought that if I could manage to learn C++, OpenAl would give me something that was much much better than the left and right speaker control I get with pygame...
But that is totally a different topic!
I would say that python is probably where you want to go. It is super easy to build single thread text based games in python (You can probably build a pretty good one after a couple hours of learning the language), and multi-threading is super easy as well. In fact, depending on how complex you would like your multi-threading to be, it is only 5 lines of code at most and most of that is opening and closing the threads...
I would say to look at pygame once you are very very very comfortable using classes and dicts.


What do people want?
An RPG would be nice, but I wouldn't touch one of those till  you have created several other games first!

2014-07-11 10:05:28 (edited by joshms123 2014-07-11 10:15:12)

Hello,
Thanks for all the replies. Just a quick note, I do know python and other languages; it’s the audio gaming part I’m now looking into. I know that Road to rage has been able to do a sort of 3d affect (not completely), but is able to put sound behind the player as well as in front (at least I think so). I am probably going to develop the games in python, so if anyone has any suggestions for a good sound engine for that, then please let me know. The reason I want to use python instead of say, pure basic is because I know there is a good screen reader lib, plus many more. Also having used the language before is a plus.
Also, my other question didn't have many responses. I'm looking for different views.
What sorts of audio games would interest you all? I am currently working on a small(ish) game, so that shouldn’t take long to complete; keep an eye out on the new releases category. I do plan on doing more sports genre games. But if anyone else has better ideas, let me know.
Thanks,
Josh.

2014-07-11 20:42:16

I can post the ten lines needed to apply a lowpass filter to a sound, which is a cheep and efficient way to make things sound at least a bit different when they're behind you.  Unfortunately, this is C++ and won't help unless you have a way to write custom DSP callbacks-you have to get the filter in the pipeline.  Recording an in-front and behind sound is also feasible; you can apply the filters with audacity and encode as ogg, which is small and avoids the legal issues of MP3, so having lots of sounds won't kill you.  I've not played Road to Rage, but doubt it implements a full HRTF.  Lowpass filters are simple enough, however, and provided by most libraries.  If someone wants to go down the road of how to design and implement simple filters, we can talk offline-I've got some things that might help-but be warned, for here there be post-calculus mathematics (that said, using a lowpass filter someone else designed is just cut-and-paste).
Pygame is where it's at for simple and quick audio in Python.  I wrote Audiogame_engine, which provides a simple SDL window, keyboard, and mouse handling interface, including handling tick timing and allowing control and menu overlays.  This still requires audio, unfortunately, so falling back to Pygame is probably what most are doing.  Camlorn_audio crashes a lot in Python, mostly due to error propagation issues and people never actually being able to provide test cases that would crash it reliably; nevertheless, Audiogame_engine works well and allows a lot of stuff.  Disclaimer: I've not tried to combine it with Pygame, and Pygame probably offers something similar in functionality if you look hard enough.
As for being on topic with the what kind of games, CAE really hit it on the head: we've got simple side-scrollers out our ears, space invaders out our ears, and card games galore.  More things like BK3, but in English, could be cool: if you haven't played it, BK3 manages to transcend the side-scrollers are one-dimensional lines, providing an experience at least close to what sighted side-scrollers are like.  I personally want something similar to Zelda or the newer Metroids, but that's hard to do well (the older Metroids are also fun and doing something similar in audio is probably quite doable-they're only side-scrollers, and BK3 managed to overturn a lot of my assumptions about such).  But seriously, basically anything goes-a better question is what kind of game do you want, because you'll probably have players no matter what it is and you're the one who has to be motivated to finish it.

My Blog
Twitter: @ajhicks1992

2014-07-11 21:51:45

If you think you are up to it, anything with multiplayer support would be awesome!
I would recommend reading some game development books, they talk about how to create your game so it looks quality and professional. Frankly, that is what separates the good games from the not-so-good games.

2018-09-25 07:44:11

I happen to have a question. does anyone have information on how to use python with jaws? I can right out the code, and have a lot of notations on this subject, but how do I run my scripts. how do I add in audio. how do I make a map. things like that. if anyone could give me some information, I would appreciate it. thanks