Canvas spatial grid collision

You can see a working example here. Be sure to click on the canvas or the key inputs will not be detected!

Are there any ways I could improve upon this? Anything that should have been done differently? Any best practices I have not implemented?

```
$(document).ready(function() {

window.addEventListener('keydown', keyPress, true); // event listener for keyboard presses
function keyPress(evt) {
if(engine.activeBlock) { // block is actively falling
switch(evt.keyCode) {
case 37: // left arrow
engine.activeBlock.keyLeft();
break;
case 39: // right arrow
engine.activeBlock.keyRight();
break;
case 40: // down arrow
engine.activeBlock.keyDown();
break;
}
}
}

// block object
function block() {
this.xStart = function() { // random x coordinate of starting position of block
var x = Math.floor(Math.random() * (engine.cellsX - 1 + 1)) + 1; // random number between 1 and cellsX
return (x - 1) * engine.cellSize;
};
this.x = this.xStart(); // x coordinate
this.y = 0 - (engine.cellSize * 1.5); // y coordinate
this.velocity = 1; // velocity of the block
this.generateColor = function() { // generates a random color
var colors = ['blue', 'red', 'green', 'black', 'orange']; // colors array
return colors[Math.floor(Math.random() * colors.length)];
};
this.color = this.generateColor(); // color of the block
this.keyLeft = function() { // key left
if(!engine.collisionLeft()) { // check collisions left side
this.x -= engine.cellSize;
}
};
this.keyRight = function() { // key right
if(!engine.collisionRight()) { // check collisions right side
this.x += engine.cellSize;

Haven't looked at the code in detail, but here are some thoughts on the overall structure:

Right now, there's some mixing of concerns and tight coupling going on. The engine calls update on the active block, but the block then calls back to the engine to check for collisions. In other words, the two are tightly coupled; they're dependent on each other, and its unclear where certain responsibilities lie.

The block is a pretty simple object, which can be reduced to simply being an x, y position, and a velocity. And it should probably stop there. The engine would be responsible for moving the block (the block object can do the calculations, though), checking collisions, accepting keyboard input, etc.. I.e. keep the block "dumb"; it doesn't need to know its context.

I'd also suggest making a similarly "dumb" grid object that the engine object can interrogate and instruct. I.e. the grid doesn't move blocks around, it simply keeps track of them for the engine. The grid could check for collisions, but it'd be up to the engine to ask.

Where exactly to draw the boundaries between the objects and their responsibilities is up to you (there are many ways to break it down), but the idea is to keep things decoupled when possible. I.e. blocks don't rely on a grid or an engine being there; the grid may or may not care about blocks being blocks, just that there's something in a given cell, etc.. Perhaps there are more things, you can extract and/or abstract and encapsulate in objects or constructors, while the engine sits in the middle acting as controller.

On a purely syntactical level, I'd move the methods of into the prototypes for the objects. That is, from this

function block() {
  // instance variables ...
  this.update = function () { ... }
}

to this

function Block() {  // CamelCase since it's a constructor
  // instance variables ...
}

Block.prototype.update = function () {
  ...
};

This will make it easier to do prototypal inheritance, as the methods will actually be prototypal.

StackExchange Code Review Q#23095, answer score: 2