Sign in to follow this  

Game Data, Data Persistance?

This topic is 3846 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Okay, I keep going back and forth on this one and am looking for some help. First I will give a very brief explaination of the game This is an online multiplayer game (not massive... in fact I don't intend to distribute it beyond my friends, and possibly their friends.) You have 5 to 20 players in a single campaign. A campaign may last as long as the players wish. Each campaign has a moderator.. Each player has one or more squads, the squads have 4 to 16 mercenaries. The actual gameplay plays like a turn based strategy wargame, where the squads face off against one another. You can have up to 4 players in any one skirmish. During a campaign, the players can challenge other players, but also have required games. The important thing here is the Squads persist, and the mercenaries persist. So if your mercenary is wounded, or gains a skill, or buys a weapon this all persists. Very much RPG like. Hopefully that was enough of an explaination... there is alot more to the game design.. but that is not what this post is about. Onto my delima. Data Persistance is proving to be a tricky beast for me. I keep going back and forth on the datastorage mechanism as well as the persistance layer. I spent alot of cycles and time wasted on using non relational db persistant mechanisms and I keep coming back to a database persistance model. So this iteration I try a Db persistance model (again). First I try to create entity mapped objects.. this is all well and good in theory. I can autogenerate my DAL, but the objects are cumbersome to use during the actual game. Instead of Mercanery.Weapons, I have Mercenary.MercWeapons.Weapon (since the Rel is many to many). This doesn't seem so bad... until you start looking using more complex objects. Squad.Mercs[0].Weapons.DamageType becomes Squad.MercSquadXref.Merc[0].MercWeaponXref.Weapon.WeaponDamageType.DamageType So I add a layer on top of this Entity mapped model that I will use to translate my data objects to game objects. This will work, but to finish the layer is alot of work... I don't mind doing the work.. but I have flipped my opinion on what is good a number of times so I am hesitant to commit. Of course, since I have a Database, I start to put my rules into the database... then I start getting into the more complex rules... so I deem them suitible to be put into the code... so half my rules are in the DB, then other half are hard coded... not good. So I decide to put NO rules into the DB.. and only use the db as a storage mechanism for persisting between game state (Is this a bad idea?). If I put no rules, then I need to do some sort of translation from DB state to in game rules. This should be fine since I have my translation layer... but I am kinda falling down now... I guess I am not looking for a specific answer as maybee some thoughts. Some links to an article or two dealing with state persistance and Data Object to Game Object Mapping would be fantastic. Just looking for a lil help. Thanks Tony

Share this post


Link to post
Share on other sites
Generally all game logic (the rules) are implemented in code. All persistent game data should be stored in a database of some kind: your own flat file system, an actual relational database, whatever makes sense for your dataset.

You don't need a "translation layer" to go from data to runtime. Your code should execute logic based on input from data.

Example data:

Hitpoints: 100
Sword: Earthcrusher 1d12 +6 dmg
Armor: 300 pts

Example game logic:

Hit opponent for (roll your dice based on the Sword data field): 10dmg
Since he has [300] armor that mitigates 10% of damage: 9dmg total now
Apply the mitigated damage: [1000] - 9 = 991health

Your data is just the value of variables in your simulation: how much damage, what texture to use, what animation to use, etc.

-me

Share this post


Link to post
Share on other sites
All you're really looking for is save/load functionality. Whether it does it to a database or a file is just an implementation detail. If you then break it down into saving/loading individual parts of the character, it becomes efficient enough to keep the persistent data always in sync with the in-game data.

I don't understand which 'rules' you might want in the database. Could you elaborate somewhat? Are you talking about stored procedures? Referential integrity? Triggers? Views? I really think it would work best just by using the database as storage, nothing more. Even if you use some sort of entity-relational mapping system to automatically persist the data, you still have no need to put any rules or logic into the database.

What language and database are you using?

Share this post


Link to post
Share on other sites
Language C#, DB is Sql Server right now. I have templates to do the OR mapping with Oracle to C# classes but.... :) I am not buying an Oracle Liscenses :).

I could easily go to MySql, or hell... the since I am not gearing this for enterprise Access could even work . So honestly the DB itself doesn't matter.

I like C# cause the toolset gears very well for rapid application design, and since they stole alot of the language concepts from Java it is very elegant in feel.

Onto the specific rules question.

I was trying to avoid specifics in my first post because I didn't want to post a 5 page outline :). I will get a little deeper here though since It looks like I was too vague.

First off there are Squad Management rules. As in, this Mercenary has access to these specific skills, abilities, weapons. This faction has access to these types of classes for its mercenaries. All this is done via RI, so I am good here. These rules actually do not persist into the game. They are handled during Squad management (between games).

The second aspect, the one I am not quite sure on the design , deals with the in game rules.

There is no retrieving data from the DB during the game (the server will update the DB with game stats... but), we only pull once at the start of the game.

You log into the server, pass your credentials. It authenticates you, then queires the DB and gives you access to your squads. This is where the persisted data is pulled. It is loaded in all clients for quick access and UI rendering, but the master is loaded in the server game simulation.

Now onto my question :).

