Re: [dev] Suckless design in Games

On Wed, Aug 11, 2010 at 1:09 AM, Alex Hutton <highspeeddub_AT_gmail.com> wrote:
> An idea I had the other day, and this is for dealing with data
> compartmentation in games, was to write a game in C and use sqlite for
> all the data. I've never used sqlite so I don't know how the
> performance would go, but it seems like a good idea to store all the
> data in a relational database as it makes it less likely that the data
> structures would have to be refactored during development and it
> allows me to avoid having to use 'objects'.

I don't know what granularity of data you're thinking of storing in
the database. If it's very fine grained data then I'd expect you're
going to hit concurrent writing lock-scaling problems (see, eg

http://www.sqlite.org/faq.html#q5

) Part of the reason why systems like git or hg don't use a standard
database for their backends is that a general purpose database
generally has limited means for expressing which subsets of the data
are independent, and hence what the minimal locking is for writers
(and reading whilst something may be writing), whereas, eg, the git
backend knows due to the data struture and code design that it can do
_almost_ everything without locking. (That's part of why it scales to
things like Ingo Molnar's automated "Merge every single patch in every
single remotely relevant patch queue into one mammoth kernel and try
and boot it for regression testing".)

One of the big advantages of "conceptual objects" (whether they're
actual language objects) is that since they can have different
implementations they can have different access semantics. As I
mentioned in a different thread, if you look at a lot of "praised" old
code it's perfectly well designed for the realities of computer
architecture at the time it was written, but nowadays a lot of it is
either "middlingly effectively written" or sometimes "PLEASE, PLEASE
don't write code that way" examples. Just because new innovations
aren't a magic bullet and are often overhyped doesn't meant they're
worthless. Personally, I think it's a shame that there's no widespread
language that has compiler/run-time support for "immutable once
set-up" variables in this multicore age. (You can have a design in
which a variable your design treats as immutable in C, but there's no
inherent support, eg, for detecting violations or cloning copies for
core's with a different cache, etc.)

-- 
cheers, dave tweed__________________________
computer vision reasearcher: david.tweed_AT_gmail.com
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot