Game Saving?
Blitz3D Forums/Blitz3D Programming/Game Saving?
| ||
| Can someone explain to me how you can create a "Game Saving" system with blitz3d? You know, so when you leave the game and play it again later, you'll have all of your data saved. |
| ||
| You write all the variables that you want saved, such as position of the player, what map he's in, etc... Into a ".dat" file. IE: Hope this helps! Good Luck with your Project! :) Thundros~ Last edited 2012 |
| ||
| Its something you need to work your game design around from the start really. You need to take a "snapshot" of the current gamestate and write your engine in such a way that it can "resume" from that snapshot arbitarily at any point. As Thundros said this will involve writing a file which contains the data held in any variables in use (the str command can be useful here as it can "see" inside some of the data types in a way thats sometimes useful for writing out data). |
| ||
| Just to add to the above two points: there is no built-in facility for saving a game. The Blitz command set is much more low-level, and just lets you save either text or binary data to a file. No idea about the shape or length of the data. Similarly, it can read arbitrary data, text or binary, from a file again, but again it will have no idea about the format. My advice is to either: 1) Study up on binary formats - you'll need to see how to make them able to handle varying sizes and kinds of elements. This is space-efficient, but actually harder to get right than it initially sounds, and you need to have a lot of offset tables and seek pointers embedded in your data, which is no fun. 2) Use a text format. The best text format for general-purpose use is probably XML. You would be advised to use an existing XML parser rather than write a new one (it's a big and complicated project and you have better things to do). If XML is too complicated, or too much typing, you could also try INI format, or JSON. The advantages of a text format are that you can edit the file in a standard text editor, seeing directly what your data is doing rather than having to view it third-hand through whatever your loader does with the data. If you choose a standard format like one of the above, other people will also be able to edit it easily as well. The data is also usually more resilient as the text imposes an inherent structure to the document that isn't really present in a binary blob. The disadvantage is size, but text files usually compress pretty well. Obviously even pre-defined formats like these don't actually know what a game entity is, so you need to come up with some system for getting your scene data into file nodes; but XML and JSON are both hierarchical (i.e. trees of parents and children), like a Blitz entity scene - this is hard to implement in a flat binary file and very, very useful as it hugely reduces the amount of processing you have to do, to go from game entities to stored entities. |
| ||
| this can also vary greatly depending on the game, a game like sonic would just need the saved position of the player and active status of mobs rings and bonus boxes and the score/lives. CIV needs to basically dump every facet of the game world to disc. Minecraft has to use compression as it is saving world chunks all the time and they would otherwise take up a fair few hundred mb to a gig for a decent sized world. Way back when, some games used a keygen savegame code, this could be entered via the game pad for 16bit console games, this long string of garbage held all the info of a game of megalomania to be resumed although spoofing a new number would not neccesarily yield results. |
| ||
| Well, the game is a platformer so the only real thing needed to be saved are "open" parts of the game. I use variables to control what or what doesn't happen in the game. For example, if you are on the first chapter of the game, the "chapter" variable in the game will = 1, so only things that are supposed to appear in "chapter 1" will appear. Once you finish the first chapter, the "chapter" variable will = 2, so everything "unlocked" from chapter 1 AND everything that is no supposed to appear for chapter 2 will appear. A save system of saving variables would actually work very well IMO. However if you disagree, please feel free to tell me. I'm trying to get as many different views as possible. Last edited 2012 |
| ||
| I agree with yasha. Personally i prefer a text based one as it is easier to debug and change the format. You can always make it a binary file when you release it, or add some encryption on the text file. Although i prefer json format to xml, however you can use any structure you like. Last edited 2012 |
| ||
| Again with my sonic analogy, this is an ugly method but it might work and only in a few bytes (wow woop de doo in the world of TB hard drives ;) ) Say you have 128 rings you could have 128 dead/alive flags (bits basically) so when you reload the level or die and spawn at a checkpoint those rings are gone (unless you want rings to respawn upon death, but that's not a save game issue) you load the level as normally, but parse the dead/alive flags and only the alive rings are inserted into the game world. same for boxes, you could have one dead/alive flag per item eg the shield, extra life or sprint, or you could just have box #1 #2 etc and have the level data keep a track of what the contents is, box #5 has been opened regardless of the content, display broken TV. |
| ||
| I find that designing your save/load routine for gameplay is very similar to designing your load routine for loading levels, and save routine for saving levels in your editor...so think about your design for these and make them quite similar. |
   |