When I started Building Browsergames back up again, I had big plans – a new design, a cleaner interface, more guest writers. Unfortunately, things didn’t go quite as I planned – and that’s why I’m writing this today.

Building Browsergames is shutting down. Forcing myself to find more writers and games to review and tutorials has had a detrimental effect on quality of the content here – and when you’re teaching someone, you need to know what you’re teaching very well.

By continually trying to post tutorials and reviews under a time constraint, I’ve done a disservice both to myself, and to the browsergame community. Corners would get cut because the tutorial needed to be up in time, and questions would go unanswered.

I also have my own projects to consider. Faction Wars, while currently in the alpha stages, is doing very well – and there are a number of other projects that are getting close to that stage themselves. Writing something for Building Browsergames once or twice a week has proven to be too much of a distraction for me to be able to get as much done as I’d like to on my own projects.

What does this mean for you, the reader? Well, it means a few things:

• Fewer Updates

  I won’t be writing much anymore. And while I’d like to publish guest posts from other developers and enthusiasts, no one actually seems interested – and anyone who does quickly changes their mind. With that in mind, it’s fairly safe to assume that Building Browsergames will not be updating very often in the near future.

• The tutorials stay

  I’m proud of what was built using the tutorials – and it even spawned an open-source project based on the code. While the code might not be the best I’ve written, I’m glad that it’s helped visitors who wanted to learn to make their own games to get started.

Essentially, Building Browsergames takes up too much of my time for me to be able to afford to keep it running at the level that I have without making some sort of income from it – and I don’t want to just plaster the site with ads and let the networks go to town. I don’t really want to do that to any of you – so for now, Building Browsergames has to go on a hiatus.

Thanks again to everyone who personally got in touch with me – there’s a good community here, and with a little bit of nurturing I think it can go on to achieve great things.

To start things off, I have a release from Fanta-Trade, a stock market simulation game:

Fanta Trade is a browsergame where users are given 100,000 (fanta) euros to invest when they sign up – in stocks, commodities, currencies, warrants – almost everything you can imagine. One of the nice things about Fanta Trade is that stock names and prices are real – so you can become a successful stock trader (or lose it all) without taking any risks in real life. You can also find some elements typical to most browsergames within Fanta Trade: teams, rankings, and a forum in which the best players can be found providing their own take on the market.

Fanta-Trade is a good game for anyone who has an interest in learning how the world of finance works – or for anyone who wants to face a different kind of competition than “send your soldiers to the enemy’s village”.

Fanta-Trade’s sophisticated simulation engine works well, and has succeeded in transforming something as complicated as investing in the stock market into something easy and enjoyable for all – especially those who don’t know how the market works. And if you get stuck, the vibrant community is always providing tips for the game – all users can open their own financial blog and start writing their own market analyses, so you can even start dispensing your own advice if you so choose.

Fanta-Trade was created in Italy, so most of the players are Italian – but it has also been translated into English. You can check it out at http://fanta-trade.eu.

Do you have a press release that you’d like us to publish? Get in touch by e-mailing buildingbrowsergames@gmail.com, leaving a comment below, or following us on Twitter.

You know, it’s really frustrating seeing people trying to pass off obscurity for security. It doesn’t work. It never has. Don’t do it. Don’t promote it. Because, when you do, it damages security overall.

MD5 has been known to be useless as a security measure for well over a decade. Why people keep using it I will never know. Especially, when the SHA family is *vastly* more secure and available in all languages. Here’s the PHP page for hash():

http://ca3.php.net/manual/en/function.hash.php

Just use SHA256/512 and be happy until the winner of the NIST contest is found. Then use that.

At any rate, your ’salt’ completely misses the point of MD5’s weakness (btw, that’s security through obscurity which is completely useless). As in, if they have access to your DB, then chances are that they have (or could have) access to your source as well. Also, I could generate a collision to that password in well under a minute:

http://eprint.iacr.org/2006/105

So, I might not have the actual password. But, I’ll certainly have *a* password that will generate the same hash. If it doesn’t work, then I look at the source and find the obscuring factor, make a minor adjustment to my collision finding code and rerun. In seconds I’ll start getting positive results. Yes, it *is* that easy.

If you want to migrate people over to the new hash, then just create a new column in the DB which will hold it and set it to null. Then on login, if this value is null redirect them to a change your password page. *Require it*. Then after some months, drop the MD5 column, clean up the logic and have the remain inactive users use the forgot your password feature if they want to play again.

That might sound like a lot of work, but it really isn’t. Especially, when considering it’s the programmers fault for screwing up the security in the first place.

There are some good points made here – so if you’re using MD5 in your game for your hashes, you may want to look into updating your code.

Plant Wars Logo

