Keep game rules in Database?

If you're going with a database, go with the database. It'll keep things simpler, easier to track, easier to backup, easier to implement/test.

Yeh, but I find it very tedious to have all the races and classes defined in the database... for example.














Now, see... I can define the different stat requirements as it goes, and it's very easy to differ the number of requirements etc...

Now if I go with a database, I would prolly need to have a single template which ALL classes need to define... no matter if the class really has a minimum stat on intelligence or strength, right?

Hope you understand what I mean...

In any case, if you end up deciding to put things in a file, you have to decide wether to use XML or not. Your current format seems to be close to XML, but isn't quite, which will cause problems later on.

So my advice is, if you go with files, either go with a home brewn format that actually fits your needs or use XML and do it right (close all your tags, read up on w3schools).

If you go with a database though, it doesn't mean you have to put in redundant data. For example, a database representation of the things you stated might look like this:

TABLES:  Race    ID: Integer    Name: String  MinStat    RaceID: Key(Race.ID)    Type: Enum(Intelligence, Strength, Agility)    Value: IntegerENTRIES:  Race(1, "Orc")  MinStat(1, Intelligence, 3)  MinStat(1, Strength, 12)  Race(2, "Elf")  MinStat(2, Agility, 15)

Indeed, using ID keys allows for tying arbitrary attribute tables to the main one.

Or y'know you could just store the config/xml in the database [grin]

Seriously, don't even joke about that! ;-)

Actually isnt what you have specified NOT 'rules' but attribute data that acts as data for the rules. 'Rules' usually are madde out of logic and equations which use the attributes as coefficients and mode switches.

You might be able to have 'synthetic' values/functions which use a databases 'business logic' via stored procedures -- which would be closer to 'rules'.

As for attributes, yes you can store game object attributes in a database and make use of all the existing DB tools to streamline your utility development.

Be aware though that accessing the data in realtime from a Database usually is quite slow and most often is best used as persistant storage with the data being loaded initially in-memory for the duration of runtime use. Slow access data like inventory/bank storage can be rolled in and out of memory if the manual operation by the player is expected NOT to be lightning quick (like game combat needs to be).

Some database systems though, like Mnesia for Erlang, can reside in memory which is quite fast.

I think either solution would be fine; this information is needed rarely (when someone makes a new character, or perhaps when they level up) and will never change, so disk access times/speeds won't be an issue. So use whichever storage location you find most convenient.

I second Joakim's point though, if you're going to use XML then do it right :).

Ok, thank you everyone!

I think I'll put everything in the database :P seems like very convenient for backups...

Most of this data is static, so it will only be loaded once during server startup, then character status data will be updated frequently during specific actions in game, but mostly will be kept in server memory.

Laters!

Quote:

Original post by bilsa Ok, thank you everyone! I think I'll put everything in the database :P seems like very convenient for backups... Most of this data is static, so it will only be loaded once during server startup, then character status data will be updated frequently during specific actions in game, but mostly will be kept in server memory. Laters!

Also look into if you want a recovery synchronization mechanism that takes a snapshot of the data periodicly so that game progress wont be lost. A complete snapshot of all the data to be copied and saved so a restore can be done if the server aborts. Doing its frequently at runtime without lagging out the players would be a goal.

Ok, guys... so I went with a "complete database sollution" where I keep everything in the database, for example:

-------------------------------------

TABLE: GameRuleSets
-------------------
RuleSetID
Description
AvatarCreationRuleID

TABLE: AvatarCreationRules
--------------------------
AvatarCreationRuleID
MinAvatarNameLength
MaxAvatarNameLength
...

TABLE: NPCTemplates
-----------
NpcTemplateID
Name
Race
Class
HP
...


-------------------------------------

Now I have come to the point where I added scripts for defining specific game rule logic and AI scripts, and I'm thinking if I didn't make a misstake and should have gone completely with the scripts approach instead of Databases for storing static game data...

For example, I'm using LUA for scripts, for example a NPC script:

--------------------------------------------------

MyCoolNPC
---------

[This part could be optional instead of having it stored in the database]

Name = "MyCoolName"
Race = MyRace
Class = MyClass

[/end of optional data]

function OnAttack(attacker)
...
end

function OnSpeakTo(player)
...
end

--------------------------------------------------

You see where I'm going with this, why should I store the static game data into a Database, when I in fact probabilly will want to have scripts for the characters anyway, so wouldn't it be more practical to store the static data in the scripts as well?

And then I would only store "Instance" data in the database, that means I would only store data about objects that are "alive"/existing in the world in the database.

Hope someone can clarify this for me, why should I use a database for that kind of data??

You're still confusing the ideas of game data and game logic.

You're trying to store your "rules" in the database. This probably isn't what you really want. Your "rules" are embodied in the code you write. They are the functions.

You've got pieces of data like "minimum name length" stored in the database. The length of a character's name is a rule. You should have a function that handles that, like:

bool IsNameLengthValid(string name);

If the valid length of a character's name is really something that's going to change often, then go ahead and put that logic into a script and call that. Otherwise just hardcode that number into the function.


Think about more complicated rules, like combat mechanics. You're going to have a really hard time storing something like that in a database, unless you use other database mechanics to embody those rules (such as stored procedures, like wodinoneeye mentioned).

Some games do go that route. Their game code is just a wrapper around the database. All their logic is in stored procedures and all their data is stored in the database. If you do it that way, you're going to end up making a ton of calls to the database, which is going to impact performance.


Personally, I'd go with a hybrid approach. I'd put game-specific DATA into files or scripts, and save game STATE data to the database. There's a difference between the data needed to CREATE an orc and the data that needs to be saved to disk once one has been created.

Yeh, exactly penance... that is exactly what I was thinking! But then after reading the replies I got, I thought I was supposed to put everything in the database, except for scripts :S

So basically I put all INSTANCE data in the database, for example when a player gets hit - update hp - when a new item is created - create an item instance - when someone levels up - update their lvl data, etc...

And as about the rules you are telling me to keep in hardcoded functions, I was thinking to keep the simplier of the rules in LUA scripts, for example the combat script could be:

function OnPlayerTriesHitMonster(player, monster)
if(player.hit_probability > monster.defense)
OnDealDamage(player, monster)
end

That was just an example, to let the administrator of the server easily change some game mechanics like that, especially the damage dealing functions would be of value and the AI functions...

Does that sound better?

That sounds more reasonable.

The most important thing to remember is that you should do what works for you. You're the one that has to deal with whatever system you choose to use, so pick the one that makes the most sense and fits your work style the best.

If it turns out that it performs poorly, or you run into problems, you can always go back and use something else. If you learn something new along the way, then it wasn't a waste of time.

If you're using C++, and if you want to play with XML, I highly recommend TinyXML ( http://www.grinninglizard.com/tinyxml/ ). It builds right into your program using only a few extra source files, and it basically builds a set of C++ objects from your loaded XML file. It can also save XML back to disk given a properly-built hierarchy of C++ objects. You can then drill into your object tree and pull out the values you want.

I guess the biggest advantage is that it's small and simple. If your XML gets super big or you need more than just saving/loading (like validation) you'll have to find a different library.