I need some code explained.

[xcb]

Hi.

I was just rewriting http://vimeo.com/105955605 this thing and searching for stuff i don't understand while rewriting it. Here is jsFiddle: http://jsfiddle.net/mstfrwvn/2/ . 

 

I learned a lot doing so, but there are still a few things I don't quite understand.

-why did she use those prototypes? Can't I just put those functions inside the constructors with "this."? Was it to make it less cluttered or something?

-why is everything in a function? Is it to "encapsulate" it from other potential code? (I hope I'm using this term correctly)

 

I also know it isn't well optimized/there are things which can be improved (I know the purpose of the presentation wasn't to make it optimized, but finding flaws in it may be a good exercise!). Things I found:

-projectiles aren't deleted after flying out of the view.

-speed of the game depends on the framerate.

 

Sooo, could someone explain these things to me and maybe find some other flaws? (I would like to strip it out of everything and make some simple games using this)

[Bananaoomarang]

Hey there

 

In answer to your first question, using the:

this.foo = function(bar) {  // Some fantastic code}

Is perfectly valid, but can be confusing. Code written as here, using the prototype object and instantiating with 'new', has two main advantages:

 

1. Every object based on the class will share the same 'prototype' code, using 'this' within the constructor only changes that object specifically. This is also more memory efficient, and leaks are likely to be less severe.

2. If you're new to Javascript, the 'this' object can be confusing. Without using 'Function.prototype.call', 'bind' or 'apply', what it references might be unexpected. For example:

var foo = function() {  console.log(this);}foo() // === the global 'window' object

This means assigning functions to 'this' here would actually just clobber the global scope, which is presumably not what you want. In fact, if using 'strict' mode (which I would recommend using all the time, as it'll save you from later headaches), in order to stop this happening and confusing people like us, 'this' here would be 'undefined', not 'window'.

 

If you assign the functions to 'prototype' and use 'new' for instantiation instead you avoid ever having to deal with this. I also think it looks aesthetically cleaner, since it avoids another level of indentation.

 

You're completely right about the second one. Conventionally it's called a 'closure', and yes, it sandboxes the code. This follows on nicely, since again it is to do with not wanting to assign variables to the global scope 'window' object. Javascript is a garbage collected language, and if an object is attached to window it'll stay there until the reference changes, either by 'delete' or being overwritten.

 

Consider:

// Global scopevar foo = 'bar';(function() {}  // In a closure  var foo = 'bar')();

In the first instance, 'window.foo === bar'. In the second, as long as nothing outside of the closure references 'foo' anymore, the garbage collector automatically takes care of deleting the object for you after the function has run, and it never gets assigned to the global window. This again, once you get over the semantics, leads to cleaner, clearer code, with less memory leaks and bugs down the road.

 

As for bullets not being deleted: yes, although this is not a problem at this scale, a simple bounds check and 'delete' would be an easy enough fix.

 

Speed depends on framerate: yes, you need to calculate a delta in time between the start of the update/draw loop and the end (you could use the 'Date' function), then scale the game objects' motion accordingly. Googling 'delta gameloop' or similar will help explain if you're confused about how to do that.

 

Other problems/future advice? I would just separate out the code. Most of it looks fine (the collision function makes me cringe, but often collision functions have to look a bit like that to be sane). 

 

I usually use browserify (you can use watchify for convenience during development). This means you can separate each module into a different file without having to worry about fifty ordered <script> tags on the page, you just include one, compiled one. For a project of this size one file is probably fine, but having the code split into separate files will make even this a lot clearer, and down the line it's invaluable.

 

The other main option for this is RequireJS, though to me Browserify seems cleaner and simpler, and I would recommend it to you.

 

Have a lot of fun

[xcb]

Thank you. Your response helped me a lot. I don't really have any more questions right now. I will check out Browserify. And thank you again for very detailed response.

[Bananaoomarang]

No problem, I've been there! Glad to help