However, there are a few problems with that approach. For one thing, it’s impossible for me to show someone else my snippet collection – and sharing your snippets once you hit the 10+ mark quickly becomes less than enjoyable. Also, what happens if your system goes down?

With that said, I am pleased to announce the launch of http://pbbgsnippets.com, a new snippet-sharing site geared specifically towards PBBG developers. I collaborated with Janne Siera on the concept, and Gabriel Bianconi did the design. Janne and I are hoping that this new snippets site will be able to spur a little bit more sharing within the PBBG community; I’m sure there are tons of useful snippets out there to share.

The code behind http://pbbgsnippets.com is available, and languages can be added as necessary – if anyone would like a copy of the source code(or a language added), send an e-mail to buildingbrowsergames@gmail.com, or just post a comment.

• Building a structured voting system(with voting rewards)
• Adding in-game chat to your game
• Creating an invitation-based registration system
• Using alternate authentication APIs(facebook connect, opensocial connect, twitter auth)
• Building a quest-based game
• Push content(orbited, comet, etc.)
• Scaling your game
• Using document-oriented databases in your game(couchdb, mongodb, etc.)
• Allowing players to set stats(assign skillpoints)
• Achievements
• Building a backend administration area for your game
• How to prevent users from editing another user’s information(validation)
• Adding alliances to a game
• Marketing your game
• Detecting and preventing cheating in your game
• Adding validation to your game
• Adding voting reward support to your game
• Building a territory map that auto-updates

If there are any other tutorials you’d like to see(or you’re interested in writing one yourself), send me an e-mail at buildingbrowsergames@gmail.com, or just comment on this post.

What are you looking to build? What features are you getting stuck on? If there’s anything you’d like to see a tutorial on(anything at all) — post a comment below and I will do my very best to get to it.

Tutorial requests will be accepted for a week, so you have until the 25th of November – at that point, I will take the list and everyone will be allowed to vote on which ones they’d like to see first.

So — what do you want to see a tutorial on?

Building Browsergames also got a little more public – starting up a Twitter account, becoming a member of 9rules, and forming the PBBG network along with Browser-Based Game Zone and BBG Universe.

I am pretty happy with where Building Browsergames has gotten to – but lately, I’ve been noticing something. The more time I spend writing, the less time I spend creating. At the beginning, Building Browsergames was a fun side project – and now, it’s morphed into a chore. By focusing so much on writing about games, I’ve distracted myself from what I really love – which is creating games.

With that in mind, Building Browsergames is changing gears. I won’t be writing on Monday, or Thursdays – I will now be writing only when I feel I have something useful to say. There won’t be any forced posts or shoddily written tutorials, rushed out under a deadline.

I don’t want Building Browsergames to die. But at the same time, certain circumstances in life have made it impossible for me to maintain a consistent update schedule without severely compromising the quality of my writing – which is not something I want to have happen.

I still want to publish content from other game developers. The PBBG/browsergame niche is so small that there are very few places for a developer’s voice to be heard – and I want Building Browsergames to continue to be one of those places.

With that in mind, the doors are open – anyone who wants to can register for the website, and submit articles for review. I promise to read and review everything that’s submitted, and publish as many viewpoints from as many developers as I can.

I still have plans for Building Browsergames – they are just on hold for now.

I’m extremely grateful for everyone who has e-mailed me and supported me on this – I’ve gotten to talk to some of the developers that I look up to most, in addition to discovering just how many people out there had a passion for developing PBBGs. I’m glad I was able to take it this far, and I hope that things will continue with other people’s contributions.

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.

Unfortunately, I have some bad news; Roger Gräler, the Produktmanager for Travian Games GmbH, e-mailed me back and told me that Travian Games currently is not in the position to write anything for Building Browsergames, and won’t be in the future either.

On the other hand, I have some news related to Building Browsergames that should hopefully make it easier for some of the games(and game developers) that I haven’t had pointed out to me: Building Browsergames is now set up to receive contributions! What this means for game owners and developers is that all you have to do is sign up for an account at http://buildingbrowsergames.com/blog/wp-login.php?action=register, and then you’ll be able to log in at http://buildingbrowsergames.com/blog/wp-admin/ and submit posts for review. If a post is approved after being reviewed, it will be put into the publishing queue – which means what you write could show up in front of everyone reading Building Browsergames.

With that being said, there are a few tips that I have for anyone who is interested in contributing:

• Code In Posts

  If you’d like to embed code in your post and have the syntax get highlighted properly, you can wrap it in <pre> tags, and set the ‘lang’ attribute to the language that you are using in your snippet. You can also optionally add the ‘line’ attribute to tell the syntax highlighter what line to start line numbers on(which is helpful if you are posting a small piece of a larger codefile, and you’d like users to know where you’re at). Here’s an example, that will highlight a Perl snippet and start line-numbering at line 8:

  <pre lang='perl' line='8'>
  my @array = map { $_ > 0 } @values; # your snippet here
  </pre>

• Your Byline

  As a bit of an extra kickback to people who write for Building Browsergames, you are allowed to include a byline with anything you write. Ideally, this is a single, brief paragraph that describes you – who you are, what you’ve built, or what you’re working on. The text that will be displayed for your Byline is the ‘Biographical Info’ that you can set in your profile(if you can’t figure out how to edit your profile, go to this page).

In conclusion, I’m afraid that I couldn’t get Travian to talk about their game with me. However, I have been working on getting in touch with some of the other games and developers that you mentioned, and should hopefully be publishing their thoughts soon.

What does that mean for you, the reader? Well, it means two things:

• I will be posting less. Building Browsergames’ posting schedule will be switching to two posts per week – monday, and thursday. While I will be doing my best to post more frequently than that, I can (unfortunately) only commit to posting twice a week for the time being.
• With me only posting twice a week, that means that there are three spaces available for any guest writers who are willing to write something. You can write a post-mortem of your own game, a tutorial on a new technique you uncovered, or anything else you want – and to make it up to you, we’ll let you include a link to your site in a short “About You” box that will go underneath everything you write. The more you write, the more exposure your site gets!

If you’re interested in writing for Building Browsergames, or would just like to drop me a line, send an e-mail to buildingbrowsergames@gmail.com.

See you on thursday!