Here are some examples of rules that get Fuzzy.
Lets say you want to use your Pilot Skill.. Pilot skill is an Intelligence, and an Agility Based skill. There is RI in the database... so I could concievably (during the initial lookup), build it so the Skill Class has a collection of Stats. These would be references to the mercanries stats.... so when the skill decides how successful its skill check is... it loops through its list of stats.. and generates its total value... then rolls against that.

Okay that is simple... sounds nice. Since Stat is its own object, this works. The DAL objects actually matches the Game Object structure very nicely.

Then I move onto something a lil less Cookie cutter. Abilities. Lets say you leveled one of your mercs, and between games he took a new ability Called Barrage.

Barrage: If the unit has a machine gun, or SMG equiped, he can fire at up to 5 targets in a 10 yard range. Each hit deals 50% of its normal damage.(this is from memory, the actual rule is much better written).

Okay... so in the DB you have a Mercenary Entity, a MercAbilityXref and an Ability.

The DAL objects Looks like So
Squad[X].Mercenary[Y].MercAbilityList[Z].Ability

But the game object is much different. Because of the nature of abilities, the rules are pretty specifc to each ability. I cannot define in the DB all the different potential mechanics of what all abilities can do, and agorythmically process them. I actually tried to create a rules engine to do this, but I have over 100 different abiilties that do anything from giving you +2 Strength, to allow you to Restore moral of all your surrouding mercs, to giving a merc a 50% not to die (1 time per battle) when someone deals a killing blow them. The task quickly became unmanagable.. and considering how easy it would be to implement the rules in code... I backed out my DB implementation and flattened my Abilities in the database to simply a human readable definition of the ability, and of course its relationship to other data entities.

In the game, the object structure looks pretty much like this. I have a base class called Ability. Ability is abstract. It has is basic behavior and interface for the game simulation accessing the Ability. The acutal meat of the code is written in the subclass. The subclass is literally a class of Type Barrage. So Barrage IsA Ability.

Now, when I load the abilities... do I just have each DB entity have a token to determine which ability to add to the mercenay, or do I actually store type information in the DB that I can use to reflectively instanciate the class

either

Merc.Abilities.Add( typeof(Squad[X].Mercenary[Y].MercAbilityList[Z].Ability.ClassType).InvokeConstructor() )

or

if (Squad[X].Mercenary[Y].MercAbilityList[Z].Ability.Token=="Barrage") Merc.Abilities.Add(new Barrage())


---------------------
At this point, I revisit skills. Since Abilities are not dependent on Data.. why are skills? Is it acceptable to have the rules for defining the extent of skills in the DB, but abilities outside the DB?

You could argue weapons have stats.. and they are defined in the DB... so those are rules too, but the difference is Skills have their object relationships specifically defined by the RI... whereas the Weapons simply have attributes in the DB that map to object relationships (weapons to stats).

Then I start thinking about Types, should Barrage really be its own class... or should it be an Ability and I use some sort of code injection model to give it it's behavior. Then I start thinking... Hmmm I could add the Code at a plug in model... fire up a second app domain... load the code from some source and ..

Then my head starts to spin, I colapse on the floor and start to cry. It feels soooooo dirty to me.

I keep going in circles... and coming back to the same thoughts. It is very frustrating... I wish there was just a book "Persistant Data Design and Integration with Game Engines".

[Edited by - tbuczek on June 1, 2007 11:22:16 AM]

Share this post


Link to post
Share on other sites

This topic is 3846 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this