Jump to content
  • Advertisement
Sign in to follow this  
breakspirit

standard way to do save games and level information?

This topic is 2612 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm currently designing a simple ascii-based game using c++ just to get a handle on basic game programming and I've got a few questions. If anyone knows of any guides on these topics, I'd love to read them.

1. What is the standard way to save game-save information in a single-player game? Things like exp or lives or whatever. I assume this would be saved in some sort of binary file? It seems like you'd want something that the user could not freely edit. I'm currently using .txt files and that is clearly not the way to go.
2. In a multiplayer client/server model, how would the server save and retrieve the game state/save information? In a database file full of players and stats perhaps?
3. How is level data stored typically? Again, it seems like this would be stored in such a way that users could not edit it. Like I said, I'm just doing a basic ascii game for now, so the levels would be very simple arrangements of characters on the screen. How should I store and retrieve this information?

Like I said, if anyone knows of any guides on these topics, I'd be interested. Thank you for any assistance.

Share this post


Link to post
Share on other sites
Advertisement
1. Even a txt file can be in binary data and therefor not read or edited by the player (without much effort). Look int XML, some basic implentations might lack it but advanced version have binary saving (even with compression). Most of the time simply enabled by setting a flag.

2. Servers would most likely save data in a mysql or comparable database, however I can't say for sure (didn't cover that topic well).

3. again, XML is a way to go (there are other
possiblities, though. Keep in mind that .txt is just an ending and doesn't say anything about the file, the average player might be kept from editing data by simply changing the ending of Level.txt to Level.l2d or something (games can read files regardless of ending).

Share this post


Link to post
Share on other sites
I'm inclined to suggest the use of SQL for everything. Online games can persist their data in a normal SQL database server, and offline games can use something like sqlite to store their SQL database in a flat file on disk. This is quite a common practice in application development - for instance, Apple uses sqlite to persist data in their CoreData framework.

As for XML, I really can't recommend it, unless you need all the power of schemas, XSLT, and so forth. JSON and YAML are much more lightweight to parse, and a lot easier for humans to read as well...

Share this post


Link to post
Share on other sites
SQLite is the way to go in general for single user applications from my point of view. In our current framework we use a serialziation mechanism (google protocol buffers) in order to get snapshots of our current state of art. Thus it allow nice network object/states transfers from/to clients. But this requirement is due to the fact that we want our clients to be able to server distributed data without relying on external database servers. For that sole reason, we are not relying on SQLite.

Share this post


Link to post
Share on other sites
XML is nice imho for indie games because there are so many free serialization librararies out there, or in the case of C#, serialization is built into the language. Also, during development you can serialize to plain text for ease of testing and verification, then before shipping the game just change it to binary.

Share this post


Link to post
Share on other sites
If you don't want to have any external dependency, you can make a class that store a list of named arrays. Then you just get pointers to the internal arrays before modifying the content and can instantly load and save to a binary file with meta data for version compability.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!