Ranger Sheck's Blog - Home

Procedural Dungeon Generation

2010-05-08T17:05:00Z

There are a lot of good resources out there for Procedural Content Generation. The PCG wiki lists a ton, and if you’re looking to read up on the subject, it’s a great place to start.

A lot of these ideas are derived from the original Nethack game (and predecessors like Rogue and Angband). As the PCG wiki says, there are two basic methods to dungeon generation: you either start with a bunch of rooms and then connect them, or you start with solid rock and carve out a maze.

As you might expect, implementations of the first method are more widely used. I’ve been playing Chocobo’s Dungeon off and on for a while now (over a year, I guess), and whenever I play it I start thinking about procedural generation. It’s quite obvious that the dungeons in Chocobo’s are a bunch of standard room shapes randomly scattered about a floor and then connected via corridors.

There is a code sample and live demo (in javascript) linked toward the end of this article, but if you’re impatient and you want to see what the heck I’m talking about, here is the demo!

Starting with the Rooms

In some cases, the shapes of rooms might themselves be randomly derived. I noticed that in Chocobo’s, there were some definite pre-created room shapes. I decided to try it that way myself. I created a couple of text files to store each room-shape’s data. I used a simple, arbitrary code for “drawing” the rooms with characters:

character	stands for
W	walls
f	floors
+	possible connection points
(space)	empty space

An example room:

W+WWWWW
Wfffff+
WfffffW
WfffWWW
WfffW
+fffW
WW+WW

Toss some Rooms together, one Row at a Time

At first it’s tempting to be really random when throwing rooms together. Most of the time, however, we want our rooms to collectively fit into a nice neat square or rectangle. Personally, I don’t want my rooms too spread out either. Which lead me to the next temptation – just create a grid and put one room in each cell of a grid. I think you can already guess how boring that might look. It’d be like someone built a dungeon on a tic-tac-toe board.

So I’m going for a compromise. First, I start with an arbitrary size limit – like: 30×40. Then I take things one “row” at a time – and by “row”, I mean a row of rooms. I pick a room at random, stick that into a list. I keep track of how much x-space (width) this room is taking up out of my maximum. I pick another random room (narrowing my list down to only rooms that will fit in the space remaining – adding 3 units to account for corridors in between), add it to the list, add up the total used space, and so on.

What I end up with is a handful of room shapes. I randomize the order of my list and start placing them in a row – as if I’m sticking objects side by side into a box – taking care to pad the breaks in between with 3 units to make sure there is minimum room for a corridor. Then I figure out the leftover horizontal space on the end of the box. I redistribute that space randomly throughout the whole “room row”, causing rooms to space out from each other a little if there is extra room.

At this point, the room-row is as tall as the tallest room. I can now shuffle the shorter rooms up and down randomly. Here’s a sample room-row:

W+WWWWW              WWW+W
Wfffff+   WWW+WWW    WfffW
WfffffW   Wfffff+    WfffW
WfffWWW   WfffffW    +fffW
WfffW     +fffffW    WfffWWWWW
+fffW     WWW+WWW    Wfffffff+
WW+WW                WfffffffW
                     W+WWWWWWW

Then we move on to another row of rooms, and another, as long as we have space to accommodate them. The key to keeping this as un-grid-like as possible is variations on room shapes – particularly, variations on widths and heights. Try making rooms that are large, small, long, tall, L shapes (pointing in various directions) and other interesting shapes.

Connecting Rooms with Corridors

There are a few different ways to go about generating corridors. You can specifically try creating them room by room, ensuring that every room is connected to at least one other room; the benefit of this method is that you never have to worry about having a map split into two segments, unreachable from each other.

I decided to go another direction though: almost totally random connections. The side effects of method are: a) you are not guaranteed that all rooms will be connected – you have to do some kind of test (like a flood fill) at the end and discard your dungeon if not all floor tiles are reachable; and b) you get some interesting results where rooms might connect to themselves by an external corridor across one side. I liked this second side effect, since it adds just a little less predictability to the process, so that’s why I’m doing it this way.

First, I find what I call the “nubs” of every room. These are the points out in space, just off the connector points that I used a ‘+’ to designate. I find each ‘+’, then ask “where is the blank space from here”? In other words, from the (x,y) of the ‘+’, I try N, S, E, W until I find the coordinates that have just a space (rather than a ‘f’ or a ‘W’). Then I take a random ordering of the “nubs” and for each one of those, I try connecting it randomly to every other. I check to see if a corridor could be drawn by first checking to see if a rectangle could be drawn, with each nub as a corner. If I can draw a rectangle without crossing any other filled coordinates, then we go ahead and make a corridor.

Drawing a Corridor

Making a corridor is pretty easy, really. You have a start point and end point. First, you have to determine which x-direction and which y-direction you need to go. For example: if your start is 2,3 and your end is 6,7, then you need to go positive in both x and y. If your start is 2,7 and your end is 6,3, then you need to go positive in x but negative in y. Then we randomly decide – either step in the x direction or step in the y direction. Each step we take, we make sure not to go over the ending x or y. For example, if we reach the x destination, then we stop picking x or y randomly and instead just step in y direction the rest of the way.

W+WWWWW          
Wffffffff WWW+WWW
WfffffW f Wfffff+
WfffWWW ffWfffffW
WfffW    fffffffW
+fffW     WWW+WWW
WW+WW

an example of a randomly drawn corridor

Notice that we didn’t bother with the walls – we’ve only mapped out the floor tiles between the start and the end points. After the floor is drawn, we can add walls by cycling through every floor tile and checking N, S, E, and W of each one. If there is a blank tile next to a floor tile, turn that blank into a ‘W’. Finally, we replace any unused ‘+’ tiles with a ‘W’ as well.

Code Sample and Live Demo

I wrote this code originally in Ruby, since it’s going to become part of the code-base for Aethora (no, you won’t see these kinds of dungeons in Aethora, but you will see a spin-off: a more “dungeon crawler RPG” type of game, less “tactics/strategy” type of game). I’ve taken the time to rewrite the algorithms as javascript so that I can demonstrate it easily on a web page and that more people will be able to dig into it and read it (admitting that more people are familiar with js than ruby).

Requirements for this code: I used jquery this time, so you’ll need that I’m using 1.4.2). I’m also using the small but awesome lowpro library, which allows for an object-oriented style way of writing behaviors for events on elements. This library was extremely useful when used with prototype, since prototype lacks the handy “attach” functions that jquery has, but I still find it nice for jquery because it allows me to organize event handling in a clean way.

If you view the source on the page (that I’m about to link to) you’ll notice a couple of other js files that I’ve created:

array.js – just a few helper methods for bastardizing the Array prototype to include sum, max, and min
room_template.js – a simple object class for encapsulating those room shapes that we set up in the beginning
mapper.js – an object class used to encapsulate the map generation functions

You’ll also see a small block of js in the source of the index file where RoomGenerator is defined – that’s the lowpro behavior. We just attach it to the “generate” form.

The room shapes are in textareas, so go ahead and tweak them if you want. Also you can play with the dimensions – I’ve given you a starting size of 30×30, but put in whatever you want. Use at your own risk!

Procedural Dungeon Generation Demo

One more note – notice that in this demo, we’re not checking to make sure all the rooms are connected. In my real code, what I do is: first generate a dungeon. Second, make a copy of the dungeon. Grab a floor tile of the copy and replace it with an ‘X’, and flood-fill out from there, replacing all f’s with X’s. Then I loop through the copy and make sure there are no f’s left. If there are, then I know those floor tiles were unreachable by flood-fill, and therefore unconnected. I toss out the dungeon and generate a new one (no, it doesn’t really take long to randomly generate these dungeons; a few milliseconds is all). Another option would be to somehow look for a way to force a connection between any disconnected rooms, by just finding any ol’ space where a corridor might fit.

Bonus Round: Converting ‘f’, ‘W’ into images

We’ve covered the generation of the rooms and corridors. If you’re making a text-based game, then just using ‘W’ to designate a wall works just fine. But if you want to convert those walls into image tiles, you’ll want to figure out how to place corners, horizontal walls, vertical walls, connecting walls, and so on.

To simplify this task, I decided to name my walls based on the directions a wall tile connects to other walls. Some examples:

WW
W

The first tile is a corner wall. It connects to a wall to the South and a wall to the East. It’s image name is wall_s_e.
The second tile connects only to the West: wall_w
The bottom tile connects only to the North: wall_n

WWW

The first tile only connects to the East: wall_e
The middle wall tile connects to the East and to the West: wall_e_w.
The last tile connects to the West: wall_w

It may seem a little backwards at first – because you think a wall is sticking out to the South, but it’s connecting to the North, so we call it wall_n instead of wall_s. There is a reason for doing it this way – it’s much easier to write code to detect which directions walls connect in than which directions they “stick out in”.

So anyway, it’s just a matter of looping through all the wall tiles and then checking: do I have a wall to the North? do I have one to the South? East? West? Okay, on to the next wall tile.

Before you know it, you’ve turned your W’s and f’s into tiles:

click the image for a larger version

Well, that’s all for today. If you have any questions, don’t hesitate to ask. I’m too lazy to put a license in the js code itself, but you can consider it licensed under MIT (so do whatever you want with it; credit would be nice, but not required). If anyone has the time to port this code to PHP, Python, perl, .NET, or whatever, please let me know. I can provide a ruby version on request, but if you’re patient, I do plan on releasing a whole giant chunk of the Aethora code base (which is Ruby on Rails) as open source.

RPG Reflections - Eschalon Book I

2010-03-14T21:44:00Z

Hey, everyone. I have been very lax on making posts to this blog lately, but I’m going to try to be more active. I’m a player as much as a developer, so I’ve decided to gather some of my thoughts about a few different CRPGs that I’ve played in the past year or so. These games will probably seem random to some people, but that’s me – I like to sample a little of everything.

Rather than write reviews, however, it’s my intention to reflect on the designs of games. There are things that I like and things that I don’t like, and I’d like to talk about why, and how the elements of these games affect my own game designs.

