Usage of standardized syntaxes in gaming: yea or nay?

Question

TL;DR: Using CSS as an element in defining rulesets in Civ-style turn-based strategy games: Madness or just plain old insanity?

Real question:

Designing ruleset parse rules is a pain. Every single game out there seems to define its own ruleset for how rulesets are to be parsed (insofar as the game features customizable rulesets, of course).

Is it time for the game dev. community to embrace standardized synatxes for rulesets?

Is CSS a viable option for customizable games?

Example: Consider a Civ-like with customizable rulesets; how nice would it not be to be able to design rulesets as follows:

artillery:era(modern) {
  range: 2;
  sprite: url(/isophex/artillery.png);
}

artillery:era(classical) {
  range: 1;
  sprite: url(/isophex/cannon.png);
}

Answer 1

I agree with Michael Stum's suggestion to keep with XML, to avoid writing your own CSS-like parser. If you can find an existing CSS parsing library that's cool, but otherwise, KISS.

Here's how your example might look in XML:

<artillery era="modern">
    <range>2</range>
    <sprite>/isophex/artillery.png</sprite>
</artillery>

<artillery era="classical">
    <range>1</range>
    <sprite>/isophex/cannon.png</sprite>
</artillery>

Not too different, eh? And with one of the many XML parsing libraries out there, I guarantee it'll be a piece of cake to load such a file.

Answer 2

Personally, I would also use XML for rulesets or other config-files.

There are some other alternatives like YAML or JSON though. These are usually smaller in file-size than XML files (if that's a concern) and there are robust parsers out there to read these files. Their syntax is also closer to CSS if that's important to you :-)

Answer 3

What you're proposing isn't a standard syntax. It looks like a standard syntax, but it's not really CSS, and the CSS model doesn't fit what you're trying to do. The syntax is good at selecting structures, but not describing them.

Screw XML. It's verbose, noisy, annoying to parse, lots of tricky edge cases, and for all its claims of validation, no one really does that. I suggest YAML. It's a standard data description format, with parsing libraries available for any practical programming language.

So here's what your code would look like in YAML - first as a bare untyped variant, then with optional type tags for people who are too pedantic to actually get work done.

artillery:
    modern:
        range: 2
        sprite: /isophex/artillery.png
    classical:
        range: 1
        sprite: /isophex/cannon.png

--
artillery:
    !Era modern: !Artillery
        range: 2
        sprite: !URI /isophex/artillery.png
    !Era classical: !Artillery
        range: 1
        sprite: !URI /isophex/cannon.png

The second format sucks. In practice, you don't really care if someone puts an !Era or a !Period or just a plain untyped dictionary there, as long as it has the keys you want - range and sprite. It's analogous to duck typing in programming languages, and it makes things a lot more readable. If it doesn't have the keys you want, it's easy to detect that at load-time even without a schema. Which is great, because you need the code anyway, so why repeat yourself? (It also means as long as the application knows how to resolve URIs, you don't run the risk of someone accidentally calling them URLs and failing to validate for stupid reasons, as you've already done.)

If you really need to have a parsable description of the data files - like, you want to automatically generate property sheets for editors and for some reason doing it in the same codebase as your engine is not acceptable - you can use something like Kwalify schemas.

Answer 4

Your language looks like CSS, but it isn't. It's your own Domain Specific Language.

Ask yourself this: Do you really want to create your own file format, for which you need to write a parser. This parser needs to be fast and robust. You also need to document your file format and teach people how it works - after all, it's a customized language. You then need to be aware that you may run into issues you never thought of - maybe someone thought it's a great idea to create a 50 MB file and your parser crashes, corrupting a savegame or so. Or you decide you need to add a feature that can only be implemented with a breaking syntax change, thus breaking all the existing files.

The reason why formats like XML are so popular is because XML has these problems solved. You can find many great XML parsers that are proven to be robust, fast and leak-free. Also, many people know XML files and how to edit them, and because it's such a generic but well defined syntax you can be sure that you can extend later.

Your motivation seems to be easy editing by hand, which is common in community SDKs. Now, the reason people edit those files by hand is that they don't have the tools the Game Devs use. You can assume that a company developing a game for several years has some graphical tools for editing such files - they may not be great and bugfree, but they edit the files for you and developers only rarely edit them by hand in order to tweak something. Those tools are rarely released in 'Modding SDKs', so most modders edit by hand.

So my initial reaction would be: Instead of spending time developing a new, unproven format that is easy to edit by hand, I'd rather use a battle-proven format and spend the time writing tools that make editing easy.

But blanket statements don't work like that. It always depends. If you spend 3 or more years writing a big game with a sizable dev team, then you can spend a lot of time developing, testing and finetuning your system. If you have 15000 files to parse, then finding ways to reduce memory usage becomes important.

But for small/medium/indie games, I'd go with a known and well-supported format like XML and a nice tool to edit it.

Answer 5

As I understand your proposal, you are speaking about creating an external Domain Specific Language (DSL) for your game rules, that adheres to a precise and standard syntax.

From my experience in building DSLs for game rulesets and my reading of Martin Fowler's recent book on DSLs, I gather that two main parts are required to build something like your idea :

• A Semantic model (or Business model) for what your DSL represents. If you do OOP that would be a class to hold the units with attributes like era, range, strength, etc. (Yet OOP is not compulsory)
• A Parser to populate that model from text files that use your chosen syntax.

I think that the larger effort is actually in building the model and not the parser, but choosing a standard syntax will make the parser much faster and easier to build. Moreover if the syntax is simple and/or known to the people who write the rules it will be that much easier for them to do that.

So yes, by all means build a rich business model for your rulesets and then write them using a standard syntax. XML is indeed very often used in that capacity in games and elsewhere, but it's generally thought to be too verbose and is increasingly replaced with leaner formats such as Json or Yaml (and why not CSS).

Hope that helps put your idea in a different light.

Answer 6

I'm not sure that is really CSS syntax, so this is more of "$selector { $rules; }" format than CSS itself. My gut reaction is that the "cascading" part of CSS would end up being overly complicated to work with and it would end up looking too much like code at that point.