Database system vs file system

This is a question that could be interpretated for several kinds of games and gameplay mechanics, and it is about what is a generally speaking better system to use for data storage of ‘items’ or objects in the world of a game?.

I’m trying to develop a Trading Card Game ( yu-gi-oh, magic, pokemon TCG, etc) for learning purposes and i wanted the game to have several hundreds of cards. Each card has:

  • Name
  • Image
  • Description
  • Uniqueness
  • Type ( there are 4+ types of cards )
  • Conditions to be played.
  • Effects ( attack/defense in the case of monsters, healing in case of magic, etc )
  • Etc

All those things are stuff that cards have in common but there are specializations of each type of card that add new rules and stuff to the cards.

In order to have for example several hundres of cards, would be better to use a file storage system like XML, JSON, etc or to use database systems? Does this apply to other game elements like inventories in RPGs, weapons, etc?

Also could these systems be implemented via blueprints or is it better to code them?.

I would use data tables in blueprints to accomplish this. It will allow you to do all of your gameplay tweaking in excel spreadsheets and then you can have a blueprint script parse the excel sheet (exported as csv). Then it’s just a matter of creating a spreadsheet with the cards on each row, and the properties each card has in the columns.

https://forums.unrealengine.com/showthread.php?12572-Driving-Gameplay-with-Data-from-Excel

Cheers,
Nick

Great, didn’t know about DataTables. So far they seem awesome and seem to allow rapid prototyping.

Really the best way is used DataTables instead SQL? What’s happend with Query SQL? If I have hundres rows and different tables, like DaylanVelez says, not is the DataTables a bummer?

Can you provide a link to more information about DataTables are best to SQL? Thanks

It really depends on what you’re trying to accomplish.

If, for example, you want to allow your players to add custom cards to the game, the easiest would probably be to use ASCII files since regular, non-tech-savvy users can open them with virtually any editor (like Notepad++) and change them. Simplest form of modding, if you will. Take a look at Starbound, that is precisely how you add new items, tiles and codexes to the game.

If, however, you have no need for that and are pretty much a one-man-army working on the project Nick Darnell’s answer over there sounds like your best bet.

But if you, for example, want to display the cards on a website it might be wisest to shift your card data to an external, cross-platform compatible third party program like MySQL. Sure, an Excel Spreadsheet would work fine for that, too, but in most cases you’ll have to write your own parser. Chances are you’ll find an SQL interface for any platform you’re using.

Plus it gets complicated if more than one person at a time attempts to alter card data on the server: at a point in time t0 two individuals check out the spreadsheet at version 1.0. At t1 person A checks in version 1.1a of the spreadsheet. At t2 person B checks in version 1.1b of the spreadsheet and all the data added to v1.1a is lost.

Summa summarum: every approach has its pros and cons and it is up to you to decide whether the pros outweigh the cons.

Excelent answer! Thanks. And speaking about performance, SQL drains more? And how much relative to use Spreadsheets? So, in final game result, what version will more faster? The version with SQL or the version with DataTables?

(speaking of the same game of course)

One thing to keep in mind as well. Write the interior of the code, i.e. that part which deals with the actual “card data” itself, in such a fashion that it’s totally insulated from the “storage method” you choose. In this fashion, you will be able to switch much faster between a “file based” system, and a “Server side” system for storage.

One way to accomplish this, is that for all the inputs, ensure that use structures, and not parameter lists into functions that you generate on the fly. Have a base structure that holds a “base card”, then another structure, that is embedded, or has a “pointer” to the specifics of the card, let the “file/database” system, construct these, then pass that into the “interior” code that actually does something with the data.

Down the road, this will save a lot of grief, as well as allow you to use both a file based system, for those cards that are particular to the player, and for “generic” cards if you will, that everyone has. Just as an example.

As a another example, this is pretty much exactly how a Compiler works, the input is totally separated from the actual code generation. The lexical analyzer portion of a compiler, totally insulates, the rest of the compiler, from the actual “file” on disk.

.

I honestly don’t know. Highly specialized third party software such as MySQL usually is also highly optimized and from my experience it’s always worth considering using it regardless of the amount of data. For an accurate response, I’d either need more knowledge about the internal workings of the software in question or a handful of benchmark tests.

Don’t quote me on the following, but in this particular case I don’t think you’ll gain any significant performance gain for either approach, depending on your method of implementation. Data is most likely to be immutable during the actual gameplay, as such it’s likely you’ll read in all the cards at the startup of the game and never do anything with the database again for the session. If you were to mutate the cards at runtime often it would be much more efficient to use MySQL since it’s IO routines are more optimized and the database file on drive is not rewritten every time a card changes. As a rule of thumb, you’ll want to avoid as many IO operations as possible as the drive is considerably slower than RAM.

MySQL excels at working with masses of data over a longer period of time from multiple clients, i.e. hundreds of thousands of cards accessed by dozens or hundreds or even thousands of clients, which you’re unlikely to be using. If I were to give an educated guess, for a standard card game made of a couple hundred cards only, the spreadsheet approach would suffice.

Also consider that MySQL requires a third party software to be running on the client or server. MySQLite would add an overhead to opening and maintaining the database, so in actuality it might be (very slightly) more efficient to use spreadsheets for this specific case.

Again, a couple of benchmark tests would either confirm or deny this.

If it’s a server, you can do SQL since you will have MySQL installed. But if it’s a single player game? DataTables are native in UE4, they will work anywhere.