Eschalon: Book I

Basilisk Games – Linux, Mac, Windows – $19.95, downloadable (price as of 3/2010)

I’ve played Eschalon Book I off and on for the last couple of years. I finally completed a game of it sometime last year. It’s a somewhat retro-style single player RPG. Combat and movement is turn-based and the isometric graphics are laid out on an invisible grid. You get one character (no parties, pets, or henchmen) and there are a bunch of equipment slots. The game features a typical exp-based level system with skill points and character attributes. Be forewarned – it takes a lot of time to level up in this game. If you’re used to the ridiculous leveling pace of your average MMORPG, you may find yourself going through ding-withdrawal.

Eschalon: Book I – in the mood for a classic RPG?

There are a couple of things I really love about EB-I. First off, it’s cross-platform, so it already gets an extra look from me. I do all my day to day work in a Linux environment, and any game that runs natively in Linux is a game I am more inclined to try out to break up my workday. It’s developed by an indie game company, and I know when I spend $20 on the download, the money is going right to the developers. Oh, and there’s a playable demo, so you can try it before you buy it.

But enough of that – let’s talk game mechanics. I’m a big fan of the turn-based play; you take a step, all your enemies take a step, that kind of thing. It’s not much for “realism”, but it’s great for casual RPGs because you can stop and think about what you want to do – and if you have to stop in the middle of combat and answer email or something, there’s no pressure – you can always come back to the game and pick up wherever you left off. EB-I does turn based action very well. Tight hallways and small rooms indoors and in dungeons provide a nice contrast to wide open spaces in the wilderness, resulting in benefits and weaknesses to different fighting styles depending on the situation.

EB-I also features an interesting day and night system. The transition doesn’t happen all at once, but rather, you get various degrees of visibility as the sun goes down and it slowly gets darker. The map system is unique in that it requires a “cartography” skill. As you walk around the world, the area you can see gets drawn in on your map. The more points you spend on cartography, the more clearly and colorfully your map gets drawn.

Oh, how I love that mapping system

The storyline of EB-I is pretty decent. As a rule, I’m never blown away by CRPG storylines, but I can say I actually read most of the dialog in EB-I as opposed to mashing the skip button as fast as I can (as with some other games that tend to drone on and on about prophecies and gods I’m expected to know about). The game has a quest system that allows you to pursue the main storyline as well as several side-quests at any given time. The quests are pretty much linear – you either do what you’re told to or you don’t finish the quest.

There are a few interesting puzzles in the game. However, there are also a few faux-puzzles – those annoying times when you have to run all the way from one end of a dungeon to the other to hit a switch that opens a door back at the beginning. These kinds of annoyances seemed to be more frequent in the early areas of the game (which had the unfortunate side-effect of making me get bored quit playing it for a while). Later on, the exploration of new areas gets much more interesting.

In EB-I, all the enemies you’ll face are specifically placed throughout the world. For example, let’s say you walk into a forest clearing and encounter three lizards. If you were to start a new game with a new character and go to that same clearing, you’ll see the same three lizards. There is no respawning of enemies, either, so once you kill those three lizards you can revisit that clearing and you’ll never see any enemies there.

I’m not sure how I feel about this little quirk. On the one hand, it’s nice to be able to travel through an area already “cleared” without having to fight through more of the same monsters. But on the other hand, there are a finite number of enemies, and thus a finite amount of experience points (and thus, levels) you can get. If you find yourself getting stuck somewhere because you’re just not strong enough, you don’t have a way to go back and re-fight easier enemies to level up. It keeps the game challenging, I suppose, but depending on the class you pick, it can be a little too challenging to be fun. There is one way to “spawn” enemies, and that is to pick a spot outside and rest for hours and hours (in game, not real time) and get ambushed by traveling gangs of enemies; but that just feels… clumsy.

My take-away from Eschalon: Book I as a game designer and developer

This game is several years old, but they still sell it, and probably make new sales all the time. Honestly, due to it’s retro design, it’s protected from going out of style. Sometime this year they expect to release Book II (finally), and will sell it for $25. Anyone who has played through the first one will almost certainly spring for the second one (I certainly will). Some thoughts:

Having no easy way to fight randomly-spawned enemies is a small hang-up, but in terms of my personal preferences in game design, I would choose to include some system that would allow for it. Spawned enemies give a player a chance to practice different combat styles and tactics, try out equipment, and see how spells, potions, and special abilities work. It allows them to do a little “field testing” before heading off to fight tougher enemies.
The game has a pretty easy-to-master interface and despite it’s limited resolution, pretty decent graphics for an indie game.
I like the skill point system and the fact that some skills are not necessarily combat-based, but still worth spending skill points in (I love the cartography and mapping system, and also the alchemy skill and system is well done). There is a quick travel feature that allows you to jump back to a few select points once you’ve visited them – that’s a great feature for casual gamers like me.

That’s all for today. I don’t know about you all, but I’m suffering from daylight-savings jet lag – which makes this a perfect Sunday for veging-out with some video games. Have a good week, and keep on playing!

Rewriting Aethora's Battle Interface - Part 1

2009-07-24T15:06:00Z

Over the last several months, I worked out a whole new interface for Aethora’s battle screen. I’ve learned a lot about javascript in the last couple of years since the original design, and I felt that it was about time to scrap the whole thing and rewrite it from scratch. I’m breaking this article into two parts. The first part here will touch on what was wrong with the old interface a little, and then focus on performance improvements. The second part will focus on “point and click” interface improvements.

Beef with the original

The original design drew the battle map by actually drawing a huge table and putting a map tile in each cell. At the end of every turn, any NPCs that needed to take their turn would do so while the player sat and watched a big “Loading…” box, then the whole page got redrawn, the server globbing a huge amount of HTML back to the browser. The only evidence that any NPCs took their turns was in the battle log.

When you wanted to take an action, you had to first highlight a target. It was like a MMORPG – target first, then act. When you targeted someone, you’d get a list of valid actions depending on whether they were friendly or not, how close you were, and how many Action Points you had left. Some players reported that they often moved PCs one tile at a time, inching their way closer to see when they would be just in range for certain attacks. Many players complained that area-based attacks could not be placed in the center of a group of targets unless one of the targets happened to be standing dead center.

old UI: tabby

The old interface also featured a bunch of tabbed components to the right of the map. They held, individually, information about the character who’s turn it was, the help screen, the chat screen, the battle log, and the “turn order” screen (which showed all the PCs and NPCs in the order in which they get their turns, each with health and defense bars). Tabs are a great way to group UI elements when you are dealing with multiple pages of configuration, but when they hide elements that players want to see constantly, then they just become a nuisance. In particular, not being able to see the battle log and the full list of PCs/NPCs with their current status was a common player lament.

Setting the bar

new UI: everything is visible

I had a couple of goals for the rewrite:

no full screen page refreshing
show the player what the NPC are doing during their turns
minimize the amount of HTML needed
separate the javascript from the server-side code in a way so that either could be used without the other (having the mindset of an open API)
fit all the elements onto one compact screen with no tabs hiding information
improve the user interaction (moving characters and taking actions)
keep everything as generic as possible to lay the groundwork for PvP/Co-op in the future

So what about PvP/Co-op? Does this mean it’s not far off for Aethora?

Well, code-wise, there’s not a whole lot to do. The server-side code has to be tweaked a bit to allow multiple parties to participate in a battle. Some game design decisions have to be made:

Where will PvP be allowed?
What are the consequences?
How long will a player have to wait for another player to act before the game passes on their turn…
...or should it act for them rather than pass?
And how many turns are passed before someone forfeits?
What if it’s co-op?
Is the battle lost if someone times out? Or is it a “draw”?

A lot of questions still to answer before we go down that road, I’m afraid.

The first couple of goals kind of go together. What they amount to is a whole lot of javascript. I took advantage of the object-oriented aspects of javascript and roughly mapped some of my server side objects to javascript objects. When the battle window first opens, some HTML sets up the framing of the layout, and then a couple different ajax calls are made: the map tiles, the “mobs” (short for “mobiles”: in other words, PCs and NPCs), the chat log, the battle log, and the actions that are available for the PC with the “current turn”. Each of these calls fills in a different part of the screen (and actually, the actions-load doesn’t trigger until after the mobs are loaded in).

From this point, I can update any individual components as they are needed. When someone moves their character, the only thing that needs to be reloaded is that mob’s stats: to reflect the deduction of movement points and to set their x,y location on the map. If they take an action against another mob, then both of those mobs need to be updated. In both these cases, the battle log also needs to be updated.

Smaller bites of AJAX – or as the kids say these days… AJAJ?

All of these updates are AJAX calls, although as many people have started to point out, AJAX is not always Asynchronous Javascript and XML. In this case, I, like many others, have set aside XML and opted for the much leaner and easier to read JSON data format. So a request is made to the server, the server does some database lookups and some processing, then sends back a pure data response in JSON form. The javascript then takes the data and decides what to do with it. Since the calls are “asynchronous”, the javascript doesn’t have to wait for all the calls to come back to deal with the data; it can start updating the battle log when that data comes in and if the mob data gets in at the same time, it can process that too, more or less simultaneously.

The bonus of this strategy is that calls to the server are extremely short. The server only looks up a small amount of data and slaps it into JSON format on each call. The side effect is that there are more calls to the server. Would you rather have multiple short requests, or single, large requests on your server? If you’re concerned about connections, you might feel as though single large requests would be a better option. However the advantage to many short requests comes in during optimization.

Bastardizing the server-side code

I haven’t mentioned it to this point, but the server side code I am using is Ruby on Rails. I love Rails for the flexibility it gives me in developing database-backed web applications (insert your own favorite ORM / MVC web framework here – I’m not biased against any, I just happen to like Ruby a great deal). Where Ruby and Rails fall behind is on performance. A Rails server uses up huge chunks of memory, and this limits the number of requests it can take at one time.

When Rails runs in development mode, you can watch the log files and take careful note of the database calls that are being made. This feature allows me to look at each of the requests being made one by one and determine that – if somewhere in all those layers that a web app might have – unnecessary hits to the DB are being made. It also allows me to grab those DB queries and throw them into an EXPLAIN statement so I can determine if indexes are being used. Then I can simplify my Rails code and optimize my DB queries as necessary, to maximize the speed of each of those individual AJAX calls.

Why not use more caching? It’s a great way to speed up a web app!

Caching is great, and Aethora takes advantage of HTML caching as well as memcached for caching database-backed objects in memory. However, during a battle, many of the stuff is just changing too fast to bother caching. The battle log is just written as row after row of minimal data, and calls only need to grab the last few rows at any given time. The stats on mobiles are constantly changing during a battle.

The battle log is an example of where the ORM model gets in the way a little. Well, I should say – it gets in the way when it comes to reading the battle log table’s rows – it’s very handy for making table writes easier to code. When reading the battle log, it’s just as easy to go from database row to json as it is to go from object to json.

Items, skills, and actions, however, are all stored in the database as objects, and are more complex to work with. They are great examples of where using class-based objects really makes the code so much cleaner. Since they are fairly static, they get cached with memcache. That not only saves us the extra database call, it also saves the extra processing time it takes the Rails server to transform a database row into an object (because the memcached server in this case is storing a marshaled Ruby object).

And finally, as a major bonus – I was actually able to take some of those simplified queries and plug them into a few lines of PHP. Yeah, that’s right – I can run both Rails and PHP on the same web server – there’s no law against it! So, for example, the battle log – these requests are made constantly while an NPC is taking their turn, so the player gets the impression that they are watching the turn unfold in real time. There is nothing secret in a battle log – no user information or anything. It really is just about grabbing a couple rows of log data and a couple fields of mob data. Using ApacheBench to do a quick speed test, the PHP calls are a little faster than the Rails calls to get the same data. Punch up the number of concurrent connections, and you really start to see a difference: with 5 concurrent connections, the PHP script time was about 2/3rds that of the Rails time. The number of simultaneous Rails processes is limited by memory usage, whereas Apache can fire off PHP scripts by the gobs.

One important thing to note if you’re going to run multiple server-side engines to respond to AJAX calls: be careful not to violate same origin policy. If you need to run different server-side code under different subdomains, make sure to set document.domain (as described in those articles). I’m using the wonderful passenger module, which allows me to run Rails straight out of Apache. In this setup, Apache can bypass Rails to get anything out of the public directory (for images, CSS, javascript, etc). If it finds a php file in the public directory, well then, it’s business as usual. That way I can have: http://mydomain.tld/something/from/rails and http://mydomain.tld/minicall.php – same domain, different server side processing!

That’s it for the performance improvements – I’ll come back and give you another article that focuses on the point-and-click interface improvements.

Running an Event

2009-03-27T16:12:00Z

Been a while since I’ve posted, so I thought I’d at least mention what’s happening in Aethora right now.

We’re currently running an event called “Pioneers Week”. Here’s the short description:

Pioneers Week is the time when people all over Hopilus celebrate the anniversary of the discovery and colonization of their continent. They honor the struggle and the achievements of their forefathers, and due to this great attention to the past and its protagonists, the flow of ather itself shifts, temporarily, creating echoes of those who have lived and worked that walk around in places where they worked and acted.

You can find these echoes – ghosts, as some call them – although you have been told they are rather weak echoes, and that there are more powerful, permanent and natural ones all over Hopilus. All towns have some old town square or town hall where the first colonists of that town appear, and on the roads you may be challenged by others, who are remembered for traveling, and like a challenge or who have failed, and are resentful for it.

The event lasts one “week”, which really means two weeks. This is the second event we’ve done in Aethora, and I think it’s going … well, it’s going ok. One goal we have with events is to make them challenging. The skill system in Aethora gives us the chance to introduce new NPC-only skills just for an event, which really levels the playing field and even the most maxed-out players will find it challenging. Unfortunately, we are finding that we may have made the event a little too challenging. Some players are getting frustrated. The dedicated players know that if they stick with it, and start with the lower level areas and work their way up to the harder stuff, they will enjoy it. However, I think more casual players are turned off by the scenario. If they have played enough to be high level, they tend to start playing the event in the high level areas and then are quickly lambasted by the event NPCs.

So what have we learned from this experience?

Well, for one thing, we’re not going to add event-only “roamers” to the world next time. They can be a real pain in the neck for players – those players that logged out in a high level area, come to the event, and then want to travel back to the low level areas to train up have a chance of being jumped by roaming event NPCs surrounding those high level areas. As you can imagine, players find this a little irritating, because these NPCs are extremely tough. And, as my lead designer put it – not everyone likes being forced into an event.

Secondly, we’re thinking the event should be more focused – in other words, it should have a clearer goal. Perhaps centered around a certain mission or something. We like for certain aspects of the event to be repeatable, so the hardcore players can enjoy it fully, but I think casual players might appreciate achieving a sense of accomplishment by finishing the main “mission” of the event. In our current event, there are two “mini-missions”, but they are really just set-ups for single encounters with rewards for their completion.

Lastly, while an event is great fun and gives us a chance to flex our creative muscles, perhaps even introduce some humor and temporary silliness to the game, we know that “real” updates to the game would probably be more attractive to our player base at this point. Initially, we had hoped that doing a few events would be an easy way to crank out some temporary content to keep players interested in Aethora. Unfortunately, the work behind an event actually takes a lot more time than you might think.

The good news is that we’ll be able to re-use the work that we’ve done and bring two events back each year, with some improvements. In the meantime, it’s time to get back to work on more permanent content and code updates!

An iGoogle Gadget for your Game

2008-07-24T00:40:00Z

If you’ve ever personalized a Google home page, you’ve seen the various gadgets that can be added. These gadgets can also be placed into other web pages, blogs, and so forth pretty easily, and they share a very similar framework with “gadgets” in other sites, such as MySpace’s new MySpace Apps. In this article, I’ll show you how to make a simple gadget that pulls dynamic data from your game and displays it in a nice little box.

Here’s a basic gadget I created for Aethora that shows a player’s list of characters and each character’s skill levels. It also displays the Health of each character, which is nice – if you’ve ever played Aethora, you know that inactive characters heal up as time passes. This gadget is handy for seeing at a glance which characters are ready to get back into action. A little minor JavaScript makes it interactive, allowing you to click on the skills link and expand each character’s skill list.

Rather than go into detail about how I created this gadget specifically, I’m going to make up a generic game called Fake RPG and explain how to build a gadget for it.

0. What you need

Before we get started, let’s run down a short list of requirements.

A game to pull data from
Some knowledge of JavaScript
Firebug is highly recommended
A design in mind: a gadget is not like a full web page, so give it a little thought. I did my Aethora gadget at 320×300, but for this example, I started with a design that fits into 300×200 pixels.
Reference: Legacy Gadgets API Developer’s Guide

1. Prepping the Data

First we’ll need to create a page that will serve up our player’s data. We’ve got a couple of options when it comes to displaying data. We can use plain old text, perhaps CSV-style, but it’s probably best if we use XML or JSON. XML is typically good for generating well-formatted blocks of data intended to be used for a very broad range of applications. Parsing XML data in JavaScript is not real fun; thankfully, we have JSON, which is much easier to work with. In this example, I’ll be using JSON for that reason.

Most languages provide simple methods for getting JSON-formatted data. In Ruby on Rails, there is a handy to_json method that can be called on any ActiveRecord object, and allows for options such as restricting which attributes get displayed, including method calls as attributes, and including associated objects. PHP (5.2.0 and up) provides a json-encode function that translates any variable (be it array, string, or any other type) into a JSON string.

Let’s do this example with a simple PHP file. Since this is Fake RPG, we’ll pretend each player in the game has four player characters (PCs) and each PC has some attributes. I’m going to fake the data as if I pulled it from a database, but really it’s just a bunch of arrays.

<?php
function make_up_stats() {
  return array(
    'Strength'=>rand(1,20),
    'Wisdom'=>rand(1,20),
    'Dexterity'=>rand(1,20),
    'Luck'=>rand(1,20)
  );
}

// pretend we loaded some data from a database
$pc1 = array('name'=>'Jack', 'level'=>5, 'health'=>100,
        'stats'=>make_up_stats() );
$pc2 = array('name'=>'Jannus', 'level'=>6, 'health'=>25,
        'stats'=>make_up_stats() );
$pc3 = array('name'=>'Samathia', 'level'=>4, 'health'=>65,
        'stats'=>make_up_stats() );
$pc4 = array('name'=>'Keleton', 'level'=>6, 'health'=>0,
        'stats'=>make_up_stats() );

$pcs = array( $pc1, $pc2, $pc3, $pc4 );

$player = array ( 'name'=> $_GET['user_login'], 'pcs'=> $pcs );

// output as JSON
echo json_encode($player);
?>

Notice our flimsy little PHP script looks for a ‘user_login’ parameter in the URL to determine the player’s username. Normally, we’d use this parameter to actually look up the player’s data and whatnot, but this tutorial is about iGoogle gadgets, so we’re faking it. If we were doing this for real, we might consider using HTTP authentication or something like that. Aethora’s gadget does not require authentication, because the player and character stats that are being displayed are public anyway. The only real “danger”, so to speak, is that someone could display another player’s stats on their own web page using one of these gadgets (of course, they say imitation is the highest form of flattery, so I don’t consider that scenario much of a security breach).

Now we test our PHP script by pointing our browser to it. You can try this by going to my example at: http://examples.rangersheck.com/fake_game_json.php?user_login=Ranger+Sheck

Notice the string of data blocked out with {}’s and []’s; that’s JSON, baby, and it translates to pure JavaScript!

2. Creating a Gadget: the XML definition file

All iGoogle gadgets require a single XML file to start with. Google prefers that you host this XML file on your own server, but if you need to, you can use their Google Gadgets Editor to host your XML file. Since I want to break out my JavaScript and CSS for the sake of cleanliness, I’m going to host my XML file on my own server.

