Building Browsergames

Christmas Survey Results

First off, a big thank you to everyone who filled out the survey – I’ve gotten confirmation on a lot of the plans that are being put into place, in addition to meeting a few more people who would be interested in writing for Building Browsergames (if you filled out the survey and gave me your e-mail, check it now – you should have an e-mail from me saying thanks).

The overwhelming response to the question What would you like to see on Building Browsergames primarily? was tutorials — while I know I’ve kept you all waiting, I’m hoping to be able to begin publishing some of the tutorials on the tutorial list very soon.

One of the readers who responded to the survey mentioned that they’d like to see some more “architecture” oriented tutorials – but forgot to provide their e-mail! If that was you, please get in touch with me at buildingbrowsergames@gmail.com, and I’ll see what I can do.

Based on the number of survey respondents who indicated that they were interested in writing for
Building Browsergames, it looks like we should have a lot more updates coming down the pipe – I also have a few changes in mind for the site that should make it easier for new (and old) visitors to find things on the site that they haven’t already, going into the new year. There are big plans for The PBBG Network and PBBG Snippets in the works as well — but I’m keeping those under wraps for now.

Once again, thanks to everyone who responded – I hope that everyone had a safe and happy new year.

How are we doing?

Now that Building Browsergames has started back up(albeit slowly), there are a lot of big changes planned. With that in mind, I wanted to ask you, the community, for some opinions on what direction you think the site should take(and how it’s doing so far).

If you’d like to provide some feedback, please take some time to fill out the Building Browsergames Christmas Survey, and give me your opinions.

Want to leave more feedback? Get in touch with a comment, or send an e-mail to buildingbrowsergames@gmail.com.

Tags: survey

EffectGames.com launches

I recently stumbled accross EffectGames.com, which bills itself as providing “free, online tools for building, sharing and playing your own browser based games”. I managed to get in touch with Joseph Huckaby, one of it’s cofounders, for a little more about the service:

Well, it took me four years, but I believe I have finally proven that you don’t need Flash to make great web games. I have just launched a new website called “Effect Games”, which allows developers to create professional quality JavaScript games for free, and publish and share the games just like they would a YouTube video.

There are several game demos up on the site, so you can see what the engine can do. All modern browsers and platforms are supported, including IE 6+, Firefox 3+, Safari 3+, Chrome 1+, and Opera 9+.
Games are powered by the “Effect Engine”, my JavaScript / DHTML library that provides the framework for displaying and animating all the graphics, playing all the sounds & music, handling the keyboard & mouse, and sprite collision detection. It can smoothly render multiple layers of parallax scrolling tiles and sprites using pure DHTML (no Canvas or SVG, so it plays nice with all browsers).

HTML 5 Audio is used where supported (currently Safari on Mac OS X 10.5 only, 10.6 and Firefox coming soon), and 3rd party extensions used elsewhere. But developers don’t have to worry about the underlying implementation. The engine provides a single API, which is the same no matter what tech is used under the covers. Write your game code once, and it’ll run everywhere. Everything is documented online, including a side-scrolling platformer tutorial.

We have an integrated web app which allows developers to prepare and design their game online. It comes with an Asset Manager for uploading and organizing game graphics and audio, a Level Editor for laying out sprites and tiles into levels, and lots of tools for manipulating graphics in real-time using non-destructive filters (scaling, rotation, and a number of other transforms).

Users can develop their games locally on their Macs or PCs, and don’t have to upload any code until they are ready to publish. The game publisher can compile their code automatically using Google Closure, and provides them with a unique URL and embed code to share the game on their own site, blog, or anywhere they want.

The engine also has a Plugin architecture to bring in 3rd party libraries to add new features. For example, we just released a Box2D Physics Plugin, bringing realistic physics simulations into the engine.

We’re getting ready to launch a slew of new features in the coming months, including video support, achievements, leaderboards, more social network integration, and the ability to save & load games in progress.

After taking a look at some of the demos, it looks like there are a lot of cool things to be made with EffectGames – it will be interesting to see what the community creates with the service.

Tags: launch

Got Snippets?

Frequently while working on a browsergame/PBBG, I’ll write a piece of code and then think to myself “hey, that might be useful in another project some day”. In those situations, I’ll put the snippet somewhere on my system, and then go about my day.

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.

The Tutorial List

Alright, it looks like the people have spoken! Here’s the full list of requested tutorials:

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

Looking for a tutorial?

It’s that time of year again — the time of year when Building Browsergames solicits ideas for the next batch of tutorials we should write.

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?

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