HTML and CSS Reference
In-Depth Information
enemy_circle: { sx: 158, sy: 0, w: 32, h: 33, frames: 1 }
var enemies = {
basic: { x: 100, y: -50, sprite: 'enemy_purple', B: 100, C: 2 , E:
100 }
Next, modify playGame to add a pair of enemies to the top of the page:
var playGame = function() {
var board = new GameBoard();
board.add(new Enemy(enemies.basic));
board.add(new Enemy(enemies.basic, { x: 200 }));
board.add(new PlayerShip());
Using the enemies object as a blueprint for the enemy makes adding an enemy onto the page as simple
as calling new Enemy() with that blueprint. To make the second enemy appear to the right of the first, an
override object is passed in setting x to 200 .
Reload the file, and when the game starts, you should have a couple of bad guys snake their way down the
screen and then disappear off the bottom. You can also take a look at to see the
effect this code has. These enemies aren't doing any collision detection, so they won't interact with the player.
The basic enemy has only three of the enemy movement parameters defined: B (horizontal sinusoidal move-
ment), C (horizontal sinusoidal period), and E (vertical fixed movement). Play with these parameters to affect
the movement. Increasing C, for example, increases the frequency with which the enemies bounce back and
Refactoring the Sprite Classes
At this point the game has three different sprite classes that all share a lot of the same boilerplate code. This
means it's time to apply the Rule of Three.
As described by Wikipedia, the rule is:
Rule of three is a code refactoring rule of thumb to decide when a replicated piece of code should be replaced
by a new procedure. It states that the code can be copied once, but that when the same code is replicated three
times, it should be extracted into a new procedure. The rule was introduced by Martin Fowler in Refactoring
and attributed to Don Roberts.
Even though Alien Invasion is a one-off game engine that isn't intended to be turned into a general-purpose
engine, it still pays to put in a little bit of time to refactor the code when it makes sense to clean up any rampant
duplication and make the game easier to fix and extend.
No one writes perfect code the first time, especially when prototyping and trying out new features. When
that code works, however, failing to refactor and clean up code during development leads to technical debt .
The more technical debt you have on a project, the more painful it is to make changes and add new features.
Refactoring can clean up technical debt by removing unused code, reducing code duplication, and cleaning up
Search WWH ::

Custom Search