The text file method would still have all the issues you'd run into by using the save file itself, and then you'd have to convert from the save file format to a text format to save, and then convert from a text format to a save file format to load. So the tutorial you saw is actually more difficult than just using the save files.
You will need a script. Can't be done without it. And no script exists (AFAIK) that will be suitable for everyone. Each one must be written specifically for that game.
The first obstacle you have to overcome is knowing where to look for the previous game's save file. Because the player can install the game anywhere they like, into a folder with whatever name they like, just searching for the game name in the default install folder (Program Files?) is only going to work a fraction of the time. To get around this (and to stop the save file being clobbered if you ever released patches/updates to the game, and to avoid the stupid permissions issues when you try to create a save file in a "windows-owned" folder), we made the games save in the %appdata% folder rather than the game's folder. We had total control over the names of the folders and files, so in the next game we knew exactly where to look. It also meant if two people shared the same computer with their own logins, they couldn't overwrite each other's save files.
The next obstacle is, when you know where the save files are, how do you know that the game was finished and can be used for the sequel? If they'd only started a game and saved it, you wouldn't want to be able to carry from that save file over to a new one. Our solution was to treat in-progress saves and end-game saves differently. We slightly changed the name of the save file when the game was finished, so it wouldn't be detected in the Continue menu of the current game, but it could be picked up easily by the next game. You could also have a "Finished" folder under your save folders and put them in there instead.
The third obstacle is planning for a game series where your save file gets used through two or more games. Will you carry over ALL the items, stats, etc from one game to the next or will you just start over with a lot of stuff and rely on certain switches or variables to tell you what happened in previous games? You could simply start your game 2 database with the game 1 database, not removing or changing anything that's there, and only adding new entries. Or you could start over with the new game 2 database without any of the unnecessary stuff from the game 1 database, but you would need to include logic in your script to dispose of the unnecessary stuff that carried over and convert stuff that stays but might have a different id in the database.
And of course the other thing you're going to need is the script to handle it all - one script for the first game, to save the end-game save files in the correct location and/or correct name, and one script for each subsequent game (as they will all have different requirements) to detect save files from the previous game, load them correctly, put the player in the correct map to begin, and again to save the end-game save files in the correct location and/or name, ready for use by game 3.
I cannot give you any more specific details than that, as that will be for you and your scripter to work out, based on how you want to handle it, and what you want to port from one game to the next.
I will tell you the easiest version of all of the above is to simply save the end-game save files to a specific location so in the next game you know where they're going to be, and keep the database - actors, items, switches, variables, etc - intact and just add new entries with each new game. This means your database is probably going to blow out in size, but the only scripts you'll need are those that modify the save and load functions to provide the ability to save/load the current game, and to save the current end game and to load the previous end game. I say "simply" because it's more straightforward. But it's not simple at all.
We may have also used a dll in order to retrieve the correct path to the %appdata% folder. Too long ago now to remember.
