Gage Herrmann

Nice list of articles. Thanks.

I was thinking about this exact thing this morning. A big reason I make games is because I notice problems in games, not bugs or graphical issues, but design and game-play flaws that I hope I can fix one day.

Cool!
Try it out: http://jsfiddle.net/eMqFG/1/

Wow, the physics and graphics look amazing.

...I don't know if I'd like looking at the little guy's butt the whole time though. ;)

@brillinfo On the contrary, I don't think it makes it less readable at all. If I use the caller's name, I know exactly what I'm dealing with. "menu.open()" is a lot easier on the brain than "self.open()".

The problem I have with "self" is that it doesn't mean anything. If you use "self" you have to go look at who called the function, which mean possibly scrolling up a few hundred lines or going to a different file.

My method instantly tells me who the caller is. I don't even think about a "caller" actually. I just think "I'm making this object do this."

Also, if we use self, what should we do if we want another callback? Write "self2"? ;)

Edit: Let me add one more thing. When you're in a callback or closure you're no longer in the class you were in. You're in no man's land, that's why you can't use "this" anymore and it's why I have no problem using the name of the object as a reference to the object. That's how I think of it, anyway.

"self" doesn't seem correct. I think we should instead use the name of the caller or something like the name of the caller.

Say your object is an Article, if you're going to lose the scope of "this" then write this:
var article = this;

If you're dealing with an object like:
$("#menu")
then do this:
var menu = this;

That makes way more sense to me.

@nickeyz

Thanks!

I'm giving a presentation on this at work on Monday. I'll definitely throw the word "scope" in there a few times.

Interesting...

If you do this, will it change the behavior of the whole page? You're essentially scrolling the body and your "fixed" element is staying still.

Considering how touchy CSS is in different browsers, this seems like it could cause problems for you later on. Have you had it cause any issues?

It took me a minute to understand that you were talking about the order in which to define things in a class, from top to bottom. At first I thought you were talking about documentation. Now it makes sense.

It works!

Example:
http://jsfiddle.net/HhPUb/2/

Having trouble with it in IE though. That could just be a jsfiddle problem.

Thank you. I work on web applications all day for banks and such. If I don't write readable code, then the next guy (possibly even me!) get's to wade through my pile of spaghetti. So, I cringe every time I hear game developers say things like "It doesn't matter what your code looks like, just start hacking!" Especially in the current open source renaissance, your code needs to be organized and readable. You should pay attention to the things that business app developers have been getting right for years.

A few ideas:

If your game connects to a server, you need to secure it. Use hashes, salts and all that.

You can write unit tests in just about any language. Since Javascript is popular for games right now I'll point anyone to Jasmine js: https://github.com/pivotal/jasmine

...and yes, use MVC. Seperate drawing logic from "business" logic (behind the scenes number stuff that doesn't have to do with screen dimensions). It takes a bit more work, but man, it really cuts down on confusion in your code.

Thanks again for the article.

That looks great. I like procedurally generated terrain.

@pvinis I would require the user to be online to buy items. They should have to authenticate with the server before purchasing anything, just like a real credit card.