The entire XML block should be wrapped in a Module element. We start with a Module Prefs section. This is where we can set up the configuration for our little gadget as well as provide some miscellaneous data such as screenshots.

<?xml version="1.0" encoding="UTF-8" ?>
<Module>
  <ModulePrefs title="Fake RPG Character Sheets" scrolling="true" height="300" width="320" 
    description="This is an example of what you might do with a web-based game and igoogle gadgets."
    author="Ranger Sheck" author_email="rangersheck@skipintrodevelopment.com" 
    title_url="http://rangersheck.com"
    screenshot="http://examples.rangersheck.com/gadget/screenshot.png"
    thumbnail="http://examples.rangersheck.com/gadget/screenshot-tn.png" >
  </ModulePrefs>

Next, we add as many UserPref elements as we need. Each of these UserPrefs can be set by the user when they install the gadget. In this case, we only need to know the login name they use for our game, and we're going to make it a required attribute.

1	<UserPref name="player_login" display_name="Fake RPG Login name (username):" required="true"/>

Here we can start displaying some HTML. When an iGoogle gadget is displayed on a page, it's actually being displayed inside an iframe. That makes it easy for us to set up whatever we want in terms of HTML, JavaScript, CSS. Notice here, I reference a .css file, a couple .js files. Then I stick in some real basic HTML that will make a nice little two-column layout. At the end, I use a couple of Google's _IG_... methods to grab the UserPref variables and to make a call to a function once the page is done loading.

  <Content type="html">
   
  <![CDATA[
    <link href="http://examples.rangersheck.com/gadget/fake-rpg-stats.css" 
            rel="stylesheet" type="text/css" />
    <script src="http://examples.rangersheck.com/gadget/utils.js"></script>
    <script src="http://examples.rangersheck.com/gadget/json2-min.js"></script>
    <script src="http://examples.rangersheck.com/gadget/fake-rpg-stats.js"></script>

    <div id="content_div" style="width:300px; background-color: #EEE; margin:0 auto;">
      <div id="char_wrap">
      </div>
     
      <div id="details_block">
        <h1>Fake RPG</h1>
        <h2 id="login_name"></h2>
        <p><em>mouse over each character for details</em></p>
     
        <div id="details" style="display:none;"></div>
      </div>
 
      <div style="clear:both"></div>
    </div>

    <script type="text/javascript">
      // Get userprefs
      var prefs = new _IG_Prefs();
  
      // make JSON request once page loads
      _IG_RegisterOnloadHandler(makeJSONRequest);
    </script>

  ]]>
  </Content>
</Module>

3. Parsing the JSON and generating HTML

At the very end of the XML file, we are triggering a call to a function called makeJSONRequest. This is just a function I created myself in the file fake-rpg-stats.js. Let's take a look at that file:


function makeJSONRequest() {
  // This URL returns a JSON-encoded string that represents a JavaScript object
  var url = "http://yourdomain.com/fake_game_json.php?user_login="
  var url += escape(prefs.getString("player_login"));
  // here we call the iGoogle method that grabs the text from the url and passes 
  // it off to our responseHandler function
  // let's set the refreshInterval to tell it to grab the content every 10 minutes
  _IG_FetchContent(url, responseHandler, { refreshInterval: (60 * 10) });
}

function responseHandler(response) {
  // display error if we got bad response
  if (response == null || typeof(response) != "string") {
    msg = "<i>Invalid data. Response: " + response + " (" + typeof(response) + ")</i>";
    $("content_div").innerHTML = msg;
    return;
  }

  // parse the response string as JSON - note that the parser resides in the json2-min.js file
  var player = JSON.parse(response);

  // we're creating two chunks of HTML - one for the left side and one for the right
  // on the left side, we stack up the character names in boxes
  // on the right side are blocks containin each of the PCs details - they all start out hidden
  var pc_html = ''
  var hidden_pc_html = ''
  // loop through player characters
  for (var p = 0; p < player.pcs.length ; p++) {
    pc = player.pcs[p]
    pc_html += '<div class="char">';
    pc_html += '<strong>' + pc.name + '</strong><br/>';
    pc_html += 'Level ' + pc.level + '</div>';
    pc_html += "</div>";
   
    hidden_pc_html += '<div style="display:none" id="pc_detail_' + p + '">';
    hidden_pc_html += '<strong>' + pc.name + '</strong><br/>';
    hidden_pc_html += 'Health: ' + colored_number(pc.health) + '<br/>';
    hidden_pc_html += 'Strength: ' + pc.stats.Strength +'<br/>';
    hidden_pc_html += 'Wisdom: ' + pc.stats.Wisdom +'<br/>';
    hidden_pc_html += 'Dexterity: ' + pc.stats.Dexterity +'<br/>';
    hidden_pc_html += 'Luck: ' + pc.stats.Luck +'<br/></div>';
  } // end player characters for loop
 
  // set login name header to our player's name
  $('login_name').innerHTML = player.name;
  // fill in the left side
  $('char_wrap').innerHTML = pc_html;
  // fill in the hidden blocks on the right side
  $('details').innerHTML = hidden_pc_html;
  // now that the new HTML is generated, we can add some onmouseover functionality
  setupRollovers();
}

A couple of things to note here. I've created some "utility" functions that you can find in the utils.js file. These are basically just some prototype-like shortcuts for grabbing HTML elements and showing or hiding them. Also, since we want to safely parse the JSON, I grabbed the parser from json.org and minified it.

If you've never worked with JSON before, go back and take a look at the code from 'fake-rpg-stats.js'. Notice how we assigned the whole block of data (after parsing it) to the player variable. This variable is a javascript object, or associative array. That means all of it's children can be accessed using an object-oriented notation or an array notation. I find OO-style more readable, so when I want the player's name, I use:

1	player.name

but you could also use:

1	player["name"]

Notice how player.pcs is an array containing the PCs, and each of those elements contains a few attributes like 'name' and 'level' as well as another array of 'stats'. It's pretty basic JavaScript to loop through our array of PCs, grab the attributes from each, and plug that data into a block of simple HTML.

4. DHTML Magic

You'll notice the HTML in both the XML file and the stuff generated by our JavaScript is pretty bare. I've kept all the styling in fake-rpg-stats.css, and that's where you'll find the oh-so-fancy background images, text colorations, and block decoration. When you mouse-over each of the names in the left side of the widget, the "stats" for that character should appear on the right. The "setupRollovers()" function we call at the very end of our responseHandler can be found in that 'utils.js' file. This function unobtrusively grafts an "onmouseover" attribute onto each of the divs with the PC names in them on the left side. When the mouse goes over one of those divs, we want to hide all other player-detail divs and show only the one we moused over.


function setupRollovers() {
  pc_name_divs = document.getElementById('char_wrap').getElementsByTagName('div');
  for (var i = 0; i < pc_name_divs.length ; i++) {
    // need a way to reference the index of this PC, so set a pc_id attribute
    pc_name_divs[i].pc_id = i;
    pc_name_divs[i].onmouseover = function() { switch_to_pc(this.pc_id); };
  }
}

// display this PC's stats and hide others
function switch_to_pc(p) {
  // 'details' is hidden by default so we don't get the border with nothing inside
  show('details');
  pc_divs = document.getElementById('details').getElementsByTagName('div')
  for (var i = 0; i < pc_divs.length ; i++) {
    if (i == p) {
      show(pc_divs[i].id);
    } else {
      hide(pc_divs[i].id);
    }
  }
}

5. Testing the code in iGoogle

the finished gadget

Assuming you have an iGoogle account, and you're logged in, testing your gadget out is pretty easy. I like to have a separate "tab" for testing purposes. If you've never added a tab to iGoogle, notice that there is a Home tab just below the search form. Next to that, there should be an "Add tab" link - just click that to add another tab and name it Testing. Once you're in a Testing tab, you can add the "My Gadgets" developer gadget. Go to this page and click the "Add it now" button.

With this utility gadget, you can paste the URL of your base XML file into the "Add a gadget" form and your gadget will automatically show up under your Testing tab. Under normal circumstances, Google will cache your XML file, refreshing it only after an hour or so. During testing, this behavior can be quite the pain in the neck, but the "My Gadgets" gadget allows you to disable caching for your gadget just by unchecking a box. Note that this only bypasses the cached file for you. If this is a live gadget, any other users who are using will still only get an updated version of the XML file every hour or so. There is no way to tell Google to manually purge their cache of your gadget's XML file. If you make a change, your users will just have to wait until the cached version expires.

Notice that when you add your gadget to iGoogle, it prompts you for the "login name" for "Fake RPG". - That prompt comes from the UserPref requirement we set in the very beginning. Since I wrote the fake PHP script to take any username you give it, you can just type anything into this field and click Save. After that, your gadget should load. Note that a user can go back and change the value they entered for username by clicking the little down-arrow at the top right corner of the gadget, and then clicking "Edit settings".

6. End Notes

The iGoogle _IG_... functions come from an API that is currently being re-written by Google to conform more to the OpenSocial API. Changing over this example code to the new API is extremely easy. You'll only have to replace the three functions that start with _IG_. Most of them are just renamed using a gadgets.* namespace. The _IG_Fetch* functions are replaced by a more generic gadgets.io.makeRequest function that takes a parameter that specifies the type of content you're expecting to grab. In the new API, you can specify JSON as a content type, which means that you'll be able to drop the JSON parser library and skip the parsing step because Google's API will handle that stuff automatically.

At this time (July, 2008), the Google's implementation of the OpenSocial API is not public. You can register to try it out in some kind of iGoogle "Sandbox mode", but the gadgets.* stuff won't work for your general end-users at this time. It's worth checking out, however, because other sites that implement the OpenSocial API use the same gadgets.* format. I experimented a little with MySpace's implementation of "gadgets" (they call them Apps), but unfortunately, MySpace Apps don't use the UserPref setting (most likely as a security precaution - it's a minor miracle they are allowing any kind of javascript back into MySpace at all). So there's no way to prompt the user for their username on another, non-MySpace system. I haven't had time to experiment with the actual inter-linking of OpenSocial data, but I expect there's a way to use OpenSocial to get a MySpace App to act just like your iGoogle gadget. From what I can tell, MySpace uses a makeRequest function which can be used to fetch XML or JSON data, very similarly to the Google implementation.

