Building Browsergames

Interview: Formulawan

I was recently contacted by the developer of Formulawan, a new racing strategy browsergame. He agreed to respond to some interview questions:

Tell us a little bit about Formulawan.

Formulawan is a sport manager browsergame about Formula One. It is a marriage of racing and strategy. Players enjoy running exciting races, but they also love to develop their team and think about the next step of their game plan.

Every player manages his own F1 team. You hire drivers and buy cars, construct special buildings and build your own equipement. It is possible to tune up your cars, to recruit staff like managers, nurses, mechanics…Players can join normal league races, take part in championships during a whole week or organize their own friendly race. As you can see, there are lot of possibilities and there is something to suit every taste…

This game has been existing for more than two years in French, and now, an English server is available since two month as well as a German Server since two weeks. A Spanish version is coming soon too…

What programming language(s) did you use to build Formulawan?

HTML, PHP and Flash.

Was Formulawan built by a team, or a single developer? How long did it take?

Formulawan was built by a single developper and it took about two years to develop the whole game. Even if the game has been improve for the very start until today ! It was his first game, and a huge project for a single man. But concerning the flash animations and the graphic design, it’s the work of Motion Twin, Formulawan’s partner.

Were there any parts of Formulawan that took longer than expected? What were they?

Yes, after the start of Formulawan, there were lots of bugs and I didn’t think that it would take all my time during months to fix them…It took two years to have a stable website !

Did you do any marketing for Formulawan, or just rely on word of mouth? If you *did* do marketing – what did you do?

On the French Server, few things were done about marketing because the developper was already very busy with the game itself. It took lot of time before Formulawan made itself known. But from the moment when the partner of Formulawan, Motion Twin, put an ad on its website www.MyBrute.com, things were different. More logs, more players ! A person is in charge of the marketing for the English and German Servers, but that’s quite new…so we will wait and see !

What plans do you have for Formulawan, going forward?

Well, as Formulawan has been launched in English and German, we can expect a Spanish server in the next weeks, and, why not…a lot of other multilingual servers in future…And Formulawan will also have new updates, as well as new tracks and even a new special game mode !

If you could give any advice to aspiring developers, what would it be?

You need a lot of courage, investment and passion to create such a game, especially when it is your first one ! You need abilities, but this isn’t the most important thing. It takes a very long time and you must have the opportunity to do this…It is very, very restrictive, but it’s also a priceless pleasure to see other people playing your game ! I would encourage all enthousiasts to create their game but not alone if possible!

• English Server : http://www.formulawan.com
• German Server : http://www.formulawan.de
• French Server : http://www.formulawan.fr

Market Opening in Browser Based Poker Games

Online poker is a very popular game. It’s also a huge industry, due to the fact that poker is played for real money and poker rooms can take a provision from the players, much in the same way as a derivatives trading exchange.

However, poker has not taken the same position within the free browser games segment, which is a bit surprising and should entice programmers looking for new niches.

Of course many people are reluctant to invest real money in a poker game with a bunch of strangers, to say the least. But playing for fun in the realm of a friendly online gaming site should definitely appeal to people, and poker is a really good game.

Let’s take a quick look at some of the challenges awaiting him or her who wants to step into a browser poker game effort.

Design

Obviously, the design should appeal to the target group – people who don’t necessarily like to gamble with large sums of money. Maybe something friendly, something with a happy feeling about it. Online flash game style.

Players will probably want to design their avatar, or at least pick it from a list, the longer the better. And the display of money needs to be very clear, so that it’s easy to see how much is in the pot and how much money the opponents have in their stacks. Even if it’s a fun money game, this will be important.

Playability

For a browser poker game to gain popularity, it definitely needs to achieve a high degree of playability. Just as with any other game, players will run away if they have to spend energy figuring out how to work the game controls.

Also, if the poker game is to be multiplayer, player interaction needs to be made really easy and smooth. Any glitches and freezes in the game flow would risk mass defection, not to speak of outright errors in counting the money owed between players.

Stability

Online poker rooms spent the first years of the poker boom struggling to build game server software with really good stability, rather than perfecting the look and feel of the poker clients (which at the time was almost exclusively a download poker game.)

They knew that players would leave really fast if they got the impression that games couldn’t be trusted. Of course, in fun money games the problem isn’t quite as acute, but stability is important.

Game lobby with waiting list feature

