01-09-2012, 12:39 AM
Using a hash to map identifiers in the form of symbols to the various objects much nicer than using an array.
Let me show you why it is a good idea by changing your DataManager.make_save_contents method so it does not overwrite the method, but rather just adds the given contents.
If we were to use an array in we put contents << $game_skillpoints, but how would we extract that information from the save files?
With your script alone we can simply extract it using contents[11] or look at the last element, but what if another script which also puts some information in save files?
Then depending on the order of the scripts it can be either contents[11] or contents[12] you have to read.
It is somewhat similar to the default saving system in XP and VX where the order in which it was saved/loaded mattered.
Of course you can map your object to a specific number which is not in direct extension of the previous last element in the array like contents[42] = $game_skillpoints.
Now you can just use contents[42] to retrieve it. Of course you can still get into trouble if another script also uses index 42. More annoyingly is for the scripter to choose numbers which probably won't be used in other scripts. Mind you, the number shouldn't be too big since that will directly effect the size of the array, which would increase the file size of the save. We can implement our own hashing function to keep the size small, but why do that when we already have a very efficient data structure?
If we use a hash we can use the symbol :skillpoints which is way more descriptive than 42. We don't have the problem what's the last element since we don't have a concept of the last element. (Actually we do sort-of as Hash implements Enumerable, but I wouldn't recommend creating hacks relying on it.)
It is still possible that another script will use the :skillpoints key as well which will cause problems.
I do suggest that you alias the original methods so that you can reuse them and only add the extra functionality. Otherwise you may mess up other scripts.
I assume you intend to release the script to the public so we really want to make it more aspect oriented.
*hugs*
- Zeriab
Let me show you why it is a good idea by changing your DataManager.make_save_contents method so it does not overwrite the method, but rather just adds the given contents.
Code:
module DataManager
# Let's open up the singleton class of the module
class << self
# change the name of the alias if you care going to use this snippet
alias_method :aliased_make_save_contents, :make_save_contents
def make_save_contents
contents = aliased_make_save_contents
contents[:skillpoints] = $game_skillpoints
contents
end
end
end
If we were to use an array in we put contents << $game_skillpoints, but how would we extract that information from the save files?
With your script alone we can simply extract it using contents[11] or look at the last element, but what if another script which also puts some information in save files?
Then depending on the order of the scripts it can be either contents[11] or contents[12] you have to read.
It is somewhat similar to the default saving system in XP and VX where the order in which it was saved/loaded mattered.
Of course you can map your object to a specific number which is not in direct extension of the previous last element in the array like contents[42] = $game_skillpoints.
Now you can just use contents[42] to retrieve it. Of course you can still get into trouble if another script also uses index 42. More annoyingly is for the scripter to choose numbers which probably won't be used in other scripts. Mind you, the number shouldn't be too big since that will directly effect the size of the array, which would increase the file size of the save. We can implement our own hashing function to keep the size small, but why do that when we already have a very efficient data structure?
If we use a hash we can use the symbol :skillpoints which is way more descriptive than 42. We don't have the problem what's the last element since we don't have a concept of the last element. (Actually we do sort-of as Hash implements Enumerable, but I wouldn't recommend creating hacks relying on it.)
It is still possible that another script will use the :skillpoints key as well which will cause problems.
I do suggest that you alias the original methods so that you can reuse them and only add the extra functionality. Otherwise you may mess up other scripts.
I assume you intend to release the script to the public so we really want to make it more aspect oriented.
*hugs*
- Zeriab