super big tree

Media, technology, education, and design.

[superbigtree]

I'm working on a tool that would replace using tabletop.js with Google Spreadsheets

Have you ever used Google Spreadsheets with something like Tabletop.js to create a miniature ad-hoc CMS?

I'm working on something named Flatsheet that is intended to solve that problem more effectively.

Flatsheet is a tool for managing tabular data with a friendly editor and a simple JSON API. The editor allows the creation of rows and columns of data, similar to a spreadsheet. The JSON API exposes that data so it can be easily utilized by websites and applications.

The current goals are to improve the editor UI to create the simplest possible editing experience, to create integrations with other tools, like syncing with Google Spreadsheets and dat, and to allow group collaboration on a dataset through the UI.

The prototype is built with Rails, Postgresql, Backbone, and modules from npm.

How can I use it?

Right now you can test out Flatsheet by creating an account and uploading a CSV file or a JSON file that contains an array of flat objects.

When you view your sheet you'll see a link for the API endpoint for that sheet. Make a GET request for that endpoint and you're ready to integrate the dataset into your app.

Check out the documentation.

Important: This is a prototype, so while we'll preserve any data that exists on the system when upgrading to new versions of the app, remember that Flatsheet is in heavy development and may change at any time. The project is open source, so you can set up your own instance of Flatsheet if you wish.

So this is open source? Can I contribute?

Heck yeah, bud.

Fork the repo here: github.com/flatsheet/flatsheet-prototype

There's also the beginnings of a javascript API client here: github.com/flatsheet/flatsheet-javascript-client

The parts that make up Flatsheet will always be open source, so you'll be able to run your own instance on your own server if needed.

What happens next?

Conducting user testing with the existing proof of concept version of the project, and iteratively creating new versions of flatsheet based on what's learned from each round of user testing.

Writing documentation, developing API client libraries (the javascript client is in development), creating example projects that show usage of the API, and integrating with related tools.

If you'd like to stay updated you can sign up here and I'll let you know when big things happen with Flatsheet

Let me know what you think

You can email [email protected] or plop your thoughts on the issues queue for the prototype.

[superbigtree]

Check out this simple implementation of pong made in a few hours last night: sethvincent.github.io/digital-table-tennis-for-two

It's made using crtrdg.js, a 2d toolkit for making games that leverages browserify for writing node-style javascript modules for the browser.

Here's the source on GitHub: github.com/sethvincent/digital-table-tennis-for-two

I'll be including a chapter on how to make pong in the next update to the Learn.js book on 2d games.

Pre-order the book for $10 or the 4-book bundle of the Learn.js series for $25 to get updates as they are released, or sign up for our mailing list to get notified when the next update happens.

Find our more about the Learn.js series at learnjs.io.

[superbigtree]

A simple example application using express, ejs, and nodemon

Let’s make a small website with express to explore how it works.

In this example our site will do three things:

serve html at the root route from a view that has a list of posts

serve html for a single post at /post/:id 

serve json at /api/posts that has a list of posts

We won’t be using a database for this example, but instead will use a json file with a list of posts.

To get started, create and change directory into a new project folder, then run npm init to create a package.json file.

mkdir express-example cd express-example

We’ll be using express and for templates we’ll use the ejs module, so let’s install those dependencies:

npm install --save express ejs

We can also use nodemon to run the app – nodemon will automatically restart the server each time you edit a file in the project.

Install nodemon:

npm install -g nodemon

Run nodemon with these options so that changes to ejs views and public files also trigger the restart:

nodemon -e js,css,html,ejs

Create a file named posts.json with the following json:

[ { "title": "This is the first post", "slug": "first-post", "content": "The pizza is awesome. The pizza is awesome. The pizza is awesome. The pizza is awesome. The pizza is awesome. The pizza is awesome. The pizza is awesome. The pizza is awesome. The pizza is awesome. The pizza is awesome. The pizza is awesome." }, { "title": "Another post that you might like", "slug": "second-post", "content": "Eating pizza is great. Eating pizza is great. Eating pizza is great. Eating pizza is great. Eating pizza is great. Eating pizza is great. Eating pizza is great. Eating pizza is great. Eating pizza is great. Eating pizza is great. Eating pizza is great. Eating pizza is great." }, { "title": "The third and last post", "slug": "third-post", "content": "The pizza always runs out. The pizza always runs out. The pizza always runs out. The pizza always runs out. The pizza always runs out. The pizza always runs out. The pizza always runs out. The pizza always runs out. The pizza always runs out. The pizza always runs out. The pizza always runs out. The pizza always runs out. The pizza always runs out. The pizza always runs out." } ]

First we’ll create the app.js file:

var express = require('express'); var fs = require('fs'); var app = express(); app.use('/public', express.static(__dirname + '/public')); app.locals({ title: 'Extended Express Example' }); app.all('*', function(req, res, next){ fs.readFile('posts.json', function(err, data){ res.locals.posts = JSON.parse(data); next(); }); }); app.get('/', function(req, res){ res.render('index.ejs'); }); app.get('/post/:slug', function(req, res, next){ res.locals.posts.forEach(function(post){ if (req.params.slug === post.slug){ res.render('post.ejs', { post: post }); } }) }); app.get('/api/posts', function(req, res){ res.json(res.locals.posts); }); app.listen(3000); console.log('app is listening at localhost:3000');

Let’s break down this example code chunk by chunk:

Require the needed modules and create the app variable:

var express = require('express'); var fs = require('fs'); var app = express();

Set up the app to serve whatever is in the public folder at the url /public/:filename:

app.use('/public', express.static(__dirname + '/public'));

You can add local variables that can be used in views and throughout the app by passing an object to app.locals():

app.locals({ title: 'Extended Express Example' });

In this example we’re loading the posts from the json file before responding to routes:

app.all('*', function(req, res, next){ fs.readFile('posts.json', function(err, data){ res.locals.posts = JSON.parse(data); next(); }); });

When a browser requests the root url, our app responds with the index.ejs file. Express automatically looks in a folder named views, so you only have to pass the file name:

app.get('/', function(req, res){ res.render('index.ejs'); });

The following code block listens for requests for a specific blog post. We search the items in our posts array, and if the slug that’s passed in the url matches a slug in the posts array, that post is returned:

app.get('/post/:slug', function(req, res, next){ res.locals.posts.forEach(function(post){ if (req.params.slug === post.slug){ res.render('post.ejs', { post: post }); } }) });

The following is a simple example of exposing a simple json feed of the posts:

app.get('/api/posts', function(req, res){ res.json(res.locals.posts); }); And finally, we make the app listen on port 3000, and print a message to the terminal:

