how to analyze the browerquest?

[adun]

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?

[mattstyles]

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 = this.game.getMouseGridPosition();
        
  if(this.game.targetCellVisible && !(mouse.x === this.game.selectedX && mouse.y === this.game.selectedY)) {
    this.drawCellHighlight(mouse.x, mouse.y, this.game.targetColor);
  }
}

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 `this.game`, 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.

[adun]

thankyou