Saves and episodic games question
- Thread starter megatronx
- Start date
There is a RM2K game called "The Way" that uses exactly the system you described. Since RM2K doesn't have game encryption, you can open the game in RM2K to see how it works (A process known as reverse engineering). Since RM2K and RMXP/VX use very similar event methods, it shouldn't be to hard to apply the technique to RMXP.
I've never tried this, but you shouldn't need a script. Whenever you load a game, rmxp just unmarshals a bunch of stuff and, then, determines if you've edited; and if so, places you in the center of the map. In other words, as long as you don't make any masive alterations to the scripts, shouldn't have a problem...actually, you may need to add about five lines of code to deal with the fact that the map from the prior game isn't in this game; I can help you do this if you want, just PM me.
No, in The Way, the database, maps, and switches change from episode to episode. For switches and variables, you would have to decide which ones will be used throughout the entire series, such as Plunge (from The Way) skill levels, sidequests that effect what happens later on, etc, and what will only be used in a single episode, such as chests opened, etc. Between episodes, you would clear the switches (set to false) and variables (set to zero) that you do not intend to carry over.
There is a more difficult solution, that is a bit more efficient. But it requires a good knowledge of scripting, and other more in-depth procedures.
Use an external install-maker, instead of RMXP's. One that supports making and reading registry entries. Have it register a key for the installation directory of each episode.
Now, RMXP games are usually quite lightweight and get moved around a lot. So we'll need to update that entry.
There are registry scripts for RMXP, I know I found one at 66RPG.com, if there isn't one here somewhere.
Use the said registry script to update that registry key for the game's location every time it's run.
Now for the second game. First we need to get those files.
This game, on first run, or on creating a new game (whichever works for your purpose), should use the registry script to copy the old save to the new directory. You may need FileUtils for this, which is freely available (just search this board or Google for links). You will probably want to rename this save to SaveX.rxdata or something to prevent overwriting.
Once you have the old file, you could simply use it as is. In order to do that, all original database entries need to stay the same, and you need to have the same number of maps or better (they don't need to be the same maps, since you can always do an immediate player transfer. But if you don't have enough maps, you can run into an invalid error.). This is inefficient, and unpractical except for its ease of use.
This step is a little bit tricker. Simply load the file, then override the players position with script immediately. Scripts work much faster for this step. Analyze the party's inventory. For example, if metal hammer had id 13, and now it has id 19, and the party has a weapon with id 13, simply remove 13 from the party and add the weapon 19. Rinse and repeat for skills, etc. Simply remove items you don't want transferred. A nice touch would be to artificially "sell" those items, giving the party some extra starting gold equivalent to the value of lost items (or half that value, for a true sold price). Just a thought. Proceed to read and alter all the data that needs to be, well, altered.
A lot of work, yes. Quite a bit. But in the end, it's a more efficient solution.
Oh, I forgot a sidenote in there. When you go to find the old savegame directory, you will need to know your current directory, which can be accomplished through 2 API calls. You will also need a solution in the event that the save never existed. For this, you could simply move on to blank data, or offer them a directory selection tree and ask them to locate the folder themselves.
[EDIT: I was retarded here. Your install maker for your new game would have saved this path to registry as well. No need for API.]
You will also want to make them select a slot (1, 2, or 3 for example. Number input if you used an unlimited saves script.) to be loaded.
[EDIT: Forgot another sidenote. In the event that the first game isn't installed, or there's no registry key, or the registry key is invalid, you could offer them a directory tree, or simply bypass this option altogether. Should be pretty obvious, but wanted to state it anyway.]
If someone has a completed game, and wants help transferring data for the new game, let me know. The first game would have to be pretty much completed, though, as I'm really really busy these days.
[EDIT: Alternative solution]
Another common alternative to this is a password system. There are a number of ways to implement a password system, the most basic would be to have a single character for each critical item and event from the previous game, as well as characters for actor data. There would be a security string spread out through this password that should be conditional, but only have a couple of useable combinations to increase security.
For example, if you want to transfer the Mythril swords, Iron Clubs, and wether or not Maya survived in the first game, the password may look something like this:
2472011522 - Password 1
0103020006 - Password 2
SSXXIIMMXX - Legend
SS = Number of Mythril Swords
XX = Security code (in this case, SS x 3)
II = Number of Iron Clubs
MM = Level for Maya if she survived, 00 means she didn't
XX = Security code (in this case, break down all previous values to single characters and add their values for a total)
Naturally, that password is extremely lightweight. You'd need something a bit heavier.
To transfer gold, you'd probably need high and low bytes for it (if you're parsing in two-character sets). Something like:
AABBCC (which for example could be 14 25 32 for 142,532 gold
To accomplish this, for those not familiar with such operations, is nothing difficult.
First, add CC gold to the party.
For BB, multiply it by one hundred.
For AA, multiply it by ten thousand.
[End alternative]
[Edit] Also, keep in mind that you may want to transfer a few extra details you aren't using in the next installment, because you may decide to implement them in a later episode, and it would be wise to carry forward through the episodes rather than hoping to track down all episodes installed.]
Hope it helps.
[EDIT: This solution is a more advanced and controllable way to do this, not the easy way. Just thought it deserved to be on the table as well.]
Use an external install-maker, instead of RMXP's. One that supports making and reading registry entries. Have it register a key for the installation directory of each episode.
Now, RMXP games are usually quite lightweight and get moved around a lot. So we'll need to update that entry.
There are registry scripts for RMXP, I know I found one at 66RPG.com, if there isn't one here somewhere.
Use the said registry script to update that registry key for the game's location every time it's run.
Now for the second game. First we need to get those files.
This game, on first run, or on creating a new game (whichever works for your purpose), should use the registry script to copy the old save to the new directory. You may need FileUtils for this, which is freely available (just search this board or Google for links). You will probably want to rename this save to SaveX.rxdata or something to prevent overwriting.
Once you have the old file, you could simply use it as is. In order to do that, all original database entries need to stay the same, and you need to have the same number of maps or better (they don't need to be the same maps, since you can always do an immediate player transfer. But if you don't have enough maps, you can run into an invalid error.). This is inefficient, and unpractical except for its ease of use.
This step is a little bit tricker. Simply load the file, then override the players position with script immediately. Scripts work much faster for this step. Analyze the party's inventory. For example, if metal hammer had id 13, and now it has id 19, and the party has a weapon with id 13, simply remove 13 from the party and add the weapon 19. Rinse and repeat for skills, etc. Simply remove items you don't want transferred. A nice touch would be to artificially "sell" those items, giving the party some extra starting gold equivalent to the value of lost items (or half that value, for a true sold price). Just a thought. Proceed to read and alter all the data that needs to be, well, altered.
A lot of work, yes. Quite a bit. But in the end, it's a more efficient solution.
Oh, I forgot a sidenote in there. When you go to find the old savegame directory, you will need to know your current directory, which can be accomplished through 2 API calls. You will also need a solution in the event that the save never existed. For this, you could simply move on to blank data, or offer them a directory selection tree and ask them to locate the folder themselves.
[EDIT: I was retarded here. Your install maker for your new game would have saved this path to registry as well. No need for API.]
You will also want to make them select a slot (1, 2, or 3 for example. Number input if you used an unlimited saves script.) to be loaded.
[EDIT: Forgot another sidenote. In the event that the first game isn't installed, or there's no registry key, or the registry key is invalid, you could offer them a directory tree, or simply bypass this option altogether. Should be pretty obvious, but wanted to state it anyway.]
If someone has a completed game, and wants help transferring data for the new game, let me know. The first game would have to be pretty much completed, though, as I'm really really busy these days.
[EDIT: Alternative solution]
Another common alternative to this is a password system. There are a number of ways to implement a password system, the most basic would be to have a single character for each critical item and event from the previous game, as well as characters for actor data. There would be a security string spread out through this password that should be conditional, but only have a couple of useable combinations to increase security.
For example, if you want to transfer the Mythril swords, Iron Clubs, and wether or not Maya survived in the first game, the password may look something like this:
2472011522 - Password 1
0103020006 - Password 2
SSXXIIMMXX - Legend
SS = Number of Mythril Swords
XX = Security code (in this case, SS x 3)
II = Number of Iron Clubs
MM = Level for Maya if she survived, 00 means she didn't
XX = Security code (in this case, break down all previous values to single characters and add their values for a total)
Naturally, that password is extremely lightweight. You'd need something a bit heavier.
To transfer gold, you'd probably need high and low bytes for it (if you're parsing in two-character sets). Something like:
AABBCC (which for example could be 14 25 32 for 142,532 gold
To accomplish this, for those not familiar with such operations, is nothing difficult.
First, add CC gold to the party.
For BB, multiply it by one hundred.
For AA, multiply it by ten thousand.
[End alternative]
[Edit] Also, keep in mind that you may want to transfer a few extra details you aren't using in the next installment, because you may decide to implement them in a later episode, and it would be wise to carry forward through the episodes rather than hoping to track down all episodes installed.]
Hope it helps.
[EDIT: This solution is a more advanced and controllable way to do this, not the easy way. Just thought it deserved to be on the table as well.]
You're all kind of over-complicating this... All you need to do is at the end of the game is to transfer the player to another map. In the first episode, you have an event to show the credits or whatever, but in the next episode, you transfer the player to the first map of the next episode. I use this method, MotW uses this. Easy peasy.
Eriol Clowphengire
Member
I have this similar inquiry but I dunno if this is plausible on my games though. Let's say:
My first game will use NGCS01_SaveXXX.rxdata as its naming convention for my first game. The twist is that the 2nd game related to the previous game may carry over the stuff you got on the first game and even carry over your NGCS01 characters to the 2nd game.
But if you don't have any NGCS01_SaveXXX.rxdata, the 2nd game will just adjust the actors from the first game though...
EDIT: I might as well try your method, Bruno!
However, my party in 1st game will be different in 2nd game... but the characters you've played on 1st game will be playable again on 2nd game onwards.
My first game will use NGCS01_SaveXXX.rxdata as its naming convention for my first game. The twist is that the 2nd game related to the previous game may carry over the stuff you got on the first game and even carry over your NGCS01 characters to the 2nd game.
But if you don't have any NGCS01_SaveXXX.rxdata, the 2nd game will just adjust the actors from the first game though...
EDIT: I might as well try your method, Bruno!
However, my party in 1st game will be different in 2nd game... but the characters you've played on 1st game will be playable again on 2nd game onwards.
Eriol Clowphengire
Member
Wait, wait, wait... On your 1st chapter, how many maps you've used? Then for the 2nd?BrunoTR":2rql5fp3 said:
Bruno there is thios handy disk changer/map limit breaker script by Zeriab
Hope that helps :D
Code:
#==============================================================================
# ** Disc Changer script (Designed for Legend of Harpine)
#------------------------------------------------------------------------------
# Zeriab
# 1.05
# 2008-09-20
#------------------------------------------------------------------------------
# Allows you to change the disc, where each disc can contain 999 maps
#==============================================================================
=begin
INSTRUCTIONS
------------
If you do not have the SDK then you have to change Game_Map
In the Game_Map setup method change the load_data line to this: (Line 50)
# Load map from file and set @map
@map = load_data(sprintf("Data/%sMap%03d.rxdata", $game_system.disc, @map_id))
After you have done this the below will work.
This script enables the change_disc command. Use script calls to change the disc.
For disc 1 create a subfolder in your data folder called 'disc1' and place the
map files for disc 1 in there.
For disc 2 you should create a subfolder called 'disc2' and place the map files
for disc 2 in there. And so on for each of your discs.
The syntax is:
change_disc(number, id = nil, x = nil, y = nil, direction = nil)
The nil numbers mean that those arguments are optional. When you don't use them
then they are set to whatever the current map_id, x, y and direction are at the
moment.
If you want to change to disc 2 then you can put this in a script call:
change_disc(2)
You will then be transfered to disc 2 with the same map id and coordinates as
what the player currently has.
If you want to be more precise and say you want to change to disc 2 on the map
with id 10 and the player must be placed at the tile with x = 6 and y = 13 then
you should put this in a call script:
change_disc(2, 10, 6, 13)
Note that when you start the game the maps directly in the data folder is used.
You can back to them by changing to disc number 0.
Basically, disc number 0 is the maps directly in the data folder and not in any
of the sub folders.
The final argument is the direction. By default the player retains the current
direction. You can put 6 different values as direction:
0, 10 : No change
2 : Turn Down
4 : Turn Left
6 : Turn Right
8 : Turn Up
If you for example want to transfer the player to disc 1, map 43 at x = 30 and
y = 4 with the player looking down you should put this in a call script:
change_disc(1, 43, 30, 4, 2)
*hugs*
- Zeriab
=end
class Game_System
attr_writer :disc
def disc
@disc ||= ''
@disc
end
end
class Game_Temp
attr_accessor :disc_changing
end
class Game_Map
attr_writer :map_id
if Module.constants.include?('SDK')
def setup_load
# Load map from file and set @map
@map = load_data(sprintf("Data/%sMap%03d.rxdata", $game_system.disc, @map_id))
end
end
end
def change_disc(number, id = nil, x = nil, y = nil, direction = nil)
# Change disc
if number.is_a?(Integer)
$game_system.disc = "disc#{number}/"
else
disc = number.to_s
disc += '/' unless disc[-1] == 47
$game_system.disc = disc
end
# Process arguments
map_id = id.is_a?(Integer) ? id : $game_map.map_id
x = $game_player.x unless x.is_a?(Integer)
y = $game_player.y unless y.is_a?(Integer)
direction = $game_player.direction unless direction.is_a?(Integer)
# Set transferring player flag
$game_temp.player_transferring = true
# Set transferring player flag
$game_temp.disc_changing = true
# Set player move destination
$game_temp.player_new_map_id = map_id
$game_temp.player_new_x = x
$game_temp.player_new_y = y
$game_temp.player_new_direction = direction
# Change the current map id in case the new and old are identical.
$game_map.map_id = 0
end
@Velocir_X: Oh, cheers. I'll cross that bridge when I get there.
@Dung Beetle: Halfway through Chapter 2. I also use a 1:1 overworld, so lots of paths n' stuff. Anyway, we're going off topic. My fault, I guess.
The problem with my method, is of course, is that you need to keep all the stuff in the database consistent. You can add to it, just keep it all in the same order.
@Dung Beetle: Halfway through Chapter 2. I also use a 1:1 overworld, so lots of paths n' stuff. Anyway, we're going off topic. My fault, I guess.
The problem with my method, is of course, is that you need to keep all the stuff in the database consistent. You can add to it, just keep it all in the same order.