how to analyze the browerquest?

Recommended Posts

hello i'm non-English beginner javascript programmer. so no  fluent English

i'd study javascript and make website by reading book for 1 ~2 years

recently i have an interest in game programming and  found open source game aka browserquest

but this source is too hard to understand 

especially renderer.js is hard

i want this source analyze 

so i want to become javascript game programmer

how to analyze?

Share this post

Link to post
Share on other sites

A whole game like browserquest is an invaluable resource, even if it is a little old now, but don't lose heart, mature codebases are very difficult to read. I'd typically give any new starter a day to poke through the code and then direct them and talk through the code structure, and you get no direction when poking through github.

Get it working locally on your machine. If you do not know how to use the debugging tools in your browser then learn. Get the code working, add breakpoints and step through functions and sections you are unsure about. Look at variables and how they change over time.

For the case of the renderer.js you mentioned, it defines an object (you might call it a class) with a load of members and methods (just like a real class). Most of the methods are specific drawing methods, take, for instance (I chose this at random), 

drawTargetCell: function() {
  var mouse =;
  if( && !(mouse.x === && mouse.y === {
    this.drawCellHighlight(mouse.x, mouse.y,;

Looks to me like it grabs the mouse position, checks if the cell the mouse is in (I'm guessing a little as this function relies on stuff from outside) is selected and then draws some sort of highlight at the mouse position using a target colour. If you then go and look at the actual cell highlight function:

drawCellHighlight: function(x, y, color) {
  var  s = this.scale,
      ts = this.tilesize,
      tx = x * ts * s,
      ty = y * ts * s;
  this.drawCellRect(tx, ty, color);

So, yeah, looks like it draws a rectangle around the selected tile. This function is easier to read as only a couple of variables come from outside.

The functions within renderer (and probably the rest of the project) are very well named. The code is excellent (as you would expect from Mozilla) and very readable.

The renderer object has a load of draw functions, and, down the bottom, contains a couple of frame rendering functions. These frame rendering functions are probably called each frame and look like they redraw the entire canvas, libraries like Pixi would handle the actual rendering for you. In browserquest the frame rendering functions use the state of the game (looks like that all comes from ``, if you look in the `init()` function you can see where `game` comes from) to render the scene. This is all fairly standard architecture.

So, the game object holds the state of the game and renderer.js looks like it is the code that draws that game state. 

Other things for you to analyse:

* There are lots of objects and players in the game, there are probably functions to define these and possibly even factory functions to create them. Have a look at how that is done. Is there a list of game objects somewhere? Maybe a list of 'master' objects that are used to create game objects as they are created in the game.

* How is input handled? Somewhere there will be code that handles the input and then makes mutations to the game state. There could be lots of ways this is done. My guess would be they use the publish/subscriber pattern, although this might get more complex because that logic could very well be held solely on the server.

* Bare in mind this is a client/server game, this makes it significantly more complex. Logic is probably held on the server, there is probably a message protocol between client and server, and the client is probably solely responsible for rendering and input handling. Of course, in practise, some logic might sneak into the client.

* Just keep going, be persistent.

Some project stuff:

* Most projects break down into the same steps (these steps have been defined like this for ages, the implementations change over the years but if you picked up a game programming book from the 80's it will likely have a diagram modelling this):

-- create game state (init/load/bootstrap)

-- start game loop

-- -- handle inputs

-- -- manipulate/mutate game state

-- -- render scene

-- repeat game loop until exit condition

-- destroy game, release mem etc etc

Libraries like Phaser model this architecture explicitly but you'll find it just about everywhere. If you can pick out where in browsequest they stuff all these sections then analysing the code will become much much easier. I've said 'game' in those steps above, I could just as easily have said 'application', most stuff works this way.

Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.