I am currently working on a text based prototype, in where the player is (eventually) allowed to have over 180 character choices in a quickly played permadeath type of game. It's a lot simpler than it sounds, based on a sort-of component system where the player choices several components, which can result in so many character types. However, each character type is distinctly defined, tagged, and marked with data for a very specific reason. So there may be a lot of different "Orcs" the player could create, they are each defined in game data individually with their respective changes to the base character.

Right now, the game only has about 4 character choices. This is easily handled in code, without any save/loading of files, or accessing of databases, or any fancy classes.

In many text based games, it is all handled in code, perhaps with a simple switch. Input choice: 1 = Human, 2 = Elf, 3 = Orc, 4 = Minotaur, etc. etc. However, this tends to get ugly when there are 180 possible choices. It gets uglier with nested switches.

I want to be able to have players filter the vast number of choices, with something like a GUI search bar or checkbox options. "[ X ] Melee Based, [ ] Uses Spells, [ X ] Uses Stealth." Even simpler, perhaps a button for players who need help choosing, or suggestions based on a few questions for new players. "Are you big on Swords or Sorcery? blah blah" Alright, we suggest you try a: Elven Fire Wizard.

Besides hard coding this information which is what I am currently planning, is there a more organized way to handle search queries, the process of elimination, filtering of results, or any other thing I might need to help ease players into choosing from what will certainly be an overwhelming number of possibilities? Even if newbies are only given a small number of choices that are easy to grasp, even expert players will need some sort of filtering system to help them decide.

As a developer, I enjoy having my code easily accessible. Reading through nested control structures to edit information isn't my favorite way of handling it. However, right now it's certainly the easiest since I only have 4 character choices. I am entirely ignorant on databases, so forgive my ignorance if I mentioned that.

I am not exactly sure if a "database" is overkill or not for game data like this. Especially game data that doesn't need to be accessible to anyone but the developer, and is only very large after a significant amount of time has passed to update the game hundreds of times.

  • \$\begingroup\$ I ask this, because after character creation, the information is never needed again. The character would be saved and all data in the character entity. I was thinking of just hard-coding the choices because they are only chosen one time. \$\endgroup\$
    – Carter81
    Commented Sep 29, 2013 at 3:33

3 Answers 3


What you are trying to do is also fairly similar to what older MUDs did. I am more familiar with the Diku variety and I'll explain it briefly here. If you think that is what you are looking for, you can look up the source code, it is fairly straightforward.

First, the different stats and skills are all hardcoded. Strength is a concept known at the code level. Same for hp, armor, stealth, fire resist and so on. All the skills like backstab, spells, hide, etc., also exist in code.

All the rest of the data is loaded from a database, even races and classes. So a character structure would be

  • base stats
  • current stats (accessor function that takes into account current status of character plus race modifier, etc)
  • race
  • class
  • inventory

Races are loaded from a file and define:

  • stats modifier (Int +2)
  • available classes if you want to limit class selection in that way
  • race-related skill

The same goes with the classes, but they define different elements

  • minimum stats requirements (if you implement anything like that)
  • skills and the level at which they are granted (spells can be considered skills)
  • experience needed to advance (if it is class-based)
  • etc.

Finally, you have the equipment which work just the same way: all defined in a file using a custom format

  • name
  • min level
  • class requirement
  • equipment slot (little bit more tricky)
  • stat modifiers (same as race: Int +2, Armor -3, etc.)
  • recharge time (for cooldowns)

So that's a brief overview but should give a good idea of what was going, you can see more for yourself in the code (tarball) but be advise there is a whole lot more concept going on in there (object containers, etc).

  • \$\begingroup\$ This is EXACTLY what I want. This makes a TON of sense, because my game is extremely similar to older MUDs. OF course the solution is already made from muds! :) I am very grateful. And +1 for including the link in addition to exact solution I was looking for. \$\endgroup\$
    – Carter81
    Commented Oct 1, 2013 at 9:29
  • 1
    \$\begingroup\$ I am so grateful for the internet. IF it were not for the "World Wide Web", lol, Game Development and complex topics would require professional level training or professionally payed salary by cutting edge businesses. Thanks to the internet, amateurs can become pro through a massive collection of knowledge, and teaching from professionals all the way across the globe. Thank you again! \$\endgroup\$
    – Carter81
    Commented Oct 1, 2013 at 9:34