When setting up online games for multiple players, you have to come up with a solution to the problem of starting and joining games. Online poker rooms and backgammon sites often feature pretty advanced game lobbies, with active games being listed and sorted in various categories.

Enabling players to join waiting lists for games that are full is very useful, even when the player is currently seated in another game – or several.

It saves a lot of manual reloading in the chase of an open seat. It also reduces the risk of failure when several players try to join a game simultaneously.

A good game lobby prevents a lot of frustration among players and works as a lubricant for the game machine.

Stop Using MD5

I recently got a comment on the tutorial entry about securing our hashes that felt like it should be turned into it’s own warning, passed on to all readers. Unfortunately, the poster didn’t give me any information, so I can’t credit them – but here’s what they said about why you shouldn’t be using MD5:

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.

Tags: comment, hashing, md5, security, update

Battle Machines (Robotechnik) Design Document

I’ve been planning on developing or at least getting the PBBG up for a while now. It has been down for about four months and the longer I take, the more time it is going to be offline. So I’m going to finally get around to it. Here are the plans, the overall, the goals, and the stages for how the game will be implemented.

Design Documents don’t have to follow a formula, just write your ideas. The important element of the Design Document is that you write the design document. If you don’t, then you will forget features and ideas that you have for the game. If you have ever forgotten a feature, then you know that feeling where you know you had a really awesome feature that would knock the socks off the gamers.

License

The license is going to be GNU Affero General Public License, version 3. This means that you can extend and do whatever you want with it, sell, build modules, make money, and whatever. The restrictions are mostly that you don’t say that you wrote the application and make the source available. It also means that if you change something, then I will get that change.

Front-End

The front-end will include the average features that allows you to see the game before you play it and register and authenticate in to the game. It might not seem like much, but the front end will probably take at least two weeks and I’m going to allocate up to four weeks towards the completion of the front end.

The features are going to be:

1. Pages – The administration will allow for any amount of pages to be added and the navigation will automatically be built to include those pages.
2. News – Kind of newbie-ish, but I think it is neat to give your players and potential players updates about what features are added to the game and what is happening. Leaving people in the dark isn’t very exciting and giving players tastes of what is to come and what has been implemented can be interesting.
3. User Module – Registering, signing in (logging in), forgot password, and demo are going to be parts of the game. I believe this is going to be the majority of the time spent for the implementation on the game.

Administration (Back-End)

The goal for the administration is to allow for every aspect of the game to be managed without having to access phpMyAdmin. It is really insecure and doesn’t give very good reports and information having to do custom queries. Also things tend to screw up when you have human interaction and repetition. The administration is going to have to be developed along side the front-end, because the entire front-end is going to be dynamic.

Something that has been of interest to me lately has been reports, so I want to have graphs of usage, graphs of active vs inactive members. I want to have graphs for paid members vs free members. I want to try to have as many opportunities to let the administrators and moderators to see visual what is happening as well as manage the game. Managing isn’t very “fun,” but graphs, graphs can be fun depending on what they are for.

Something else, I’ve experimented in the past has been cheating detection, but the algorithms are slightly tricky. I want to try it again, but it will most likely be a stage 3 feature. I’m going to try to apply as many hooks as possible to allow others to add it once I release the source.

As for everything else, the main features here, will be managing what items are available in the game, the price, and what everyone has. There will also be permissions, so that not everyone will be able to change someone’s info.

I also like playing my own games, but I think there is a disconnect with having an administrator play the game, because some one is going to feel that the administrator is cheating. Therefore, I’m thinking of preventing the administrators from playing the game and forcing them to create a new account. There will also be logging as to what administrators do and when they did it, so that if someone does question the administrator actions, there will be a log backing the action up.

Game Interface

To be honest, it has been a while since I have played the game, so I’m sort of going to make this up as I develop the game. My main focus will be on the front-end and the back-end. I’m also going to attempt to implement as many current features as possible in to the new foundation.

The game is a robot wars type of game, so you build a robot or many robots and then fight them against other player’s robot(s). The goal, I think is to add more JavaScript and interactivity to the game. I suppose the problem I’m going to have, is that I’m going to be limited in the terms of graphics. However, if the game takes off, then I plan on finding someone who can develop the graphics for me.

Therefore, these features are going to be the main starting point for the game aside from the games past features:

