Episode 6: Factories

admin Episodes

So initially I had all my code in one file. This was fine at first, after separating my code into states (see previous episode), I continued to add more and more features, most of which were pretty raw. Eventually my JavaScript file was over 3,000 lines long (which seemed huge to me).

This was about the time that I initially called it quits. My code was a jumbled web of noodles, and it was getting more and more difficult to change or add stuff. I was getting less done each time I sat down and coded, and I was losing direction and drive.

As I mentioned in the introduction, I found motivation to pick Zyrian back up after watching some videos on YouTube about the importance of finishing your software projects. I was inspired. I wanted to accomplish something. I wanted to be proud of something. I wanted to show someone something that I forged with my own 10 fingers and have them say, “oh, that’s kinda neat.”

Anyway, when I came back to the project a few months later, I found my code to be borderline incomprehensible – and I’m the one who wrote it! I was pretty ashamed of myself, so I decided the first thing I was going to do was come up with a better way to organize my code.

After reading a bit online about JavaScript programming patterns, I found something called the module pattern. If you don’t care about programming patterns, skip the boring stuff.

Boring Stuff

JavaScript is a powerful language, but if you have a background in a more tightly-controlled language like Java, you may find JavaScript’s freedom frightening. In JavaScript, all of an object’s properties and behaviors are public, which can lead to errors and poor coding. After all, why write accessors and mutators when you can just access your properties directly?

The module pattern is a way of encapsulating code by defining anonymous functions and immediately executing them. Because everything defined in a function is local in scope, and because all functions in JavaScript are objects, we can create an anonymous function and return only the properties and behaviors we want to expose.

As an example, I have a module that controls sound in its own file called sound.js, and it looks kinda like this (except with more things in it):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// Define sound factory
GameSystem.SoundFactory = () {
  // Define factory properties
  var SFXVolume;
 
  // Initialize properties
  var init = function() {
    SFXVolumeIncrement = 0.1;
    SFXMaxVolume = 1;
    SFXVolume = SFXMaxVolume;
  }  
 
  // Play a sound effect
  var playSFX = function(key) {
    var sound = GameSystem.game.add.audio(key, SFXVolume);
    sound.play();
  }
 
  // Increase sound effect volume
  var increaseVolume = function() {
    SFXVolume += SFXVolumeIncrement;
    if (SFXVolume > SFXMaxVolume) { SFXVolume = SFXMaxVolume) };
  }
 
  // Expose internal functions
  return {
    init: init,
    playSFX: playSFX
};
})();

This example of a factory returns three functions: init, playSFX, and increaseSFXVolume, and it has a property called SFXVolume which it uses internally to determine loudness. At this point we’ve successfully created an object that only exposes the functions we want it to, but things really get interesting when we start tying multiple modules together…

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// Define projectile factory
GameSystem.ProjectileFactory = (SoundFactory) { // Accept the sound factory as a parameter
  // Fire a projectile
  var fireProjectile = function(ship) {
    // Create the projectile sprite
    var projectile = GameSystem.game.add.sprite(ship.x, ship.y, ship.weapon.projectileSprite);
 
    // Set its velocity
    projectile.body.velocity.x = 0;
    projectile.body.velocity.y = -100;
 
    // Play the firing sound
    SoundFactory.playSFX(weapon.fireSound);
  }
 
  // Expose internal functions
  return {
    fireProjectile: fireProjectile
};
})(GameSystem.SoundFactory); // Pass the sound factory as a parameter

By passing our sound factory as an argument into the projectile factory, we are then able to expose only the init and playSFX functions. Ta-da!

Side note: I know Phaser has some built-in support for things called “plugins”, but I never got the hang of it. Perhaps I’ll investigate more in the future.

Interesting Stuff

I put all my game code in a variable called GameSystem so it wouldn’t interfere with other scripts or libraries. I could have called it Zyrian, but I wasn’t sure I would be sticking with the name (and I’m still not sure). So from now on when you see GameSystem.yadaYada, that’s just referencing some part of my game’s code.

Anyway, I now had a strategy for fixing my problem, so I painstakingly traversed each line of code and transmuted them all into different modules, which I called factories. Here are the factories I ended up with:

  • collisions.js
  • controls.js
  • entities.js
  • helpers.js
  • init.js
  • items.js
  • load.js
  • menu.js
  • nodes.js
  • npcs.js
  • missions.js
  • projectiles.js
  • sound.js
  • storage.js

Some of these were created right away, and some of them spawned from stuff I added later on. You may be able to figure out what they do just by the name, but I’ll explain most of them in future episodes.

Yay better code!

Leave a Reply