Re: How to Handle Sounds in BGT
That's actually alot of stuff you ask here, hopefully I don't miss anything out.
I think part of my problem is that I don't know much about sounds to begin with, it makes sense to load all of my sounds before the game loads in a single object, but how do you access them? It has to be hard to keep track of which index is associated with which sound assuming we store them as an array. If a dictionary, what would you use as a key, because if you gave every sound a unique name, it would be very tedious to go through and load all the sounds by hand, it is much easier to give generic names, that are numbered, so you can load them using a loop, but I would imagine that it is hard to work with those sounds.
There are multiple questions in here. Some of those are basic programming questions which don't relate to sounds explicitely. How do you handle a collection of different data objects (might it be sounds, strings, whatever) and how do you address them properly, without wasting too much time?
That's totally up to the programmer. Imagine it like you want. Create a class which loads the sounds if you tell it which sound you want and stores it the way you like.
Try yourself if it's more efficient to go through an array with strings or some sort of whatever you like or searching a dictionary for the stuff you want. That depends actually on the amount of sounds your game will have.
An array might be the most efficient way until it reaches a certain size. If you notice that this size will only be reached as soon as you played several hours along it might be acceptable to use an array anyway. Dictionaries are comparably slow in comparison to arrays, but their processing time is really constant, which makes them a good solution if you know that you're using alot of sounds and that the array processing time will quickly exceed the dictionary processing time.
You know why I don't want to answer such questions with a detailed solution, because there might be another best fitting solution for your case here, and because there are so many solutions.
Just imagine two arrays, one containing the string of the sound name and one, the same size and the same indices, the handles to the sound objects. That way you could search array 1 for the sound string and return array 2 at the same index if the sounds could be found. If it's not found, you could just load that sound and add the sound to array 2 and the string to array 1 and you'll find it the next time you want to load it within your class so you don't need to load it again from hard drive.
That's one way i'm using in one of my projects (not even bgt, because those concepts apply to any other language too).
I load sounds always using a class implemented by me. This class gets a name. The class looks if it already knows the sound. If not, it loads it from hard drive and if yes, it returns that already loaded sound. If you then load all sounds one time on startup the game will know all sounds and the loading is done forever.
If you like and know that your game will be very large, because you included over one gb of sounds in your game, you can even garbage collect the sounds you don't need anymore.
Don't forget here that all sounds loaded will ly in the game's RAM until you unload the sounds manually or close the game. That's why the game's RAM usage might skyrocket if you decide to include several gigs of audio and load all of that on game start.
Back to topic: the index you use to find your sound is up to you. But why not simply use the sound's name? What's the problem here?
Of course you could also access the hard drive using directory level access functions and load all sounds you find automatically (no need to do that by hand) and there is so much more you could do if you want... the possibilities are endless.
So as I start creating my classes for the player and, monsters, and other game objects, I want to create a handle for the sound as a class level variable, so that I can use a constructor to point the handle at the given sound object, right? I do not want to load the sound in each object such as in the constructor?
Depends on your implementation. If you aren't storing the sounds somewhere in memory, then yes. It would be absolutely inefficient to load them all new again if an object is instanciated. But here again, that depends on your chosen implementation.
And I think this is where my inexperience about using sounds is going to really show, what do you mean about encrypting and decrypting sounds? Why do you need to deal with encryption at all when working with sounds?
Again not a question about sounds themselves.
The problem related to assets in general apply here, which many people here don't understand at all. Any assets found in games, programs and all that kind of stuff are licensed (except open source stuff). That means people payed for it, if not the user, but the developer. Sound libraries aren't free, at least not the most of them.
Music producers want to be paid too, by the developer. The developer then paid several hundreds, if not thousand dollars for his sound effects and music to use in his program. Of course he doesn't want any user who plays his game to enter his game folder, find the sounds he wants, copy that stuff and insert it into his own game, all for free, and then wants to be paid for his game too. All without paying a single dollar for that. Best example might be the quite popular Crazy Party game in the forums here. Most of the music found there was stolen from Pokémon games like Pokémon Rangers, Pokémon Black & White and so on. Not that the Crazy Party developers didn't pay for it in any way, the also get in conflict with the law. If GameFreak or some other developer who licensed the music they're actually using noticed that, they could get in real trouble, paying hundrets and thousands of dollars, no matter if their game is for free or paid. You're not allowed to use stuff you don't own. That's why developers encrypt the assets they're using as best as possible, making it almost impossible for users who just play the game to decrypt the sounds and use them for their own project. But encrypting this stuff also means that the game itself must be able to decrypt the assets on runtime and in RAM, because if you store them decrypted on hard drive somewhere, the user might again be able to copy the decrypted sounds and all work would be worth nothing.
That's why developers (Crazy Party too) encrypt their sounds.
Regarding your question to my last post, I just answered that above. If you hold the sounds in memory, you don't need to load them again from hard drive.
I only asked about the global variables because all of the game based tutorials I have seen, mostly python based, including BGT, seem to use and often encourage using global variables. So I started wondering if global variables are used more in game programming than else where? it kind of makes sense because if you have to access a central object where all of your sounds are stored, it seems like it would not be very efficient to pass that object through to every class and function that needs to access a sound. Also, for timers, and other game states, it also seems to make sense to set these as global. Is this what most people are doing, or is there another method of handling these game properties.
That's usually bad practice. But again, some stuff can be saved as global variable, but I'd prefer to use either static variables or singleton classes, meaning variables with exist in all objects of a class or classes which may only exist once per program. Those are basic programming concepts, if you don't know about those things, try googling it yourself (my response is rather long even without explaining that stuff).
That makes a lot of sense about the listener and source now. So just to be clear, if I wanted to give the player a sound when they are moving, I would set the listener and the source to the coordinates of the player's position?
That's absolutely it. If you move the listener, the source will stay absolute and therefore move more left or right from you, just as you move the listener. If you want to have this source always in the middle, unrelated to the listener, you usually can tell the sound to be non-relative (usually some sort of relative = false initialization or playback parameter), the sound will always stay in the middle.
Best Regards.
Hijacker
_______________________________________________ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