1. Modular User Interface

   The navigation will be at the left side, of course, but there will be other “modules” that the player will be able to open (show) and close (hide). For instance, there will be an AJAX chat system, which will allow the player to chat with their team and with other players. This can be locked and kept open going to page to page or it can be closed and open per page. I want to allow the user interface to allow this.

   The game will not be completely AJAX, because I want to allow those who don’t have JavaScript enabled to still play the game. It is just that the game will be a lot more interactive, if JavaScript is enabled. I also don’t see that many players without JavaScript, so I’m not going to limit the game for those 1%-2% that don’t have JavaScript.

2. Store

   The player will be able to build, upgrade, or sell their robot(s) here. Most likely there will be a table (at the start) with the different areas on the robot and allow the player to pick and choose the part they want to buy for that area.

   At the start, the player will be given a set amount of money and allow them to create their first robot. This should allow for customization, but also be fair for every player. So if the player starts out with an awesome body, they might not have enough for any weapons, so the player is going to have to make sure they customize correctly to allow for the best stats for the robot.

3. Battle Arena

   The game is slightly different per other games I have built in the past. Different robots are going to have different stats, therefore, it only makes sense to allow any player to attack another player. The other player will be allowed to decline or accept and then pick the robot they want to battle against the other. After that, the attacking player has to confirm. The battle will then start and the results will be instant.

   In future versions, I want to allow for real-time battling, if both players are online. In terms of getting the game out the door, I am not going to focus on this feature and just implement the basics.

   The winner will receive money for winning and the loser will lose money. Also given, how long it can be before battles will be fought, it might allow for other players to bet on the winner and then pool that out to the winners of the bet as well.

4. Training

   The player will be allowed to pit their robot against a computerized opponent with random, but with attributes close to that of the players. This will allow the player to see how they will fare against opponents of like systems. Also it should help with developing their robots and guessing what the outcome will be against like enemies. I’m unsure at this point whether the training will also include missions, which will allow the player to make money.

   I also have ideas on creating AI opponents for while the game doesn’t have many human enemies to make the game interesting. AI is difficult and always time consuming, so I’m unsure at this point whether I’ll be able to get around to implementing it. If I do, then it will be a stage 3 feature.

5. Teams

   The focal point of any robot war game is a team going against another team. This will be fought much like the battle arena, but the team leaders will make the decisions with the players accepting them. I always want to add as many features as possible to this, but I’m going to keep this simple. The teams will have registration, description (team and player), site link, chat, and battle logs. I plan on extending the team features as the game is developed, but at this point, I only plan on the game taking two months, so while this is a stage 2 feature, I plan on implementing it before the game is released.

User Management

The user has to be able to change their password, see their stats, etc. They will do it here, separate from the game interface. I don’t want to implement the interfaces to where they are cluttered with different details. I want players to focus on the game and those who want to edit their user info to focus on that on only display links that go along with their user info.

You could say the different areas are much like a forum, except that instead of a big forum with posts and replies, you have a game.

Game Engine

The game will be built using Yii (PHP framework), QGL (PBBG class library), and jQuery (JavaScript library). It will be developed completely for Battle Machines, with foundations in set to have the game part stripped out and the game engine used as a foundation for other games. It is just that the game engine and the game will be developed side by side and built for each other.

Stages – Roadmap

I usually develop full game projects in three months. That was when I didn’t have a 40+ hour a week job, so I’m unsure how that is going to translate to how long it is going to take to finish this project. Most likely I’m going to cut back features and just stop after the time has past. I’m expecting the project to be done within the three month time frame. If not, then I’ll return it to later. The most important part, for me, is the game part, which is the second stage, so I’ll have a chance to go back to the user features and administration later.

1. Stage 1 – 2 weeks (+1 week for Yii Framework)

   Stage 1 is building the front end and the back-end to allow for managing the front end. I suspect this will take around two weeks to fully implement. I’m allow allowing one week to get the foundation with Yii up and running before the first stage even starts. I haven’t used Yii before and I will need to get familiar with it. I think one week should be enough time and I’m expecting that it will only take a few days before I can start implementing the main features.

2. Stage 2 – 6 weeks

   The game features will take most of the time and I’m going to focus on the above features as well as taking the current features and porting them to the new framework. I’m going to be using a lot of JavaScript, but I have been using jQuery for a while and I’m fairly proficient with it. I’m thinking I’ll be able to prototype the features fairly quickly and get the features fully developed quickly. I’m going to estimate a week for each above feature and an week (or any time left) on any current game feature that isn’t implemented above.

