Save Games?!?

I am currently making a game, but have still to implement some sort of save game system... The game loads all of its data in from a database with several tables, but sets variables during play as well...

Ideally, I want four save slots, so I thought of choosing a save slot before play starts, copying the master db file to the folder, ie save1... and playing from there... but how would I save what data was stored in the variables when the player wants to save? using an .ini file? i've never had to do this before... can anyone advise on this?

cheers

I'm not really sure how exactly you mean, is the game variables stored and accessed directly from the database? Since that might implicate performance problems, but i don't know what kind of game you are making so i can't say.

I think an unlimited amount of save slots would be most preferable.

thanks for replying kedaman...
most of the variables are set from the master database through labels showing fields in the game ie:
label1 is linked to data1 and shows a field called "name", so:

Dim Name As String
Name = label1.caption

but some are set through input boxes in the game, ie:

YourName = InputBox.....

any further suggestions?

How about just saving the variables in binary mode, then when you load the game, set the values from the data you get from the file.

Well i'm kindof out too when it comes to databases and would store in binary, but i guess scotty wants to have it his way.

I was going to ask what kind of game you were making so that i can see what would be suitable data storage, so can you explain what you are doing?

Exactly. What datatypes are you storing? My bet is they're all Strings and/or Longs, which could be stored in a text file (.txt, .ini, etc) or the registry and accessed much faster than from a database.

However, if you are already hitting the Db when the game loads and you have some sort of splash screen or something to entertain the user during data acccess, then maybe you should just store them in the Db and read them with the rest of the stuff when your prog loads. And when the user saves his/her game, put up another "Please wait" message while the dirty data gets saved.

As long as you're not reading them while the user is playing, the performance hit probably won't be noticed.

All of the variables are of type String, Integer, Boolean or Long... I didn't say I wanted to save them into the database, I simply said that values were taken from the database and were set as variables, which could be saved in the text, binary, whatever file along with the other variables et from within the game...

So how would I go about saving the variables in a binary or text file? Preferably, I'd like to use a text file as I haven't used binary files before...

Cheers

hello?

"hello?" he called from the bottomless pit of being stuck on how to do something... lol, sorry but i really need this help guys!

wait until they get out of bed! its 4 am here.

the easiest way to write to a file in your case:

dim a as long
a = 14

open "filename" for output as #1
print #1, text1.text, text2.text, a, etc. ' as many variables as you need
close #1
and to restore the variables:
open "filename" for input as #1
input #1, text1.text, text2.text, a, etc.

