7
\$\begingroup\$

Recently I was researching several entity systems and obviously I came across T=Machine's fantastic articles on the subject. In Part 5 of the series the author uses a relational schema to explain how an entity system is built and works. Since reading this, I have been wondering whether or not actually using a compact SQL library would be fast enough for real-time usage in video games.

Performance seems to be the main issue with a full blown SQL database for management of all entities and components. However, as mentioned in T=Machine's post, basically all access to data inside the SQLDB is done sequentlially by each system over each component. Additionally, using a library like SQLite, one could easily improve performance by storing the entity data exclusively in RAM to increase access speeds.

Disregarding possible performance issues, using a SQL database, in my opinion, would allow for a very intuitive implementation of entity systems and bring a long certain other benefits like easy de/serialization of game states and consistency checks like the uniqueness of entity IDs.

Edit for clarification:

The main question was whether using a SQL database for the actual entity management (not just storing the game state on the disk) in a real-time game would still yield a framerate appropriate for a game or even if someone is aware of projects that demonstrate SQL in a video game.

\$\endgroup\$
9
  • \$\begingroup\$ Sounds like you're looking for a discussion. I don't see an actual question here. Whether it's "fast enough" depends on the design, the scale of the system and what the definition of "fast enough" is. Can you elaborate more on what your actual question is? If your question is if it is fast enough, your question is likely too broad. \$\endgroup\$
    – House
    Oct 18, 2012 at 13:58
  • 1
    \$\begingroup\$ @Byte56, You're right the "question" was not really clear. I edited the post accordingly. \$\endgroup\$
    – Marc Müller
    Oct 18, 2012 at 14:14
  • 2
    \$\begingroup\$ Oh, I see. That is indeed a very good idea, I would love to see it implemented somehow. I can't answer your question regarding performance, though, I'm sorry. \$\endgroup\$
    – Asakeron
    Oct 18, 2012 at 14:49
  • 3
    \$\begingroup\$ AI War actually uses nosql (or maybe SQLite) to manage 10,000s of units, and has some pretty deep AI stacked on top of it. There are definitely games that use sql for managing entities. I will turn this into an answer once I have done more research (although, someone else is free to beat me to the punch). \$\endgroup\$
    – kurtzbot
    Oct 18, 2012 at 18:15
  • 1
    \$\begingroup\$ The rephrased version of this seems to be effectively almost identical to another question asked today: gamedev.stackexchange.com/questions/40215/… \$\endgroup\$
    – Kylotan
    Oct 18, 2012 at 19:58

3 Answers 3

Reset to default
2
\$\begingroup\$

In my experience using a relational database for these situations is fairly clumsy. It can be fast, in very simple cases, but translating object oriented entities into relational tables is itself a burden. You might look into some of the newer object database solutions like VelocityDB. But don't take my word for it - do some testing to see what works best for you.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ Thanks for the answer. Yes, translating objects into a relational format would be painful, but the entity-system I am referencing does not use objects at all but already formulates all data in a relational scheme. I'm currently implementing a basic implementation to benchmark the speed of SQLite. \$\endgroup\$
    – Marc Müller
    Oct 19, 2012 at 10:19
1
\$\begingroup\$

In most cases the objects/entities in a game change over time, sometimes very quickly for purposes of animation, sometimes less often. I think it is obvious that any object that is changed several timer per second is probably not a good candidate to be managed by a database. So anything that requires 1 or more SQL queries for each frame is right out.

This does not mean that databases should not be used, but in the past I have used them to store objects not visible/used at the moment. Database, especially SQLite, are very fast if you need to select a group of objects, and then load them all at once. So, what I ended up doing is maintain the objects in memory (no SQL) while they are being actively used, and as they go out of scope they get saved to DB, and more objects that become active loaded.

Another situation where I have used DB heavily is when creating a multiplayer server, especially where transactions are required for 'crafting' new objects and trading them between players. You can see how in such situations it is critical that the transactions are serialized and that no loss of data is allowed.

If I had to sum up quickly, databases are great for objects that do not change very often (many times per second), but I would not dare use them for anything that needs to store changes due to animation.

\$\endgroup\$
1
\$\begingroup\$

You could combine SQL persistence with some ideas described here: Best practices for periodically saving game state to disk

Essentially, you don't want to use SQL server to load/store your entities real-time on the fly. But if you load/update/insert the entities in a background thread through some memory buffer, it could work just fine. I myself am trying to implement my own game server that way.

Also I suggest this article: Evolve Your Hierarchy, especially the "IMPLEMENTATION DETAILS" part - it explains some issues you might face when implementing entity systems and what compromises could be taken to improve performance.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .