Ok, I had this idea a while back--posted here about it, in fact--about a continually growing adventure game where expansions could be downloaded for it and run from the main game. Initially I'd intended to have the expansions each given their own subdirectory because each would need to have its own MUSIC.VOX. However, I also need the expansions to be able to return to the original game--I'd intended to do this via another RunAGSGame command that would call the original game.
Then I found out that there's no way to go "up a directory" with RunAGSGame. So, the only way for the game and the expansions to BOTH be able to run each other is to have them in the same directory.
Now I have my original problem--I need the games to have different music, and I'd rather not have the music as separate mp3 files. I want it to be compiled somehow so that it is only accessible through the game.
Bottom line: I want to make it so that one AGS program can start any of several others, and that the others can all start the original, and all of them have separate music which is only accessible through the game. Am I asking for the impossible, or is there a way to accomplish this?
You raise a number of issues that I will try to answer for you.
- Call/Return via RunAGSGame - I am writting a module to make this much easier. There is a version for AGS 2.70 in this version of DemoQuest. (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=23083.0%3Cbr%20/%3E). I have a new version of the module nearly ready for use with the current beta version of AGS 2.72. If you want to work with that one let me know and I'll let you know when it's finished.
- music.vox - This file is shared by all games called via RunAGSGame(). I believe that speech.vox and the save game files are also shared. This should probably be brought up in the technical forum to discuss how AGS might be changed to avoid this problem. Perhaps the file names could be made unique by appending or prepending the game name or by allowing RunAGSGame() to use path+filename as it's parameter.
- workarounds - Here are a couple of workaround you could try until AGS provides additional support for this.
1. Use all the music in all the games and then use a shared music.vox file. Actualy you wouldn't need to play() each music file in each game but you would need to have the same musicxx files in each game's Music directory.
2. Use midi music and everything will be in the exe or ags file.
3. Speech.vox - I don't know what you could do aboutthis one??
All the music is MP3s. I don't think I'm using speech.vox at all.
What exactly does your module do? Would it make it possible to use RunAGSGame for games in different directories? If I could do that, the rest of the problem would be solved, I think.
I think if you just drop individual MP3 files into teh game's folder the game will use them directly (not sure). So, you may say just put music#.mp3 into the game's folder, where # weren't used in the original music.vox and the game should play these files anyway. The disadvantage is of course, there can be lots of files scattered around in the game's folder, and everyone can play the files directly outside of the game.
Quote from: KingMick on Wed 19/04/2006 20:01:53I need the games to have different music, and I'd rather not have the music as separate mp3 files.
Yeah--like strazer indicated, though, that would sort of defeat my purpose. Actually, however, I realized upon further reflection that it's not the idea of people playing the mp3's separately that bugs me so much as it is the idea of people replacing the game's mp3's with different ones.
I thought about this further, however, and I think I've come up with a few ideas of my own on how to ensure that doesn't happen (or at least, to make it much more difficult).
The only issue that remains is, of course, compression--but actually if I recall correctly, music.vox doesn't compress the files very much anyway. I could be remembering wrong. :shrug:
If you don't mind having music in separate files then you can rename your music files and use that name with PlayMP3File:
PlayMP3File ("resource1.dat");
where resource1.dat is actually an mp3 file.
Trickier (additional) method involves modifying the header (several first bytes) of a "resource1.dat" file so that it would be impossible to play it with the media player.
The actual header is then stored in the game code and could be written into "resource1.dat" when you're about to play it.
But it has some pitfalls as well, not to mention the need to mess with resource files (they should normally be readonly). A workaround would be not to write into "resource1.dat" but create a new one (say "temp.dat"), and play that instead.
Another workaround is to encript the files in some way, and then decrypt them and save them as MP3 files during runtime, but IMO that's just wasting time and doesn't worth the effort.
Yeah, I thought about that too--I know there's a plugin or module that lets you encrypt/decrypt files somehow--but I don't really want to mess around with that unless I have to.
I don't care so much if people can listen to the MP3's outside the program, what I don't want them to do is REPLACE the mp3's with other ones. Is there a way for AGS to detect things like the length or the header or file-size of an MP3? If I could do that, then I could at least make it not worth the effort for someone to find an MP3 they could replace the game's with.
If there's no way to do that, then I'll probably go with Scorpius' file-renaming idea. I actually didn't know you could change an MP3's extensions and still have AGS recognize it.
Quote from: KingMick on Fri 21/04/2006 04:25:04Is there a way for AGS to detect things like the length or the header or file-size of an MP3?
There is no ready to use means in AGS, but then again, you can use AGS file Input/Output functions to read the header or detect file size.
You can?
Darn it, I was just trying to figure out how to do that last night, browsing through the help file. How do you do those things? Is there some kind of plugin I need to download or am I just missing the documentation somewhere?
If I can read the header and detect the file size, I think that would be good enough for me. The idea is that if someone just tries to replace an MP3 file on a whim, the chances are good that the game will give them an error message and crash--I think that would be discouraging enough that most people would probably not look into it further.
As an example, the following function should report filesize, it actually returns one fourth of file size (or it can be made to return total size with error of up to 3 bytes) because otherwise it would be awfully slow for large files. Generally, filesize should not be retrieved this way.
function noloopcheck File_GetQuarterSize (String filename) {
File *file = File.Open(filename, eFileRead);
if (file == null) return -1;
int sum = 0;
while (file.EOF == false)
{
file.ReadRawInt();
sum ++;
}
file.Close();
return sum;
}
For a file with a size of 133 333 bytes it would return
133333/4 = 33333.25 ~ 33334 (ends with 4 because of .25 giving +1)
But even that implementation would possibly be very slow for larger files (such as mp3 music ones) so see whether it works too slow for you.
on game_start:
if (File_GetQuarterSize ("resource.dat") != 100000)
{
Ã, Ã, AbortGame("resource file corrupted");
}
where 100000 is about 1/4 of "resource.dat" size (in bytes).
That is its real size either: 400000, 399999, 399998 or 399997 bytes.
Therefore see what Display("Quarter: %d", File_GetQuarterSize ("resource.dat")); will show and use that number to compare with.
File_GetQuarterSize can be optimized. For instance it can read larger blocks (using strings). That would make it work much faster but it should be implemented (if possible) with care to allow cross-platform compatibility (because of strings).
Alternatively, there could be some sort of a more complex checksum, CRC algorithm involved, but personally, I think just renaming music files should already be enough and it doesn't worth the hassle, really.