RunAgsGame uestions

Started by jamesreg, Wed 15/01/2014 22:06:36

Previous topic - Next topic

jamesreg

I have a few questions about the RunAgsGame function.

Beings I am doing a game which is a complilation of other games many of which can fit in one room or so on but some can not.
Since I am only one game into it so far I began to wonder if it would not be better for me to utilize the runagsgame command
and seperate the games into seperate ags games with the main game acting simply as a launcher.

even though I understand some basic principles of how this works im I am still unsure about a couple things.

1) If running each game as a seperate ags game and utilizing the runagsgame command to call each game up Does that mean each game would be able to use its own save game features and such out of the box?

2) when it comes to sprites do all the sprites have to be in the first original game or can each game have its own sprites saved in that particuar ags game? and how does the numbering of the sprites thing work back and forth? I will have no need to call up any sprites back and forth between games each one will be independant of any other games. But was unsure if say one game had sprite number 1 and say the launcher had sprite number 1 as something different how that works.

3) other then the coding runagsgame command to lauch the new game is there any other set up or things that must be done? the manual says that the speech.vox and other such files are shared what do I do with the ones from the new game delete them or what and exactly what does that mean does that mean all sound files need to go into the first copy?

Sorry if my questions were confusing but others who have done things with the runagsgame feature id like to here from you and your experiences and anything else you may want to comment on to watch out for or know about. and do you think this is the way for me to go with my project?

4) is there a limit of runagsgames you can have other then alot would be a huge download?

Khris

1) is actually answered in the manual entry. The games share save game slots, and loading a slot from the previous game will switch back to that game.

2) Each game has its own sprites. (You are building the games separately, and sprites end up as part of the exe.)

3) all external files, for example audio.vox, are shared. This means that you should probably import every soundfile into all games, so that you can use either game's audio.vox (because since you'll compile them separately, each game is going to have its own audio.vox, and they need to be identical since you can't merge them).

4) I don't think there's a limit.

From a technical side, the exe file that ags produces is a copy of acwin.exe (the engine) with all the game data appended to it. When you use RunAgsGame, the engine part of the current game exe will keep running but from here on out use the resource part of the other exe file. This is also why the games have to use the same resolution and color depth; all you're doing basically is using the rooms from another game in your first one.

If you're going to use no speech, and only audio (midi, ogg?) and video (flv) that is compiled into the exe, all you have to worry about is the resolution and color depth.

jamesreg

Ok this sounds like the way to go for me as I wont be using any voice files nothing needs to be shared back and forth ill still have to play around with the saves probably something simular to the code you gave me earlier that I have been playing around with but I was going to have to do that anyway.

So doing it this way I could do the following as well

1) each game could be released speperatly if I wanted to it will load up just fine  or I could load it with a launcher or any of the other games using runagsgame. Correct?

2) If I exit the "loaded up game" can I set it to return to the orginal game which is actully just a menu list or launcher.

This sounds like the way to go.

Khris

1. Yes
2. Instead of QuitGame(), just use RunAGSGame() again, this time running the launcher game.

SMF spam blocked by CleanTalk