_25_11_2024_15_40_33.jpg)
_25_11_2024_15_40_55.jpg)
_25_11_2024_15_43_24.jpg)
|
Socoder -> Blitz -> Blitz and SQLlite? |
|
| Sat, 30 Jan 2010, 10:42 | |
|
LostUser |
I was wondering, rather than using .dat files, or memory (which would only work the time you use/play the game), is it possible to use SQLlite? I'm currently working on Django and for production it uses SQLlite and I think the iphone uses it too. Does anyone have any thoughts on this, can it work without a webserver; or would the download so big/large that it would really be useless. Also, one has to think about where save games go, and what happens when you start a new game -- does it delete existing data every time you start a new game, etc. |
| Sat, 30 Jan 2010, 19:59 | |
Stealth
|
It depends how much data you're working with. If you're just storing 10 - 20 setting configs then no, it's overkill. But if you're writing a spreadsheet program then I can see that being justified.
-=-=- Quit posting and try Google. 
|
| Sat, 30 Jan 2010, 20:20 | |
|
mindstorm8191 |
...Umm, I honestly have no idea how development on an iphone would work. But on PCs, for standard games a database might not be the best route to go. I would recommend not dismissing .dat files so quickly. See, any data your program makes use of must be loaded into memory anyways. A database must do the same thing, only in a more behind-the-scenes approach. But at the same time, this kinda decision depends on what goals you are trying to fulfill. If you're after ease of use, .dat files are simple to process, can contain any kind of data, any amount of data you want, and a well-built file loader can pull it all into memory for you. If you wanna save such files too, a well-built save routine does the same. But at the same time, perhaps a database would be just about as easily-accessible as a .dat file. That is, only if all your important contents can fit into a database design. See, databases are ideal for websites because a web page needs to be a quick in-out task. Instead of 'picking up' a large data file and working your way through all the data to get what you need, a database allows you to pick what data you want to retrieve and grabs it for you, working as a resident utility. But a quick grab-n-go approach isn't ideal for a PC game, since the program stays around for a while. It has time to load everything into memory, and play with it as much as needed. If you're after a more managed approach to getting everything loaded, i.e. not have everything loaded at once, you will have to resort to more sophisticated methods, depending on the most reasonable solution to boost speed. So, what kind of goals do you have in mind, here? -=-=- Vesuvius web game
|
| Sun, 31 Jan 2010, 01:49 | |
JL235
|
I think it really depends on the game. There are some games where using a DB can make a lot of sense. I'm thinking more about big management games like Civilization or the campaign sections in Total War. To save you just dump the whole DB to disk. End of. Also there is no reason why the DB shouldn't be in memory whilst the game is running. The reason high-end servers have tonnes of ram is precisely to avoid having to do disk IO. Infact I'd say the game would be pretty much unplayable if it was performing disk IO every time I moved the player (would cause lots of freezing). |
| Sun, 31 Jan 2010, 05:18 | |
HoboBen
|
The SQLlite download is about 1MB (keyword "lite"!). Firefox uses it for bookmarks, history, etc. If a full database is overkill, however, why not save data to a structured binary file? For example, if each entry is say 200 bytes, you know that to skip to record 5 you seek to the ((5-1) * 200)th byte. That is in essence a really simple database. However if you're loading everything into memory anyway, it doesn't matter so much how you save or load things - you would load the file contents into your own data structures in code. -=-=- blog | work | code | more code |
| Mon, 01 Feb 2010, 03:54 | |
|
LostUser |
OK, that makes sense. Thanks for your help!
|
|
|
| |||
|
| ||||