And how about database binding?

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • And how about database binding?

      I was thinking that binding the game data in a MySQL database back end would be interesting. You could keep track of all current game state information in real-time - and still allow a copy of the whole thing to be made (by the MySQL server) as a "save game file."

      Am I making any sense? Or am I completely off the deep end?

      It would be a small conceptual step from here to supporting an MMO style game (probably not really massive, but you could have a very large number of people tromping around this way).

      I don't know - just thinking out loud. I personally hate database programming, but it has its uses....
      "Your job is not to die for your country. Your job is to make some other poor sod die for his."
    • RE: And how about database binding?

      I've pondered your query (hah get it)... anyway i've had the same idea but database access is slow and built for large amounts of data rather than instant access. From what i've seen MMOs use data bases for simple retrieval of data during load times like user stats they just load into memory or monster specs that get loaded on map changes.

      Overall, it's not really a great idea but i'm sure the limits could be pushed slightly. Personally i would just design a file format to meet specs rather than using existing database formats because they are built for massive amounts of data and only occasional access. If you get a good design then i would love to help out on it. (I'm really bored and i've been meaning to get some expierence working with databases)
      .Code
      push you ; haha!

      The post was edited 1 time, last by DarkPenguin ().

    • I'm not so sure on the speed issue at this point. I've worked with database access through an internet connection (ASP.NET and MS SQL Server) with small data transactions (phone number searches) and had lightning reaction times with 1, 20 and 50 number lists searched against a database of 500,000 numbers from 10 feet away and from 8000 miles away.

      Neverwinter Nights has severe database access lag times. I'm not sure why this is, but perhaps it's because they're accessing Paradox tables manually. My intention is to literally run a SQL server (MySQL is free, is all) and let it handle transactions through an ODBC driver. That way most queries should pop back pretty fast since the DB server is running concurrently with but independently from the game (the game doesn't have to manage it and it's in its own apartment so from the game's perspective it should be pretty fast). DB accesses would probably have to tag a callback to indicate when they were done.

      See gamasutra.com/resource_guide/20030916/lee_01.shtml for some insights, and there are a few other articles on Gamasutra as well.
      "Your job is not to die for your country. Your job is to make some other poor sod die for his."
    • Real time access using a SQL database is out of the question as far as i know. I would bottle neck all access to a database in a load screen and just dump all the stuff you need into memory. I think even small transactions would take a 500 miliseconds or even a second which increases porpotonal to the number of simulatnious queries(the reason MMOs can be slow to load some time).

      I may be wrong. I'm not a Database admin. I'm just speaking from what expierence i have.
      .Code
      push you ; haha!
    • 1) You can't use mySQL (or other similarly licensed Databases) in client programs, without those programs being open-source. I don't think this applies to you, but it surprised me.

      2) PostgresQL seems more worthwhile for game development. You can actually have it spit results back as custom C structures, which means (I think/hope) you would eliminate most of the text precoessing normally associated with using a database. This should help speed things up. (NOTE: I'm still developing with mySQL, and discovered PostgresQL only recently)

      3) Databases are meant to be reliable first, powerful second, and fast last. That really doesn't coincide immediately with games. Still, you gain an easy to use, and ready made mass data storage system, and you can probably strike a very powerful balance.

      That's just my opinion, though.
      -Larrik Jaerico

      www.LarrikJ.com
    • Well, have a thread that handles DB access so it doesn't bite your main loop. If you lose the last 3 seconds of your player's data, it's probably not as bad as losing the last week of said data. Point being, send the transaction and carry on, don't wait for it to return success or failure so it doesn't hang up your main loop. Loading resources from the DB (or other data, for that matter) could work through some sort of caching or streaming system on a callback as well.

      Anyway, check out that article. They use a DB backend for everything! And most "shards" or whatever they call their world instances can support many thousand players at once. I just think it would be good for saving state data for up to ~500 players (Think Uber Neverwinter persistent worlds).

      Interesting that MySQL is so snotty. I guess I'll have to look into PostgreSQL too! I thought MySQL had a "commercial" version available though.... Anyway, free is good.
      "Your job is not to die for your country. Your job is to make some other poor sod die for his."

      The post was edited 1 time, last by Nebuchadnezzar ().

    • They do indeed have a commercial version. But if you think about it, using a database in a client program is ridiculous. You'd have to actually install mysql on the client machine, configure it for your game, and then use it. Only Access databases avoid that crap.

      The thread thing is a good idea. If you designed your internal structure to track its own changes, the DB thread could (slowly) constantly update the DB with the new information. Although, my game project doesn't require real time DB access, so that solution is a bit overkill for me.
      -Larrik Jaerico

      www.LarrikJ.com
    • I don't know about "ridiculous," after all, Neverwinter Nights utilizes a (very slow implementation of a) Paradox format database system to allow persistence between modules. The ridiculous part is the part you mention - installing and configuring mysql. However, you could more readily bind postgresql (assuming it's open source) directly, or by sockets, or whatever, so that it more directly interacts with and is more a direct part of the game. Additionally, you could make some access time optimizations to make it better suit it's new role as a resource storage system.

      My idea for using it as both resource storage and game-state memory is a bit extreme - NWN only uses it to keep certain critical data from the plot (like whether you've spoken to a certain NPC, whether you've completed certain tasks, who's ticked off at you, etc). I was mostly thinking out loud, but if it's possible to do it and keep it reasonably fast it seems that it wouldn't be too horrible a thing to do. After all, everyone I know hates to have to load a game from an hour ago because they forgot to save at a critical point. This would practically eliminate that problem (and you could of course still allow manual saves that would be separate from the autosave - a must in my book actually).

      Anyway, mostly just food for thought, and for anyone thinking even a little about any type of MMO.

      Rich
      "Your job is not to die for your country. Your job is to make some other poor sod die for his."
    • I don't really think that you should be using a database for normal saved games in a normal single player game, or even client program (and autosaving before a load and every 15 minutes or so like KOTOR is pretty effective...when it doesn't crash). It's really not hard to write your most important data to a file and read it back in, and its a hell of a lot fast than using the DB for that. For an MMO, things are different because users won't accept a server crash as a reason they need to re-do the last bit of time of their game.

      Server-side it makes more sense, since you often need other player's data, its more reliable, and any delays shouldn't freeze a client's computer (in theory).

      Just my two cents. When it comes right down to it, if it works go for it.
      -Larrik Jaerico

      www.LarrikJ.com
    • With todays current MMO's, its only saving user data, not worlds state . All the games I have played have no real world state. I'm sure players would like to see this change someday though.

      Don't crucify me if I'm wrong, I'm only on chapter 10 and I've only written single player games before I got this book, but the programming for a MMO seems to me like it would have some major changes in architecture from a simple multiplayer game. Instead of having one system being a server and a client, you have multiple multiple dedicated servers. Several login servers, several servers that are dedicated to a single zone for a single game shard/server.

      So, what I guess what I'm saying is that doing the database binding would be good practice, but what you end up with wouldn't probably be that close to what would be used in a MMO.

      <shrug> just my opinion </shrug>
    • I know that they usually run several login servers, but I don't think that they span servers with a shard. In other words, I think that a single shard is on a single server. Now, perhaps that "single" server is a Beowolf cluster....

      I'm still not convinced that DB ops are that horribly slow. Like I said, I've played with it before and shooting large numbers of queries against fairly large tables was very fast. Then again, it could have been that the sets were composed of very small data (phone numbers). I'm gonna run some benchmarks....
      "Your job is not to die for your country. Your job is to make some other poor sod die for his."
    • There's good reason to use databases in MMOs - because they're really good at keeping a consistent data image with thousands of simultaneous updates, have backup/restore tools, and can be accessed with third party tools like Excel.

      Using them in games - I've often considered using databases in production - so that changes to data can be tracked, but I'm no so sure that using them in the installed game is a good idea because of some speed concerns but most especially the additional software to install.
      Mr.Mike
      Author, Programmer, Brewer, Patriot
    • If anything, the effort would be better spent on writing a file/resource access system that could seamlessly switch between files, DB queries, network transfer, etc. This way, you could develop your game using the database as a backend allowing you to tweak and fiddle with values in real time, then finalise it into a custom flat file for use in the final production. Using a specific file system interface should allow you to do this, especially if your actors and data structures all have 'serialise' methods. I belive they did something like this for Age of Empires.
    • Interesting compromise - DB for development, then switch to flat file for production. Perhaps allow real-time swapping of some resources (scripts for instance) and data (combat values perhaps) even in flat mode....

      If we pack our resources, then in flat-file dev mode we'd want to be able to load from an unpacked directory instead of the packed resource file I guess. Who'd want to refresh a monolithic zip file just to update a single script? Anyway, this would work well for an editor as well as testing.

      I have been considering Torque's approach to editing - right from within the game. I think I'd take it a step further and add script editors, data tools and other goodies.
      "Your job is not to die for your country. Your job is to make some other poor sod die for his."