Say I've got a list of a hundred unique weapons, how can I programmatically and easily identify them all?

Question

I've got a class, WeaponFrame, that has an int member, weapon_frame_id, that I intend to use as a way to identify the weapon, and I use that compare against other WeaponFrame instances.

The problem is that I want to pull the weapon from the global list of WeaponFrames and equip it on an Actor. As the designer, I might know that weapon_frame_id #2 is the bow weapon I want, but what is the best way to programmatically identify them?

If I assign an ID to the WeaponFrame on instantiation, I am unable to rely on the value being identical the next time the game is run, unless I assign the value to an enum or int then. That might work though.

I'm using C++11, would I just create a namespace somewhere, and enumerate all the weapon types,

enum class WeaponFrameIDs { 
  Sword = 1,
  Bow = 2, //repeated a hundred-plus times
};

or would I make a ton of const integers in a header somewhere, even if effectively an enum that way too:

namespace WeaponFrameIDs {
  const int Sword = 1;
  const int Bow = 2;
}

I could also use strings mapped to an integer, but I'm losing compile-time verification (and I can't use constexprs with VS2013), and run the risk of duplicating entries. However it supports dynamic assignment to the list:

std::unordered_map<std::string, int> WeaponFrameIDs {
  {"Sword", 1},
  {"Bow", 2},
};

Is there an alternative that I'm missing? What is the best way to write a system for identifying weapons in a game?

If it's relevant, here's an example situation I'm trying to solve via code. I am not using a visual editor where I can drag a weapon onto an actor.

void set_up_actor()
{
  Actor actor;
  WeaponFrame* weapon_frame = AllWeaponFrames.at(WeaponFrameIDs::Bow);
  actor.weapon_frame = weapon_frame;
};

---

Points I'm looking to avoid:

• Filling an entire header with enums
• Needing to recompile the entire project because I changed that header
• Losing the ability to verify the id at compile time
• Eventually add user-generated ids. This conflicts a lot with the compile-time verification.

I'm trying to solve the best way to pull the Weapon from a list, whether it's by ID, index, specially mapped key or something else.

• If I use a literal ID, actor->weapon_id = 1, I don't know what weapon is tied to the ID of 1.
• If I use an enum, or a const int, to represent the 1, I need to recompile the game for each of the new weapons I add.
• If I change the id type to a string, I lose the ability to programmatically validate the string against the existing list of weapons.

Answer 1

Persist your weapon data seperately. You probably want to use a database, but you could also use a file and load it into memory. Using constants creates (at least) two problems, the first is adding or changing data requires you to recompile the binary, and the second is it inflates the size of the binary.

Let's consider a simple example where we use database.

Suppose we have a table for weapons which has the following a columns, id (pkey), name (varchar), max damage (int). Our weapons do a random amount of damage between 0 and max damage.

We also need a table to store player data, it will have the following columns, id (pkey), name (varchar), and weapon_id (fkey).

Our program defines the following structures (for simplicity).

struct Weapon {
    int id;
    char *name;
    int max_damage;
}

struct Player {
    int id;
    char *name;
    Weapon *weapon;
};

Suppose a player with an id of 1 loads into our game.

SELECT * FROM player INNER JOIN weapon ON weapon.id = player.weapon_id WHERE player.id = 1

We can use the data returned from the database to fill in our structs and the rest of the program can use them.

Do not get bogged down in the specifics of this example as it is mearly that.

Answer 2

The simplest and easiest way to handle this is to:

1. Store weapons in a file to be loaded at runtime.
2. Use fixed-length strings as identifiers for the items. Your code references them by using string literals.

Fixed-length strings make for great identifiers. They are:

1. Hard to overlap. You need the identifiers to be assigned by hand in the weapon files themselves, not at load time (this allows the identifiers to be persistent). But it's really easy to accidentally reuse an integer value, especially if you're counting from 1. It's a lot harder to repeat a fixed-length string by accident. Even a 16-character string has plenty of space, and a 32-character one is long enough for you to have a naming convention with groups of names partitioned by prefixes and such.

2. Fast to compare. When doing comparisons with fixed-length identifier strings, you don't care about any specific ordering. You don't specifically need ASCII, lexicographical, or Unicode ordering. What you need is a single, specific, unchanging ordering. This can be achieved by comparing the strings as though they were arrays of integers rather than bytes. A 16-character fixed-length string can be compared with 2 64-bit integer compares rather than 16 character compares.

   This also makes lookups in associative containers faster.

3. Not particularly large. 16 character strings are probably big enough for a unique identifier, but if you want to get really descriptive, you can use 32. Oh sure, that's bigger than the 4 or 8 bytes a single integer would take up, but it's not a huge amount.

   • And if their size does become a legitimate problem (which it almost certainly won't), you can always have non-debugging builds have the fixed-length string class store a hash rather than a string. You'll lose #5 on this list, but you'll get back the storage space from your strings.

4. Legible in code. When you read your code, you see string names, so you have an idea what it's referencing.

5. Legible in the debugger. This is a very big deal. At some point in your game's development, you're going to be looking at some data structure and trying to figure out which weapon this data structure is referencing. An integer value is pretty opaque; a fixed-length string can be read in the debugger and tells you everything you need to know about what is being referenced.

Yes, there's no compile-time protection in your source code references, but you lost that the moment the weapons stopped being part of your C++ code. After all, if the weapons are not part of your code, there's nothing that ensures that the integer 1 or an enumerator maps to the actual weapon that it appears to (or any weapon at all). That's determined by what is in your weapon file, not what's in your C++ code.