The easiest way (I think) is to make a UDT (User Defined Type) which holds all of the info, that way you can easily read and write it, and add new options too (although you can't read the old files anymore then)...

Some sample code (tested):

Code:

---

' Put all data you want To save here
Public Type SAVEDATA
    PlayerName As String
    CurrentScore As Long
    CurrentLevel As Long
    HasSword As Boolean
End Type

' The variable that will hold the above information
Public tData As SAVEDATA

' Let's say the user is named 'Psycho' And has got the sword
tData.PlayerName = "Psycho"
tData.HasSword = True

' Wow, he made it into the Next level!
tData.CurrentLevel = tData.CurrentLevel + 1
tData.CurrentScore = tData.CurrentScore + 500

' So we need To save, let's save into the file 'save001.dat'
Call SaveGame(App.Path & "\save001.dat")

' Once we need To load the data, use this
Call LoadGame(App.Path & "\save001.dat")

Public Sub SaveGame(Filename As String)
    Dim iFree As Integer

    ' Open the file
    iFree = FreeFile()
    Open Filename For Binary Access Write Lock Read Write As #iFree

    ' Write the data
    Put #iFree, , tData

    ' Close the file
    Close #iFree
End Sub

Public Sub LoadGame(Filename As String)
    Dim iFree As Integer
    Dim tTemp As SAVEDATA

    ' Open the file
    iFree = FreeFile()
    Open Filename For Binary Access Read Lock Write As #iFree

    ' Read the data
    Get #iFree, , tTemp

    ' Close the file
    Close #iFree

    ' I used an Empty version of SAVEDATA To make sure
    ' it's loaded correctly (don't know If it'll make any difference,
    ' but just To make sure...
    ' So we need To copy it to our tData variable
    tData = tTemp
End Sub

---

Good luck!

sure you could. Add a 2nd udt for "extended" info. And after reading the first one check for eof. Microsoft does this will .dlls. They don't expand current ones. They make new ones with the new add-in functions. The problem is that you would have to specify a max length for each string your way.
Plus there is the extra step of reading and writing to the array.

Got a theory:

1. An UDT is written to a file in the exact order as it is defined, this means that you should not move for example HasSword to above PlayerName, that would mean it can't read the file anymore.

2. Normally when you write a string to a binary file, you have to know the exact size of the string, or it will not read it correctly. This is done automatically when you write an UDT, so Visual Basic resizes the string correctly when attempting to read the UDT from the file again.

Those two combined with a little logic I come to the following conclusion (don't ask me how):

If you want to change your UDT in a later stage, make sure you add all new options below the other ones, it does make a difference. If you're trying to read an old file using the new UDT, theoretically all the original items will be filled correctly, but the items you added will just be empty (or False or 0 for booleans and longs)...

This gives the same result as the way described by Lord Orwell, but it's easier, doesn't need fixed-length strings and was totally my idea :D (ok, forget the last one ;))


I haven't tested this theory, but I would be suprised if it turned out different...

version incompability should be supported with file converters

Writing to the registry is pretty darn easy, too.

This is a simple example using the built-in registry writing/reading functions in VB. They are a little restricive because you can only go a few levels deep when creating keys, but they are easy to implement.

Basically, one way to save a setting is to do this:

Code:

---

SaveSetting <GameName>, <PlayerName>, <SettingName>, <SettingValue>

---

And to read the setting you do this:

Code:

---

<SettingValue> = GetSetting(<GameName>, <PlayerName>, <SettingName>, <DefaultValue>)

---

For example, to save the current score (which is held in the global variable m_CurrScore) for the player "DeathLord" in the game, "Space Titans", you do this:

Code:

---

SaveSetting "Space Titans", "DeathLord", "Current Score", m_CurrScore

---

And then to read it again:

Code:

---

m_CurrScore = GetSetting("Space Titans", "DeathLord", "Current Score", "0")

---

Of course, you would probably have a registry key that held all the saved players names, then you would let the player choose a name from a list (which you generated from the registry), store the chosen name in a variable, then pass that variable to the SaveSetting and GetSetting functions to retrieve info for that player.

Just another way to do pretty much the same thing.

The registry is offcourse a way to store the data. But what if you are going to have unlimited savegames and a lot of data for each savegame? The registry will be able to hold all that data, but Windows will slow down because of it's size and generally people don't appreciate it if you fill their registry with a lot of data...

Anyways, you've got a lot of options to save the data, you should be able to work something out by now...

Good luck!

Quote:

---

Originally posted by PsychoMark
Got a theory:

2. Normally when you write a string to a binary file, you have to know the exact size of the string, or it will not read it correctly.
This is done automatically when you write an UDT, so Visual Basic resizes the string correctly when attempting to read the UDT from the file again.

theoretically all the original items will be filled correctly, but the items you added will just be empty (or False or 0 for booleans and longs)...
I haven't tested this theory, but I would be suprised if it turned out different...

---

Answer to #2: Make it from a custom TYPE with declared string lengths and no problems.
As for the rest, it seems to me if you try to read more info from a file than it has, you get an "input past end of file" error.

Well, the only way to know it is to test it, so I did: my theory was correct.

I ran my original code for saving the file, then added a "NewName As String" to the type, and read the file which was written with the old type: no errors, just an empty string!

This means that there's no need for fixed-length strings or EOF checking with previous types, all you have to take care of (when you load an old file) is to fill the empty data...

That wouldnt change anything, an empty string passed with get, doesn't return anything either. There's no EOF checkin in binary mode, that's one of the factors why binary mode much faster than input. if you happen to read beyond EOF, no data will be read, and the file remains intact, if you do though, you might have a corrupted file. In that case the equivalent to eof would be lof(filenumber)<loc(filenumber)

oops. But you should always assign string sizes to a type. If you don't there is no way for you to dynamically edit them in the file.
Which i assume you would want to do in a save game.

Why? Can't you just write the type to the file like in my sample code? This way, when you read it again, the strings will be sized automatically...

You don't really need to edit a particular field, you can just rewrite the whole file using the type (it's not going to hold 4 MB of data, is it?)

well i dont really know the application. But baldur's gate has meg save files. Every item in every shop is stored in your save file after you visit the shop. And if he has one file with multiple save games in it, then it would be a necessity that they all be the same size.

Yeah, you're right. If files could get really big you should have some way of determining where all data is so you can edit is easier. But most games don't save their data until you tell them to, so if it's going to be that way, it shouldn't really matter, although it's a lot more flexible but difficult if he's going to use your idea...

hmm, looking at your sample psychomark, it won't work, binary mode doesn't write descriptors to dynamical strings, you have to do it manually by building headers into each type

do wha?

I am lost by your terminology Kedaman

but I tested his "dynamic string" method and it actually seemed to work to my surprise. :rolleyes:

Code:

---

Private Type testtype
firstnum As Long
secondnum As Long
stringtoget As String
thirdnum As Long
End Type
Private Sub Form_Load()
Dim newtest As testtype
Dim newtest2 As testtype
Open "test" For Binary As #1
newtest.firstnum = 7
newtest.secondnum = 999
newtest.stringtoget = "test string that will cause error"
newtest.thirdnum = 5
Put #1, 1, newtest
Get #1, 1, newtest2
MsgBox newtest2.firstnum
MsgBox newtest2.secondnum
MsgBox newtest2.stringtoget
MsgBox newtest2.thirdnum
Close #1
End Sub

---

kedaman, did you look at it or did you actually try it? I tried it and it loaded all settings perfectly (and not only with an already filled UDT, but also with an empty one)...

in particular i dont know what you meant by descriptors and headers.

I think he meant writing a couple of Long's for example at the beginning of the file telling the game how large each string is...

oh well, i've been working with files since i started with gwbasic, (so don't tell me what to do hehe :p)

