15 replies to this topic

[Ed Mack]

Hey!

For ages I've been researching and trying out different things, and I'm at the point where I want to make a proper, polished mini-game. My aim is a small shop-sim, but for the moment I'm concerned with a few various architechture details.

I've decided I really need a good entity meta-data system, so I plan to store the following fields:

Entity, Property, Value

With this I can store all entity properties and inheritance information (and instances can just inherit from proper definitions and live in the same/a shadow database).

Is a database like SQLite suitable to store and recall this data? Is there a need to cache it in my game's data structures? Or should I go for a simplistic text-file + STL structure approach? I just need acceptable speed and little hassle.

[Kippesoep]

SQLite will do fine for this. To make it a little easier to modify and more lightweight, you may want to use a simple XML file instead, though.

I'd recommend caching in-game, yes. That's a lot easier and several orders of magnitude more efficient than generating a query-string every time, having SQLite parse it, run the query, return the data and then parsing that. Also makes default values easier.

Personally, I'd go with XML (or another simple text format).

[Ed Mack]

I think XML is overkill when a simple CSV format could be used.

What would be the most efficient way of recalling the data using STL? Should I use a map<entity name, property-value pair> type container, or another?

[Kippesoep]

The neat thing about XML in cases like this is that it enables grouping of elements, is easily human readable and very extensible (major consideration for me).

That said, if you are certain you'll stick to this format, then by all means, use CSV. That is very easy to parse (even easier if you can guarantee that any strings in there won't have commas in them).

The best way to recall? Well, if you're not storing them directly in attributes of your game objects (possibly a class definition object), then I suppose the best way would be to use a hash table/std::map. You can use strings as keys in there, which is nice. For maximum efficiency, you'd probably have to create an enum which defines a constant for each attribute and use those as an index into an array/std::vector.

Something like:

enum
{
  ACCELERATION,
  DECELERATION,
  MAXSPEED,
  SHIELDSTRENGTH,
  //total count
  NUM_PROPERTIES
};

std::vector <int> properties;
properties.resize (NUM_PROPERTIES);
properties [ACCELERATION] = ...;
...
int t = properties [ACCELERATION];

This looks nicer, of course:

std::map <std::string, int> properties;
properties ["acceleration"] = ...;
...
int t = properties ["acceleration"];

That is also more extensible, but less computationally efficient.

Edit: The above code links properties with values, obviously. You could use a simple struct with property/value pairs and link them to entity names as you suggested. Same tradeoffs apply.

[Methulah]

I would use MySQL. I like databases, they are particularly easy to use, and are almost as fast as storing it in a file, and infinatyl easier to modify.

[Kippesoep]

While databases are versatile, I think a MySQL installation for a mini-game is extreme overkill ;) Especially when using C/C++ as Ed is likely doing (because he was considering SQLite).

[Methulah]

Right, didn't read the post properly ('tis a curse, is it not?) and didn't pick up minigame thing. SQLite would probably best.

[Ed Mack]

I think for simplicity and less coding, I'll use SQLite - it's got a great reputation and awards for its codebase. I'm going to keep property names strings so this can be purely data-based (and so I don't have to export the same enums into C++, SQL and the scripting system).

Thank you for this input and feedback :)

I plan to attach scripts to everything - from the gui controlling entities to the trees, and have event -driven functions in those scripts. Stuff such as decision trees, pathfinding, planning, blackboards, messaging, and rule systems will be C++ side with a standard interface from the scripts.

At the moment I plan to use Lua since it is lightweight, well tested and has a very nice set of standard libraries. Has anyone had experience with using lots of lua scripts all in the one application (perhaps in a similar fashion?). Is it suitable for this amount of usage? I think it is, but want to make sure before I put that expectation in code.

I hope to be able to modify the behaviour of objects at runtime via the minimal gui - a bit like Visual Basic, but without Basic :D

[Nodlehs]

Ed Mack said:

At the moment I plan to use Lua since it is lightweight, well tested and has a very nice set of standard libraries. Has anyone had experience with using lots of lua scripts all in the one application (perhaps in a similar fashion?). Is it suitable for this amount of usage? I think it is, but want to make sure before I put that expectation in code.

We use Lua at the company I work for and have been extremely happy with it, and its performance. It ties in great to C/C++ and we have used it in many different applications. Just make sure you start a new lua state for each thread if you go multithreading.

[Ed Mack]

I do not plan to multithread, but thank you for the caution. It's good to hear news 'from the trenches' :)

I may post some class design questions later, depending how happy I am with my prototypes.

[Reedbeta]

Lua looks very nice. I am thinking about using it as an embedded scripting language for my projects as well. Let me know how it works for you!

[Ed Mack]

Shall do. LuaBind is an essential to take the hassle out of the api btw.

[Nodlehs]

Just for some numbers, right now we run about 1050 lua scripts every second, as well as quite a few of those are calling C functions inside of them and our bottle neck isn't Lua. I am sure we could push it a lot harder than we are with no problems.

[Ed Mack]

Woah, that's excellent. Thank you, my application will be manageable for sure.

[DownloaderKL]

How would Lua take out the hassle in using an API?

[Ed Mack]

Have you tried calling functions from the lua C interface? It's more cumbersome than needs be, and most other operations are the same. The luabind wrapper makes life sunny and happy.