"Game" Engine Requirements System

I am/have been building a game for a long time now. The game is a web browser based system, and data is stored using JSON stored in RavenDB.

One thing I am very constantly running into as a problem is the notion of Requirements. Anyone who has played a game, particularly an RPG, is probably familiar with this. Requirements such as Requires Level 10 to use or Requires [Race] to use.

This has been a constant struggle for me, and I have finally worked out what I feel is a solution; But I wanted to see if there were other people who have overcome this issue and could offer any advice.

The way it works is that all of the various things in the game that can have requirements have a field...

List Conditions { get; set; }

Conditional is defined like this;

public class Conditionals {

    public Condition Named { get; set; }
    public Condition Minimum { get; set; }
    public Condition Maximum { get; set; }
    public Condition Exactly { get; set; }
}

And then each of those is a type of Condition, which is declared like this;

public class Condition {

    public string Id { get; set; }
    public string Name { get; set; }
    public string Adjective { get; set; }
    public string Label { get; set; }
    public T Value { get; set; }
}

So then the JSON would, if I am right, look like this... assume an item that requires level 10.

var Conditionals = new List{
    new Conditionals {
        Minimum = new Condition{
            Id = "clue/level",
            Name = "Level",
            Adjective = ">=",
            Label = "Level is greater than or equal to 10",
            Value = 10
        }
    }
};

These will be resolved when the character is retrieved from the database using Clues. Clues are simple key/value pairs, like a dictionary. A clue has an identity and a value only.

```
var character = new Character {
Level = 11,
Clues = new List () // clues will contain key/value pairs
};
// on database save

I have never written code against a RavenDB, and very seldom use Json (actually, "never" is almost accurate). The way I see it, the classes that end up Json-serialized and persisted to the database, are analoguous to Entities (Entity Framework), or POCO's.

They are part of your data model.

It might seem (/be) code duplication, but if you had a domain model (which might mirror your data model... or not) and a way to "translate" a domain entity to a data entity (and vice-versa), you could very well use an enum in your domain model, and have it serialized as a string.

Basically: the shape of the data shouldn't drive, nor define, the shape of the objects your application is going to work with.

Your business logic (well, the actual game!) should work with the domain model objects, and then you'll have a data access layer that will do its job with RavenDB and Json - the business logic shouldn't be bothered with these concerns.

The Label is a good example of why presentation concerns and data concerns need to be separated: serializing and storing it is a waste, you already have all the necessary information in the other fields.

If you had a domain model Condition, it could have a Label property, with logic to build the string out of the other values.

StackExchange Code Review Q#37982, answer score: 5