Game states

[Froton X]

I've resumed my learning of the phaser js and even though I'm still a beginner, I've noted that the "Var _____ state" always corresponds to the file name, like play.js starts off with var play_state, and so on. However, I've noticed another thing. Why is the game.js start of with the declaration "var game =.." and not end with "State"?

 

Is there a phaser dictionary or list showing all the possible definitions in each category and the "when" and "when not to" of using definitions a certain way? If I can understand the "whys" of something, I can learn it in record time, instead of brute force memorizing or just learning it through repitition alone. Those help, but I can do it much better knowing the "why"? For example, I found this in a phaser related example: "var GameState = function(game) { };", it is different from any I've seen before, is it to get it to work on a webpage standalone? "GameState" is different from the other var declarations I've seen which used lowercase and "_". I don't just want to see and copy, I need to know and understand it! I only know some html before all this. I enjoy the challenge of trying to learn this "language" of computers.

[ctmartinez1992]

WAT?

[Videlais]

It reads as if you are actually asking about programming syntax styles rather than game states themselves, so I am going to try to answer that.

 

As for using an underscore as a prefix for variable names, it comes from the need to visually differentiate between 'private' and 'public' functions in JavaScript (and other ECMAScript languages). Since JavaScript is a prototypical language, its inheritance structure is different from other traditional object-oriented languages like C++ and Java. Just about everything is 'public' in JavaScript in the sense that it can nearly always be accessed directly from an object by knowing its property name. In order to mark the differences between them, then, some programmers use an underscore before a variable name for functionality that is supposed to be 'private'.

 

The underscores between words usually occur because variables can't have spaces in them. And one way to create the illusion of a space is to use an underscore. For example, if I had a variable named "Menu_Screen_Two", I could use underscores to help name the variable and make it look as if it had spaces in its name.

 

The two other prominent syntax styles are Pascal Style, capitalizing each concatenated word in a property or function name, and Camel Case, having the first word be lowercase and each subsequent word start with an uppercase letter. The former, Camel Case, is used by the DOM standard in naming JavaScript functionality (like getElementById, for example) and many programmers use it for their own naming conventions as well.

 

Remember too that JavaScript itself is not a typed language and makes no demands on how programmers name things other than the two rules of variable names not starting with a number and not containing spaces. Variables can be called "GameState", "gameState", or "Game_State". To the language itself, there is no difference. It will accept all of them.

 

 

The other issue you are asking about concerns file names.

 

Like programming syntax styles, this too is governed not by the language itself, but by naming conventions. Since JavaScript is built on past languages and those who write it often come to it from other backgrounds, many people name their files after the objects they contain. A game's menu, for example, may be in a file called "gameMenu.js" or something similar.

 

This is for convenience, not because JavaScript demands it be that way. (Unlike, say, Java or ActionScript where it is a requirement that the filename match the object contained within it.)

 

When a browser parses a HTML file and finds SCRIPT tags, it loads them one after the other into a global scope. For as long as that page is not closed or reloaded, all JavaScript within that page can generally access everything loaded after it within that page. All variables created during the first SCRIPT tag, unless deleted or created in another scope, can be referenced from later SCRIPT tags within the same page.

 

For convenience, many JavaScript programmers use a system of naming files for what are in them and then load them in a dependency list. (If Object A needs Object B to exist before it can run, Object B needs to be loaded before Object A.)

 

A common way of dividing up a project into different files is to have Phaser loaded first and then something like a "game.js" file next. For projects less than a few hundred lines of code, it is often easier to work on it all in one file and have that be something like a "game.js" file. However, it is a best practice to have files named after their contents and to load multiple files, even if that means more bandwidth taken up for testing. (For publishing/production code, it is best to use a closure compiler for JavaScript projects. However, that's definitely an advanced topic to learn about.)

 

(To answer your question about game states, they need to have certain properties. This means that they can be objects or functions in JavaScript. All that is required is that for the properties of 'preload', 'create', 'update', and 'render' they themselves need to be functions. Those properties need to be able to be 'called' from Phaser's internal functionality and therefore must be functions.)

[Heppell08]

+1 to Videlais for that answer.

[Froton X]

That was what I was looking for, thank you, Videlais. This should make things easier for me.

[george]

Nice! Sometimes it's so hard to be free. No one tells you how to name or code things

Regarding the underscore in Javascript: I think the underscore_case is much more clearer in dividing words. I kind of prefer it. This style is so common in ruby so I write half of the day in underscore_case when programming ruby code.

 

Despite the fact that I like the under_score style more I force myself to use CamelCase in Javascript.  Somewhen in the past I read an article about coding styles and the argument to use CamelCase in Javascript was (of course among other valid arguments) that the word JavaScript itself is CamelCase. (Yes! Just have a look at Wikipedia). This changed something in my mind. Something so fundamental like the name itself is CamelCase and I never connected those lines ?! From that moment on I always forced myself to use CamelCase in JavaScript even that I liked the underscore case more. Why?

 

Not only because of the name story It's THE naming convention most JS developers choose today. That makes it more comfortable to read other's code and also give code to others. Just think of Phaser to be in context. You want to contribute? Forget about the under_score style. Phaser is programmed in CamelCase.

 

It's also easier from the viewpoint of decision making . Back in the days I remember myself coding under_score OR CamelCase. It only depended on my mood and it could virtually change with every new file. Sometimes programmers hate freedom.

 

Regards George