what i meant is that each type containing dynamical arrays or string should be preceeded with a header type, just containing the sizes of the strings/arrays used, and the good part is that you can choose whether to use byte, integer or longs as descriptors.
Redim the the arrays after getting the header and space the strings. Nested dynamical types require nested loops for filling the arrays (this get's really complicated with huge types and i'm currently developing a code generator for it)
Lord orwell sample happens to work because the string was already filled

lol, sorry to interrupt such a fascinating argument full of language i don't understand guys... ;) if you go back to the top of the page, you'll realise i started this string...

i don't particularly want anything as massively complicated as you have all described, most games i have seen have just stored the contents of variables in a text file! does anyone have any coding on how to do this?

put simply, i want a small piece of example coding showing how to save the contents of variables to a text file and how to load them again...

by the way, as you asked i am making a small football management game, so things such as squads are saved in a database file and don't need to be saved as variables in the text file...

for the sake of the example, you could show how to save the managername (string), money (long), and onholiday (boolean) variables...

thanks guys, roll on the argument lol

To kedaman: Lord Orwell's sample used a new empty variable, newtest2 :p

To scotty85_2000: You can easily use my sample and replace the items in the SAVEDATA type with your own. That's in your case I think the most easiest and flexible way...

it wasnt already filled. I loaded it into a different variable altogether.

Dim newtest As testtype
Dim newtest2 As testtype

Put #1, 1, newtest
Get #1, 1, newtest2

i posted your simple answer as my first post in this thread.
but for your sake, here it is again:

to write it:
open "file" for output as #1
print #1, managername, money , onholiday
close #1

to read it:
open "file" for input as #1
input #1, managername, money, onholiday
close #1

oh! i mean that's something new, and i think it's something specifically new in vb6 because that never worked in vb5, i have to check this out

?
what is?
i use vb5. my code worked in vb 1.

That's why I use it all the time for things like this: you can change it easily, the loading and saving will remain the same, all the data is nicely stored into one place (tData.PlayerName instead of meaningless variables floating around in your program)...

hmm. I tested and it seems to have problems reading stored boolean variables. :(
you would have to store them as their actual numerical value of -1 instead :(
Kedaman, if you are referring to the strings loading correctly, then it surprised me too. I have recently installed the service pack though. That might be the difference.

hmm, i don't happen to have my vb5 left, but youre right it works with vb1, and so it probably works with vb5. big mistage :o because i've been working around this for years. Thanks to you guys,now i know it works, and i even tried dynamical arrays, seems to work too :D saves me a lot of pain

Yeah, it works with arrays too, that's another great thing about it...

Lord Orwell: I can't see any problems with the booleans, they work fine for me. If they are a problem, maybe you could bypass that by using a Byte and set it to CByte(Boolean) and use CBool(Byte) to get it back... but as I said, they weren't a problem for me...

boolean works fine for me.
might be, that the service pack contains a fix to the descriptor bug, and i didn't have any service pack installed last year