3. Stage 3

   This will be the stage to pack as many features as possible before release. If there are still incomplete features from the first two stages, then they will be completed or polished during this stage. The main point is not to add many features as possible, but to add features that the player isn’t really going to use all that often. If the player is going to be using it, every time they play, then the feature belongs in stage 2, so that it gets as much time as possible to be developed, tested, and polished before release.

   I have already stated several features that will hopefully be in stage 3. The other features are allowing for desktop applications to interface with the browser game, so that you can have a 2D or 3D playing experience on top of the current browser implementation. Well, actually that is the only other feature I can think of, besides porting the rest of the current game features to the new system for this stage.

I like to do rapid develop as much as possible. That is just how I roll. I also like using old code (that doesn’t suck), so I intend to build upon this version’s code base when developing the second version some time next year. It really depends on how well this game takes off. I want to get at least three games out by the end of this year. Hopefully, I’ll be able to bring the previous developer back to further develop his game. This will allow the game to be worked on after I’m “finished” with the current set of features.

The other two games are Farmer Sim and Mecha Asylum, which will be built off of this game foundation (game engine), which should hopefully shorten the time for those games and enhance this game with better front end and administration features. I’m going to be writing design documents for those games after I finish this game.

Tags: design document

Plant Wars: Postmortem

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.)

Winding Down

Building Browsergames launched on April 14th, 2008 – almost exactly 11 months ago. In that time, the site has accomplished a lot – we wrote a tutorial, interviewed multiple game creators, and managed to get post-mortems from a handful of different and unique games – like BlackSwordRPG, Booze Quest, Battlemaster, and many others.

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.

Getting your game to done: trimming your design

When most developers set out to build a browsergame, they tend to make big plans.

“It’ll all be real-time, and we’ll need at least six database servers just to handle the sheer amount of awesome!”

..The reality is, especially if it’s your first game, you won’t be able to build something quite that large(and most of the sites you visit on the internet don’t even use two database servers, anyway). However, that doesn’t mean that you can’t start taking the first steps, by getting something out there.

But what if you’re attached to your design, and that is what you want to build?

The simplest answer is trimming – take your entire design, and start stripping things away. Generally, I find that it’s helpful to make two lists – “things that have to be there”, and “things I want to have be there”. Then, you take all of your design notes and figure out what goes onto which list.

One of the easiest ways to do that is to start by putting everything onto the “things I want to have be there” list. Then, move pieces of your game over, one-by-one. Generally, things that are worth moving over are:

• Self-contained

  The feature shouldn’t rely on any other features to work. You’re getting your game up and running so that you can add more to it, not so that it will fulfill your design perfectly from day one.

• Small

  If one piece of your game will take two months to build, and each other piece averages a few days to a week, that feature isn’t a very good candidate(no matter how cool it is). Especially when you’re building your first game, motivating is hard – the more easy wins you have while you’re building it, the less likely you are to get discouraged and stop. One of the easiest ways to get easy wins is to focus on easy features in your first version.

• Low-resource

  Most of the developers that I have seen starting to build their own games have been working in a shared hosting environment, paying $5/month. And while your game is in it’s fledgling stages, that’s fine – but if a feature on your list calls for six database servers, you may want to keep it on the “I want” list instead of the “I need” list until you can actually justify the resources.

• Playable

  The last, and probably most important point, is that your feature needs to be playable. If that feature you’re considering moving over is really super-cool but isn’t something the players can interact with, it shouldn’t be in your first version. Building features that no one can see is a bit of a gamble even when your game is established; what are your players going to care if they can’t see it?

Once you’ve gone over your list and moved the bare minimum of features over to your “things that have to be there” list, you’re ready to start working on your game. Keep both lists somewhere that you’ll see them often, and while you’re building your game periodically review them – a lot of the time, features that you’ve built into your game will make it so that other features you wanted to have(but kept off your list) are now possible – and even easy.

Tags: design, features, release, trimming

Don’t let it die: keeping your game alive post-launch

So you’ve built and launched your game. Now what?

One of the most important things to do after launching your game is to keep it going; a lot of the bigger games out there(Kingdom of Loathing, UrbanDead, etc.) have been running for years – and the fact that they’ve been running for so long is part of their staying power. After over 5 years of building content, Kingdom of Loathing is extremely well established; it would be difficult for a new game to compete with them without providing a different gameplay format to entice players with.

