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.