2 replies to this topic

[slayemin]

I'm a bit confused as to the best approach to interface with a game model.

I've simplified my game model so that I interface and maintain it through a console application. I've got game objects of various types, managed by game manager classes (list wrappers which enforce business logic), and a method for interacting with the objects.

Initially, I decided to go with a "command prompt" style for interacting with the game model. In the final game, the console window would receive commands and run them against the game state model. Here's an example (commands are in bold, output is in italics):

:\>dir
factions
mages
spells
:\>cd factions
:\factions\>dir
Empty set!
:\factions\>new faction test
:\factions\>dir
test
:\factions\>cd ..
:\>new faction test2
:\>new mage tim
:\>cd mages
:\mages\>dir
tim
:\mages\>cd tim
:\mages\tim>dir
name: tim
health: 200/200
state: alive
:\mages\tim>set health 100
:\mages\tim>dir
name: tim
health: 100/200
state: alive

Etc, etc.
This is handy in that I can easily load the game state model by creating a text file which contains a list of commands to run. And, if two computers are running the same game state model, I can just send a text command through the network to keep them synchronized (but that's later).

It dawned on my recently that really what my game state model is doing is running and maintaining a database and updating its state as the game progresses. So, why am I reinventing the wheel when a real database exists (like SQL)? What I'm doing above is merely running queries to create, read and manipulate data sets. So, why not just run the game state in an actual database and avoid rewriting a full blown database architecture from scratch? And since databases already support multiple connections, multiplayer would just be a matter of connecting to the database and querying the current game state and updating the game state model on the client side. Saving a game isn't necessary since the data resides on the database as an instance, loading a game would merely consist of selecting the instance to load and then repopulating the client with the stored game state data. It would save a ton of time in terms of avoiding rewrites of code to mimic a database.
However, if I use a commercial database engine, it creates a challenge when I go to distribute the game. Either:
A) People have to install a database on their game client (SQL Express?)
B) People have to connect to a database online (which could possibly cause game performance issues due to latency)
Or, in the worst case:
C) I create my own database backend which is a part of the game state model and is embedded with the game (probably most common?)

If I go with a database style for interacting with the game state model, here are the equivalent commands (not necessarily standard query language):
create faction test;
create faction test2;
create mage tim;
select mage from mages where name = "tim";
name: tim
health: 200/200
state: alive
select faction from factions where name = "test";
name: test
members: 0
state: extinct
update mages set faction = test where name = tim;

Etc, etc.

Naturally, this kind of game state management would be overkill for games like pacman or pong, but for games with larger data sets, this seems like it'd be a good way to go. Unless, I'm totally insane and over thinking this. What are your thoughts? How are you managing your game state model?

[Krohm]

So, why am I reinventing the wheel when a real database exists (like SQL)?

Error. "Real" database systems are justified when

• There's a lot of data (Gigs, at least)
• There are a lot of users (I'd say tens, at least)
• Each user does a lot of potentially concurrent modifications.

Nobody stores (say) textures in a real RDBMS. Everybody store them in a simple image. But in line of concept we could store those pixels in a RDBMS... somehow. It would be an abomination.

It would save a ton of time in terms of avoiding rewrites of code to mimic a database.

Except most RDBMS are geared towards non-interactive applications with much more data... and much more users. Yes, they are used in gaming but not in this way as far as I can understand.

How many hundreds of megs do you need to fiddle.
How many players do you plan to support.

I use extensive scripting in my game. On profiling, gameplay takes less than 3%. I am unsure how much data it's actually there, but I'm 99% sure it's less than 512 KiB. As for the "real code", it's written in C++, takes about an hundred megs (assets included). You know C++ does not have a DB in. It's likely at least some RDBMS have C++ in them.

[slayemin]

Thanks for the reply. I realized that I was spending a lot of time managing data in lists and was looking for ways to do that better. Databases are pretty good at that, so I was seriously considering it as a better alternative to what I was doing. I think I'm insane and overthinking this and this is one of those "unproductive tangents" a project can take. I've aborted the whole effort of trying to build a scripting engine since I can just...write the raw code much faster. Man, I'm such an idiot sometimes... so frustrating. I wasted a few days going down a rabbit hole