# Integer vs String for "type" data in data-driven games

I've been developing a few mobile games, in which those games fetch their data from a server-database.

I'm used to storing "type" values as an integer identifier, and an enum in the client to identify the data coming from the server.

I'm under the impression that games like MMOs or PC games that get patches model their data to identify "types" as integers.

As an example: On the database table:

Monsters Table: MonsterId(int), Name(string), MonsterType(int)

On the client-sided code:

typedef enum {
MonsterTypeGround = 1,
MonsterTypeAquatic = 2,
MonsterTypeAmphibious = 3,
MonsterTypeAerial = 4
}MonsterType;


Is there an objectively correct answer on what to use (int vs string) for these types of data?

Do I have the correct impression that MMO's usually use integers for this, or it highly depends on the developers as well?

• Using an enumeration is equivalent in performance to using an integer, because compilers magically convert them.
– Anko
Feb 16 '13 at 11:44
• In most of what you would call "AAA" games, types are referred to by strings everywhere where the content is created, then they use some hashing like CRC32 to hash the string name to an int when it's saved to files or loaded in the engine. Of course ints are much more performant for various tasks than strings Feb 16 '13 at 12:31
• Thank you! I never thought of using strings then hashing to save file. Thanks for the inputs all of you guys! :) Feb 17 '13 at 4:39

It depends on the developer. But I'd say ints are more common.

It's generally far more efficient to use an int for both network communication and storage. You need to be careful to ensure int IDs are "stable" - that you don't insert or remove an enum value, except adding news ones at the end of the list. Otherwise your data breaks.

For data source, using strings is fine and has value. I'd just generally expect a tool to convert any XML/text data files into efficient binary data during build. It's easier to inspect and debug text file. That does not means that text/strings are good for editing; always put effort into good tools for game/level designers. Developers, not designers/artists, are the only ones who should ever have to open any data files for raw inspection/editing.

Also, beware encoding too muxh in code-specified ints. That defeats the purpose of data-driven design. For things like your simple example, if all the monster type affects is movement and combat, you can easily make that data-driven. You van use flags to denote the surface/tile types a monster can move on and more data to define those surface types (e.g. a mountain is "outdoor large impassable, value 3" and all flying monsters have bit 3 set for movement (or a list of string identifiers, of course). Same goes for combat immunities and the like. Only put in code what needs to be controlled by game logic.

• Thanks for the input! What if, say, I have a table of skills, each row is a different skill and each skill has a different implementation on the client-side code. Does that match my previous example or it's an entirely different case altogether? If it's still the same case, then would it make sense to use "string" identifiers instead of int to make it more readable for fellow developers? Feb 16 '13 at 7:01
• That's a better example. Again, you can use text sources/scripts id'd by name, and then "compile" it into compact form for runtime. So long as you ensure clients aren't out of sync with each other or the server (version your data and make sure clients have the right version), or you somehow get stable ids, it should be fine. Feb 16 '13 at 21:43

You can use whatever sort of data can be correctly interpreted by the receiving end. Ideally you use the format that strikes a good balance between being small in size (to reduce bandwidth, memory use, etc) and being easy to use (so your code isn't overcomplicated by it).

If you know that both sides have a list of all the possible values, then you can just send a number and they can look up the correct value based on that number.

But if there is a near-infinite number of different values that could be held, it's not feasible to put them in a list and send a number to look them up with. There, you might send a string - names are an example of this.

• Thanks! I'm quite conflicted by this however. What if say I have a skill "name" that's displayed in the game, and an ID to identify the skill with. Wouldn't it be repetitive to use say name:"Increase Agility" id:"increaseAgility"? Or are those two different matters? Feb 16 '13 at 14:16
• If there is a unique ID, and both sides understand the ID, you'd use that, whatever form the ID is in. Repetition is not really the issue - the issue is whether the ID does the job you need, which is representing the object uniquely, now and in the future. Generally speaking I'd prefer an integer type to a string because they're easier to prove unique. But you have to think about what will be easier for you to use, eg. during development. Feb 16 '13 at 20:43