If you're expecting to have 180+ different types of characters, even if they are constructed via different combinations of components, you definitely don't want to hardcode the choices and guides for them. You're going to want to write a generic solution.

You can start by sorting out the different layers of base types and components that will be attached to them. The effects those components have can be categorized and turned into values, and the values for each component can be specified in non-code files that are read by your program. All your code has to do is load component data and combine values together, ultimately forming one of your final character types. Thus, the characters, their properties, and their abilities become emergent.

Suggestions for new users, as well as filters and search queries can be implemented by matching a set of input values to component or base character types. If you don't want users to interface with these raw values, you can create an abstraction layer over them. For example, instead of having users enter Strength: 5, you can give them choices like High, Medium, and Low, and behind the scenes convert them into actual values your system uses.

The 'database' you're talking about would be the collection of data defining different components and their values.

A More Concrete Example

Let's say we want the game to have two base classes: Elves and Orcs. The first thing to decide is how to quantify what separates different types of these classes, and thus different playstyles among players. Typically these are things like Melee, Archery, and Magic skills. To get the most emergent behavior, we'd want variables which don't directly relate to the high-level skills, but can be combined to make them. So something like:


A Melee character would be high in strength and defense. An archer would be high in agility and stealth. This scheme offers a lot of gray area between different specializations and more choices for your players.

Each base class provides some starting stats in each of these categories:

    Strength: 4
    Agility: 8
    Knowledge: 7
    Defense: 3
    Stealth: 5

    Strength: 9
    Agility: 2
    Knowledge: 3
    Defense: 7
    Stealth: 4

Components that you add further define characters by adding or subtracting from these stats. I'm not really clear on what your components are, so I'll get creative for this example. One component could be armor:

The Iron Armor of Superb Armor...ness
    Strength +0
    Agility -1
    Knowledge +0
    Defense +10
    Stealth -2

The Light Armor of Extreme Brightness (Get it?)
    Strength +0
    Agility +2
    Knowledge +1
    Defense +5
    Stealth +3

I'm not sure this is such a great example component in terms of character development, but hopefully it conveys the idea. Note how these components can be defined in external text or XML files. In terms of numbers, if you have two base classes and 10 types of armor, that gives you 20 unique final character options. That number multiplies further with other component choices. And you didn't have to hardcode a single one :).

For your new users, you ask them to fill out the stats of their ideal character, or help them fill out the stats with a series of questions. You can then find a base character and components which best match the set of stats.

  • \$\begingroup\$ Thank you. This is helpful. If you do not mind a more detailed example, I would be grateful. It may make it easier for me to plan better, the better I understand the concept. \$\endgroup\$
    – Carter81
    Commented Sep 29, 2013 at 7:54
  • \$\begingroup\$ No problem, I've expanded the answer with an example. \$\endgroup\$ Commented Sep 30, 2013 at 4:41
  • \$\begingroup\$ Thank you. Especially for suggesting the XML files. I think that might make it easier for me to read/edit the data. \$\endgroup\$
    – Carter81
    Commented Oct 1, 2013 at 9:32

You should probably play some League of Legends (LoL for short). Seriously. It is a great example of a few Classes (Mage, Carry, Ranged, etc.), that can be broken down into 70 or so characters, each of which can equip a large number of 'components', making for vastly different play and experience for the player.

Sounds to me like that's the kind of concept your going for (character wise). Now, in LoL each character is distinct (at it's base) from any other character, but you could probably get away with simply having a list of types of characters (Orc, Human, Lizard, etc) with no base abilities. Instead, each component in your game would be tagged with metadata.

A sword would be tagged ('Melee','Warrior'), 
a wand ('Magic', 'Mage'), 
leather armor ('Ranged', 'Stealth', 'Assassin'),
a dagger ('Stealth', 'Assassin','Melee'),
fire spell ('Magic','Fire','Mage')

A player selecting Orc, leather armor, dagger, and fire spell could be called an 'Orc Fire Assassin' or 'Stealthy Orc of Fire"

This would require entering metadata for each of your 'components', but I see no reasonable alternative.

If none of this helps, maybe it would be a good idea to discribe how components and character work together in your game.

  • \$\begingroup\$ Hehe, I actually originally had "League of Legends" and a bit of detail about the system in the OP. However, I took it out because this question isn't about how to design the characters or components. It is how to store, access, and organize the data in code. Great suggestion though on the naming conventions! \$\endgroup\$
    – Carter81
    Commented Sep 30, 2013 at 3:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .