Changed Earth Worlds – Database Foundation

Last time I talked about what database products I’m using, how I’m using them and started the discussion of building a database back end for Changed Earth Worlds with the creation of a Character_Classes table that contains some starting stat values for the different types of characters players can roleplay.

This time, I’ll talk a bit about some other foundational tables that I’ve constructed, mostly the Characters table.

The Players table isn’t really that interesting right now, mostly just a record of usernames, passwords and PINs that players will eventually be able to use to log in from the game client to the game server.  A copy of this table will also be used on the eventual web site for the game to allow players to purchase in game money, sign up for discussion forums and so on.  At some point, we’ll have to build a login screen on the game client so we’ll revisit this table later on.  The only reason to build it now is because the Characters table will have a foreign key that will connect one or more characters to a given player.

The Characters table is where we’ll get to wallow in some actual game mechanics for the first time.

+------------------+------------------+------+-----+---------+----------------+
| Field            | Type             | Null | Key | Default | Extra          |
+------------------+------------------+------+-----+---------+----------------+
| character_id     | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| player_id        | int(10) unsigned | NO   | MUL | NULL    |                |
| character_name   | varchar(255)     | NO   |     | NULL    |                |
| character_class  | int(10) unsigned | NO   |     | NULL    |                |
| stat_thought     | int(10) unsigned | NO   |     | NULL    |                |
| stat_imagination | int(10) unsigned | NO   |     | NULL    |                |
| stat_matter      | int(10) unsigned | NO   |     | NULL    |                |
| stat_energy      | int(10) unsigned | NO   |     | NULL    |                |
| character_level  | int(10) unsigned | NO   |     | NULL    |                |
| stat_health      | int(10) unsigned | NO   |     | NULL    |                |
| stat_power       | int(10) unsigned | NO   |     | NULL    |                |
| stat_armorclass  | int(10) unsigned | NO   |     | NULL    |                |
| stat_tohit       | int(10) unsigned | NO   |     | NULL    |                |
| stat_plurfulness | int(10) unsigned | NO   |     | NULL    |                |
+------------------+------------------+------+-----+---------+----------------+

Again, we’ll keep things very simple, leaving optimization and any encryption of data fields for another time.

When you inspect the table, you might notice that there’s been a change from when I did the Character_Classes table.  I’ve changed the base stats, largely as a result of a conversation with my friend Jeremy who possesses an absolute wealth of knowledge about building RPGs.

We were discussing the way that elemental forces such as earth, air, fire and water are naturally opposed to each other and how this leads naturally to skills in RPGs being associated, either naturally or through ‘buffs,’ with certain elements.  When these skills are used against opponents who are associated with a certain element, they are made either stronger or weaker depending on the nature of the opposing elements.  For instance, a water attack will be weak against a water based creature but strong against a creature associated with fire.

Similarly, certain base stats are naturally opposed to one another.  In classic RPGs, a fast, agile character (with high agility) can get in close to a large, strong character (high strength) and do lots of damage.  However, if the larger opponent gets in a hit, they are going to do a lot of damage to the smaller, agile character.

I knew that I wanted a novel stats system for CEW, one that would accurately represent the nature of reality in the CEW universe, a reality in which the outcome of conflict is determined more by the manipulation of reality itself rather than whether a character has certain objective attributes.

What we came up with is a system of 4 base stats in 2 pairs of 2 opposing stats.

Thought (Left Brain Logical) opposes Imagination (Right Brain Holistic).

Matter (Physical Mass) opposes Energy (Non-Physical Potential or Action).

Because all skills in CEW are essentially “magickal,” even those normally considered non-magickal such as hand to hand combat or used a ranged weapon, these 4 stats represent the 4 spheres in which skills can be used.  Skills can affect matter or energy or some combination of both.  They can also use logical thought or holistic imagination or some combination of both.

If you go back to the character classes defined earlier, it’s not to difficult to determine which will be the primary and secondary stat for each.

A Maker’s primary stat will be Thought because a Maker must be able to think logically and understand the working and structure of physical objects.  Her secondary stat will be Matter because she is dealing largely with inanimate physical objects.

A Healer’s primary stat will be Imagination because, as a class that works largely with living beings, the complexity of trying to understand them in a reductionist fashion would simply be overwhelming.  Consequently, she must be able to imagine the objects of her work in a holistic fashion, not as an assemblage of units but as a system of cycles.  Because she is primarily concerned with animate beings, her secondary stat will be Energy.

A (Peace)Keeper’s primary stat will be Matter because she uses her skills to affect the abilities of her physical body.  Her secondary stat is Imagination because, like the warrior who uses Zen to enter a state of no-mind so as to perform “Right Action” without having to think about it logically, she must use her skills in a holistic, in-the-moment manner.

Finally, a Traveler’s primary stat will be Energy because she opens portals to other subrealities and manipulates energy so as to appear invisible, to move with great speed and so on.  Her secondary state will be Thought because she must use her logical, problem solving mind to defeat traps and locks, detect dangers and use her cleverness to move stealthily.

The Characters table contains 4 fields that will contain the current values for these stats:  stat_thought, stat_imagination, stat_matter and stat_energy.  Right now these are absurdly large integer fields which I’ll pare down later.

Although these stats can be changed, either permanently or temporarily, they are base stats because they are relatively stable and because the other stats are calculated, at least in part, from them.

Except for character_level and stat_plurfulness (which I’ll explain later), the other stats are all calculated and can change substantially during a single session of play.  There are a few stats missing from the table right now but I’ll add those, such as a field to keep track of experience points and another to keep track of current maximum values for certain stats.

For now, let’s focus on stat_health and stat_power.  These two are extremely important because they indicate whether you’re able not only to perform actions but, indeed, whether you’re even able to stand.

Mio Walking

So I made a cute little Mio (from K-On!!) walking gif.  Now I can use her as a demo game character since her character design (5 head) is very similar to the characters I’m drawing for Changed Earth Worlds.

mio.left

Changed Earth Worlds – Starting the Database

To build pretty much any kind of online game, we’re going to need some kind of database for storing data on characters, maps and so on while the servers are offline and for backing up data when they are online.  Usually, for convenience, performance, reliability and security, the database is not only going to live on it’s own server but probably on some kind of small cluster of servers.  Trying to use less than two database servers past development is just asking for downtime and enraged players.  Probably the simplest database server implementation an online game can tolerate would be something like MySQL running replication to a single slave server.  That way, if the primary server dies, you can fail over to the slave.

Another option these days would be to use one of the NoSQL databases but they don’t seem to deal with clustering very intuitively and the user base for them seems to be overly rabid about them, making me want to back away slowly and speak in a calm, soothing voice.

For my purposes, I’ll probably go with Clustered MySQL partly because lots and lots of people use it for all kinds of enterprise scale things and partly because I’m very comfortable with it, having used it to build tons of web applications over the years.  However, because I have a sense of slight uncertainty about it’s future after it’s purchase by Oracle, I’m giving myself an out in case I end up having to use something else.

That said I should mention that…

I, FOR ONE, WELCOME OUR NEW ORACLE OVERLORDS OF EXTREME REDNESS!  <.<  >.>

Although for my purposes using something like Hibernate to do database persistence seems like overkill (and yet another technology to sit around learning instead of writing code), I’ll be writing my database classes so they’re as self-contained and flexible as possible in case I have to connect to something other than MySQL.

The nice thing about MySQL is that I can run it on about anything and access it using tons of free management tools.  Makes it very easy to prototype the databases I’ll need and play with them without having to spend a bunch of time on configuration.  In my case, I have it installed on a VirtualBox vm running CentOS Linux 5.5.  That’s probably the environment it’ll end up running in throughout development and even into alpha testing, beta testing and live launch.

I like CentOS Linux.  It’s conservative.  It’s safe.  It’s stable.  It’s familiar.  I don’t need it to do anything magical.  I just need it to sit there and run forever without freaking out and making me babysit it.

For building databases, I’ve tried a number of tools, including the new MySQL Workbench, and I’ve just never found anything I like as much as plain old MySQL Administrator and Query Browser.  Again they’re simple tools and they just work.

Unlike a lot of people in IT, I don’t really feel any need to prove my geekful manliness by dancing forever on the raw bleeding edge of whatever magical new thing someone has decided is super cool this week.  I prefer simple, reliable tools that behave in a predictable way and just let me create things.

So, having said all that, I’ve got MySQL installed on my vm, I can access it using my tools and I’m ready to start building something.

So where do I start?

Last time I talked about the character classes available in Changed Earth Worlds.  I think that’s a good place to start because the one thing a game has to have to really be a game is a player.  Without a player, a game isn’t a game.  It’s a simulation.

Having said that, it might seem like I would want to start with some kind of character table to store all the characters created by players.  However, there’s a more fundamental layer that has to be built first, a character_classes table.  This table will store the available character classes and some base values associated with them, allowing us to add or modify classes later to expand or fine tune the game.

Some starting values we might want to associate with the various classes are their starting stat values.  If you’re not familiar with RPGs, then stats (or statistics) are values that represent the most basic qualities (or weaknesses) of a player’s character.  In classic RPGs, these statistics can represent qualities such as intelligence, strength, dexterity or charisma, for example.  A magic user will need high intelligence values to successfully master and cast magical spells.  A fighter will need strength to wield her weapon. And so on.

Many games will have as many as seven or eight statistics.

For Changed Earth Worlds, however, I’ve chosen to work with a highly simplified stats system, partly because I don’t want the game to be confusing to casual players and partly because it’ll make balancing the game easier.  The latter is important since I’ve chosen to build the entire game myself and will not have the benefit of a development team to assist with balancing.

Changed Earth Worlds will be built using KISF principle: Keep It Simple & Fun.

Characters in CEW will have just four base statistics to represent their qualities.  These qualities have been selected to have maximum relevance to the activities in which players will be engaged.  They are:

Intelligence
Imagination
Strength
Agility

If you look back at the character classes available in CEW, it’s pretty easy to see how these statistics can represent the strengths and weaknesses of each.  Each class has two primary stats and two secondary stats.

Maker – Needs high intelligence and high imagination so that they can visualize objects and environments and assemble them logically in their minds before Actualizing them.  In general, a Maker will have higher Intelligence than Imagination.

Healer – Similar to a Maker but needs higher Imagination than Intelligence because of the intuitive nature of channeling energy to effectively heal injuries and cure diseases, not to mention creating or transforming living things.  Living things are simply too complex to visualize logically and require the vast reserves of the right brain.

Keeper – Of course, this character class will require Strength and Agility to function well.

Traveler – Unlike the Healer’s relationship to the Maker, the Traveler does not have a relationship to the Keeper, occupying a somewhat unique space between Maker and Keeper.  Travelers require high Agility as they use their bodies to physically travel between subrealities, slipping bodily from one to the next.  However, they also require either relatively high Intelligence or Imagination to fully use their abilities since, due to their furtive and scavenging nature, they must exercise a good deal of cleverness.

Since we can’t simply have the starting values for these statistics be zero and have the players survive for more than a few seconds, we have to assume that all characters, to be assigned these roles, must have some starting values that represent their suitability to their class.

In classic RPGs, this is accomplished by rolling the starting scores randomly, usually using some dice or a pseudo random number generator.  However, for the purposes of game balance, this creates an undesirably large set of possible character development paths and, for the purposes of making the game fun and easily understandable by casual players, it creates unnecessary complexity when creating a character for the first time.  New players especially can become easily confused, assigning points to the wrong statistic for their chosen class, resulting in hours or even months of frustration.

Instead, CEW character classes will always start with the same base statistics, creating playable and fun characters for the chosen class automatically.  Players then have the option, as they advance, to assign ability points to these statistics as they wish, making their characters individual, unique but still likely playable as they develop and grow.

This is where I’ll start with the database, the creation of a character_classes table so that I can define the starting values of each statistic relative to class.  The table looks like this:

+----------------------------+------------------+------+-----+---------+----------------+
| Field                      | Type             | Null | Key | Default | Extra          |
+----------------------------+------------------+------+-----+---------+----------------+
| character_class_id         | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| character_class_name       | varchar(45)      | NO   |     | NULL    |                |
| starting_stat_intelligence | int(10) unsigned | NO   |     | NULL    |                |
| starting_stat_imagination  | int(10) unsigned | NO   |     | NULL    |                |
| starting_stat_strength     | int(10) unsigned | NO   |     | NULL    |                |
| starting_stat_agility      | int(10) unsigned | NO   |     | NULL    |                |
+----------------------------+------------------+------+-----+---------+----------------+

The structure is very simple and not very optimal but it’ll work as a starting point.  We can adjust it later and add more fields as needed.

So many online games fail at this point, at the very beginning, by hard coding these values somewhere into their server code, making it difficult to add classes later.  Hopefully, it’s not so common these days but there’s a book called Developing Online Games that talks about horror stories resulting from well known games that failed to do this simple thing.

Now that we have this table, let’s populate it with our data:

+------------+--------+------+-----+------+
| class_name | intell | imag | str | agil |
+------------+--------+------+-----+------+
| Maker      |     40 |   30 |  15 |   15 |
| Healer     |     25 |   45 |  15 |   15 |
| Keeper     |     15 |   20 |  40 |   25 |
| Traveler   |     20 |   15 |  15 |   50 |
+------------+--------+------+-----+------+

The first question you might ask is how I selected the starting values for each of the statistics.

I guessed.

Basically, I gave each class 100 ability points and then divided them up in a way that seemed appropriate for each class’ needs.  Again, these values can and will probably change as I continue development and especially during play testing.  But they make reasonable values for now and it’s easy to understand how and why they’re assigned as they are.

I could probably create some spreadsheets and spend a few months deriving ideal ranges and values but I’d like to actually complete a game sometime this decade.  So I’ll shoot from the hip a bit and adjust empirically as I develop.

When I get far enough along, even before I have code written for any kind of a playable game, I’ll be able to take all these guessed values and create a simple table top RPG so I can play test them with some friends.  That’ll give me a better idea how things will work before I build too much of the game mechanics.  And, who knows.  It might even turn into a fun Changed Earth Worlds table-top RPG or collectible card game later.

Next, I’ll work on a Players table so it can be tied to a Characters table which will use the Character_Classes table I just created.  One of the goals for CEW is for Players to be able to have multiple Characters so I’ll decide how to address that as well.