Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am currently creating a browser based game, and was wondering what was the standard approach in making diverse conditions and status bonuses database wise. Currently considering two cases.

  • Event Conditions
    1. Needs min 1000 gold
    2. Needs min Lv 10
    3. Needs certain item.
    4. Needs fulfillment of another event
  • Status Bonus
    1. Reduces damage by 20%
    2. +100 attack points
    3. Deflects certain type of attack

I wish to be able to continually change these parameters during the process of production and operation, so having them hard-coded isn't the best way.

All I could come up with are the following two methods.

Method 1 Create a table that contains each conditions with needed attributes

Have a model named conditions with all the attributes it would need to set them

   condition_type (level, money_min, money_max item, event_aquired)

Method 2 write it in a DSL form that could be interpreted later in the code

Perhaps something like yaml, have a text area in the setting form and have the code interpret it.

  condition_type :level
    min_level: 10
  condition_type :item
    item_id: 2

At current Method 2 looks to be more practical and flexible for future changes, trade off being that all the flex must be done on the code side.

Not to sure how this is supposed to be done, is it supposed to be hard coded? separate config file? Any help would be appreciated.


For additional info, it will be implemented with Ruby on Rails

share|improve this question

You won't be able to store the conditions (logic-wise) in the database (unless you decide to store scripting code directly in the database). Instead you could establish a construction where each condition and bonus is associated with a unique key. You can then in turn store these keys in the database.

For example to describe the event conditions required to unlock status bonus 1 you would have tables resembling the following:

 StatusID StatusBonusKey ParameterN
   1     "reduceDamage"      20       

[Event Conditions Table]
 StatusBonusId EventConditionKey ParameterN
     1           "goldRequired"      1000
     1           "levelRequired"      10

I would then suggest using a factory to load this data from the database and creating instances of the event condition classes passing that parameters stored in the database and likewise with the status bonuses:

if (eventConditionKey == "goldRequired")
 goldRequired = parameter[0]
 return new GoldRequiredCondition(goldRequired);

The advantages of using this approach is that it will not require changes to the database when you need new conditions and status bonuses. When you want a new condition or bonus the only place you will need to make changes is in your code. The disadvantage is the lack of automatic verification of the data you insert into the database. You will be able to insert keys that have no match in code, and set it's parameters to values that make no sense.

share|improve this answer
Thanks for the writeup! definately consider that – Saifis Mar 4 '11 at 17:08

I think this is one case that would benefit from a document-database solution (i.e a "NoSql" database).

If you're set on using a SQL database then @Qua's answer is probably best.

The 2nd method you mentioned would fit perfectly with the document model. I'm currently looking at implementing something similar with MongoDb, which from what I've seen essentially stores and allows easy querying of JSON objects. See this answer for some more info.

Also keep in mind, that you can have more than one type of database. I'm using SQL for stuff that fits nicely into a relational model and Mongo for stuff that doesn't.

share|improve this answer
Thanks for the info, I've tried stuffing objects into mysql once on rails, it worked but wasn't the prettiest of sights, having a clean way would come in handy. – Saifis Mar 5 '11 at 10:09

Method 2 is not bad, it is versatile, but hard to manage the logic and more importantly, not platform independent unless you use something like XML or JSON. The data still stays application dependent - that might be a problem when you want to create another (non-web based) interface for your game.

Method 1 would work for an SQL database, but if you want to keep it fast when your app is under a heavy load, you might want to think again about having to join tables or do 3 consecutive queries for a single item.

If you knew that you were not going to have more than 64 statuses and 64 conditions and not have any single item have more than x number of statuses and y number of conditions, then you could solve this with the bitwise comparison of two 64 bit integers and x + y numeric fields in the same record where values would be given in the order appearance as a set bit.

It might not be the most beautiful solution and somewhat limited, but it's very fast if you expect the db to be hit hard. I used to operate a web based browser game with a 50k+ user base, and it taught me the usefulness of this approach.

share|improve this answer
Bit comparison sounds like a good idea, the limitations might not always be a bad thing either, it would be a nice limit to keep the game system form becoming overly complex. – Saifis Mar 5 '11 at 10:06
Perhaps it would be even better if the values would have key pairs that indicate which bit they offer a value for. That way you could filter for condition and status values as well with a single query. Good luck! – Konrad K. Mar 5 '11 at 10:43

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.