With that being said, there are a few small, easy things that you can do to make sure that your game never seems ‘dead’:

• Update your game

  Just like Evil Trout said in his post-mortem for Forumwarz, “the job is never quite done”. There will always be a part of your game that needs work; maybe the design needs cleaning up, or there are bugs to be fixed, or there’s a new feature that you’d like to add. Whatever it is, there’s always something you can do with your game – so do it! If you can commit to updating even just once a week, it will show players that you’re dedicated to your game – and their confidence in your game’s staying power will grow.

• Tell people you updated your game

  Updates are good, but they’re not going to show users that you’re actually working on your game if they have no idea they’re happening. If most of your updates are content additions and features, you may want to start up a development blog – if the changes and tweaks you’re making to your game are primarily smaller(like balance adjustments and bugfixes), you may want to stick with something like Twitter. Whatever you do, you need to come up with a way to show users that your game is still actively growing and changing.

• Advertise

  This suggestion might sound a little weird, but think about it: when have you ever seen a dead game in an ad? By keeping your game ‘out there’, you’ll keep attracting new players – and it’s the community that will keep you motivated to work on your game, even when you don’t really want to.

• Respond to all e-mails promptly

  This is something that I’ve been neglecting with Building Browsergames lately – but an important(and easy) way to keep players from thinking that your game has died. Have you ever e-mailed someone, waited two weeks, and still not gotten a response? It’s hard to tell whether they even got your e-mail!

  When an e-mail comes to you, respond to it as promptly as possible. If a user e-mails you with a question(or a bug report) and gets a response within half an hour, they know that your game isn’t dead – and they know that you’re listening.

What do you do, to make sure your game doesn’t die? Is there anything on this list you’re not doing?

Using Google in your game

Sure, Google is the king of web search right now – but did you know that there are a few other services Google provides that you can use in your game?

Google Apps

Google Apps allows you to set up your own suite of Google-driven applications, for free – giving you shared documents, e-mail, calendars, and wikis. If you have control of your domain’s DNS records and haven’t already set up any MX records for another service, I would highly recommend Google Apps for your e-mail – I’ve been using the service for the last 6 months on a number of side projects, and haven’t had to deal with any headaches or downtime. Also, a 99.9% uptime guarantee is great if(like me) your core competency is development instead of e-mail.

Google Ajax APIs

Google also makes available a large number of Ajax APIs for developers – which lets you build things like Google Maps into your game, for free. One of the more useful APIs that they make available is their Ajax Libraries API – which means that you no longer have to worry about hosting your own copy of the core libraries for the javascript framework you’re using. The benefit of using Google’s Ajax Libraries API comes from caching, primarily – if users have visited a page that used the Google Ajax Libraries API before they visit your site, the javascript will be cached – which means that’s one piece of code their browser won’t need to fetch again when they visit your page. In the end, this results in a speed boost for your site – and even if the user doesn’t have the library cached yet, Google’s servers are configured with optimal performance and cachability in mind, so you don’t need to worry about doing that yourself.

Those are just two of the services Google offers that are useful to browsergames and not every developer knows about; are there any other Google tools your game is using?

Tags: api, google

An Interesting Business Model

Recently, there was a topic posted on the Browser-Based Game Zone Forums titled How to Make Money with a PBBG. The original poster has a few ideas for how to make money with his game, but was just wondering for some thoughts from other developers.

Codestryke, who owns and runs a handful of games, spoke about one of his games – which uses the ‘players buy turns’ system with an unusual twist: when one player buys turns, all the players get them. Turns are also kept in a ’stockpile’ of sorts – there are so many turns available for purchase each day, and once all the turns for the day have been bought players will have to wait for the next day to buy more.

I got in touch with Codestryke to ask him about why he went with this system as opposed to something a little more common, and this was his explanation:

In a turn based game everyone should get the same amount of turns as turns are actions so if someone gets more then another player then of course they will be able to dominate more. The only way to make the game fair yet earn income is to allow everyone to get them and the player who uses them in the best manner is the winner.

We do this on Cypher and did it on another game we ran called BordelloBattles where the idea came from originally. It’s worked out extremely well for both balance, a way to earn income and to bring a community effort into supporting the game.

While this business model seems to have worked out fine for Codestryke, I am sure that there are more out there – what sort of interesting business models have you seen in browsergames lately?

Tags: businessmodel, monetization