This is Jon from Plant Wars, which is yet another PBBG (what else would I be doing here?). I started the game around 9 months ago as I was searching for a job after graduating with a bachelor’s in Computer Science. I had only learned a minimal amount of PHP for a class project earlier in the year, so I definitely have used the process as a learning experience. Still, I’m pretty sure I can tell you more about what not to do than what to do. As with any web-based game, we are constantly developing and are far from being done.

First of all, set up a test site with its own test database. Keep it up to date so that you’re not tempted to cheat and just make this tiny change on the live site first. I cheated when I implemented the password change feature. The query it used when someone changed his password was “UPDATE Users SET Password=md5($newpassword)”. Notice something missing? That “WHERE Id=$_SESSION["Id"]” clause is just so easy to forget. That was a mess that would have been worth any level of inconvenience in maintaining the test site to avoid.

Secondly, I’d recommend using a framework, such as the Zend Framework for PHP. This is because I didn’t and still don’t. I don’t even have data access objects. Sure, I store some commonly used methods in files that I include on every page. Alas, I’m still in the habit of embedding queries in the pages directly. Separation of logic and presentation? Yeah, that’d be nice.. At my day job, I use the Struts framework with Java – and while it does make the initial development take somewhat longer in the case of Struts, it is definitely worth it. The maintainability is increased incredibly by the proper separation of concerns. Once you learn a framework, you should generally find that your productivity increases. The initial learning curve is worth the sacrifice at the beginning for the long term benefit.

Perhaps the most important thing I did right was to have my friend Daniel help me out whenever possible. Going at such an endless project alone is intimidating, and having someone else to shoulder some of the burden is essential. Coming home and seeing a new feature implemented that you didn’t have to lift a finger for is exhilarating. Plus, then you have someone to brainstorm with and to just talk with about the game. Your girlfriend (or mom, if that’s the case) may pretend to care, but she’s probably tired of hearing about it.

In the same vein, it’s essential to have some trustworthy staff members. Grant these people moderation powers on your game’s forum and give them the ability to check the logs for cheaters. Write a nice administration panel for them (and yourself) that will streamline the process of checking for cheaters. For example, one button click to see all users who have shared an IP address. Examining log files may be your thing, but it’s time that you should be spending developing. Ensure that your staff is – once again for emphasis – trustworthy, as well as good role models for your community.

If you have staff that you don’t know personally help on the site’s development, don’t give them access to the live database. Restrict them to the test site – another good reason for its existence. Merge their code yourself. I made the mistake of granting access to the live database to my first staff member. I got off easy when he just made a page to bump his stats up artificially.

My final recommendation is regarding monetization: if you would like to at least make enough cash to pay for your hosting costs (which we usually manage – if barely), ensure that people can donate for some advantage in your game. For example, with Plant Wars, donors gain fertilizer (which is spent to train, fight, etc) at twice the rate of non-donors. I charge a low price of $2/month, and I’m not sure if I would recommend going that low. My initial price was $5 and that received lots of complaints and no donors, but now that the game has progressed, I’m more inclined to believe that anyone who donates currently would be inclined to do so even if it were a couple bucks more expensive. Use your best judgment. Also, I allow anything that can be bought with real money to be sold player-to-player so that a) there is more motivation for people to give me real money and b) people who can’t give real money still have the opportunity to gain the same benefits with increased activity.

People hate clicking on ads. It is worth the minimal time investment necessary to sign up with some sort of pay-per-action network, such as CPALead (disclosure: referral link). This allows players to fill out an obnoxious survey for an in-game reward, while you get some money.

Come check out the Plant Wars blog and you can also follow us on Twitter! (As a related, post-final recommendation, open up communications from your game as much as possible. It increases the likelihood that someone will find you from a social networking site or a search engine.)

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.

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>

Today, we will be altering our database by adding a few of the prerequisites for our combat system to be a little fuller – instead of players visiting the forest to encounter enemies, they will be able to visit any number of areas that we can define in the database. We will start by adding an areas table to our database, that we can use to keep track of information related to each area the player can visit:

CREATE TABLE areas(
	id int NOT NULL AUTO_INCREMENT,
	name varchar(100),
	PRIMARY KEY(id)
);

In theory, this table is all that we need to add to enable multi-area support(after changing our combat code, of course) – but we will also add a table called area_monsters that will allow us to control which monsters can be encountered in which area:

CREATE TABLE area_monsters(
	id int NOT NULL AUTO_INCREMENT,
	area int,
	monster int,
	PRIMARY KEY(id)
);

With this table created, we will be able to insert rows for monster + area combinations – allowing us to control which types of monsters the player will encounter in each area.

If you’re aware of our current database structure, you might be wondering: why didn’t we just add another stat to each of our monsters, called something like “Area Monster Is In”? The reason for that is simple: with these new tables, we will be able to retrieve which monsters are in an area using a single SQL query, that would look something like this:

SELECT monster FROM area_monsters WHERE area = <area_id>

If we were to use our stats system for this, we would need to do something much more complex – first determining which stat we should be retrieving, and then retrieving the relevant rows for every entry in the database – at which point we would need to work through our rows and determine which values we actually needed to use. Therefore, adding our area_monsters table will allow us to keep track of which monsters are in which areas a little easier.

With that being said, all of our initial preparations are finished – our next step(which will come later) is to add the code to actually interact with the tables that we have added to our database.

Serve statics from somewhere else

In the beginning, letting your Rails setup serve everything is very easy. But as your game grows in popularity, you’ll notice that your app spends a lot of time serving up things that never change.

The first thing we did was separate out all the static images onto a separate server running nginx. Nginx is notoriously fast at serving static content and it did a good job for us. This left our Rails instances to serve only game-related activities.

Another useful bit was using a plugin called bundle_fu. Bundle_fu takes all the javascrips and stylesheets you use in your app and creates a single file for the browser to download. So, instead of the browser having to make 6 connections to get all those pieces, it makes 1. This functionality is built into Rails since version 2.0.

Optimize your environment

Initially, we ran Apache proxying to 5 to 10 mongrel servers running Rails. Then we switched to Nginx/mongrels which gave us a bit of speed and a bit of memory back, after doing some more searching we eventually switched entirely to the Litespeed webserver with no mongrels. Litespeed is an awesome product and we have had rock solid performance with it for the last year. Although, all my latest Rails deployments have been with Apache & mod_rails (Passenger) running with the Ruby Enterprise Edition.

One big upside to Litespeed and Passenger is that you don’t have to manage mongrels anymore and restarting the website is super fast. Also, Ruby Enterprise Edition (REE) can reduce your memory requirements up to 30%.

Memcached

I think the biggest anecdotal speed increase we got was from integrating support for memcached. It was as simple as adding the acts_as_cached plugin and marking a few models to be cached. From there, we began optimizing which models were cached for the best performance.

Watch for slow queries

Edit your mysql.cnf file to start logging slow queries and then watch that log like a hawk. When you see a query that isn’t using an index, make sure you add the appropriate index to get that query to be fast again. This won’t help much if the query only runs once a day, but if it runs every few seconds — you’ll notice the difference.

Throttling the game

Early on when there were only a few hundred people in our game we added a bunch of notifications to our chat system so that people would know that others were there and something was happening. Crank that up to several thousand people and those notifications are nothing but annoying. So, we added code that checked for the number of currently online people and throttled those informative messages when things got busy and brought them back when things calmed down again. This made a big improvement in the quality of play during busy times.

These are just a few of the things we tried, but they were the most successful at improving the performance of our game.

If you’d like to see it, browse over to Tooth & Claw

Now, that’s not to say that none of them are good or anything – just that the selection is limited. And with a number of sites vying to be the be-all-and-end-all with forums, blogs, contests, and other features, it’s hard to decide: which site(s) should you follow?

With that in mind, I am proud to announce that Buillding Browsergames, Browser-Based Game Zone, and BBG Universe have united to form The PBBG Network. Our goal is to bring you the best in PBBG-related content, on each of our member sites. Building Browsergames will be providing the ‘blog’ portion of the network, while Browser-Based Game Zone will provide the forums, and BBG Universe will serve as the rankings site. Hopefully, by having each site switch to focusing on one main ‘feature’, we can improve each of our sites – and focus more on our core competencies and less on having every feature under the sun.

I’ve been struggling for the last few weeks to try and find a way to make combat ‘fun’ – while it’s a big part of a lot of browsergames, it’s a part that (I think) could use a little bit more polish in most of them. Fighting monster after monster after monster isn’t fun – it’s only a means to an end. I think that even the boring parts of the game should still be fun. With that in mind, I set out to build a combat system that would achieve two things:

1. Be a combat system.
2. Be fun.

After thinking and pondering, I believe that I’ve finally come up with a system that works(and you’ll probably be able to figure out how it works in the screenshot below).

Rawrmy's refreshed combat system

A little bit more time was also spent fleshing out the different areas of the game – and they’re what I will be working on now. I am afraid that my schedule has been getting busier and busier, lately – which means I can’t devote as much time to Rawrmy as I would like to. While I am still hoping to have something releasable by the contest due date, I don’t think it will be quite as strong an entry as I would have liked.

Completed this week:

• Combat system refresh – the combat system is now a little more fun to use, in addition to more challenging for players who have gotten to the higher experience levels.

Still to do:

• Content needs fleshing out – while this combat switch has made Rawrmy ‘feature complete’, it hasn’t made it solid yet. There needs to be a lot of polishing done in regards to content, areas, and the way that in-game items work.