Music and sound in AGS

[Sslaxx]

Would being able to refer to the music/sound files by their AudioCache index number be at all a useful compromise there?

[Crimson Wizard]

Code: ags

   randomclips[0] = aSound1;
   randomclips[1] = aSound2;
   ...

IMO this is retarded. If one can manage it tidily, using numbers is much more elegant than referring everything via an object. It is fine to give people a choice to make their codes more descriptive(and more bloated) but giving up a good feature just to please the OO people is not a good move and more stupidly, the engine is already referencing the sound clips by numbers internally, just not directly accessible.

First of all, this is bloated because you have to do this in script "by hand". To think of this, every array in the game (characters, etc) is being constructed like that on startup, only internally. Here in this example I constructed my own "alternate" array of game items. Is there so much difference between getting a random item by number from "original" or "custom" array?
What if you won't have to write this in script, but manage items in project folders having editor/engine do the rest?

Then, addressing items by their array index may cause troubles because their positions may change in the future. You'll have to keep an eye on that every time you add/remove/change anything.
I totally agree that in current AGS it might be easier to do address things by using indexes in their main arrays (I myself did that many times), but IMO that's only because AGS script does not provide alternate appropriate ways to do this.

Also, I don't think this has anything to do with OOP... it is rather a question of Key type which is used to iterate/access data.

//---------------------------------------------------------------------------------------------------------------
EDIT:
I am sorry for not saying this first time I edited this post, but I think I should elaborate further.

You called using indexes ("numbers") an "elegant" solution. I have to disagree. That may be (or may seem) simple and fast to use, but I do not find it elegant.
Let's examine two options when you need to get some items from project data array.

Option 1 is when you need some certain item. Whether you access it by script name (cEgo) or by index (0) - it does not make much difference. In any case you must know its name (or "name" - an index).
Option 2 is when you need to get a group of items. It is here where method actually makes difference.

When you are getting a subset from a master set you are using certain rule of comparison. There's a reason why you are selecting these items and not the others. In you example you select them because they are appropriate candidates for a random sound.
Now, when you use numbers, you actually check the comparison rule by yourself. It is you and only you who knows which items should be used. In other words you do the extra work that could be done by the engine - if only you told it how to choose, which criteria to use. Not only this is an unsafe and error prone way, it is also a non-ultimate way, because, as I've already mentioned, you may change the number/indexes of your items later and also because you won't be able to reuse such code as-is.

What I want to say, there is always a criteria when certain items are being chosen from the set (aka collection). If AGS have means of defining these and getting items using these - that would be better solution.
What criterias might that be?
* All items from custom group.
* All items with custom property having certain value.
* All characters in the room.
* All room objects in the rectangle.
* ...

In your case that could be "all sound clips marked as 'use for random sound'" (or similar).

[Gilbert]

Would being able to refer to the music/sound files by their AudioCache index number be at all a useful compromise there?

Yes. As I mentioned the sound clips are already numbered internally. Being able to address the clips directly with these numbers would be the most appropriate.

First of all, this is bloated because you have to do this in script "by hand". To think of this, every array in the game (characters, etc) is being constructed like that on startup, only internally. Here in this example I constructed my own "alternate" array of game items. Is there so much difference between getting a random item by number from "original" or "custom" array?

This is very stupid. If as you mentioned, every array is already constructed that way internally, then there isn't much reason to waste time(and probably memory) in constructing more arrays manually when it is not necessary. You seem to think that the random sound example I mentioned is the only use of this feature but as I already pointed out, this is only a quick random example of how this can be used. In fact, there are numerous uses to this and you already mentioned earlier, that one use is to iterate through all the clips for some reasons, which cannot be done with the clumsy manual assignment way. Also, if it's done the way sprites are handled we don't even need to have an internal array. The point is to address the items by numbers. For sprites, while they're assigned automatically some numbers during import, you can change their numberings manually afterwards in the editor, so you can assign whatever "meaningful" numbers to them you like. (So sprites aren't really arranged in an array, as you can say have sprites #1,2,3,100,101,102 with #4-99 non-existing.)

What if you won't have to write this in script, but manage items in project folders having editor/engine do the rest?

This could be useful, but as I mentioned don't focus on just the random sound example. Sometimes I will need to have the clips arranged in a certain order for more complex stuff(such as using a formula in determining which item to use) so it is ideal to have numbers attached to them like the sprites.

Then, addressing items by their array index may cause troubles because their positions may change in the future. You'll have to keep an eye on that every time you add/remove/change anything.

If they are implemented like sprites as mentioned above this isn't a problem, as the numbering of existing items will not be renumbered by the editor every time you add/remove/change anything.

Option 1

No objection there.

Option 2

As I mentioned it is not limited to simple things like random sounds. If you think just being able to group items according to different criteria is enough this is your own preference. I actually abuse using the sprite numbers a lot, by say, choosing an appropriate sprite to display based on the result of a formula according to different parameters. Numbering the sprites appropriately can get the job done clean and straight and if you fear that people will not understand your own moonspeak, you can just put a few lines of comments to explain the numbering system. This is much more better than throwing in 100+ "descriptive" lines of assigning items to a custom array, which is prone to errors and is inconvenient.

[Crimson Wizard]

Ah, pardon me, I made a mistake by focusing on "get all matching things" and forgot about "get things ordered so that a formula could be used".
I think I am also having "universalization" issue and that makes me go too far sometimes.
Currently I am trying to find out what would be better way to solve this problem so that it's both easy to use if you need to do some simple things and if you need something complex.

The problem with game items is that their organization in project tree either hides their order (e.g. audio clips) and/or makes it impossible to change that order (practically anything else).
You mentioned how sprites are being ordered by assigning numeric ids to them. If other game items could have same changeable numeric ID that would indeed make the situation easier.

//------------
EDITED.
Here was some lengthy suggestion, but later I decided to remove it, because I started to feel I went into wrong direction again. Probably I need to think more on this.

[Crimson Wizard]

This might be too late to mention, but there's an option in General project settings: Enforce new-style audio scripting. When set to FALSE it enables older functions like PlaySound (which takes sound index as parameter). Probably it will allow to mix both styles in one game. Never tried that myself though. Not the best thing, but may work as a temporary solution.