Building Browsergames

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

Post Mortem – Orion’s Belt

Hello, my name is Pedro Santos and I’m one of the developers of Orion’s Belt (OB). Orion’s Belt is a tactical mmo where the player has to manage planets and explore the universe. There are a lot of games of this genre, but OB differs because it’s very tactical, on very different levels. We didn’t want to make just another clone so we invested a lot of time designing a new game with lots of interesting features.

We started to develop OB for a school project, 7 years ago. Soon after we launched the game and kept it as a hobby for about 5 years. All that time we learned that we didn’t had a scalable game, and we had many difficulties to maintain the game.  But the experience running the game was very valuable, because we learned several useful things:

• Technical skills aren’t important – no one cares about the site being made on tech X or Y, they just want it running and bug free
• Having a pretty website is very important for converting new visitors…
• …but good game play is what keeps them around
• Having a quality website, and an excellent game play is worthless, if you don’t get people to see it!

This last point was our biggest problem! We only targeted the Portuguese market, and in about five years, we got ~5000 registrations. That is a very small quantity! One thing is a player registering, playing, doesn’t liking, and moving on. That is normal, there will always be people that doesn’t like the game. But they should at least try it, to know about it.

After realizing the problem, we searched for solutions. How to property promote a browser game? That is, with a limited budget of course. We are still working on that, but now that we learned that our biggest problem was distribution, we’ll be less likely to fall on the same problem again. At least we hope so.

All that time running the first version of OB, we had a great community supporting us, and that made us go on. A couple of years ago our current employer found us and he liked our work and and project so much that he decided to fund a new version, without any of the problems of the previous one. We have been spending the last six months working full time on OB, and getting paid for it! It’s like a dream come true, after a lot of hard work. And now we have a marketing department to assist us on promoting the game.

So, if you’re starting or running a small browser game, don’t give up, focus and work hard. There’s a huge market and we all have a place on it. Also, network like hell and share ideas with other developers.

Tags: orionsbelt

We’re Finished!

It’s been just about 10 months since we first began our tutorial, by designing the database for our game. Over the months, our game has grown and evolved – and for the most part, we have fulfilled our original goal: to build a basic browsergame.

Over the course of our tutorial, we’ve:

• Built a basic authentication system
• Added some simple stat storage and retrieval for every entity in our game
• Created an items system
• Created a basic combat system
• Built armor and weapons into our combat system
• Fleshed out our exploration system to support multiple areas

While that might not seem like much, what’s important here is that we’ve laid the groundwork for something bigger – and if you were thinking of building your own game and not sure where to start, now you’ve got your starting point.

Not sure what to do next? How about:

• Building quests
• Player vs. Player combat
• More shops
• More items
• Player rankings

With the code that we’ve written for our tutorial(which you can get from the Google Code project), you’ve got a decent starting point for your own game.

With that being said, we’re finished! The first tutorial is complete – now go out and make something with it!

What do you want to see in the next tutorial? What could have been better about this one? Send your thoughts and suggestions to buildingbrowsergames@gmail.com.