While somewhat old news to some, the Google App Engine is an amazing tool allowing developers to tap into the scalability offered by the Google framework while developing entirely standalone applications. What’s more, along with the offer of the code base to build from, Google also allows developers to host their projects, at no cost, on the Google App Engine server (up to 10 applications per user, no less). I was excited to learn of the project initially, and the more I have delved into it, the more enthralled I have become.

For years now, I have wanted to have the means by which to develop a small tactics style RPG game, and while I have had the basic coding knowledge needed (not to mention buckets of ideas), it has been difficult to bring myself to the point of actually taking on such a daunting task. Having the opportunity to build on the data store and framework Google has offered with their App Engine has given me that extra little boost to begin development on one of my long time goals.

Technological Challenges

Of course, taking on development of a game is no small undertaking, as I am becoming more and more aware, but the more involved I get, the more excitement builds. I have already been able to finish two of my major milestones for this game: generated maps using simple text files for mapping purposes and unit movement algorithms that take into account terrain penalties and obstructions. Now, while these things may sound simple to those of you who have worked on this type of project before, throw into the mix the fact that I knew not a lick of Python when I started the project about a month ago, and this is the language in which the entire framework is written.

Don’t get me wrong, though: I have been thrilled at the opportunity to learn a new language (two if you throw in my crash course to learn Common LISP as well, but that’s another story), and thankfully Python has been a breeze to pick up — quite possibly one of the reasons it was chosen by Google for the engine. Some of the quirks of the language still trip me up from time to time (like having to define class functions with the first parameter of “self”), but those are quite minor in the grand scheme of things. What is really thrilling to me is being able to write all this for web, because it allows me to use libraries and visual mediums with which I am already familiar.

To avoid making just another cookie cutter game to float out there, I decided a long time ago that I would not be using Flash for my first iteration of the game. In fact, I determined that, with my knowledge and experience with jQuery and writing custom JavaScript, the whole game would be supported and animated using plain DHTML and JavaScript libraries. I have written some custom AJAX handlers already in use for movement, and I have already begun building my JavaScript framework to support all the different modules that will be added as development progresses.

On With the Visuals

In order to have something substantial while in the development phase, I nabbed a bunch of sprites from the SNES game The Legend of Zelda: A Link to the Past (© Nintendo) as place holders, since they have the basic theme and style I was after: top view, grid based mapping system. For now, only the base units are in play — as seen in the screen shot posted above — and will be expanded into about a dozen different unit types with different visuals and movement capabilities.

Of course, for copyright reasons, I will not be using these sprites for more than simply the place holders during development, and for that reason, I have begun discussions with a couple friends about the possibility of getting design help with the unit, obstruction and building sprites as well as the terrain texturing. As with the sprites, the terrain is extremely rudimentary at this stage: simply background colors assigned to the various coordinates based on terrain type. It’s not pretty, but as you can see from the screen shot, it gets the point across. In the image, the following terrains are able to be seen:

• White – Mountain
• Lt. Green – Plains
• Dk. Green – Forest
• Black – Roads
• Blue – Water
• Tan – Desert

Of course, this is not a comprehensive list of terrain, since we will eventually want to support additional terrain as well as terrain modifiers due to weather conditions, etc., but it gives an idea of the direction I am wanting to head with things. The fun, and challenge, with the terrain will be trying to seamlessly integrate the different terrain types in the joining coordinates on the map. I have some ideas on how to accomplish this feat, but it will definitely take a little work on the rendering functions.

Game Design and Architecture

To those who are still reading, I have either stumbled upon a topic about which you are as interested as I, or you simply have nothing better to do at the moment. In either case, I will humor you with some of the overall game design which I am hoping to implement within this game. Of course, while a theme and genre are some of the easiest to initially pick out, I feel they can either make or break a game. I have chosen both based on my own personal interests and creativity and have settled on a turn-based tactics style MMORPG.

It is difficult to have a solid story for a fully web based game, but I am going to do my best to incorporate some story elements from a world I have been devising over the last several years into the game. In my opinion, this incorporation should help in piquing interest in the different units, abilities and factions that exist within the game world. Upon release, the basic game will be 2 player, turn based; however, I would, at some point, like to be able to add the option of more players on a single board: playing either individually or with allies from within their faction.

The units themselves will be selected and modified off the battlefield by players. Upgrading certain stats based on their battle experience and equipping them with a variety of weapons, armor and other modifiers that will enhance their effectiveness in battle. As a player progresses, he will have the ability to purchase the rights to create a new unit for his squad (or clan). These new units always start out at the entry level, and with careful planning, a player will be able to play against opponents of all experience levels. Each squad’s level will be rated based on the cumulative total of the individual members’ levels, and the player will only be able to engage other players within a reasonable range of his current squad level.

Active units within the squad may be switched out in order to give lower level units a chance to gain experience. Different battles will allow a varying number of your units to be on the field at one time. Player units will act as generals, for lack of a better term, and they will have the ability to spawn or recruit helper units depending on their abilities and the map modifiers. For instance, if you have a unit equipped with charisma, he may sway a town on the map to your cause and allow you to begin recruiting additional foot soldiers — for a training cost, of course. Likewise, a wizard may be able to summon a stone golem on a map with a mountainous region. What keeps the game interesting is that the types of units that can be recruited on a single map will vary depending on which general(s) you choose to direct your armies. If you choose wisely, you will be victorious.

One reason to have the active units be removed from the active battlefield into positions of leadership is that it also allows a player to have multiple battles active at one time. Imagine a player with only three active units assigning them all to a single campaign against an opponent who is less than active. If the units are tied to the battlefield, they can only appear in one campaign at a time, but with them simply managing the troops, the ability to have multiple, concurrent games is granted — while still keeping with the overall theme of the game.

For those not familiar with turn-based tactics games, let’s review the basics. Each player, on his turn, is able to perform one or both of two phases with each unit under his command. Movement is the first phase that is an option. During this phase, a unit may be moved to any valid spaces on the board. The second phase is the action phase, in which a unit may perform exactly one action — attack an enemy unit, heal self or friendly unit, supply a friendly unit, cast a spell, etc. Each unit has their own phase monitored, so the order in which the phases are performed is entirely up to the player for each individual unit. Sometimes it is much more conducive to attack a nearby unit before retreating to safety.

Each unit is also equipped with standard RPG style elements (HP, MP, attack, defense, etc) that are all incorporated into the algorithms used to determine the outcome of individual actions. Also along the lines of the traditional RPG, each unit type has specific strengths and weaknesses that must be used and complimented with other units in order to have a successful campaign. Resources available on the maps will also be needed in order to continue building structures and recruiting units to your cause.

Obviously, while this is a fairly lengthy post, this is just lightly scratching the surface of all that is going to go into this game. I hope to have something playable by the first of the year, but I may be a bit over-optimistic with that goal. Whatever the time frame works out to be, though, suffice to say that I am thoroughly enjoying the process of both learning the technologies and putting them to practical use in yet another time waster.

Check back for occasional updates as I complete different portions of the game. Also, as I am intending for the entire thing to be open source, I will post code from my JavaScript library that has been especially useful to me from time to time as well. In the meantime, feel free to leave me your thoughts and comments as things progress!