app.listen(3000); console.log('app is listening at localhost:3000');

Next, we’ll need the views for rendering html. We’ll use a templating language named ejs for our views.

The only downside to ejs is that it doesn’t allow us to specify a layout view like we did with sinatra and erb.

To get around that we’ll create header and footer views that we later include on other views.

Let’s a views folder for all the views to live in:

mkdir views

And create all the view files that we need:

touch views/header.ejs views/footer.ejs views/index.ejs views/post.ejs

Add this content to the header.ejs file:

<!doctype html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no"> <title><%= title %></title> <link rel="stylesheet" href="/public/styles.css"> </head> <body> <header> <div class="container"> <h1><a href="/"><%= title %></a></h1> </div> </header>

Add this content to the footer.ejs file:

<footer> <div class="container"> <p>Posts are also available via json at <a href="/api/posts">/api/posts</a>/ </div> </footer> </body> </html>

Add this content to the index.ejs file:

<% include header %> <main role="main"> <div class="container"> <% posts.forEach(function(post){ %> <h3> <a href="/post/<%= post.slug %>"> <%= post.title %> </a> </h3> <div><%= post.content %></div> <% }); %> </main> </div> <% include footer %>

Add this content to the post.ejs file:

<% include header %> <main role="main"> <div class="container"> <h3><%= post.title %></h3> <div><%= post.content %></div> </main> </div> <% include footer %>

Let’s add some css styling so this looks a little more readable.

First create the public folder and the styles.css file:

mkdir public touch public/styles.css

Now add this content the styles.css file:

body { font: 16px/1.5 'Helvetica Neue', Helvetica, Arial, sans-serif; color: #787876; } h1, h3 { font-weight: 300; margin-bottom: 5px; } a { text-decoration: none; color: #EA6045; } a:hover { color: #2F3440; } .container { width: 90%; margin: 0px auto; } footer { margin-top: 30px; border-top: 1px solid #efefef; padding-top: 20px; font-style: italic; } @media (min-width: 600px){ .container { width: 60%; } }

You should now be able to navigate the home page, three blog post pages, and the posts json feed. Run the project with the nodemon command:

nodemon -e js,css,html,ejs

This post is an excerpt from Development Environments for Beginners, a book that teaches using git and vagrant to set up development environments for ruby, javascript, and python. You can buy the book alone or as a bundle with a series of javascript/node.js books called Learn.js.

[superbigtree]

I'm excited about this animation I added for shielding the player against enemies. This video also shows that you can buy and eat potatoes to increase health points. Play the game here: http://superbigtree.com/mossybellies/

[superbigtree]

Creating animations with javascript, the canvas tag, and crtrdg.js

Let’s make some canvas animations happen for a specific amount of time before stopping, or to perform certain movements, then stop.

We can define an animation then run it on mouse click or key press.

The trick is to define a trigger that starts the animation, draw the thing and concurrently step toward an end condition, and define an end condition.

In these examples I’m using crtrdg.js to set up the canvas and provide some helper methods, but you could easily accomplish this with plain javascript or with other game/canvas libraries.

Here’s an example where a box spins for a while after clicking the mouse:

var Game = require('crtrdg-gameloop'); var Mouse = require('crtrdg-mouse'); var game = new Game(); var box = { position: { x: game.width/2, y: game.height/2 }, size: { x: 100, y: 100 } }; box.rotate = function(){ degrees += 25; } var mouse = new Mouse(game); mouse.on('click', function(){ box.rotate(); }); var degrees = 0; game.on('update', function(){ if (degrees > 0){ degrees--; } }); game.on('draw', function(context){ context.save(); context.translate(box.position.x, box.position.y); context.rotate(degrees); context.fillStyle = '#fff'; context.fillRect(-box.size.x/2, -box.size.y/2, box.size.x, box.size.y); context.restore(); });

Demo: http://superbigtree.com/crtrdg-demos/01

This example moves the block and spins it only when the wasd keys are pressed on the keyboard:

var Game = require('crtrdg-gameloop'); var Keyboard = require('crtrdg-keyboard'); var game = new Game(); var keyboard = new Keyboard(game); var box = { position: { x: game.width / 2, y: game.height / 2 }, velocity: { x: 0, y: 0 }, size: { x: 100, y: 100 } }; box.rotate = function(){ if (degrees < 15){ degrees += 25; } }; box.input = function(keys){ if ('A' in keys){ box.velocity.x = -5; box.rotate(); } if ('D' in keys){ box.velocity.x = 5; box.rotate(); } if ('W' in keys){ box.velocity.y = -5; box.rotate(); } if ('S' in keys){ box.velocity.y = 5; box.rotate(); } }; var degrees = 0; game.on('update', function(){ if (degrees > 0){ degrees--; } box.input(keyboard.keysDown); box.position.x += box.velocity.x; box.position.y += box.velocity.y; box.velocity.x *= .9; box.velocity.y *= .9; }); game.on('draw', function(context){ context.save(); context.translate(box.position.x, box.position.y); context.rotate(degrees); context.fillStyle = '#fff'; context.fillRect(-50, -50, box.size.x, box.size.y); context.restore(); });

Demo: http://superbigtree.com/crtrdg-demos/02

This example extends the previous one to increase the size of the box when the mouse is clicked, and if the player is holding down the shift key when the mouse is clicked, the size of the box decreases:

var Game = require('crtrdg-gameloop'); var Keyboard = require('crtrdg-keyboard'); var Mouse = require('crtrdg-mouse'); var game = new Game(); var keyboard = new Keyboard(game); var mouse = new Mouse(game); mouse.on('click', function(){ if ('<shift>' in keyboard.keysDown){ box.size.x -= 25; box.size.y -= 25; } else { box.size.x += 25; box.size.y += 25; } }); var box = { position: { x: game.width / 2, y: game.height / 2 }, velocity: { x: 0, y: 0 }, size: { x: 100, y: 100 } }; box.rotate = function(){ if (degrees < 15){ degrees += 25; } }; box.input = function(keys){ if ('A' in keys){ box.velocity.x = -5; box.rotate(); } if ('D' in keys){ box.velocity.x = 5; box.rotate(); } if ('W' in keys){ box.velocity.y = -5; box.rotate(); } if ('S' in keys){ box.velocity.y = 5; box.rotate(); } }; var degrees = 0; game.on('update', function(){ if (degrees > 0){ degrees--; } box.input(keyboard.keysDown); box.position.x += box.velocity.x; box.position.y += box.velocity.y; box.velocity.x *= .9; box.velocity.y *= .9; }); game.on('draw', function(context){ context.save(); context.translate(box.position.x, box.position.y); context.rotate(degrees); context.fillStyle = '#fff'; context.fillRect(-box.size.x/2, -box.size.y/2, box.size.x, box.size.y); context.restore(); });

Demo: http://superbigtree.com/crtrdg-demos/03

Let’s add boundaries to the game so that the box can’t be moved outside the browser window:

var Game = require('crtrdg-gameloop'); var Keyboard = require('crtrdg-keyboard'); var Mouse = require('crtrdg-mouse'); var game = new Game(); var keyboard = new Keyboard(game); var mouse = new Mouse(game); mouse.on('click', function(){ if ('<shift>' in keyboard.keysDown){ box.size.x -= 25; box.size.y -= 25; } else { box.size.x += 25; box.size.y += 25; } }); var box = { position: { x: game.width / 2, y: game.height / 2 }, velocity: { x: 0, y: 0 }, size: { x: 100, y: 100 }, speed: 10 }; box.rotate = function(){ if (degrees < 15){ degrees += 25; } }; box.input = function(keys){ if ('A' in keys){ box.velocity.x = - this.speed; box.rotate(); } if ('D' in keys){ box.velocity.x = this.speed; box.rotate(); } if ('W' in keys){ box.velocity.y = - this.speed; box.rotate(); } if ('S' in keys){ box.velocity.y = this.speed; box.rotate(); } }; box.boundaries = function(){ if (this.position.x <= this.size.x / 2){ this.position.x = this.size.x / 2; } if (this.position.x >= game.width - this.size.x / 2){ this.position.x = game.width - this.size.x / 2 } if (this.position.y <= this.size.y / 2){ this.position.y = this.size.y / 2 } if (this.position.y >= game.height - this.size.y / 2 ){ this.position.y = game.height - this.size.y / 2; } } var degrees = 0; game.on('update', function(){ if (degrees > 0){ degrees--; } box.input(keyboard.keysDown); box.position.x += box.velocity.x; box.position.y += box.velocity.y; box.velocity.x *= .9; box.velocity.y *= .9; box.boundaries() }); game.on('draw', function(context){ context.save(); context.translate(box.position.x, box.position.y); context.rotate(degrees); context.fillStyle = '#fff'; context.fillRect(-box.size.x/2, -box.size.y/2, box.size.x, box.size.y); context.restore(); });

Demo: http://superbigtree.com/crtrdg-demos/04

These are some rough demos of what you can do with canvas / javascript / crtrdg.js. I’ll be expanding on examples like these and providing in-depth explanations of how they work in an upcoming book, [Learn.js #02: making games with node.js and browserify]. You can preorder the book, or learn more at learnjs.io.

[superbigtree]

[superbigtree]

What I learned from Ludum Dare #27

Ludum Dare #27 was my first successful participation in the game-making event. Originally I intended to enter my game in the 48-hour competition, but I eventually decided to give myself the extra time and enter the game in the more relaxed 72-hour jam. Here's the entry page for my game.

I didn’t expect to have as much fun and to end up with a game I like as much as I did. Here’s a few things I learned from the experience:

Make something simple.

Total obvs, right?

If this were a listicle, the title could be something like this:

5 things I learned from Ludum Dare #27: make something simple, make something simple, make something simple, make something simple, & make something simple.

Compromise when I realize my simple idea was too complex.

This is a common problem.

“Oh, I have this really simple idea, it’ll just be this and this, and I might as well add this because I know I’ll need that later which means I should also add this which will make that easier and ...”

Shut up. Just don’t.

A game doesn’t have to be complex to be fun. It’s ok to slow down, simplify, and just implement one of the 30 ideas that seems simple to do all at once.

I expect to get better at coming up with small ideas as I go. It’s a skill that depends on being able to accurately estimate the time a project/feature will take, something I continue to improve at.

Use the language / framework / tools I already know.

I actually learned this a while ago, but Ludum Dare reminded me. A year ago I was trying to learn java, implementing pong in java/opengl, and hating life. Java seemed difficult, verbose, and I hated it.

I was learning a new language and new programming concepts and new design skills at the same time.

I found myself thinking, “I should just be writing games in javascript. I know javascript.”

So for the past year that’s what I’ve been doing in my spare time.

And during Ludum Dare I realized that was the right choice: I now understand a lot of game design and programming concepts that a year ago were massively intimidating.

I implemented things in javascript during Ludum Dare that previously seemed impossible, but only because I was confident writing javascript.

Do something that’s new to me. Set a learning objective for the jam.

Over Ludum Dare weekend I learned the concepts of maps and cameras, making the camera follow the player around the map, and drawing game objects on the map in relation to camera position.

This is a fundamental part of game development, but it took me a while to learn. Now that I’ve done it one, I get how it works. It was just big enough of a problem to be challenging, but it didn’t suck up my weekend.

I should always have some reasonably-sized new thing to learn during a game jam like Ludum Dare. The next learning objective might be managing collections of game objects, or a clean design pattern for game levels.

I want versions of Ludum Dare for all the types of projects I do.

I mean, a hackathon is like a game jam is like Startup Weekend, etc., but I suspect that doing projects in short sprints like this would help me stay focused and interested in what I’m working on.

A couple weeks ago I tried to write a 50-page book in a weekend. That worked out pretty well. Next time I try it I’ll up the page count.

There’s something about the 2-3 day sprint that really works for me.

I’d like to do a 48-hour sprint taking my Ludum Dare #27 game and turning it into something with more depth, story, and varied gameplay.

And I should be clear, I didn’t stay up super late trying to get things done for the jam. I don’t think that’s necessary. A 48-hour sprint might actually have 20-30 hours of actual work, with plenty of sleep, eating, water, walking around, and relaxing.

Do stuff with the game after Ludum Dare is over.

I forked my Ludum Dare game and did two things with it:

Made it the banner on this site for a project I’m working on about indie game developers in Seattle: seattle.io.

Started a new version of the game called mossy bellies that I plan to continue working on until I complete the gameplay mechanics I originally had in mind for the game: superbigtree.com/mossybellies.

Find local people, meet up, and play each other’s games

In Seattle we had a show and tell the Monday after Ludum Dare weekend. Knowing that I had an afk deadline to finishing this game, knowing that I had to show people something and I had to talk to them about it – I’m pretty sure that’s the main reason I made as much progress on my game as I did.

Do more of this.

As a learning opportunity and as a source of fun, Ludum Dare is awesome.

More like that, please.

I also wrote a couple of progress reports about the game: part #1 and part #2.

[superbigtree]

Introduction to grunt.js and npm scripts, and choosing between the two.

As our javascript projects get more complex, we need ways to automate all the repetitive tasks that come along with building applications.

We need to run tests, run jslint, create builds, run a development server, deploy code, and otherwise manage our projects.

Grunt.js is great for these things.

Hold it.

Before you jump to grunt for all your build-step and task-automation needs, consider if the npm scripts feature might suit your needs.

Maybe you only need to run a development server for you html/css/javascript project.

Instead of jumping to grunt, first create a package.json file if you don’t have one already:

npm init

This will ask you a few questions about your project. Answer and you’ll get a package.json file!

It will probably look like this:

{ "name": "example", "version": "0.0.0", "description": "example project", "main": "index.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "author": "sethvincent", "license": "BSD" }

You can revise the main value to be whatever makes sense for your project. If this won’t be released on npm, you might not even need main.

Now, check out the scripts section. There’s already test, but it needs to have an actual command associated with it. Change the error message to whatever command you use to run tests.

I might change it to something like this:

"scripts": { "test": "node test.js" }

Where test.js would contain a set of tests written in tape.

To run the tests, you can run this command:

npm test

That doesn’t gain a whole lot of simplicity over just running node test.js, but when the command for running tests is more complicated, being able to run npm test instead helps out a lot.

A development server

Let’s use a simple development server designed to work with browserify named beefy.

Install beefy as a development dependency:

npm install beefy --save-dev

Add a start script to your package.json:

"scripts": { "test": "node test.js", "start": "beefy index.js:bundle.js --live" }

Now we start to see how npm scripts can be useful. That beefy command is just long enough that it’s useful to have npm start as an alias for our development server.

Just to prove it works, create an index.js file and pop in a short console.log statement:

console.log('it works!');

Now run npm start, and you’ll see output that looks like this:

> [email protected] start /Users/sethvincent/workspace/bookery/tmp > beefy index.js:bundle.js --live listening on 9966

Now you can go to http://localhost:9966 to see if the console.log statement worked.

It did! (right?).

You might be saying, “hey, I don’t have an index.html file what is this magic.”

If there isn’t an index.html file in the directory you’re in when you run beefy, it’ll serve a really basic index.html file so your javascript can run.

Add another statement to your index.js file:

document.write('served.');

You’ll see that without reloading the page the string served is now displayed in your index.html file.

Arbitrary scripts

There are a few default script names you can hook into and run your own scripts using npm aside from test and start. To see a list of them, read the npm-scripts documentation.

You can also run arbitrary scripts. Let’s add a pizza script.

``` "scripts": { "test": "node test.js", "start": "beefy index.js:bundle.js --live", "pizza": "node pizza.js" } ```

Let’s pretend pizza.js automates the process of ordering a pizza online from your favorite pizza place (shit, this should be a thing).

To run the command we prepend our script name with run, like this:

npm run pizza

You can add whatever scripts you want. You can even set up a master script that runs a bunch of your npm scripts! Chek it out:

``` "scripts": { "test": "node test.js", "start": "beefy index.js:bundle.js --live", "pizza": "node pizza.js", "everything": "npm run pizza && npm test && npm start" } ```

In the terminal execute this command:

npm run everything

And you just ordered pizza, ran tests, and started your development server! That’s pretty good. That easily rivals the most basic grunt.js implementations.

So, that gives you a sense of when to use npm scripts. Use npm scripts when your requirements are simple. You may find it will work for many situations.

Things get complicated

npm scripts are great for simple projects, and sometimes even for complex projects if your write your own build tools.

But for bigger projects I tend to use grunt. I’ve been experimenting with using grunt to generate static sites similar to jekyll.

Let’s try out an example that includes: - generating html from ejs templates - bundling javascript with browserify - including javascript from bower in our browserify bundle - a development server using connect - and deploying the generated code to github pages

First you need to install the grunt command line tool:

npm install -g grunt-cli

Next, we’ll run npm init again to set up the project.

We have a bunch of development dependencies for this project, so add those to the package.json file:

"devDependencies": { "grunt": "~0.4.1", "matchdep": "~0.1.2", "grunt-contrib-clean": "~0.4.1", "grunt-contrib-concat": "~0.3.0", "grunt-contrib-connect": "~0.3.0", "grunt-contrib-copy": "~0.4.1", "grunt-contrib-watch": "~0.4.4", "grunt-browserify": "~1.2.0", "grunt-gh-pages": "~0.6.0", "grunt-ejs": "~0.1.0", "debowerify": "~0.1.3" } }

Run npm install in the terminal to install those dependencies.

Now, before you run the grunt command, you need a file named Gruntfile.js.

Create the file and add this to it:

module.exports = function(grunt) { grunt.initConfig({ clean: ['dist'], ejs: { all: { options: { // site-wide vars here }, src: ['**/*.ejs', '!node_modules/**/*', '!_*/**/*'], dest: 'dist/', expand: true, ext: '.html', }, }, copy: { all: { src: ['*.css', '*.html', 'images/**/*', 'img/**/*', '!Gruntfile.js'], dest: 'dist/', }, }, browserify: { all: { src: 'app.js', dest: 'dist/app.js' }, options: { transform: ['debowerify'] } }, connect: { options: { port: process.env.PORT || 3131, base: 'dist/', }, all: {}, }, watch: { options: { livereload: true }, html: { files: '<%= ejs.all.src %>', tasks: ['ejs'], }, js: { files: '<%= browserify.all.src %>', tasks: ['browserify'], }, assets: { files: ['assets/**/*', '*.css', '*.js', 'images/**/*', 'img/**/*', '!Gruntfile.js'], tasks: ['copy'], } }, 'gh-pages': { options: { base: 'dist/' }, src: ['**/*'] } }); require('matchdep').filterDev('grunt-*').forEach(grunt.loadNpmTasks); grunt.registerTask('default', ['clean', 'ejs', 'browserify', 'copy']); grunt.registerTask('server', ['default', 'connect', 'watch']); grunt.registerTask('deploy', ['default', 'gh-pages']); };

Let’s run through this a chunk at a time:

This is the essential boilerplate to get started writing a Gruntfile:

module.exports = function(grunt) { grunt.initConfig({ // config goes here. }); };

Next, you also need to load the grunt plugins being used in your gruntfile. Here I’m using a module that checks the package.json filed for any module that starts with grunt- and loads it as a grunt plugin.

require('matchdep').filterDev('grunt-*').forEach(grunt.loadNpmTasks);

Here we register tasks:

grunt.registerTask('default', ['clean', 'ejs', 'browserify', 'copy']); grunt.registerTask('server', ['default', 'connect', 'watch']); grunt.registerTask('deploy', ['default', 'gh-pages']);

default, server, and deploy are all commands now that can be run like this:

grunt grunt server grunt deploy

The default task is run when you run the grunt command on its own. Each of those tasks are essentially a list of things that need to be done.

Let’s take a look at each of those items in detail.

clean deletes the dist folder so that it can be built fresh using other config tasks

clean: ['dist'],

ejs takes care of compiling all the ejs templates and putting them in the dist folder:

ejs: { all: { options: { // site-wide vars here }, src: ['**/*.ejs', '!node_modules/**/*', '!_*/**/*'], dest: 'dist/', expand: true, ext: '.html', }, },

copy simply copies the static files that don’t need to be processed and puts them into the dist folder:

copy: { all: { src: ['*.css', '*.html', 'images/**/*', 'img/**/*', '!Gruntfile.js'], dest: 'dist/', }, },

browserify bundles the javascript, and we’re using the transform option so that we can require javascript components from bower in our node-style code:

browserify: { all: { src: 'app.js', dest: 'dist/app.js' }, options: { transform: ['debowerify'] } },

connect runs the development server:

connect: { options: { port: process.env.PORT || 3131, base: 'dist/', }, all: {}, },

watch keeps track of all the relevant files, and when they are saved, reruns the necessary tasks to move the files into the dist folder.

watch: { options: { livereload: true }, html: { files: '<%= ejs.all.src %>', tasks: ['ejs'], }, js: { files: '<%= browserify.all.src %>', tasks: ['browserify'], }, assets: { files: ['assets/**/*', '*.css', '*.js', 'images/**/*', 'img/**/*', '!Gruntfile.js'], tasks: ['copy'], } },

To get live-reloading of the page working correctly we embed this snippet into the html:

<script id="live-reload" src="http://localhost:35729/livereload.js"></script>

gh-pages takes whatever is in our dist folder, copies it to a gh-pages branch, and pushes it to our github repository.

'gh-pages': { options: { base: 'dist/' }, src: ['**/*'] }

I like that one a lot.

So, you can see that doing all the things that grunt is doing for our static site generator would take a lot of work to replicate using only npm scripts. The best part is that I didn’t have to write any of the grunt plugins that handle the real hard work, I just plugged them together in the Gruntfile based on the documentation of each plugin.

Here’s a list of the plugins and npm modules I used:

Grunt plugins:

grunt-contrib-clean

grunt-contrib-concat

grunt-contrib-connect

grunt-contrib-copy

grunt-contrib-watch

grunt-browserify

grunt-gh-pages

grunt-ejs

Other modules:

matchdep

debowerify

I based the grunt example on a yeoman generator I’m working on: grunt-static-site. Please try it out and tell me if you come up against any issues in the issues queue.

[superbigtree]

ludum dare #27 progress report #2

The ludum dare competition ended. My game isn’t finished.

Luckily there’s the 48-hour competition, and the 72-hour jam, a more relaxed version of ludum dare.

I’ll submit my game for the jam rather than the competition.

I’ve made some progress, though, and as a test-run of developing with crtrdg.js, I’ve learned a lot. This is a kind of brain-dump of what I learned.

There are a few difficulties I’ve encountered:

managing collections of entities, like bullets and monsters.

managing maps for multiple levels

managing state of entities in general for multiple levels

managing representations of state in game ui

altering canvas animations based on entity state

managing collections of entities, like bullets and monsters.

I’ve got a lot of for loops running through arrays all crazy-like. I’d like to clean that up.

managing maps for multiple levels

Actually, I haven’t even really tried this yet. Maybe it’s not as hard as I expect. But I know that I haven’t allowed for this in crtrdg-scene yet. And maybe that module doesn’t need to know about the size and features of the map of each scene. Maybe it does. I’m not sure.

managing state of entities in general for multiple levels

This is probably the messiest thing in the game right now. Keeping even just the player’s state correct when switching through scenes/levels is a little messy.

managing representations of state in game ui

This actually isn’t difficult. I’ve got some repetitive code taking up space, though. Not sure what to change about that. This could likely be taken care of with whatever client-side web framework fits in best with the crtrdg.js way of doing things.

altering canvas animations based on entity state

Wanna see something totally gross? Check this out:

if (player.visible){ /* the body */ context.fillStyle = this.color; if(this.scrunched){ context.fillRect(this.position.x - camera.position.x-10, this.position.y - camera.position.y+30, this.size.x+20, this.size.y-30); /* the eye */ context.fillStyle = this.eyeColor; /* direction of eye */ if (this.direction === 'right') { context.fillRect(this.position.x+this.size.x-5 - camera.position.x, this.position.y - camera.position.y+35, 10, 10); } else { context.fillRect(this.position.x - camera.position.x-5, this.position.y - camera.position.y+35, 10, 10); } } else { context.fillRect(this.position.x - camera.position.x, this.position.y - camera.position.y, this.size.x, this.size.y); /* the eye */ context.fillStyle = this.eyeColor; /* direction of eye */ if (this.direction === 'right') { context.fillRect(this.position.x+this.size.x-15 - camera.position.x, this.position.y+5 - camera.position.y, 10, 10); } else { context.fillRect(this.position.x+5 - camera.position.x, this.position.y+5 - camera.position.y, 10, 10); } } }

Nasty, right? I know this can be improved.

This is where I could rely on another canvas drawing library to simplify things. I need to look around and see if anything fits well. But managing the changes to animation based on entity state could potentially be handled in the crtrdg-entity module somehow.

[superbigtree]

Here's a little sample of the platformer component of the ludum dare game I'm working on. The background changes every ten seconds.

I'm still working on the resources and points systems for the game. That's coming up in the next 19 hours or so.

Source code. Demo.

[superbigtree]

Ludum Dare #27 progress report #1

The competition started at 6 p.m. pacific time, and i was bummed that the theme ended up being “10 seconds”.

But overall the first day was a success. I learned something that I’ve been trying to learn for months: having a map that’s larger than the canvas, and a viewport that follows a player around the map.

Finally. I’ve been trying to learn that for a while.

My primary goal is to make a text-based browser game like Candy Box and A Dark Room.

I also want to make a platformer.

Can I use mechanics from both styles in my one ludum dare game?

Let’s find out.

Demo. Source on GitHub.

[superbigtree]

Progress so far on my ludum dare game. Code here: https://github.com/sethvincent/ludum-dare-27

[superbigtree]

Introduction to using crtrdg.js for making 2d canvas games

What is crtrdg.js?

crtrdg.js is intended for making simple games – stuff like old-school nintendo or sega. Arcade 

games. Platformers, top-down rpgs and multi-directional shooters, weird puzzle story games that don't make sense. Stuff like that.

I started it because most javascript game libraries I’ve experimented with just don’t fit the way I think, or have expansive APIs that do far more than I need, or have usage patterns and deeply-nested namespacing that I get confused by.

It’s not you, javascript game libraries. It’s me.

After following the development of voxel.js, seeing what can be done with browserify, and learning how to use the node.js events module, I knew what I needed to do.

I needed to make a javascript library for 2d games.

But wait!

I don’t want to make some rehash of everything else that already exists. I expect that the implementations I’ve created in these crtrdg.js modules are pretty weak, naive examples of game programming. But that’s ok. My goals are a clean, simple API first, good documentation second, and everything else somewhere around last.

My plan is to use this stuff to make weird sloppy fun games. crtrdg.js might not make sense for you if your goal is a highly performant and technically complex game. If you want to learn and goof around, crtrdg.js is here for you.

There are a few goals for crtrdg.js:

Simplicity.

The API must be blunt. Minimize callbacks through the use of events.

Use npm.

There’s so much on npm that’s useful for making 2d games. The shit is kinda blowing up. Check out the list on this wiki to get a sense of what’s available.

I decided that games I make for the web should utilize npm, and use browserify to bundle that code for the browser.

Little modules.

I want to just make one module to handle each small task in a game. I don’t need the mouse in every game, so I don’t need the mouse interaction code in my library for every game.

Composition over configuration.

I’m creating a set of crtrdg.js modules that can be mixed and matched and used in combination with many of the thousands of modules that already exist on npm.

I want to put these small, understandable modules together in interesting ways. I don’t want to dig through a huge library’s API to figure out each new piece of functionality, then dig through the code to figure out how to override it when something doesn’t work the way I want.

Learning.

I’m learning how to do all this stuff as I do it.

And I hope that crtrdg.js will be useful as a tool for learning how to make 2d games and how to write javascript.

Getting started

If you use yeoman, you can use this generator to start a new crtrdg.js game: https://github.com/sethvincent/generator-crtrdg.

If you don’t have yo, the yeoman generator, installed yet, do so:

npm install -g yo

Install the crtrdg generator:

npm install -g generator-crtrdg

Create and navigate to a folder you want the game to live in:

mkdir new-game && cd new-game

And run the generator:

yo crtrdg

This will ask you to tell it the name of your game, then install dependencies, then give you a few files. The ones we’ll look at now are index.html, and game.js.

index.html

<html> <head> <meta charset="utf-8"> <title>pizzaparty</title> <link rel="stylesheet" href="style.css"> </head> <body> <h1 id="title">pizzaparty</h1> <canvas id="game"></canvas> <script src="./bundle.js"></script> </body> </html>

Pretty simple stuff. I named my game pizzaparty, and the generator placed that in the page title and h1 for me.

Note that the canvas has an id of game and that the script src is pointed at bundle.js. We will generate bundle.js automatically with our development server using a cool tool named beefy.

game.js

var Game = require('crtrdg-gameloop'); var Keyboard = require('crtrdg-keyboard'); var Mouse = require('crtrdg-mouse'); var game = new Game({ canvasId: 'game', width: 800, height: 400, backgroundColor: '#ff1f1f' }); var keyboard = new Keyboard(game); game.on('update', function(interval){}); game.on('draw', function(context){}); game.on('pause', function(){}); game.on('resume', function(){});

This sets you up with a little bit of scaffolding to get started.

update

game.on('update', function(interval){ // in here you should put the // logic/calculations of the game });

draw

game.on('draw', function(context){ // in here you should put the // actual drawing of the game // the context argument gives you the context of the canvas });

pause

Everything you put in here:

game.on('pause', function(){ // your pause code });

Will get executed when you run game.pause().

resume

And everything you put in here:

game.on('resume', function(){ // your resume code });

Will get executed when you call game.resume().

For usage of the crtrdg-keyboard module, check out the github page: https://github.com/sethvincent/crtrdg-keyboard.

For usage of the crtrdg-mouse modules check out the github page: https://github.com/sethvincent/crtrdg-mouse.

Run the server

To run the game and load it in your browser, run this in the terminal:

npm start

You should see output like this in the terminal:

> [email protected] start /Users/sethvincent/workspace/tmp/pizzaparty > beefy game.js:bundle.js --live listening on 9966

Go to http://localhost:9966, and you’ll see your game!

You can make edits to your game.js file and the browser will automatically reload the page, thanks to the beefy module we’re using to serve the game.

The npm start command is just an alias for this:

beefy game.js:bundle.js --live

It takes your game.js file and serves it all bundled with the dependencies as bundle.js.

Create a player

Now, we should make something that can move around on the screen!

Let’s create a new file: player.js. In the terminal run:

touch player.js

And add this code to the file:

// require crtrdg-entity var Entity = require('crtrdg-entity'); // require the inherits module so we can make Player inherit from Entity. var inherits = require('inherits'); // make the Player funtion inherit from crtrdg-entity inherits(Player, Entity); // create Player function function Player(options){ this.position = { x: options.position.x, y: options.position.y }; this.size = { x: options.size.x, y: options.size.y }; this.velocity = { x: 0, y: 0 }; this.friction = 0.9; this.speed = options.speed; this.color = options.color; }

We’re requireing some new modules in this code, so we better install those dependencies:

npm install —save crtrdg-entity

We actually don’t need to install the inherits module again, as it is used elsewhere in crtrdg.js code.

Now, let’s make a little box to represent our player in the game that can be moved around the canvas.

In game.js, require the player.js file:

var Player = require('./player.js');

And create a new player:

var player = new Player({ size: { x: 10, y: 10 }, position: { x: game.width / 2 - 5, y: game.height / 2 - 5, }, color: '#fff', speed: 5, visible: false }); // add the player to the game player.addTo(game);

crtrdg.js entities have update and draw events just like the main game object, so we can use those like this:

player.on('update', function(interval){ // move the player }); player.on('draw', function(context){ context.fillStyle = this.color; context.fillRect(this.position.x, this.position.y, this.size.x, this.size.y); });

We should add a few methods to our Player constructor that we can then use in our game, so go back to the player.js file and add these methods:

move:

Player.prototype.move = function(){ this.position.x += this.velocity.x; this.position.y += this.velocity.y; };

boundaries:

Player.prototype.boundaries = function(){ if (this.position.x <= 0){ this.position.x = 0; } if (this.position.x >= this.game.width - this.size.x){ this.position.x = this.game.width - this.size.x; } if (this.position.y <= 0){ this.position.y = 0; } if (this.position.y >= this.game.height - this.size.y){ this.position.y = this.game.height - this.size.y; } };

input:

Player.prototype.input = function(keyboard){ if ('A' in keyboard.keysDown){ this.velocity.x = -this.speed; } if ('D' in keyboard.keysDown){ this.velocity.x = this.speed; } if ('W' in keyboard.keysDown){ this.velocity.y = -this.speed; } if ('S' in keyboard.keysDown){ this.velocity.y = this.speed; } };

Get all that into the player.js file, then we can edit game.js to add to the player update listener:

player.on('update', function(interval){ this.input(keyboard); this.move(); this.velocity.x = 0; this.velocity.y = 0; this.boundaries(); });

Cool

Go check out the game in the browser, and you should now have a little white box you can move around!

Find more modules you can play with at crtrdg.github.io and on npm.

Check out requirebin, a really great resource for experimenting with the npm/browserify way of life in the browser.

And check out this demo that includes an enemy and the ability to shoot little square bullets for ideas on what to do next:

example crtrdg game.

Source on GitHub.

[superbigtree]

Comparison of hello world in sinatra, express, and flask

I've been writing about creating development environments for ruby, javascript, and python for a new book, and was struck by the differences and similarities between the syntax of these three languages and the APIs of sinatra, express, and flask. Check it out:

Ruby & Sinatra:

require 'sinatra' get '/' do 'pizza is awesome' end

Look at how tiny and pleasant that ruby code is!

Put this code in a file named app.rb, download sinatra by running "gem install sinatra", then run "ruby app.rb" to serve the app.

Javascript & Express:

var express = require('express'); var app = express(); app.get('/', function(req, res){ res.send('pizza is awesome.'); }); app.listen(3000); console.log('app is listening at localhost:3000'); 

Put this code in a file named app.js, download express by running "npm install express", then run "node app.js" to serve the app.

Express doesn't automatically take care of listening on a default port, or telling the user that the app is listening, so that adds just a small amount of extra code compared to the ruby/sinatra example.

Python & Flask:

from flask import Flask app = Flask(__name__) @app.route('/') def pizza(): return 'pizza is awesome' if __name__ == '__main__': app.run() 

Put this code in a file named app.py, download express by running "pip install flask", then run "python app.py" to serve the app.

Python feels different because of it's use of meaningful whitespace and lack of curly brackets or do end for blocks. Everything is just indented 4 spaces instead to represent blocks of code.

These three examples still feel very similar, though. That's no coincidence. Both express and flask were (I think) inspired by sinatra's clean and simple API.

[superbigtree]

My strategy for client-side package managers (choosing between npm, bower, and component)

There is still no best answer to client-side package managers and dependency management.

We still have to cobble together the solutions that work best in the context of each project, but at least we’re not downloading js/css manually through the browser, or using wget, or writing bash scripts to download/update our client-side dependencies.

We have better options.

I focus on three that fit best with my development workflow:

npm

bower

component

All three are quite different:

npm

npm nominally started out as a package manager for node, but can be used for any javascript, and along with a tool like browserify it's easy to use npm packages and node-style modules in the browser. It's not super useful for css libraries – but it's easy to imagine a tool (built on something like brfs) that could make bundling css npm packages super pleasant.

You install npm by installing node.

Packages are installed using npm install <package name>.

Example:

npm install --save request

The optional —save option adds the package as a dependency to the project’s package.json file. You can create a package.json file with the npm init command.

bower

bower is a hero of client-side code: it's great for both css and javascript. It's easy to manage dependencies – even if those dependencies don't have a config file for bower. You can install a file or git repository as a dependency alongside packages in the bower registry. Bower doesn't make any assumptions about how you build or deploy code, so it is compatible with amd modules.

Bower is distributed as an npm package so install it with: npm install -g bower

The -g option installs the bower package globally and exposes the bower command.

Packages are then installed like this:

bower install --save <package name>

The optional —save option adds the package as a dependency in the project’s bower.json file. If bower.json doesn’t already exist, you can create one with the bower init command.

component

component is a tool with a more focused and defined goal for front-end code than npm and bower. It uses CommonJS style modules. Each component may contain javascript, css, fonts, and images. Some javascript-only components can also be used in node.js. See the Component FAQ for more details.

component is also installed using npm:

npm install -g component

The syntax of the component command is a little different.

Component relies on github repos, and uses the same namespace, so a package is identified by /.

Installing looks like this:

component install <username>/<package name>

Example:

``` component install component/dom ```

The above command installs the dom component, which is a collection of small components that replicate the functionality of jQuery.

To add dependencies to component.json, you can use the component-set command.

Learn more about component here: https://github.com/component/component

When I use npm for browser code:

Games. There's been a lot of interesting activity in javascript game development in the node.js community using browserify. voxel.js is one of the biggest examples, with a goal of creating minecraft-like games in the browser. For examples, check out this wiki of game-related modules and projects that use node/npm/browserify: https://github.com/hughsk/game-modules

npm/browserify will also be useful for creating applications that might share javascript code on the server and the browser. This approach also works well when the javascript requirements for the client-side are minimal, or if you prefer to write client-side code in a node style.

If I’m using npm and browserify, I’m almost always using beefy as the live-reload development server. It’s great.

I sketch ideas in requirebin.com sometimes. It’s a pretty great little service that let’s you require modules from npm, run them through browserify, and view the results of that code. All in the browser.

Learn more about npm at npmjs.org

When I use bower for browser code:

When the project requires a front-end framework like backbone or angular, I use bower as the package manager. It's currently the best way to package arbitrary dependencies of a javascript application. It’s possible to use backbone and jquery with browserify, but so far that hasn’t made sense for me yet.

Typically using bower means that I am also using the build tool grunt and associated plugins as the live-reload development server, for packaging builds, and any other task automation.

Learn more about bower at bower.io.

I don't really use component yet.

But I definitely want to. It looks like there's some great work happening around component. I expect that there will be instances when I'll want to use some of the available components. Many components have node.js support, and should just fit into my usual npm/browserify workflow without issue. I would likely be installing those components via npm rather than the component command.

Use all three at once!

Check out this great guide for using components, bower packages, amd modules, and even global variables with browserify: Browserify and the universal module definition

[superbigtree]

I’m using semantic versioning for my book about javascript.

Every technical book should do the same.

I’m following semantic versioning 2.0.0, and transposing that specification to a book is surprisingly straightforward and fun.

As of August 12, 2013, my book Learn.js is at roughly 100 pages / 15,000 words. It is at version 0.4.1. 

Patch version: x.y.Z

Patch versions like 0.1.1 will be released for copy editing and formatting changes. Bug fixes.

Minor version: x.Y.z

Each minor version release, like 0.2.0, will be for large new sections of content, like a chapter. A minor version may be released if the copy editing is substantial.

Major version: X.y.z

The first major release, 1.0.0, will be the feature complete book. It will be about 150 pages, and will have a series of chapters that convey how to use various javascript libraries and development tools with a focus on project-based learning.

A book’s breaking changes.

The main difference between using semver for a book rather than software is that I’m treating the meaning of the document like the concept of an API. Breaking changes to the book’s ‘API’ consist of substantial changes to the tone, purpose, order, and meaning of the words in the book. The book’s point of access is the information that is conveyed.

A revised chapter that uses a different demo project than before would be a breaking change, copy editing the chapter would (probably) not be a breaking change.

Adding a new chapter isn’t a breaking change (because it is backwards compatible, right?), but updating the libraries that are used as examples throughout the book would be a breaking change.

A breaking change alters a section of the content to the point that it is mostly unrecognizable to someone who read the previous version of the content.

Releasing early, often, and in an organized way.

Because the target audience for this book is technical, and likely already have at least heard of semantic versioning, this will be a great way to communicate the updates to the book.

Along with a changelog, roadmap, and issues queue, semantic versioning should make it clear to readers the status of the book and help them decide if they are ready to make the purchase or wait until a major release.

How this can be replicated.

I’m using a combination of leanpub.com, gumroad.com, github.com, and a landing page using GitHub Pages to manage the writing, releases, promotion, error reporting, and sales of the book, a set of online tools that anyone can use to get started writing and releasing their own book.

Authoring a book about the web on the web.

Lean publishing seems cool, and my goal is to use standards like semantic versioning so that readers can hold me and my work accountable, and so that I can be organized about how I release updates to the book.

[superbigtree]

Introduction to making html5/javascript games with Coquette.js

Coquette is a game development library from developer Mary Rose Cook. It looks like it was abstracted from her Ludum Dare 26 entry, Left Right Space.

I was struck by how straightforward and easy to use Coquette is, and made a weird asteroids-like game over a couple of afternoons: BlockSnot.

Let’s take a look at the basics of using Coquette.

To create a game with Coquette, you start with a simple game object:

var Game = function(canvasId, width, height) { this.coquette = new Coquette(this, canvasId, width, height, "#000"); };

You can create update() and draw() methods on Game and these will get called automatically:

Game.prototype.update = function(tick){ // do something on each update // this is a reasonable place to handle collision detection // and other calculations }; Game.prototype.draw = function(){ // draw stuff to the screen that belongs to the game };

Coquette is comprised of a few modules:

entities

collider

inputter

renderer

ticker

Entities

Entities are all the things in the game, like the player, enemies, items, etc.

To create an entity, first create a constructor function that takes a game object and a settings object as arguments:

var Pizza = function(game, settings){ this.game = game; this.toppings = settings.toppings; };

Like the Game object, entities can have update(), and draw() methods that get called automatically:

Pizza.prototype.update = function(tick){ // do something on each update }; Pizza.prototype.draw = function(){ // draw stuff to the screen that belongs to the Pizza };

Now, to create instances of Pizza, use coquette.entities.create() like this:

coquette.entities.create(Pizza, { toppings: ['cheese', 'pepperoni'] }, function(pizza) { // in this optional callback you can do stuff with your // newly created entity });

Delete an entity with coquette.entities.delete() like this:

coquette.entities.delete(pizza, function(){ console.log(‘yeah, eat that pizza.’); });

Get all entities with coquette.entities.all()

You can pass the name of one of your entity constructors to get entities of a certain type returned as an array: coquette.entities.all(Pizza)

Collider

Check to see if to entities collide in the game.

Here’s an example from the Coquette readme of a Player entity that supports collision detection:

var Player = function() { this.pos = { x: 10, y: 20 }; this.size = { x: 50, y: 30 }; this.boundingBox = coquette.collider.CIRCLE; this.collision = function(other, type) { if (type === coquette.collider.INITIAL) { console.log("Ow,", other, "hit me."); } else if (type === coquette.collider.SUSTAINED) { console.log("Ow,", other, "is still hitting me."); } }; this.uncollision = function(other) { console.log("Phew,", other, "has stopped hitting me."); }; };

An entity must have size, position, and boundingBox properties like above in order for collision detection to work.

Inputter

Coquette’s input handling currently only supports keyboard events.

To use it, call coquette.inputter.state(), and pass in the key that you’re looking for:

var up = coquette.inputter.state(coquette.inputter.UP_ARROW);

Here’s how the list of keycodes mapped to names in Coquette:

BACKSPACE: 8, TAB: 9, ENTER: 13, SHIFT: 16, CTRL: 17, ALT: 18, PAUSE: 19, CAPS_LOCK: 20, ESC: 27, SPACE: 32, PAGE_UP: 33, PAGE_DOWN: 34, END: 35, HOME: 36, LEFT_ARROW: 37, UP_ARROW: 38, RIGHT_ARROW: 39, DOWN_ARROW: 40, INSERT: 45, DELETE: 46, ZERO: 48, ONE: 49, TWO: 50, THREE: 51, FOUR: 52, FIVE: 53, SIX: 54, SEVEN: 55, EIGHT: 56, NINE: 57, A: 65, B: 66, C: 67, D: 68, E: 69, F: 70, G: 71, H: 72, I: 73, J: 74, K: 75, L: 76, M: 77, N: 78, O: 79, P: 80, Q: 81, R: 82, S: 83, T: 84, U: 85, V: 86, W: 87, X: 88, Y: 89, Z: 90, F1: 112, F2: 113, F3: 114, F4: 115, F5: 116, F6: 117, F7: 118, F8: 119, F9: 120, F10: 121, F11: 122, F12: 123, NUM_LOCK: 144, SCROLL_LOCK: 145, SEMI_COLON: 186, EQUALS: 187, COMMA: 188, DASH: 189, PERIOD: 190, FORWARD_SLASH: 191, GRAVE_ACCENT: 192, OPEN_SQUARE_BRACKET: 219, BACK_SLASH: 220, CLOSE_SQUARE_BRACKET: 221, SINGLE_QUOTE: 222

Renderer

Coquette’s renderer module calls the draw() that you define for the game and all entities in the game.

Inside of any of those draw() methods you can use this line to get the canvas drawing context and draw:

var context = coquette.renderer.getCtx();

Ticker

The ticker updates the game loop at 60 frames per second. From the project readme: “If the main game object or a game entity has an update() function, it will get called on each tick. If the main game object or a game entity has adraw() function, it will get called on each tick.”

Make a game!

Coquette is an awesome choice for simple 2d games – it would be well-suited to the upcoming Ludum Dare competition.

Take a look at the demos in the Coquette Github repo, and dig around in my BlockSnot game for ideas.