That's all for now. Here's all the code I showed you in one archive: fake-rpg-gadget.zip. Now get started on some gadgets of your own!

Game Design Principles - Part 2

2008-06-28T00:54:00Z

Continuing from Game Design Principles – Part 1.

Game Design Principles behind Aethora (5 through 9 of 9)

5. Good strategy should mean combining lots of different skills. The appearance of a successful strategy that utilizes only one or two skills is an indicator of imbalance.

Everyone who’s ever played a MMORPG knows that balance is always an ongoing issue. The developers are always making adjustments to classes, abilities, equipment, and so forth. The sheer quantity and variety of factors that are involved make the concept of total balance something that’s impossible to achieve during the design phase. You can get pretty close, but one thing a designer has to remember – you design aspects of the game with certain intended uses, and the balancing you provide is based on those intended uses. When players get ahold of the game and start using things in ways you didn’t intend or anticipate, you’re going to discover new imbalances. It’s a fact, Jack.

So one easy rule of thumb that I’m using here, somewhat specific to Aethora, but in general I think a good strategy: If I notice that a player is gearing up all their characters with the same gear, then I can guess that they think they have found an attack or two that is far superior to other attacks. Sometimes, this strategy is a bad one. Other times, the player could be onto something – there may be an attack that makes a battle much easier to win and other attacks are inferior by comparison.

The overall point is, at least for Aethora, the game is party-based. A good party in any RPG should have some variety. Characters tend to fill different roles, such as melee, magic-user, healer, and so forth; or in common MMORPG-speak: Tanks, DPSers (damage-dealers), Buffers, Healers, Crowd-Controllers, and various other “Support” roles. So, in Aethora, I want to see the good players using a broad mixture of skills in combat.

6. Victory in combat on average should be decided by factors in this pecking order: Good strategy > Higher Skill Levels > Better Equipment

Aethora is a tactical, or strategy RPG. Party-based combat on a map is the core of combat, so I try to spend some time thinking about what makes map-based combat fun and challenging. I like to think of a tactical RPG almost as a game of chess; but instead of simply different move-patterns, the pieces have different offensive and defensive abilities. Since the game at it’s core is still a role-playing game, the whole point is to advance character development; so character skill levels should, of course, make a difference when it comes to combat. The secondary method of character development in an RPG has to do with acquiring better equipment, and clearly a well crafted longsword should outperform a rusty fire poker.

So the goal of this principle is this: good equipment is no substitute for adequate skill levels, and skill levels are no substitute for good strategy. In other words, a player should still have a chance to win a fight in which they are outclassed in terms of equipment and skills, to a certain degree, as long as they employ good strategy. Likewise, if a player has a poor strategy going into a fight, expensive equipment will not save them.

To achieve the “Higher Skill Levels > Better Equipment” part of this principle, there is some real basic math going on. The combat formula uses some weighting to give advantage or disadvantage between attacker and defender skill levels, and then a lesser weighting when comparing attacker’s weapon strength with defender’s armor strength. Making “Good Strategy” the most important factor in combat is a little trickier, and it relies pretty heavily on principle #5.

7. No “punishment” paths in missions (quests). Any path that “burns a bridge” should be roughly equal in benefits to any other path.

Mission-writing has been a primary goal of our development team in the last few months, so I felt it necessary to lay down this particular ground rule. It’s very tempting to create a branching point where a player can chose to do the “right thing” or the “wrong thing”; after all, decision making is part of the challenge of doing quests or missions. So if a player chooses the “right thing”, maybe they get a little more gold in the end, or even a better piece of equipment as a reward; and that makes sense. However, it makes me a little uncomfortable to see a situation in which a player might do the “right thing” and gain access to another mission later on, where the player who picks the “wrong thing” ends up at a dead-end.

Mainly this principle has to do with Aethora being somewhat of a “casual” RPG. I’d hate for a player to become frustrated and quit because they missed out on something when they took the wrong path – especially when the decision was tricky (and often these things are not obvious). Since this is an online game, and not a single-player game, there is no previous saved game to reload when you make a mistake.

So I devised a simple formula for “factors of mission outcome equality”: Chance for another mission = 100; unique piece of equipment = 10; monetary reward = 1

In other words, two branching mission paths that both offer another mission are roughly equal (100 vs 100). Two branching paths in which one offers gold but the other offers equipment are close enough to equal (10 vs 1). Branching paths in which one offers a new mission but the other offers only one piece of equipment are not close enough to equal (100 vs 10). But, if you really want to write two branching paths and let one lead to a new mission and another lead to a bag of unique equipment (like say 8 pieces, or 100 vs 80), then I’m more likely to allow such a choice (as long as the storyline makes sense, of course).

What we end up with is less chances for “right” and “wrong” paths and more paths that are just “different” – and I’ve found that these can be much more interesting. You can see that I’ve made an assumption here that what players want most of all is to do more missions; I think for the majority, that’s part of the fun of the game. Completing a quest or a mission is an accomplishment. Therefore, a chance for another mission outweighs material rewards many times over.

8. The best RPGs incorporate fun and engaging gameplay as well as quality story lines. These are two dimensions on one grid; to cover the maximum amount of area possible, both dimensions need to be stretched.

At this point, I’m going to take a moment and re-iterate that these principles are largely based on my personal opinions when it comes to role-playing games. The first part is easy: if gameplay – and by that, let’s be frank, I’m mostly referring to combat – is weak, then I’m not going to play a game. Combat needs to be interesting, engaging, should not feel overly formulaic, should not be too long and should not be too short. That’s a pretty tall order to live up to, but remember, this is a principle – an ideal – I’m aiming for. I’m not claiming that I’ve reached it 100% with Aethora.

To be honest, if the gameplay of a particular CRPG is pretty good but the storyline is inane, there’s still a pretty good chance I will play the game. Let’s face it – storylines in CRPGs for the most part are pretty thin, so players have learned to deal with it. That being said, when I look back on my most memorable experiences with CRPGs, the games that had great storylines stand out the most.

So you see, these two factors can combine to make a great game. However, it’s my opinion that you’ll lose people quicker if gameplay is weak. If gameplay starts out good but becomes tedious later on, you may lose more people that way as well. Ranger Sheck’s inner voice: “If you want people to play the game, you better make the game fun to play.” But, then, I love to write, and I know how memorable a good storyline can be, so with this principle I’m recognizing that good stories are going to help make a mediocre game reach for greatness.

I’m willing to bet some developers (especially browser-based games, where text is easier to work with than graphics) are going to disagree and claim that a good story should carry the most weight. I love a good story! And for that reason, I do a lot of reading. A lot. Even the best storyline in a game cannot come close to a good book, and so when I want a good story, I don’t want to sit in front of my computer screen and read page after page – I’ll sit down with a good book. That’s why it’s my opinion that quality writing can greatly enhance, but not carry, a CRPG.

9. There is a third dimension that is unique to online RPGs: player community and interaction. While more difficult to stretch, this dimension bears much greater potential.

This last principle expands on the previous one, to serve as a reminder of why “online” role-playing games are different than offline CRPGs. Aethora needs a lot of work in this area, because other than buying and selling equipment to other players and some sharing of information through chat and forums, there isn’t much other player interaction. I recognize the fact that having a more interactive community really has a profound effect on the popularity and “stickiness” of an online RPG. Therefore, this principle is here at the bottom, not because it’s the least important, but the one that Aethora needs the most work on.

I have some big plans in this area, and I just need to find some time to work on them: – Player crafting and tradeskills to increase market trading between players. – Contests and tournaments where players can face off against similar groups of NPCs and see who does the best – Player versus player combat (I’m still on the fence about this one, as the nature of a web-based game introduces a lot of potential issues) – The ability for players to own land and populate land with guardians – even to the point at which a player might create an entire “dungeon”, populate it with baddies and treasure and then invite other players to come try their hands at it. My ultimate goal, to put it simply, is to have ways for players to generate content.

Well, that about wraps it up. Comments? Questions?

Game Design Principles

2008-06-28T00:28:00Z

A couple months ago, I made the change from being the sole developer and writer for my game and invited some of my players to join me in creating a design team. While all the coding responsibilities still rest on my shoulders, the other designers have been contributing artwork, mission plots, non-player character design, weapon and armor design, area design, and so forth. I quickly realized that while it’s possible for people to get a sense of what a coder’s thoughts and motivations are by playing their game, there are still many aspects of a game’s design that are not so easy to interpret.

When I set up a forum for our team to collaborate in, much of the initial conversation was brainstorming about changes or additions to make to the game. I found myself defending and explaining various methods and components of the current design and what those explanations meant for future design. I realized that while I am open to other ideas, there were certain things that I wasn’t likely to budge on. The more I thought about it, the more I began to understand that I had internalized a set of principles that guide the path of development for my game.

Do I think all games should follow these design principles? Certainly not! Many parts of this list were born out of being unhappy with one particular aspect or another of a game that I otherwise enjoyed; some other parts were born out of recognizing which parts of existing games I think were done really well. But without a wide diversity of drivers and factors behind game development, where would we be?

So you may agree with these principles, and you may not. The perspective they are written from lies in the development of a role-playing game; specifically a computer role-playing game (CRPG), and more specifically than that, an online, web-based, strategy (or tactical) role-playing game. To date, combat is the largest aspect of my game, and since it is a tactical RPG in terms of a combat system, some of these principles might only make sense in that context. Others, however, are more universal.

As you read these, please take note: The words are mine, but the thoughts behind them come from an accumulation of years of experience in playing, thinking, and talking about games. I don’t claim any kind of exclusivity or originality on any of these concepts.

Game Design Principles behind Aethora (1 through 4 of 9)

1. No wrong path for character development.

