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.

NPCs might even talk to a character differently depending on the character’s “class.”

To keep things simple, Changed Earth Worlds will offer four (4) character classes but, to keep things exciting, each class will be balanced so there will be plenty of skills, items and adventure opportunities regardless of the class selected.  Even Healers which, in most games, tend to be supporting characters will have lots of unique and exciting skills to employ.  To some extent, players can also use skills and items from other classes with limits to their ability to master them.

Maker – After The Change it was discovered by Sophie Core that certain individuals possessed an ability to consciously create and alter reality as they wished, usually by imagining the desired results and performing an activating ritual.  The technical term for this is ‘Actualization’ but PCs and NPCs will often refer to it as simply ‘Magick’ for the sake of convenience, recognizing that the ability comes from a natural source rather than a supernatural one.  For the most part, the citizens of Changed Earth don’t believe in Magick as a mystical or supernatural skill.  They view it instead as having a scientific basis even though they may not understand it fully.  Makers, using Magick or Actualization, can create, transform (modify) or destroy, with the appropriate skill level, an object or environment of any size.

Healer – Like a Maker, a Healer can alter reality through the use of imagination and ritual.  However, there are two key differences between a Healer and Maker.  First, while Makers Actualize inanimate objects and environments, Healers are able to create, transform or destroy (kill) living things, living environments (ecosystems) or animate objects.  Second, while it is relatively easy for them to transform, heal and destroy living things, it is relatively difficult (due to the complexity of living things) to create them.  Only at high levels of experience and skill can they reliably create living things.  Due to the consequences to their karma, it is inadvisable unless absolutely necessary to kill them.  However, there is a counter-balancing factor.  Healers, unlike Makers, in their ability to transform living things can transform a dangerous monster into one that is less dangerous, a Tentacle Beast into a Fluffy Bunny for example.  They can also do the reverse, creating dangerous barriers of enemies for other players or enemies to encounter.

Keeper – A (Peace)Keeper is an individual who is able to alter reality only as it pertains to their own physical existence.  Using imagination and visualization, a Keeper is able to perform physical feats of speed, strength, endurance and agility impossible for non-Keepers.  A Keeper might flit effortlessly from building to building, avoid projectiles by contorting their bodies, mount a blindingly fast counter-offense, fire a weapon with inconceivable accuracy or wield a weapon such as a sword with unthinkable speed and precision.

Traveler – A Traveler uses their intuitive understanding of quantum physics not only to travel easily between worlds using portals of their own making, slipping effortlessly from subreality to subreality, but also to achieve effects such as invisibility and teleportation of themselves, other people and objects of any size, depending on their skill level.  Travelers are explorers and opportunists, scavenging what they need as their move through worlds.

This first one shows the technologies that I used: Java, NetBeans IDE and Slick2D.  It is probably the more coherent of the two although the game was in an earlier state.

The second video shows the game at a point where there were enemies, some kind of accounting for hit and mana points and the beginnings of some strategy.  It is, however, the less coherent of the two.