Quite simply, because while I usually feel pretty comfortable around computers and trying new things with new programming languages, Javascript has always been a formidable foe to me (for whatever reason). I knew I had to do something to take Javascript down a notch in my own mind so that I would have the confidence in moving forward and really exploring the language. Given that, and I that I am a huge gaming geek and I decided that I wanted to go pretty hard on this project.
I know, but I can't really learn things in a fictitious vacuum. It simply doesn't work for me. I need to see something applied before the concept of why you would do something one way versus another sinks in.
So, I took the liberty of doing a ton of research and then spending about 12-15 hours learning a game framework called phaser.io. Phaser is an HTML5 game rendering engine that interacts with the canvas element.
What is interesting about Phaser is that it dictates very little about the way in which you build your game - after all, the entire engine lives in one file (phaser.js - please use the minified version for production). The good is that, because the engine is very un-obtrusive, you have an immense amount of flexibility. The bad is that you will see 10 examples of games done in 10 different ways, forcing you to go back to square 1 and do a lot of research on how games work, how you are going to organize your code and how Javascript really works with objects, which is exactly what I wanted out of this exercise.
Games rely on a few core concepts. First, games exist in individual 'states' - a loading screen is a state, the main play screen of the game is a state, a high-score screen is a state, etc. Roughly speaking, each screen in the game exists as its own state. Here, for simplicity, there is only one state - the main game play window. The character never dies, the game just goes on and on until a user refreshes the page, at which point the game begins again.
Next, games need to be able to render art assets (e.g. a picture of the character or the boss) in a way that is responsive to the physics of the world. Such images, which are commonly referred to as sprites, can sense world boundaries, contact with other entities that have been enabled, etc.
Lastly, games operate using an update loop - a user-defined function will be called by the game engine 60 times per second. Within that function, we do everything that we need to update the game - we check for collisions between the actors and the environment and act accordingly and sense and react to character movement. That is more or less it...
To re-iterate, our game has a single state, which I called 'main'. Using Phaser is really as simple as telling the game to start its engine with the state you've defined and then defining 3 functions that the game engine will use to run your game.
preload() - this is where we load all of our game assets, including art, sound, etc.
create() - this is where we actually draw onto the screen the various art resources that we are going to use, initialize the audio, the keyboard, etc.
update() - this is the aforementioned update loop. This function will get called 60 times a second, allowing you to update your game within.
You can see that Phaser is just phaser.js and that we have to provide/build out everything else. So here is what I did.
I first decided that there would be an 'assets' directory and that all art and audio assets would live there.
I similarly decided that all the Javascript should live in one place so I created '/src'. Within that directory, there is a directory solely for Phaser stuff, which consists of only Phaser.js at this point. The 'lib' directory within 'src' was where I decided to store all of our models and that is where you will see objects representing the Hero, the Boss, Gems, etc.
That leaves 'tests', which simply contain the jasmine tests and which is super easy to set up - Google/YouTube should really be able to straighten you out in under an hour, at which point it will just look like RSpec to you.
Lastly, there is main.js, index.html, and the file you are currently reading (whatILearned.html). The only remarkable item of note in index.html is that it is basically empty. Our Javascript code takes care of writing to the named element 'gameDiv' so it really is sufficient to just have the named element.
Main.js is thus the entry point - here is where we define the main state object. Within that, I have used objects as namespaces to create sub-libraries that essentially handle all the required functionality.
In other words, during 'preload()', I simply delegate to a set of functions within this.preloader. Similarly, when I go to draw on the screen, I ask this.draw to help me out and draw all the things I need on the screen. Again, behind the scenes, its just using objects as namespaces (and you can see this if you read the jasmine tests or just look at the code, but its amazing what that simple trick can do for code organization and readability (IMO)).
I could go on, but better than that, I really urge you to start your own Phaser project, or better yet, fork mine and improve it!