This principle is at the top of the list for a reason – it’s the one that was the foundation for the character system in Aethora. This character system, while not 100% unique, is very rare in the broad range of RPGs out there, because it is classless. In a role playing game, you need roles, and in most games this role is chosen from the start as a job or a class. In some cases, it can be changed or it has branches later on in a character’s development. In Aethora’s case, the character has no class, but simply a set of skills. There are no levels, no experience, no points to spend. When you want your character to learn how to fight with a sword, you have to put a sword in their hand and get them to battle. The more you use a skill (against better and better enemies) the better you get.

The big seeds for this principle are in my frustration with pretty much any role-playing game. As much as I love to game, there are always those people out there with much more time on their hands. There is always someone to figure out which combination of race and class is the best, which branch is the best part of the skill tree to take, etc, etc. Inevitably, I’d be feeling like I made a mistake at some low level or even at the point of character creation that didn’t fully manifest itself until I got to a higher level and realized I’m just not as effective a character as I could be, but there’s no way to correct it without “re-rolling”.

In Aethora, you are not allowed to delete any characters; you can only change their name or appearance at any time. If you decide that one of the roles a PC is playing is not the ideal role for the balance of your party, you simply re-equip them and start them down the path that works for you. No regrets means no re-specing and no re-rolling.

2. Roleplaying for roleplaying’s sake, not as an excuse for convenience.

This principle is not so much a hard and fast rule, but more of a guiding ideal. I think, at the core, what this comes down to is honesty. If players are given some obviously convenient excuse for the blockage of a path or method, then they are going to lose trust in the game designer. Blatant abuse of “magic” explanation or other non-explanation of game mechanics weakens immersion, and when immersion breaks down, a player is going to start to see the “human side” of the developer. If you’ve ever played Pencil and Paper role-playing game, you may remember some moments when your Dungeon Master tried to railroad you down a path that they had meticulously laid out for you. Sometimes a player’s natural reaction to being railroaded, oddly enough, is to try to jump off the tracks. This is the kind of thing that reminds a player that they are playing a game with limitations; and that’s what I mean by “weakening immersion”.

Take the example of a 3D MMORPG. A lot of times, travel can be a real pain for players in a ginormous 3D world. To keep people from getting frustrated, developers might introduce ridable mounts that increase travel speed. This example makes perfect sense – the player doesn’t have to stretch any imagination to get on a horse and move a little faster. Now say, after a while, the developers decide that players aren’t getting to all the new fancy areas they’ve put in, so they want to make travel even more convenient; so they introduce a magical teleport system where any player can walk up to an area and be beamed over to another area fairly easily. While the new system is certainly more convenient for players, this is, in my opinion, an example of breaking the RPG setting and simply making it easier to get to the hack-n-slashing. When a player has to cross a long expanse of land to get to their destination, they develop an appreciation for the vastness of the world their character inhabits. When they bounce around via a loosely-expounded teleportation device, the world becomes a lot smaller.

3. Avoid imposing realism in favor of fun.

In some ways, this principle is the opposite of #2, but it takes a slightly different mentality. When designing an RPG system, it’s tempting to try to be as realistic as possible, whether it’s in combat, travel, basic survival, etc. One of the classic examples is the notion of hunger. In EverQuest, like many text-based MUDs before it, a player is required to carry food and drink with them at all times. In the old MUDs, you used to have to manually eat and drink food until you were satiated. In Everquest, they automated it slightly by making your character periodically eat something from their inventory. If the character had no food, they would start to get hungry (and eventually, once hungry enough, penalized in combat).

For a lot of players, this type of realism is part of the challenge of role-playing. For many others, however, it becomes just a big pain in the neck. It’s not really very mentally challenging, unless you consider trying to remember to buy food when in town a mental challenge. For me as a player, it became the most annoying when I regularly ran out of food while out adventuring and sometimes had to trek back to town just to fill up.

Whenever something like that happens, the player feels like they are doing work rather than playing. Sometimes, you have to do a little work in an RPG – that’s the nature of that style of game. As long as it’s balanced by fun, then a little work is okay – but too much work overshadows fun. That’s kind of a key point, so I’m going to restate it: If I feel like a game is making me do too much work, I’m not going to play it.

4. Heroes don’t have time for pest control jobs, I don’t care how inexperienced they are.

This principle might be specific to the setting, but honestly, I think it can be applied to most role-playing games out there. Ok, sure, the point of an RPG is that you start with small challenges and work up to larger challenges. But why, oh why, do I always have to start out killing rats? Don’t you think it would be a little more fun if we started our characters a little later in their careers? In D&D terms, I’m talking about starting at level 3 or so instead of level 1; when I first start out let me fight some orcs instead of garden snakes. I mean, come on – can you even imagine trying to stab a rat with a dagger? Wouldn’t it make more sense for that shopkeeper to just put down some rat traps or some rat poison?

So why does a typical RPG start you out on pest control duty? To be honest, I think designers like to make those first couple of levels ridiculously easy so (a) you’ll get used to playing the game and (b) you’ll get addicted fast. All of us RPG addicts are sucked in by accomplishments. We live for that “ding” sound, and once we’ve gone from level one to level two, we feel like we’ve made an investment.

The “pest control” concept goes beyond those initial stages of character development, though. For this reason, I’ve made it one of my principles. Whenever you ask a player to: clear an area of infestation/invasion/etc; bring back N number of pelts/sashes/ears; scavenger hunt for ores/oysters/Easter eggs; in any kind of typical mindless hunter/gatherer scenario, you’re basically giving the player busywork. You’re not challenging them with making appropriate decisions or problem solving – you’re acting like that doddering old substitute teacher who would come in and make the class do macaroni pictures or origami rather than attempt the lesson on fractions.

Again, why do we see this style of “quest” so often in RPGs? They make good time-sinks. Sometimes mindless play is actually pretty entertaining; heck, sometimes that’s exactly what we’re looking for in a video game. But personally, I feel like there are enough opportunities in any online RPG to go out and enjoy mindless combat. If I’m really on some kind of Quest or Mission, I want a little more of a challenge. To me, that’s what defines a Quest or Mission: it’s a challenge (and there’s a reward when it’s complete).

Continue reading principles 5 through 9 in Game Design Principles – Part 2.

Introducing MoveableMap

2008-03-18T15:23:00Z

I posted this on my other, more tech/web-dev oriented blog, but since it’s a great tool (or at least example to learn from) for web-based game developers, I figured I’d mention it here.

MoveableMap is a javascript library (open source, MIT license) that allows you to turn any block of HTML into a draggable, moveable entity within a viewport. Similar to the draggable behavior of Google Maps, but hopefully very easy to implement.

More information and demos can be found here: MoveableMap

Statistics: What are the real odds?

2008-03-08T19:08:00Z

Wow, it’s been a while since my last post. I wish I had time to do this more often, but such is life.

I’ve been thinking a lot about statistics lately, and how they can be used in game design. We’ve all seen this problem in any game, particularly indie games (including a lot of browser-based game) – a problem with randomness. Sometimes a game doesn’t appear to leave enough to chance, and it becomes predictable. Other times a game is too random, to the point of frustrating a player when despite skill or a “better hand”, fate can easily turn against them.

This article will be the first in a series of probably three articles on statistics and randomness. Today I’d like to talk about what it means to consider the odds that an event might happen, given multiple attempts at it. For example: if an event has a 25% chance of occurring, you might expect that given 4 attempts at it, you’re pretty much guaranteed success. Given a second thought, we know that not to be exactly true. So what are those odds, anyway? More after the jump.

Let’s start with a simpler example: the good ol’ coin flip. Flip a coin once – what are the odds of getting heads? 1 out of 2, or 50%. If you flip a coin 8 times and it came up heads every single time, what are the odds of one more flip being heads? This is, of course, a trick question. The odds are still 50/50 because each flip of the coin is unaffected by any other flip. The individual flips are independent events. How about the probability that by flipping a coin twice, both times it comes up heads? There are four possible outcomes of two flips of a coin (H=heads, T=tails): HH, HT, TH, TT. Right there we can see that two heads occurs once out of four possible outcomes, so the chances are 1 in 4, or 25%.

This example leads us to the Multiplication Rule for Independent Events. Independently, each flip has a 50% chance of coming up heads. When events are independent, to find their cumulative probability, you can multiply their individual probabilities. Probabilities are always calculated as a number from 0 to 1; the equivalent of 0% to 100%. So to get the chance of a getting two heads out of two flips of a coin, we multiply:

P(heads and heads) = P(heads) x P(heads) = 0.50×0.50 = 0.25

In other words, 25%.

How does this relate to a game? Knowing how to calculate the cumulative odds that an event will occur can help identify when an event has been set up to happen too rarely. Imagine a scenario where a player has to search three chests and each time there is a 20% chance that a chest will contain some amulet. In order to get to a secret room, the player needs to get all three amulets. You might think that sure, the odds of getting the amulets from all three chests are against the player, but there’s still a pretty good chance. Let’s find out.

P(amulet and amulet and amulet) = P(amulet)³ = (0.20)³ = 0.008

In other words, there’s a 0.8% of getting all three amulets. Less than 1% – that’s pretty close to impossible! Even if the player is allowed to attempt the task periodically, it’s likely they will never achieve the goal.

Let’s try a different angle. What if we know what the percent chance is of an event and we want to know what are the odds that it will happen at least once given a set number of trials? For example, taking the coin flip – if I flip a coin twice, what are the odds that I will get heads at least once?

If you recall, the four possible outcomes of two flips of a coin (H=heads, T=tails): HH, HT, TH, TT. In this case, we win if the outcome is HH, HT, or TH. That’s 3 out of 4, or 75%. Another way to make the calculation is say the probability of the first coin getting heads is 0.50 (HH or HT), and the probability that the first coin was not heads but the second coin was heads is 0.25 (TH). Since either of these combinations means success, we add them together:

P(heads on first flip OR heads only on second flip) = 0.50 + 0.25 = 0.75

Now of course, neither of those methods are very helpful when doing anything more complex than a couple coin flips. A third way we can look at the situation which lets us use the multiplication rule is to think of it in terms of what is the probability that the event does not occur. In other words, what are the chances that both coin flips will come up tails? If we can find that, we can take the inverse of it to find the probability of our desired event.

P(tails and tails) = (0.50)² = 0.25
P(not both tails) = inverse of P(tails and tails) = 1 – 0.25 = 0.75

As you can see, the inverse of a probability is found by subtracting that probability from 1. All three methods have shown us that the chance of getting at least one head out of two coin flips is 75%.

Now let’s think of a more useful scenario. Let’s go back to our three chests story, but this time we’ll say the player only has to get one amulet. The chance to get an amulet from a chest was 20%, so the odds that they don’t get an amulet from a chest is 80%. They have three chances (because there are three chests), so let calculate the odds they don’t get a single amulet from any chest, then take the inverse again to find out if the player has a decent chance of getting at least one amulet:

P(no amulet and no amulet and no amulet) = (0.80)³ = 0.512
P(at least one amulet) = 1 – 0.512 = 0.488

In other words, they have a 48.8% chance of getting at least one amulet in three tries.

Let’s take this example a little further, because I really want to point out a common misconception about odds. The chance to get an amulet is 20%, or one out of five. Logically, you might think that if you give a player 5 chances, they will be guaranteed to get the amulet once. This faulty logic is often referred to as the Law of Averages (which is not actually a “law” of real mathematics at all). Given what we’ve learned, let’s see what the real odds are for a player finding at least one amulet in 5 tries:

P(no amulet and no amulet….etc) = (0.80)⁵ = 0.32768
P(at least one amulet) = 1 – 0.32768 = 0.67232

Given 5 tried, the chance of getting one amulet is actually only about 67%. It’s likely, but it’s far from a guaranteed success, isn’t it?

So how do you guarantee success based on probability? Well, you’re going to have to do it programmatically, because no combination of probabilities (other than all events getting a 100% chance) is ever going to combine to become 1.0. If you flip a coin 100 times, it’s extremely likely you’ll get at least one head, but technically there is one outcome that would result in 100 tails.

Let’s look at one last example so we can see how more chances increase the likelihood of a success. Let’s say a player is on a quest and has to get a special belt that some orcs wear. One out of ten orcs wear this belt, so we set up the game to give any slain orc a 10% chance to drop the belt. If the player kills just one orc, they’ve got a 10% chance to get their goal. Let’s look at the chances of getting a belt for 5, 10, and 20 slain orcs (notice that the chance of not getting a belt is 90%):

P(at least one belt in 5) = 1 – (0.90)⁵ = 1 – 0.59 = 0.41 (or 41%)
P(at least one belt in 10) = 1 – (0.90)¹⁰ = 1 – 0.35 = 0.65 (or 65%)
P(at least one belt in 20) = 1 – (0.90)²⁰ = 1 – 0.12 = 0.88 (or 88%)

Even after killing 20 orcs, there’s still only an 88% chance of success. When we said 10%, we were thinking the player would have to kill about 10 orcs, but turns out even killing 20 orcs is not as close to 100% as we’d like! Now that we’ve done the calculations, we can see that we may be frustrating players with these odds. Let’s readjust and try a 15% chance for an orc to drop a belt (85% chance they don’t drop one):

P(at least one belt in 5) = 1 – (0.85)⁵ = 1 – 0.44 = 0.56 (or 56%)
P(at least one belt in 10) = 1 – (0.85)¹⁰ = 1 – 0.20 = 0.80 (or 80%)
P(at least one belt in 20) = 1 – (0.85)²⁰ = 1 – 0.04 = 0.96 (or 96%)

Hey, that’s a little more reasonable. We might even want to tweak it a little farther; at least now we have a method to determine the real odds.

In summary, when it comes to probabilities, don’t rely on “instinct” or faulty logic like the “Law” of Averages. Some simple calculations can give you a much more concrete idea of what kind of chances you’re giving your players.

Interface Design in a PBBG - Sound Familiar?

2007-09-12T23:51:00Z

Browser-Based Game designers, take note from some of the web-based app designers: the term “Look and Feel” means more than you think! Win back some of those players you frightened away by seeing your game through their eyes and giving them some familiarity to start with.

Which came first?

In the web-based application development communities, once in a while you see this kind of chicken and egg argument pop up. The question is, which design comes first, code or interface? A lot of solo developers like myself go right for the code. After all, without a solid code design plan, with data models and business functionality, the application is useless. Google didn’t become the most popular search engine because it looked pretty; it works well, that’s how it became popular.

Your graphical people, of course, will go the other way. Google is the exception to the norm, they’ll tell you. Especially in today’s Web Too Oh world, first impression is key, because people can leave a website just as quickly as they arrive.

Of course, it’s more than just visual aesthetics. As websites move deeper into that uncanny valley and look more and more like real-deal applications, designers and developers must take into consideration their site’s interact-ability. The key questions are: What does it look like from the client’s perspective? What does it feel like to the client?

So, I switched sides. Yes, I know – code base is very important. Data structure is very important. However, let’s be frank – that’s the easy stuff. That’s the logical stuff. The hard part – the thing that sets you apart from everyone else (or makes you look the same) – is the interface. Not to mention, when you start your design from the interface side, you’ll find some things you would have missed. You think a lot harder about what it’s like to be in your client’s shoes.

It talks like a duck, but walks like a Sasquatch

Familiarity is a design concept that becomes important here. The more your web-based application acts like real application, the more your clients are going to treat it like one. When they begin to recognize certain interface elements, they will start attempting to use other elements, like shortcuts, or they will start looking for familiar context menus, like the kind you get from right-clicking in a normal application. The moment they hit CTRL-S expecting to save a record or a document and it doesn’t work, their trust in your site is broken. Their browser’s implementation for that key combo fires off and they are reminded once again that it’s not really a full blown application, it’s just a web site.

With browser-based games, the same problem exists. After all, computer games are nothing but entertainment applications. As javascript, Flash, and other technologies allow web developers to create browser games that act more and more like full blown computer games (or even console or arcade games), we’re running into that familiarity snag, but it’s two-fold. Not only will your players be looking for familiar interface elements, they will be looking for familiar gameplay elements. Games are a lot more varied than business applications in both these respects, so it’s going to divide your client-base into two factions: (A) people that play tons of games and realize that every time they pick up a new game, they may have to learn some new gameplay concepts and they may have to master a new interface and (B) people that play only a few games and only really like something new when it closely resembles something they’ve seen before; if it doesn’t, then it better be something that’s not hard to learn or get the hang of.

The Lost Players

The big problem is, those people in that second group – that’s the majority, and those people will walk away the fastest. I’ve seen people on dev boards say time and time again, “well, if it doesn’t look great but it’s fun to play, I’ll enjoy it”. That’s probably true for a lot of people, even people in group B – the problem is, most of them are leaving before they get a chance to find out that a game is “fun to play”. They’re not going to take the time to leave you feedback either and let you know what turned them off.

Let’s look at some possible reasons for new players to give up on your game within five minutes:

They got lost. Right from the beginning, they didn’t know what to do.
They thought they were getting into a game they would already know how to play (they were wrong).
They thought they were playing a game that would be easy because it’s a game on the web (they were wrong).
They saw half-assed graphics and figured the game was unfinished and not worth their time.
They found little on-screen help and a separate manual consisting of tons of pages that were hard to read and probably uninteresting.

Some of these people, they’re on their coffee breaks, they’re killing time, they’ve got a meeting in 20 minutes; they’re looking to web-based games as a spend amounts of time in varied increments. Maybe they want to kill 10 minutes, maybe they want to kill an hour or two. If you hit them over the head with some interface that looks and acts like nothing they’ve ever seen before, and a game that plays like nothing they’ve seen before, they’re going to get frustrated and look for something easier.

The Balancing Act

Obviously, we don’t want to make cookie cutter games that all look and feel the same way. I’m suggesting that when you can create familiarity, you create comfort, and you alleviate frustration. When you can’t make an element familiar, whether it’s an interface element or a gameplay element, then make sure it’s easy. Easy to use, easy to understand – look at it from the perspective of someone else (someone who’s not a developer). The key is to find that balance between the unique and the familiar.

Many games pride themselves on their depth. Too much complexity translates to a bunch of white noise, static, to the first time player. When you want to add complexity, do it in bite-sized increments – open up features one at a time to players after they get comfortable with the basics. During development, only add new features when you’re sure the simpler parts are solid. Honestly, it’s better to have a few concepts that work really well and look really good than a whole box of unfinished pieces (with lots of “potential”).

And definitely don’t hit your players with all the information available up front, let them discover some things on their own – it’s part of the reward of playing a Persistent BBG.

The Death Penalty - Handling Defeat in CRPG Design

2007-06-04T05:02:00Z

Computer Role-Playing Games are notorious for lacking in actual ‘Role-Playing’. Your typical hack-n-slash CRPG takes the mechanical concepts behind pencil-and-paper role-playing games and automates them, giving these games a much greater focus on combat more than anything else. Once the mathematical base of a CRPG is established, often times the role-playing aspect is grafted on afterward, like fake skin on a robot. On the surface, it looks like a role-playing game, but underneath beats the gear-filled heart of a cold, calculating mechano-man.

Due to the combat-centric nature of most CRPGs, one of most malformed aspects of their ‘role-play’ is Death. CRPGs provide faster and more plentiful combat, which inevitably leads to a great deal more death than a pencil-and-paper RP session. Depending on the game setting, unchecked death of both non-player and player characters alike can really distort any kind of believable storyline. Many CRPGs go out of their way to explain the use of magic and divine intervention in their settings, but most of the time not only is the death of character usually extremely temporary, character “respawning” is generally flimsily explained (if at all). Non-player death fits into two categories: either non-player entities stay dead once killed, never to be heard of again, nor have their deaths questioned by anyone else; or upon death some cosmic timer ticks over and respawns them periodically.

