The Three Biggest Problems Facing PBBG Designers Today
Problem #1: Party Of Two Or Two Thousand
You know how board games always have something on the side of them that says, “For 2-5 players,” or something like that to indicate how many people the game is sized for? It’s partially a practical thing, they can’t include enough cards or tokens or a board large enough for a group of 30, but it’s also a factor in the game itself. It was never tested for 30 people, for that matter it may just not work very well when scaled to 30, 300, or 3000. There are PBBGs out there with 30,000 people on a single server, how do you even design a game like that?
I have no idea. Literally, no idea whether the game I’m working on now will be fun when I throw lots of people at it. It could suck. It will suck, the creator of BattleMaster virtually guarantees it, and you know what? He’s probably right.
My current hope is that I’ve got a good idea for a game and I’ve taken the same path a lot of games take by giving every player basically the same starting conditions so they’re left to their own devices in competing with other players. But is just starting with a level playing field enough? Is there a way other than playtesting and adjusting, playtesting and adjusting to have a better idea of how to make a game interesting when you don’t even know how many people are going to play it?
One possibility I’ve considered is the idea of forcing division into groups upon the players. Creating a game and really balancing it well for say 25 and then as players join they automatically get assigned to a group until it hits the magic size and the game gets going in earnest. So a single server might be running hundreds of games at the same time rather than one game with thousands of players. Short of sites that let you play real board games online (e.g. http://gametableonline.com/) , I’ve not seen anything like this though and as with all these questions, I’m not very sure how well it would work short of building a complete game and testing it.
I know it does offer some possible advantages because you can actually have certain people fill certain roles. There will be only three people who can be doctors, two police officers, 12 zombies, etc. The roles are set and they play them out till the end of the game. Cooperative games are all the rage in the board game world right now and often they work on this very principal (e.g. Battlestar Galactica). I’m so-and-so and here’s what I can do. I have in-game abilities that maybe nobody else in the game has and vice versa. You can even have traitors who are working against the group but nobody knows who they are or perhaps even if there are any.
But then what do you do when one of them leaves?
Problem #2: Someone Comes To Town, Someone Leaves Town
In addition to being the title of a book by Cory Doctorow that I really enjoyed, this is how I describe a problem that I see as one of the worst ones a persistent online game may face. People come, try it, and then leave never to come back. Or they join it to stay but only a couple of days before it is scheduled to end or after all the empires are all built up and the game experience is completely different from players who started the game together.
Board game players don’t face this problem nearly as much. Sure, people get called away for emergencies on occasion, but the social convention is that if you’re coming to play that you’ll stick with it until the end of the game. Board games tend to have fairly short lifespans compared to PBBGs though. With timeframes of weeks or months their games are much more likely to have people quit because of something coming up or losing interest. What happens to those players? Are they a zombie that sits there unresponsive while the player is gone? Do they become a computer controled character when the player is away? Do they fade away as though they never existed?
New players are more easily dealt with. They can be shunted off to a newly opened game in order to keep them from joining too late. Or, if you design an open-ended game then perhaps it won’t matter when they join. Most MMORPGs are constrained to their world needing to exist in a kind of weird stasis. Yes you obliterated that dungeon full of bad guys yesterday. Today, it’s all put back together so someone else can go do the same thing. You’re living in WestWorld and Yul Brenner’s gunslinger will be just fine as soon as we repair him.
Problem #3: Numbers, Complexity, and the Digging of Holes
The last of three big problems that I see PBBGs having to deal with is the problem of numbers and complexity. It’s not that board games don’t have to deal with lots of variables and complexity too, they do. The introduction of a lot of different elements is what keeps a game from being something easily analyzed and “solved” to the point where it’s no longer fun to play. The problem is again one of scale.
Any board game designer has to deal with complexity by saying, “What can my players manage in their head with a few additional play aids I might give them?” Scoring, number of pieces, number of cards, size and complexity of the board are all constrained by what real people can really hold in their hands/calculate/see. But as soon as you get a computer involved the temptation is to throw out all of that. I don’t have to have only four kinds of armor, I can have 40! I can have 150 different weapons, all with subtly different values for attack and defense. I can even have each one keep track of how sharp it is. It can get worn down over time…
But then that complexity comes home to roost when it’s time to actually playtest that game. How do you adjust a game with four thousand variables without getting your own version of the butterfly effect. One little tweak here makes a huge difference over there, or perhaps even worse, a huge change here has almost no effect because of the unforseen influence of some other things you can’t seen working in the background. The more complexity you put in, the richer your game seems. But at the same time you’re digging your own grave deeper and deeper.
This is probably the most solvable of the three big problems; just scale back. But scale back to what? Unless you’re willing to lock the number of players per game at a fairly small number, what are the effects of a small tweak when it may change things for hundreds or thousands of players? Is it going to completely upset the economy in your game?
In Conclusion
What do you think are the biggest design problems PBBGs face? Have you seen solutions to these problems in existing games or have ideas for solutions that no one has tried yet? I know I’m looking forward to hearing from others interested in PBBG game design on these and other problems.
Post-mortem: Forumwarz – We’re not dead yet!
In addition to doing an interview with us, Evil Trout from Forumwarz also wrote a post-mortem. Here were his thoughts:
For most retail computer and video games, once your game gets shipped into stores, the job is done. Sure, there may be bug fixes or future downloadable content, but those require a skeleton staff and minuscule budgets compared to the development of the initial game.
On a browser game, the process is a bit different. Since there is no physical product shipping out in flashy boxes, you can deliver new content with virtually no deployment costs. However, in this sense, it means the job is never quite done. It becomes a constant effort to continuously improve the product. It also becomes trickier to try to sell it.
So this article will be a little different than a “post mortem” on a typical console or retail game, as I am still actively working on the project. Forumwarz is my full-time job. At any given time we have a lengthy list of enhancements we want to add to the game. In a given week, I typically deploy 10 to 30 updates. Most of them are small bug fixes or enhancements to streamline the process, but sometimes they are larger features that make up entirely new components of the game.
What’s Forumwarz?
Forumwarz is a parody role-playing game. You play it in your web browser. The hook is, instead of playing as a knight battling orcs in dungeons (or whatever), you role-play an Internet user “pwning” fake internet sites. Yes, that’s right: Forumwarz is an Internet game where you simulate an archetype of an Internet user. You can play as a Troll, Emo Kid, Hacker, Camwhore or Permanoob. Within the game’s universe, there are hundreds of fake internet sites that you navigate to, leveling up, gaining new abilities and employing new equipment. You also meet and interact with all sorts of interesting and sometimes bizarre characters along the way. We like to call it “the Internet — in game form.”
Our team is quite small. I’m Robin “Evil Trout” Ward, the only full-time employee and I’m responsible for the programming. I came up with the initial idea for the game. Our head writer is Mike “Jalapeno Bootyhole” Drach and our third partner is Jason “BINGEBOT 2015″ Kogan. I’d say at this point all three of us are game designers and heavily involved in every aspect of the game’s development.
The Perks
It is awesome to have created something from nothing (okay, nothing but a high-speed internet connection and healthy dose of caffeine). A few years ago, Forumwarz was just an idea, and now it’s a game that players enjoy every day. I remember the first few pieces of fanmail I got and how awesome it was to hear people gush about it.
My professional background in programming before Forumwarz was J2EE and PHP, although I’d dabbled in many other languages in my spare time. For Forumwarz, I decided to try out Ruby on Rails because I’d heard positive things about it. I quickly fell in love.
Ruby made all other programming languages look ugly to me. Rails made complicated web tasks simple. I found it easy to jump in and start learning, but hard to master. I am still learning to this day and it’s a huge privilege to be able to work with it.
The Doubt
Before I worked on Forumwarz, I was a web developer who implemented other people’s ideas. This sometimes meant doing things that I thought were wrong for the products I was working on. Don’t get me wrong: I understand that I was building software for other people in exchange for their money, and I was happy to build things however they wanted it. But there was always this feeling in the back of my head that, “Wow, if that was my money I would do things differently.”
It’s one thing to constantly tell yourself that you wouldn’t make the same mistakes that other people make. It’s something completely different to step up and start putting your money where your mouth is. In fact, it’s downright terrifying.
I remember when I first started telling people about the game. Some were friends and family. Some were members of the local Ruby/Rails community. I must have explained the concept several dozens of times. I am not exaggerating when I say that, save one or two exceptions, I always received a blank stare. It wasn’t hard to read their reactions: They either didn’t understand the idea or, worse, thought it was stupid. The honest ones even told me so (and I appreciated it)!
If I could go back in time and give myself only one piece of advice it would be: Doubt is normal. If you are investing your time and money in a new venture or project, you will doubt yourself.
I worked for over a year on Forumwarz before we opened it up to the public. I kept up a furious pace of development, working 10-12 hours a day, usually taking one day a week for rest. I was investing an enormous amount of time in something that I couldn’t even explain to people properly! Before we launched our beta, I’d tell myself on sleepness nights that at least it was a blast to learn, and it gave me the opportunity to fall in love with Ruby on Rails, so it wouldn’t matter if only five people ever liked it. Still, I knew there was someone out there who would get the joke.
Launch
We launched the game in an invite-only beta on Halloween 2007, through the popular Something Awful forums. Hundreds of people played that day, and we watched them post their responses. Our entire team was blown away at how much positive feedback we received right out of the gate.
To this day, it remains one of the most positive experiences of my life. I learned a valuable lesson: Just because other people don’t get excited about your idea doesn’t mean it’s a bad one. I’m not sure if I was just terrible at delivering the pitch. Or maybe Forumwarz is a game that’s simply better experienced than explained. It’s likely a bit of both.
We took off the “beta” tag and opened our doors to the public in early 2008. We quickly grew to 30,000 accounts. In October, we launched our second episode of the storyline which had a small fee ($10) to play. Shortly thereafter we hit 100,000 accounts and have been growing aggressively since. Word-of-mouth recommendation and positive feedback from influential sites like Wired.com and Gawker gave us the initial boost in membership, and we’ve followed up by advertising wherever we think we have a chance of being noticed. Now, after about a year of being open to the public, we’ve seen more than 130,000 people sign up for the game. I can finally say with confidence that more than a few people do get the joke.
Growing Pains
Scaling from 1,000 users to 100,000 users in one year presents a great deal of difficulties. When I say “scale,” I am not simply referring to the site’s performance (although we underwent several major hardware and software upgrades to sustain the load). I am also referring to the infrastructure you need to deal with a community that large.
If your forums get 1,000 posts in a day — especially on a site that’s essentially “about” flaming forums — will you have the resources to moderate them?
What about bug reports? Would you expect that many users will submit a bug reports just because they can’t solve a puzzle in the game?
A small percentage of your users will try and hack your site. Most people are smart enough to avoid SQL injection, but is your site safe against XSS or XSRF attacks? And there are other, less immediate issues related to having a suddenly large community. Some users will simply email you with personal comments and you’ll seem ungrateful if you don’t reply. In a given day, I receive hundreds of emails related to the site (errors, correspondence from users, bug reports, etc). If I responded to each one I wouldn’t have any time to work on the game at all!
This is something we are still very much working on. We have elected a couple of moderators who are doing a great job maintaining our forums. We recently launched a knowledge base to help people find answers to their questions, but it’s far from perfect. I know that we’ll never be able to help every user through the game, but we want to make sure that people have as close to a painless experience as possible.
Having a thick Skin
Gamers are awesome because they’re often intelligent, focused and passionate. However, that also comes with the side-effect of them often being quite opinionated.
Gamers will criticize just about every decision you make. A certain percentage of it can be ignored as trolling, but sometimes I’ve made decisions that I thought were in the best interests of the game and it wound up upsetting many people.
Forumwarz has evolved to encompass many different gameplay styles that all interact in one game ecosystem. As I mentioned before, our team is small. We do our best to think things through, and we often solicit our users for feedback on upcoming features. However, in my experience, no small group can effectively predict how tens of thousands will use a new gameplay feature. We do our best when we launch new content, but the real testing is done when all those eyeballs fall upon the page.
If there is a major problem with something, it shows up immediately. Fortunately, since the game is web-based we can deploy updates quite quickly. In fact, I have gotten somewhat used to only launching a feature when I’m sure I’ll have a couple of days set aside to throw up patches to address any initial issues.
As I said, most of our users are passionate because they truly love the game and want it to be the best game on the web. Their feedback is invaluable. Others, however, can be quite mean. If your project ends up attracting any kind of sizable community, be prepared for nastiness. People will say hurtful things, and they will make it personal. Sometimes I find it hilarious (like when they Photoshop my head onto images) but other times it does sting. So make sure you have a thick skin!
The Road Ahead
I recently read a comment on the Hacker News (http://news.ycombinator.com/item?id=424111) that resonated with me:
I asked Jessica Livingston to speak at the business of software conference, and I suggested that
she talk about all the ways Y-Combinator startups fail. “That would be boring,” she told me, “it’s always they same thing: they just stop working on it.”
As someone who has started hundreds of software projects in my lifetime (most of which only lasted a few hours of development), I fully understand this. Keeping a web business online involves working hard through many periods of doubt. Most people don’t stop because they are starving to death and can’t feed their family; they stop because they have grown tired of it or have been discouraged by some kind of recent event (perhaps income drops, a new feature was a disaster, etc).
I’m quite proud of Forumwarz and the community it has spawned. It is worth the occasional sleepness night or headache to keep it going. Ultimately, it’s been quite rewarding to work on and I will continue doing it as long as I possibly can. If I hadn’t persisted through the doubt when this started two years ago, I’d still be developing other people’s ideas and wondering if anyone would get the joke.
Save bandwidth while improving performance!
Bandwidth can be very troublesome, especially if you’re at a limited hosting solution, with only a small amount of gigabytes to serve per month. If your site uses a substantial quantity of images and scripts, you may find yourself having a big problem.
Lets imagine that a new user goes to your site and he/she will need to download 100kb of scripts and images, plus the XHTML page. If you have 50.000 requests, you’ll serve a significant quantity of bandwidth. And you may even serve static content to old users if you don’t configure correctly your static content headers.
Step 1 – Decouple the static content from the dynamic content
First you need to prepare your game to be able to get your images/scripts from anywhere. Instead of linking like:
<img src="/Images/Sample.png" />
You need to code your application to link like:
<img src="http://some_host/Images/Sample.png" />
And have the http://some_host easily configurable somewhere. That way you’ll be able to change the location of your static content and make use of content distribution networks. This can be a complex task if you leave it to the end, so you should start as soon as possible using this strategy. Note that this way you may still use your main server URL for static content.
Step 2 – Use a Content Distribution Network
Now that you have a configurable static content location, you have several options to consider. For example, if your game is open source, you may create an account at SourceForge.net and then you’ll have your own web space to use. You could then configure your game to use as a location for static content something like:
http://your_game_name.sourceforge.net
And that’s it! You’d save a lot of bandwidth and server load just by changing some configuration. But having an open source game isn’t always an option. Fortunately, there’s a free content distribution network named Coral CDN that is very easy to use. Imagine that your game is at the http://your_game_name.com url and that you configured your static content location to http://your_game_name.com. To use Coral CDN you’d have just to change the static location to:
http://your_game_name.com.nyud.net
Appending the “.nyud.net” will make Coral to automatically act as a proxy to your content and cache it. For example, you can try it at this site: buildingbrowsergames.com.nyud.net.
There are other CDN solutions out there, some will cost more money and will be better. A great advantage of CDNs is that they have servers all over the world and will sync your data all over them. So, if your server is in England but you have a user from Japan, the CDN will serve the static content from the nearest server, and your user won’t need to fetch content from the other part of the world.
Step 3 – Configure Static Content Headers
So, by now you don’t have to worry about bandwidth, because you’ll have a third party serving it for you. But there’s something more you can do to improve user experience. When a browser requests content it may cache it according to the server configuration. But if you don’t configure the server properly, the browser may ask for the same static file over and over again.
This won’t be costly for you, but for the user experience. If a user makes a request to your game and the browser has everything cached, the request will be almost instantaneous! However, if the browser needs to refresh data, it may ask for the static content again, and that may implicate that your user will have to wait a second and see loading images.
Resources
This article is just an introduction to make you aware of static content problems and how to solve them. To learn more about client side performance, you can study the Yahoo’s Best Practices for Speeding Up Your Web Site. They have a lot of useful tips, and if you use Firefox, you may install YSlow, an extension that will rate your site in terms of client side performance.
Another great tool to use is something like Fiddler, that allows you to see all requests made by the browser, headers, and so on. By using it you’ll see where you can improve.
Interview: Evil Trout from Forumwarz
Back when I asked who Building Browsergames should approach, you all commented and e-mailed with your thoughts on games you’d like to hear from. Some, like Travian, have already told us that they will not be talking to us. However, some games have responded favorably, and I am hoping to post their responses in the coming weeks.
One of those games was Forumwarz – I managed to get in touch with Evil Trout, the developer, and ask him a few questions. His answers are below, and I’m hoping that we’ll see a post-mortem soon.
Tell us a little bit about Forumwarz.
Forumwarz is a parody role playing game about the Internet. Instead of playing a wizard slaying goblins in dungeons, you can play as a camwhore “pwning” forums on a fake version of the Internet. You communicate with bizarre non-player characters via an instant messaging interface, buy things from online stores and basically laugh the whole way through.
Honestly I’ve always felt the game is better played than explained, so if you head on over to http://www.forumwarz.com and click “New Game” you can start to get a feel for the game before you even have to register for an account.
You launched a second episode of Forumwarz a while ago that was “pay to play”, and caught some flack from players. Was it what you expected?
It was always part of the plan to charge for future episodes. In fact we talked about it back in early interviews: http://waxy.org/2008/02/forumwarz/
In early 2008, we didn’t hear much about it, but as Episode 2 got closer to release we started getting a lot of feedback. As you pointed out a bunch of people had negative things to say and yes, we did expect that. People would always rather play something for free than have to pay for it!
I think a lot of people didn’t understand that it costs money to run and develop a game. We weren’t asking for money out of greed, it was to cover our costs and to continue to improve the game.
What are your thoughts on charging for your game?
I’m happy to say now that it has worked out quite well for us. A few people predicted it would be the death of Forumwarz, but things are more active now than ever! We recently passed the 120k user mark.
Is there anything you’d do differently for the next episode?
We had a very aggressive timeline for Episode 2 that nearly killed me 
I think for Episode 3 will we give ourselves a longer timeline and use that to make it even better.
One of my goals is to make the battles and equipment more varied. Pwning forums is fun, but I think it could be a lot more strategic.
What first got you into browsergame/PBBG development?
I’ve always been obsessed with gaming, and I’d been working in web development for years. It was a logical jump, I think, to try and create a browser game. To be honest I’d barely played any before, I just wanted to try out my idea of forums as a game!
What made you choose Ruby on Rails as a platform for Forumwarz?
I’d been working in J2EE for years and had grown quite sick of it. I’d heard a lot of buzz for Ruby on Rails around the web, and I downloaded Rails to just dick around with it. I didn’t think I would take to it as seriously as I did. I just loved how quickly I was able to get stuff done. It didn’t take me long to get hooked.
What was your most significant challenge building Forumwarz?
The hardest part is having all these awesome ideas and not enough time to get them done! Also, gamers tend to be very passionate about games and that makes them quite critical at times. You have to have a thick skin, because every day a dozen strangers are going to tell you how you could be doing your job better 
What was the least significant challenge?
Probably the discipline to work on it every day. I know some people have problems committing to projects, but if you really love what you’re working on it should be easy to devote lots of time to it (or maybe I’m just a masochist.)
What plans do you have for forumwarz, going into the future?
We have a bunch of cool aspects we want to build on top of it to make it more interesting, as well as our commitment to getting Episode 3 done and to conclude the current storyline.
Do you have anything to say to budding browsergame developers?
Just work on something you really enjoy. I think the rest comes easy.
You can check out Forumwarz at http://forumwarz.com.
Interview: Tom from BattleMaster
In addition to writing a post-mortem, I was also able to secure an interview with Tom, the developer of BattleMaster. This is what he had to say:
Tell us a little bit about BattleMaster.
Well, I tend to want to create games in niches where I don’t see anything already. I don’t feel like making just another FPS or RTS or whatever, I’ve always wanted to make the stuff that nobody else had made.
So in the browser-games environment, you have a lot of realm-building games, and you have the old MUD and freeform roleplaying area. But very little that mixes and merges both. I had a freeform e-mail game about 10 years ago, and BattleMaster started out as a strategy extension. Then I found there’s nothing like it on the market, where you have a realm-building game but it’s not one player per realm, but you have internal politics, and characters with enough depth and history to allow roleplaying.
Ever since, I’ve been walking the fine line between RPG and strategy game.
You mentioned in your article that battlemaster has been under development for 8 years – were you ever tempted to give up? What kept you motivated to work on BattleMaster?
Yeah, there have been times. Several times in those 8 years I’ve just taken a step back and not done anything on the game for a month or two. The great thing about BattleMaster is that it runs anyways. Even when there are bad bugs in the game, players will roleplay their way around them, and exploiting bugs is generally frowned upon. I can count on one hand how many times in those 8 years the game was stopped with no turns running, and except for twice it was always something like “moving server to a new hosting center” or “replacing server with a new one”.
What’s kept me motivated has always been the players. There are easily two dozen people playing BattleMaster who are more devoted to and fanatical about it than I am. If you can literally feel how much the game means to some people, that gives you the boost you need to get through those motivational downs.
There’s been one case I know about where a father kept contact with his sons through the game after an ugly divorce. He wrote to me a year or so afterwards and told me how in his view the game had saved what remains of his family. You don’t forget mails like that.
Are you the only developer for Battlemaster, or have you ever hired help?
I’ve hired help many times, and there are half a dozen or so names of additional coders right on the start page. Some of these people have helped for years, some only for a few months, but I couldn’t have done it without them.
How much did/are you paying for battlemaster?
Absolutely no idea. The most valuable commodity is probably time. There’s a couple associated costs that I could or could not attribute to the game, such as software I bought that I use mostly for coding, etc. The highest single expenses have probably gone to hardware (the game runs on a dedicated server I bought specifically for it) – but I don’t really keep a record. Thanks to my work history (I worked for a dot-com company when I started BattleMaster, I work for an ISP now) hosting has never been a problem.
You mentioned in your post-mortem that the players play a big part in helping you decide what features to build into BattleMaster – have there ever been any features they wanted but you didn’t, or vice versa? How did you respond?
Absolutely. There’s always stuff that people want that doesn’t fit into the game. It might be a good idea, just not for this particular game, or it might be something that on second thought really isn’t all that good. When an idea is posted to the discussion list, I usually follow the exchange between the players for a short while before I chime in. There are, however, a couple “over my dead body” requests, and the BattleMaster Wiki contains a “frequently asked, frequently rejected” page.
What plans do you have for battlemaster, going into the future?
Oh, we do have a couple of very exciting changes coming up, with a big one (a new classes system) that just went live, and another big one (new layout with clean xhtml instead of the current frame-based one) in the pipeline, as well as half a dozen or so further down the road. There’s also one big secret project that I’ve recently completed the prototype for that will be included whenever it’s done, but right now I can’t tell what it is.
Do you have anything to say to new browsergame developers?
I’d like to pass on what I consider the most valuable hint I’ve ever read regarding software development:
“Build one to throw away (you will anyway).”
In other places and contexts, that’s phrased as “don’t be afraid of failures” or “there are no errors, only feedback”. What it all means is that your first game will suck. Period. No if’s or but’s. I know my first game sucked. In fact, I’ve got a whole history of failures.
So when you write your first game, and you think that it’s certain to be the next big thing, then you’re creating your own disappointment. Let me repeat that: Your first game will suck. And no, there’s no way to skip it and start with the second. You have to make the sucking one, and maybe two or three of those, before you get something good.
If you want to check out BattleMaster, you can visit http://battlemaster.org/.
Making your game more accessible
Recently, we talked about keeping your game accessible for those with disabilities. A few of the changes that we mentioned making to your game are fairly easy changes to make, but a few require some custom Javascript to implement. Today, we’ll be working through two simple tweaks you can make to improve the accessibility of your pages: changing the text size, and changing the color scheme.
We will be using the jQuery javascript library to accomplish both of these effects, along with some custom CSS.
First off, let’s say that the stylesheet for your page looks like this:
1 | body {font: 75% verdana, sans-serif;color:black;background:white} |
If you want to add some alternate color schemes to your page, you could add them in your CSS like this:
2 3 4 5 | body.default {color:black;background:white} body.red {color:red;background:green} body.blue {color:blue;background:white} body.green {color:green;background:black} |
By setting up our CSS in this way, it is easy for your designer to make color scheme changes to the entire page whenever we modify the body’s class, simple by writing their CSS based on which class the body has:
body.red p.warning {/* this would only be applied under the 'red on green' color scheme*/} body.green p.warning {/* this would only be applied under the 'green on black' color scheme*/} p.warning {/* this would be applied regardless of color scheme */}
We will be using jQuery to dynamically add these classes to our document as necessary. We’ll start off with a basic HTML document – I’ve inlined the CSS so that you can see it all in one place; in a production environment you should make sure to keep your stylesheets separate.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> <title>jQuery accessibility demo</title> <style> body {font: 75% verdana, sans-serif;color:black;background:white} body.default {color:black;background:white} body.red {color:red;background:green} body.blue {color:blue;background:white} body.green {color:green;background:black} </style> </head> <body> <p>This is our page, with some filler content.</p> <p> <select id='body_colors'> <option value='default' selected='selected'>default (black on white)</option> <option value='red'>red (red on green)</option> <option value='blue'>blue (blue on white)</option> <option value='green'>green (green on black)</option> </select> </p> </body> </html> |
With our document set up, we’ll add the Javascript code to toggle our body’s class for us:
27 28 29 30 31 32 33 34 | <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.3/jquery.min.js"></script> <script type="text/javascript" charset="utf-8"> $(document).ready(function() { $('#body_colors').change(function() { $('body').attr('class',$(this).val()); }) }) </script> |
If you’re new to jQuery, that will probably look like voodoo to you – but it’s actually a fairly simple piece of code. We’re selecting the element on the page with the ID #body_colors(just like you would with CSS – in this case it’s a <select> element), and then attaching an event handler to its onchange function – every time that the value of the <select> changes, our event handler fires. All it does is find our <body> tag, and then set it’s class to the class that the user just selected.
If you open up our tester page in your browser, you should be able to see that when you select something from the dropdown, the style of the page changes – which is exactly what we were going for. You can also see it in action at http://buildingbrowsergames.com/demos/accessibility-1.html.
Modifying the text size is a bit of an interesting change, as it will require you (possibly) to modify the way that you write your CSS. When we first defined the styles for our body, you’ll notice that we added the ‘font’ declaration, with the size of ‘75%’. What this has effectively done is made it so that the baseline size for all the text on the page is 12 pixels. By putting this declaration onto our body element, we can now use ems to size our text; if you wanted to make some text that was 12 pixels, you would give it a font-size of 1em – for 24 pixels, you would use 2em, and so on.
Now, at first blush you may be saying “this is kind of cool, but…why would I ever use it?”. The reason for this is simple: it makes writing our javascript much easier. Let’s add some stuff to our HTML page:
27 28 29 30 31 32 33 34 35 | <p> Change font size: <select id='text_size'> <option value='50%'>smaller (8px)</option> <option value='75%' selected='selected'>default (12px)</option> <option value='100%'>big (16px)</option> <option value='125%'>bigger (20px)</option> </select> </p> |
With our font-size dropdown added, we will be writing a little bit more javascript:
42 43 44 | $('#text_size').change(function() { $('body').css('font-size',$(this).val()); }) |
This piece of jQuery is even simpler than the earlier one – all we do is modify the ‘font-size’ attribute on our <body> tag with the value of the selected option.
If you take a look at your page in the browser now, you should notice that selecting different options in the dropdown also alters the text-size on your page. As long as you use em’s for all of your font-sizes in your document, that means that altering the text-size will transform the text across your entire site – making it much easier to read for users who have a hard time reading small text. If you’d like to see the entire page in action, you can take a look at http://buildingbrowsergames.com/demos/accessibility-2.html.
As you can see, making it so that users can alter the color scheme or text size of your page isn’t particularly difficult – but for users who need to be able to make those changes, it will make the difference between playing your game, and playing a different game that caters to their needs better. Here’s the entire source for our demo page:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> <title>jQuery accessibility demo</title> <style> body {font: 75% verdana, sans-serif;color:black;background:white} body.default {color:black;background:white} body.red {color:red;background:green} body.blue {color:blue;background:white} body.green {color:green;background:black} </style> </head> <body> <p>This is our page, with some filler content.</p> <p> <select id='body_colors'> <option value='default' selected='selected'>default (black on white)</option> <option value='red'>red (red on green)</option> <option value='blue'>blue (blue on white)</option> <option value='green'>green (green on black)</option> </select> </p> <p> Change font size: <select id='text_size'> <option value='50%'>smaller (8px)</option> <option value='75%' selected='selected'>default (12px)</option> <option value='100%'>big (16px)</option> <option value='125%'>bigger (20px)</option> </select> </p> <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.3/jquery.min.js"></script> <script type="text/javascript" charset="utf-8"> $(document).ready(function() { $('#body_colors').change(function() { $('body').attr('class',''); $('body').addClass($(this).val()); }) $('#text_size').change(function() { $('body').css('font-size',$(this).val()); }) }) </script> </body> </html> |
Keep your game accessible
A Building Browsergames reader by the name of BlindAngel recently got in touch with me to talk a little bit about accessibility in browsergames – namely, the fact that it’s something a lot of browsergame developers tend not to think about when they are developing their games.
In the interest of transparency, I should clarify something here; BlindAngel is blind. So she, more than anyone else I know, is well qualified to talk about accessibility in browsergames; it’s a topic that applies directly to her.
One of the first groups she mentioned to me with accessibility concerns was people with vision loss; for people with less-than-perfect vision can have problems with text sizes on websites. Take a look at any website you run – how big is the text? Would you be able to read it from a meter away?
Another group that can have problems with games is those that are color blind, or have trouble distinguishing colors – sometimes simple combinations like black text on a white background can look blurry, and be difficult for them to read.
The biggest accessibility challenge for people who are blind is that, in BlindAngel’s words, “people forget that we have to use an automated program to access anything on the computer”. She mentions that captcha’s are a big problem for screen readers(and you shouldn’t be using them anyway, because they don’t work). In her case, she has actually ended up not playing games that she was interested in that used captchas.
Another problem that blind people face when playing games is with images in general; BlindAngel gives the example of a game she plays with cyphers in it:
Some games and site rely on the person being able to see to be able to play sections of their game, for example In one game I play there are missions to do and they include cyphers, this is where a word is comprised of individual letters that are 1 letter per graphic and then scrambled. As I am unable to see, this is completely skipped by my screenreader…
Another issue she has is that alt tags on images are not always used correctly; the description needs to be “clear and concise”:
…there is nothing worse than a description that tells you it’s a person – are they doing something? is it male or female, adult or child, dressed or not…
Javascript is also not very well-suited to screen readers; BlindAngel mentioned that she has encountered dropdown menus that contain links – and as soon as she scrolls down the list so that her screen reader reads them, they redirect her to the page that they are linked to, instead of allowing her to read them.
Using accesskeys for some of the links on your page is a simple but effective accessibility tweak; for someone relying on a screen reader, they are not going to be able to instantly look at all the links on the page – instead having to read through them one by one. By consistently making it so that the ‘h’ key goes to home, and the ‘p’ key goes to the user’s profile, they no longer have to read through all the links on the page when all they want to do is go to their profile page.
These are some of the bigger accessibility problems encountered by people with disabilities who want to play browsergames; but as developers, we can fix them. It’s easy enough to add more descriptive alt text to your images, and basic accesskeys to the important links in your game. You want players for your game, right? There are thousands of disabled people out there; and making even just a few of these accessibility changes will propel your game to the forefront of their ‘to-play’ lists.
Battlemaster “Post Mortem”
by Tom Vogt <tom@lemuria.org>
Introduction
As far as post-mortem articles go, this one does not really qualify. For one, it is neither “post”, nor “mortem”.
BattleMaster is a game that has been in development for over eight years now, and most of that development has happened while the game was public – people have been playing it while it changes all the time. It has been declared a “permanent beta”, and evolves continually. There are no “versions” or “releases”, but continuous updates. I will focus on the pros and cons of this style of development.
Development Style
What does “permanent beta” mean, in more detail, and how did I decide on it?
The second question is easier to answer: I didn’t. It happened. When BattleMaster was first released, it was intended as a small add-on to another game of mine. It was very simple and outright primitive. It proved hugely popular, quickly passed the original game that had spawned it, and I could not help but start to expand it. Today, the BattleMaster code is roughly 45,000 lines of code.
What “permanent beta” means is that there is no version number or fixed release cycle. Whenever a new feature is ready, or a bug is fixed, the updated code is uploaded to the game. This sometimes happens several times a week. It also means that many features are available in the game while they are still incomplete, and players can test those changes early on, provide feedback, and often influence the ongoing development.
Advantages
The advantages of developing the game while it is being played are considerable. The primary advantage is that for an amateur like me, it would not have been possible to come up with a game as complex as BattleMaster in a different way. When you are coding for fun, not money, you don’t want to code for two, three or eight years before you release the game.
Early feedback from players also prevents dead ends, places where you move into one direction and then find out it all sucks. That still happens, but the player feedback usually stops it before too much time has been invested into a feature that only sounds good on paper.
Another advantage is that the development cycle is very short. For simple features, players can see an idea of theirs in the game within days of suggesting it. This keeps players “in the loop” and encourages them to actively contribute ideas and suggestions.
Disadvantages
There are also some considerable disadvantages to this “permanent beta” method.
The main problem I see in the game today is that there are a lot of game features that were never properly finished. I either abandoned them or other things came up that were more important. These beginnings of a new, never-finished feature often remain in the code, and while they usually do no harm, they make future changes more difficult.
Not having specific releases also hurt teamwork within the developers and makes bug hunting more difficult.
You also alienate players that do not like the game changing around them. On the other hand, there are many players who enjoy exactly that, so it kind of balances out. I list it under disadvantages because new players more often fall into the first category, as it makes it more difficult to learn the game. This limits the growth of your game.
Another huge problem is that I have broken the game quite often. Often, that is just painful, with a backup having to be used to restore the game state. At times, you do irreparable damage. That’s when you wish you had your own QA department.
What Would I Do Differently?
When you’ve done a project of this size, you have to ask yourself if you would do it the same way again. If the answer is “yes”, you’ve learnt nothing and wasted your time. There are quite a few things I would do differently if I were to write another BattleMaster today:
One is the use of an MVC framework. As BattleMaster is written in PHP, I’d pick CodeIgniter, which I’ve been using for other projects, but the exact choice is not as vital as the decision itself. BattleMaster is coded in 2001 PHP, and freely mixes input handling, game mechanics and output. It’s also chock full of direct database queries right in the pages. While over the years I’ve separated out often-used queries into a library of game-mechanics functions, today I would make sure that any and all database queries are encapsulated somehow. Of course, back in 2001 there simply were no frameworks around that would have done the job.
The second thing that I recommend to anyone starting a new game today is to use as many globally unique identifiers as possible. In BattleMaster, game worlds are separated with each having its own database. ID numbers are unique on that database, but not globally. When the game was started, there was only one game world, and no plans for more, so everything was coded for one game world. Later expansions added more game worlds, by simply changing the database to access. But then players wanted to move characters between game worlds and that’s when fun starts. Also, identifying anything within the game always requires the combination of world and local ID.
The third thing on my mind is that I should have started using revision control (Subversion in my case), regular automated backups and a bugtracker much earlier. During the early days, I worked without these tools, and it did hurt me enough to finally start using them. Nowadays, when I start any software project, one of the first things I do is setting up a Subversion repository and if the project isn’t for purely personal use, I also set up a copy of Trac to cover the “bugtracker and more” part. And as soon as a project goes live, I set up a cronjob to at least do a daily database dump.
There are also a few things where I’m not sure if I would do them differently, but which caused me pains at one time or the other.
One is that I learnt just how much you make yourself tied to a specific database if you don’t work hard on avoiding that from the start. Even though I had a database abstraction layer very early on, it was a few years later that I realised that wrapping mysql_query() into a generic db_query() function isn’t enough. I tried switching to PostgreSQL once and found out that it uses serials instead of auto_increment, for example. The amount of changes that difference alone would have required was surprisingly large.
Conclusion
In summary, it has been an interesting trip, and a huge learning experience. It has done a lot for my coding skills, and the ability to test new ideas out quickly is very rewarding. There’s things I would not repeat, and like any hobby there are times when things suck.
One big thing that I learnt is that building things in small steps is a great approach to developing a game. Sometimes, my own enthusiasm gets the better of me, but most of the best features of BattleMaster started small and where gradually improved upon.
For a hobby project, I can recommend not being afraid of changing things “in flight”. It does keep the game fresh both for you and the players, and if you take steps to minimise the effect of bugs, it can be an overall positive experience. It also brings you and your player community closer together, and that is one of the most important things you can do for both of you.
Post-Mortem: Robot Warz
Well, technically, the name was changed to Mecha Warz, but to prevent confusion with Mecha Asylum, I’m going to use the original name. There is a bit of history with this game, so I’ll start with how I came to work on this project and then go on to the postmortem.
When I joined the project, it was already in development with three to four developers. I recovered from a period of depression and wanted to start development on a PBBG. I contacted the person I worked with 6 months prior after the second iteration of Mecha Asylum was a failed attempt. I wanted to get to work on a project that was complete and had active players.
What Went Right
- Group project.Well, there were multiple developers working on the project, but that was a WTF? in and of itself. There wasn’t any version control, so there were some interesting instances of overwriting another’s work.
It was an accomplishment to go from one developer working on a project to four and I still do think that is what I liked most about the project. It would have been better if all of us were intermediate to advanced level developers and used version control. I’ve rectified the situation in the present to prevent the failures from occurring again.
- Active player base.I enjoyed entering the development with an active player base. It helped with the motivation to add and fix features for them to play. I think it speaks a lot that people will play any game or give any game a try, just to waste a little time. It gives me hope that at least someone will play my game, if it at least functions.
What Went Wrong
In the case of Robot Warz, we were developing portions of the game live, so a player could, if they knew where to look play the parts that were being worked on. It also meant that some portions of the game could suddenly stop working, when a missing semi-colon or another bug was inevitability was introduced.
- Administrators and developers played the game also.The game playability must protect the boundary of fairness, whether real or perceived. In the case of this instance, it is a gray area, because the administrators didn’t cheat. However, they could have and to the player it means nothing if the administrator could easily with a click of the button give themselves more money than any player in the game.
After thinking about it a great deal, if you are going to develop the game, then the other players shouldn’t know that you are an administrator and if you are, then you shouldn’t have access to play the game. Administrators, if they want to play the game, should have another account to do so with the same access as the rest of the players.
Ethically, an administrator probably shouldn’t play the game at all and should be completely separated from the playability to be as neutral as possible. If an administrator crosses that line, then feelings might be hurt when a decision was made against another player, because of an in-game alliance. Whether or not the administrator made the decision based on that is irrelevant to the player and would cause to destroy the fun factor of the game.
- There wasn’t any version control.I remember implementing a feature and bug fix four times, because every time the file was overwritten by another developer who didn’t download the file from the server. It was only resolved, because I contacted the developer who was doing it and told him the situation. If version control was used, it wouldn’t have mattered, because his changes would have been merged with mine and resolved.
- Security, what security?When I joined the project, register globals was used throughout the code base. I had to inform the other developers about super globals. I also spent a great deal of time going through code and updating the code to use the correct super global. I should also mention that in all fairness, the project was based off an open source browser based game engine that had these flaws inherent in the code. It might not have been the complete fault of the developers on the project.
Validation and sanitization was only added when an security hole was already being exploited. Therefore, it was more of a cat and mouse game of patching holes after the hacker exploited it. There were also too many areas in the code that had to be patched to prevent future attacks. I wasn’t much of an security expert, but you don’t really need to be when all validation and sanitization is programming common sense.
It is difficult to take much from the project, but when you have your name associated with a project that has a magnitude of attack vectors, then you pretty much have to take it personally.
- Disjointed game features.The game features were developed separately from other developers and also separately from the original game purpose. I think I added a farming feature, because it “would be cool”, as opposed to matching the rest of the game playability. Yeah, I didn’t really get the whole game design concept and planning games at that time.
What I Learned
I learned the importance of version control and I’ve used it every since, even when I’m working by myself. It was the first time, I really seen an importance for it. Actually, I didn’t know about version control at that time, but I thought there had to better way to prevent events like when my file was replaced from happening without having to create a copy to ensure a backup was saved. I’ll learn the name Version Control and Subversion, 8 months later while working on Astrum Futura.
Security is important! The crackers that attacked the site, really expressed the importance of sanitization and validation. I’ve since practiced a great deal with making sure that I always code projects around a paradigm that includes those two. It is easier to sanitize and validate when first coding the project, then it is to react to attacks and fix security holes retroactively.
I’ve also learned that games tend to play better, when they’ve been planned and the game features flow together. When you add features, because they are cool and not to complement or extend the current game base, then you create a patchwork game that ends up confusing the player. For example, if you are going to add a pet, then make sure it isn’t for a robot game.
Interview: Pepeshka from Booze Quest
Booze Quest was the winner of the Browser-Based Game Zone PBBG contest, and one of the prizes that Building Browsergames put up for the winner was an interview. I got in touch with Pepeshka, the developer of Booze Quest, and managed to ask a few questions:
-
What first got you into browsergame/PBBG development?
I’ve been interested in game development as far back as I can remember; it’s been the only career that I’ve ever considered, to be honest. All of my projects in the past have been small, but now I wanted to write something which could reach a wider audience. When you consider technologies for delivering a multiplayer game, browser-based games shine. Everyone has a web browser, there’s no downloading required, the tools are powerful and the process is well established.
-
What made you choose ASP.Net as a platform for Booze Quest?
I chose ASP.NET because I have experience in C#, which is the codebehind language I use for my pages. I’m also a big C# fan; I think object-oriented languages speed the development process and result in more stable code. I understand that the newer versions of PHP are OO, but I was already going to have to learn HTML, MSSQL etc. to produce this game so I decided not to add PHP on top of everything else.
-
What was your most significant challenge?
Time, easily. Time was a huge weight on my back the whole time – I had two months, during which I had to produce projects for school and survive finals. It was tough to find the hours to squeeze into the project, and I ended up having to make some hard cuts before the deadline.
-
What was the least significant challenge?
My game uses a tile-based system for drawing the player’s bar and letting him or her interact with it. Coming into the project I had no idea how I was going to implement that in HTML, but the first system I tried worked beautifully. I never had to scrap any code, and the entire system was done in a few days.
-
What did you spend too much time on?
Art ate a surprising amount of time. I also used much more time than I thought I would on bugs – both finding and fixing them. Finally, I didn’t do my homework on hosting policies, and ended up surprised when all my database code broke after purchasing a shared hosting account – that was two solid, depressing days of rewriting code.
-
How much are you paying for Booze Quest?
Well, I use shared hosting, which runs about $12 a month if you throw in the domain name and all. I don’t mind footing the bill at this point.
-
With a time constraint on the development of your game, was there anything you meant to build but had to cut to finish on time?
Plenty, in fact entire portions of the game play had to be scrapped. Initially, I wanted to make each player’s bar two-story – a bar on the first level and an inn on the second level. Adventurers would rent the bedrooms overnight and provide a secondary source of income for the player. I was about a month away from the deadline when I realized there was no way I was going to be able to write the code and draw all the bedrooms for an inn before the deadline, so out it went. To be honest, once I yanked the inn I realized it was just unnecessary complication and probably didn’t need to be in the game in the first place; I have no plans to implement it in the future.
What hurt was cutting the player-versus-player combat system before the deadline. Booze Quest is intended to be a player versus player oriented game, and it was a really hard call to not include PvP by the contest deadline.
-
What are your thoughts on the fact that Booze Quest won the PBBG contest? Were you surprised?
I had a cautious optimism after viewing the other entries in the contest. Tygras had some phenomenal art, Cubicle Battles was unique and made me laugh and Pirates Glory had some awesome game play elements – really all the other entries were top notch. I’m very pleased that I won, but I’m more thrilled that the contest succeeded in getting some awesome new games out on the internet. (I was also secretly rooting for Cubicle Battles. Shhh, don’t tell anybody.)
-
What plans do you have for booze quest, going into the future?
I intend to continue actively developing Booze Quest! I’m working on a patch for the more serious issues my players have been bringing to my attention, and then I’m on to getting PvP into the game. Booze Quest will stay my active side project for some time to come.
-
Do you have anything to say to budding browsergame developers?
For all game developers, I’d say “write down every idea that comes to mind, no matter how sillyâ€. Booze Quest spent about six months as a half-page of scrawl before I fleshed it out for the competition. You never know which of your ideas will mature.
If you want to try out Booze Quest, you can visit http://npcrpg.info.
About
Got Something to Say?
Follow Building Browsergames on Twitter!
Recent Posts
Archives
