To add some thoughts to Peter's discussion...
In game design speed is definitely of the utmost importance since a
visual game is basically a UI that is time-sensitive (unlike nearly any
other type of software). It's usual to implement some slow data
mechanism, typically an internet service DB for things like profile and
history, then an internet comms module (multiplayer etc.), normal SQLite
style DB for local data and on top of that a quick-lookup cache DB for
anything that the UI will need rapidly.
The reason the cache needs to exist is that DB's are slow in game terms.
They spend their time and 50% of their code to ensure your transaction
is SAFE and ACCURATE rather than Quick (which is a MUST for any normal
application, but we really don't care about much in games). A lookup
list or pointer dictionary is a far better way to access your speedy
info - but not the best way to access ALL your info, so the best system
usually turns out to be some hybrid setup.
Sadly there is no off-the-shelf guaranteed best hybridization (that I
know of), you will have to use the best way that is memory and space
efficient, and where that falls short in retrieving timing, cache the
items that are needed quicker. It's a process. We usually start out with
a good DB engine (SQLite always in our case) and a good caching engine
(which we route through the same dispatcher so that development of the
downstream parts are oblivious and unaffected by how the data arrives),
and then move things over between these systems as needed.
One accidental side-effect of using sqlite as much as possible is that
over the last ~15 years games/apps using sqlite have gotten faster by no
effort of ours, but by the mere virtue of sqlite code itself doubling in
speed every 10 years or so. That's an amazing benefit.
On 2018/01/18 2:41 AM, petern wrote:
FYI. 2D/3D game usability is extremely sensitive to response time. A stock
in-memory SQLite database with plenty of memory is still too slow for
tracking the state of an interactive graphical game especially on portable
grade cpus. Any practical realtime video game using SQLite is probably
doing so only to save and restore the game board between games. The
actual game time logic and player movements are entirely coordinated by a
custom engine which interfaces directly between highly optimized in-memory
data structures and the graphics library. The equivalent loop in SQLite
would be a statement that has already been prepared and is receiving rows
from the database without interruption for the entire game duration.
Without heavy rework of the whole database concept, that simply can't work
because a statement's results are isolated from subsequent model changes
while result rows are being read. Even a cursory look into production
quality video game development will tell you that a database is the wrong
technology to base a video game engine on.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