I’d like to talk about the abuse of death and non-player entities some time, but today I want to focus on player death. In a pencil-and-paper RPG, death is usually permanent. If you have a generous Game Master, there may be ways around it, but chances are pretty good that there’s going to be a creative plot-line to go along with any form of resurrection. In a single-player CRPG, death is usually pseudo-permanent; I say pseudo because you can always reload a saved game. If the game is party-based, then you may have that typical flimsily-constructed method of resurrection (e.g. take them to church and say a little prayer/pay a little cash and presto, alive again).

In an online CRPG, you don’t have the luxury of reloading a saved game. To keep people from just giving up, game designers need a way for players to respawn. Let’s face it, no one is going to keep coming back to a game if they have to make a new character every time they die. The old telnet-based MUDs set the standard for player respawning – upon death, you found yourself back in your home town (usually in a church or other sanctuary). You probably lost a level and all of your equipment and maybe even your gold. Banks became extremely important to players that needed to get back into the game after a death and may have stashed extra equipment and money. MMORPGs started out following the MUD standards; however, as time goes on, MMORPGs attract more players who have less and less gaming experience (RPG or otherwise), and have subsequently softened the blow of Death, so to speak. In many MMORPGs, dying does not result in loss of equipment or skills or levels or whatever. A player may lose “experience points”, or in some cases merely acquire an “experience debt” that has to be worked off.

In many cases, whatever the Death Penalty, player revival typically goes unexplained. In your average fantasy MMORPG, you die, you respawn at some kind of “home point”, and maybe you have to sit out some “death effects”. No one lets you know which god kindly plucked your body out of one place and trans-dimensionally reconstituted it in another place, dusting you off, patting your behind and wishing you well on your next adventure. A notable exception to this norm (speaking primarily of fantasy-based MMORPGs) is PlaneShift, in which if you die you awaken in the underworld. Not much explanation is needed for that situation, and I think it’s a creative way to deal with death. That being said, if you’re not familiar with the game, navigating your way out of the maze-like underworld can take you nearly an hour (unless you’re lucky enough to run into another lost soul who knows where they are going).

What’s a computer role-playing game designer to do? History shows us that any integration of player death/resurrection and a believable role-playing storyline ain’t gonna happen. So we expect players to accept resurrection (with weapons and armor still in tact) as a run-of-the-mill activity. Happens all the time, no big deal. They accept magic and monsters and all the rest of it, why should we focus on believable death scenarios?

Sadly, we’re forced to resort to using death as a venue for penalizing a player for biting off more than they can chew. This is the part where role-playing collides with game-play. The more you attempt to incorporate story-like role-playing into character death and recovery, the harder the game becomes. When death is frustrating, players quit, and with persistent online games, the loss of a player is the loss of regular revenue. So designers are forced to turn their backs on role-playing to compensate. In my opinion, as the years go by many games have over-softened the Death Penalty. This is especially true of MMORPGs, who prefer to keep players no matter what and often sacrifice challenge for revenue.

When I was in the initial planning stages of design for Pioneers of Aethora, I had a bug up my butt over the ever-weakening Death Penalty I’d seen in MMORPGs. In my game design, a player has a collection of eight characters, four of which can be placed into an active party at any given time. You go into combat with your four characters, facing off against a group of non-player characters. Winner takes all. The role-playing explanation is that defeat means surrender, and the victors should strip everything away from the defeated, no matter which side wins. The losers walk away empty-handed. Sounds fair, right? And I got out of trying to explain death, because no one actually dies! Meanwhile, since you have eight characters total, you can bench injured characters and give them a rest while you play with fresh characters. No divine intervention or beam-me-back-to-town tricks called for. I thought I had the role-playing aspect and the death penalty nicely wrapped up.

Of course, there were a couple problems. First of all, defeated characters lost all their equipment – not just what they were wearing and wielding, but what they had in their inventories as well. Since there is no bank (as of yet) in Aethora, the only way to stash extra equipment is to move it around and make sure it’s not in the inventory of any active characters. Obviously, this kind of stock-piling is quite the pain in the neck – but failing to do so would result in a player losing a ton of equipment in a defeat. Secondly, there is no way to judge what the ability of your opponents will be before you jump into a battle – in some areas, the encounters occur randomly without your choice to engage. This problem makes it possible for players to end up in combat they could never win. Finally, there was no way to retreat from battle.

Some players just dealt with these issues. Other players I believe accepted the penalty for what it was, but I fear many may have lost interest in the game along the way in unspoken frustration or perhaps even boredom – acquiring new equipment might mean going back to fighting enemies well below the player’s challenge level. One player (who happens to be a real life friend of mine) suddenly became extremely vocal about the issue a few weeks ago, and I decided to reevaluate my game’s Death Penalty. After mulling over the possibilities, I came up with some options that I feel provide some kind of balance to those ever-conflicting forces: role-playing, challenge, and player enjoyment.

First off, I changed the loss of equipment to be only the equipment being worn and wielded by the characters upon defeat. The non-player characters aren’t carrying unused equipment around anyway, so it still seems fair. The RP explanation? The victors can only walk away with so much stuff, so they assume your best gear is the gear you went into battle with. Secondly, adding the ability to flee from battle was essential. There is no real role-playing reason for keeping this feature out of the game, my reason was purely mechanical. In Pioneers of Aethora, skills are earned in real-time during combat – you take a swing with a sword, you have a chance of increasing your sword skill right at that moment. So my concern was that allowing players to flee from battle might entice some players to go into fights and notch up a few skills, then run off. Therefore, in order to maintain some challenge, fleeing characters lose a few skill points.

It’s actually worked out rather well so far. If a player senses defeat, they can choose whether they will lose equipment or skill points on a character-by-character basis. Since the fleeing option has been implemented, I’ve seen it used quite often. What’s encouraging is that a player who flees from battle often enters another battle somewhere else shortly afterward – a sign that the death penalty is not deterring defeated players from continuing play.

The party-system in Pioneers of Aethora plays a large role in making defeat play well with role-play. MMORPGs and other CRPGs don’t have that luxury if a player represents just one character, but can’t they do better than RETURNING TO HOME POINT?

(if you’ve held on to the story this long and want to read the short blurb I wrote for the players, it’s in this update, with links to more details in the in-game forums. Registration required to read the in-game forums.)

PBBG - Persistent Browser-Based Games

2007-05-29T18:29:00Z

Today I learned a new acronym: PBBG. Persistent Browser-Based Game. Acronyms are great because they are these kind of self-importing entities that have the potential to carve something substantial into the world’s vocabulary. Just by the very act of instantiating a new acronym, you’ve taken the first step towards establishment, acceptance, and eventually, household knowledge.

Ok, maybe that’s a bit extreme, but one thing you can say about an acronym – the subject of an acronym is being talked about enough and with enough consistency to warrant abbreviation.

I’m here to embrace PBBG. I happen to be the sole developer of a PBBG (a label I applied just today, of course) called Pioneers of Aethora (more about that later). It’s actually an extreme convenience for this acronym to come along. I’ve been googling about, trying to find suitable testers for my game, and lemme tell ya – it’s hard to nail down what a PBBG is. You’ve got your web-based games, probably 99% of which are Flash-based and are most definitely not persistent (unless you count scoreboards). Then there’s “online RPGs”, which typically lands you in MMORPG-dreaming land. Or you can try “Indie games”, which will probably help you find some great sites and forums, but I’ve noticed that’s these places are usually looking at downloadable/installable games (they’re usually receptive to web-based games to some degree, but it’s not their focus). Lastly, trying to search on anything too generic with “rpg” in it drums up a whole lotta stuff about Pen and Paper RPGs (including independently produced P&P RPGs, which I would have found extremely cool at one time).

So what exactly is a PBBG? Well, there’s a definition at http://pbbg.com/ that’s pretty good. Essentially, we’re talking a game that you play in your browser; as in no installable/executable. But it’s not one of these puzzle/casual/action/arcade kinds of games where you play, get a score, try to beat your score, get addicted, try to beat everyone else’s score, etc. Instead, the game is persistent. Typically, this means it’s going to be a role-playing game of some kind. You create a character (or characters, or a kingdom, or a pet monster), you play a little, you go away, you come back tomorrow and pick up where you left off.

It’s the pretty standard concept behind an RPG, but I’m glad someone created this acronym to distinguish these browser-based RPGs from other web-based games, and as well from non-browser based “online/multiplayer” RPGs.

It’s not just the name, or the acronym, however, that makes me happy about this; it’s the fact that we’re witnessing a new gaming genre being established. Sure, it may be yet another spinoff or sub-genre of some pre-existing concepts, but the scaffolding for this PBBG genre has some very unique and exciting characteristics. The last couple years have been all about Web 2.0, and while it’s hard to distinguish hype from reality, there are aspects of Web 2.0 that lend themselves very nicely to web-based gaming.

Let’s consider some of the hurdles an independent game developer faces when constructing a game.

UI development. Personally, I’ve started work on a few games myself that began as text-based, and when it came time to start adding a graphical interface, well… that just steepened my learning curve a bit, didn’t it? With a web-based game, you can do a hellavalotta presentation with HTML and CSS, and when you need to, javascript can fill in the cracks.
Data retention. Serializing classes and writing them to files, reading them later, trying to keep them indexed, etc. I never got very far with that part either. With a PBBG, you’re most likely developing with a language that has built-in hooks into any database you could think of (not to mention memory caching options).
Networking. I never got this far with any of my games. I had a lot of spectacular plans, lemme tell ya, but it wasn’t gonna happen. Obviously, not an issue in PBBGs – you get the networking for free.

There’s probably other stuff I’m not thinking of. All this PBBG talk makes me think there are others out there just like me – big aspirations for developing a game independently, but too many obstacles. Now I’ve got this game that’s downright playable. The progress of web technology has given us a new platform, a new sandbox to play in, where our unrealistic and perpetually unfinished projects can get closer to actuality. Just like the youtubers who suddenly discovered that they too could film a video and share it with thousands of people, we’re realizing that we can develop our own multiplayer, networked, persistent games.

And we don’t have to use C. Or C++. Or C#. Or (as Q-Bert would say) C#$%^&.

Have Kingdom of Loathing and Neopets paved the way for a gaming revolution? Or just another cool acronym? Here’s hoping it’s both.