Bang Pre-Alpha

May 12th, 2012

I have a new ongoing project, it’s called Bang. It’s a canvas-tag based display list written in Javascript. I’m going to be using it in place of AS3/Flash in my web authoring tool chain. Bang on Github. There are three main elements of Bang that make it special:

Modules

When writing a project with Bang you keep your code separated in modules. Each module exposes a Javascript Object, like a constructor function. The modules object is passed into each module definition, exposing your module to other modules that depend on it. Keeping your code in modules like this means you need only expose one global variable, the list of modules. Any modules loaded this way are essentially sandboxed in that modules object.
You define a module in a similar manner to RequireJS and the AMD:

mod({
name : 'MyObject',
dependencies : [ 'bang::Geometry/Rectangle.js', 'myLib::SomeFile.js' ],
init : function initMyObject(modules) {
function MyObject() {
this.x = 0;
this.y = 0;
}
MyObject.prototype = {};
MyObject.prototype.constructor = MyObject;
return MyObject;
}
});

The module system is another project of mine called Mod. I’ve written about it before. It’s very small and simple and it gets the job done (the job of code separation and later compilation).
Bang adds support for Google’s Closure Compiler to Mod, so once your project is ready to ship you can compile (in a sense), compress, obfuscate and pack your code down into a deployable script or a neato mosquito PNG. I like the PNG method because it’s slightly more obfuscated and adds further sandboxing, but that’s a topic for a later post.

It’s like Flash, but not too much like Flash…

Bang is enough like Flash/AS3 to be familiar, but sacrifices some AS3 similarities in exchange for simplicity and consistency. The complexity in Bang is very small. There aren’t any tricks to make it more Flash-like than it has to be and it won’t protect you from learning canvas operations. In fact, you’ll have to learn about the CanvasRenderingContext2D to do any real drawing. I’m not aliasing those calls and hiding it in a mock Graphics object for you! ;) And you should be learning these new technologies without crutches. Think of Bang not as a set of crutches, but as a set of wings, or at least a hammer and chisel. No one likes masonry-by-hand.

It is fast.

The original pre-alpha version of Bang takes Douglas Crockford‘s extremism literally. There are no uses of the keywords ‘this’ or ‘new’. It accomplishes (multiple) inheritance through special constructor functions that add functions and closures to objects (or creates new ones). This, although a departure from AS3 at first, actually gives projects written in Bang an AS3++ feel. Multiple inheritance is awesome. Private variables are awesome. With prototypal inheritance you lose private variables so by using special constructor functions we can create private variables through closures. These features are awesome, but as Martin Hunt of GameClosure pointed out to me, it’s not fast. Processing time will go up linearly with the number of properties and methods created in the class. This means that if you’re creating a lot of complex game objects every frame tick, the project will likely start chugging. This is not fast. Apps have to be fast! For this reason I started a new branch of Bang that uses traditional prototypal inheritance. This branch will include a dirty rectangles implementation for really lazy redrawing, and I have plans for using WebGL for rendering down the line. Stay tuned!

A tiny demo

Take a look at the source for this div. This is the compiled output of the main branch of Bang. It’s clean, right?!




mod – A javascript module definition and loading tool.

January 18th, 2012

Now that I’ve been writing a lot less Actionscript and a lot more Javascript I’ve found that I often need a system for separating my code out into modules. Javascript doesn’t provide a convenient way to load scripts and define modules so I wrote a tool I call ‘mod‘ that uses either XMLHTTPRequests or script tag injection to load scripts.

mod uses initialization objects to define modules. A module object takes a name, an init function and optionally an array of dependencies (paths to other scripts you’d like to load before initializing the current module). You can also supply an optional callback to execute after the module has been initialized. Both init() and callback() are passed an object that contains all the initialized modules thus far.

Defining a module looks like this:

mod({
    name : 'Main',
    dependencies : [
        'anotherModule.js'
    ],
    init : function initMain(modules) {
        // we can access anotherModule because mod.js
        // loads and initializes dependencies in order
        var anotherModule = modules.anotherModule;
        return {
            someValue : anotherModule.someFunction(),
            functionToExpose : anotherModule.someFunctionToExpose
        };
    },
    callback : function cbMain(modules) {
        // we can access Main because callback() is not called
        // until after Main's init()
        var Main = modules.Main;
        window.exposedFunction = Main.functionToExpose;
    }
});

In this first call mod packages your module initialization object and starts loading its dependencies (either through XMLHttpRequest or script tag injection). Once the dependencies are loaded (which may or may not define more modules and load more scripts), the result of the init function is stored in mod.modules, in this case as mod.modules.Main. The loaded modules are exposed to your init and callback functions as the only parameter, so they don’t clutter global space. As an added benefit, you can share data between modules using mod.modules.

If you use mod to write lots of modules (like I do when working on a big project), mod can ‘compile’ your project for you, removing all script loading. It essentially takes all your init and callback functions, wraps them inside an island closure and prints them to one monolithic file which you can then compress with YUI or a google ‘something-or-other’.
To do this, load your project in your browser, open the js console and type mod.printCompilation(). Alternatively, to store in a string, type var compilation = mod.compile();.

Measuring the speed of light using marshmallows in a microwave

November 21st, 2010

I just saw a video here about using neon bulbs to visualize microwaves in a microwave oven.
Another great microwave oven experiment (that I learned from Lynn Cominsky at Sonoma State) is measuring the speed of light (or the frequency of the microwaves emitted) using marshmallows.

1. Cut a bunch of marshmallows in half (or use small ones) and cover a plate with them.

2. Take the rotating platter out of the microwave and place the plate inside. The rotating platter helps cook your food evenly by spinning the food in and out of the microwave’s ‘hot spots’, but for this experiment we want the marshmallows not to cook evenly. The microwaves are emitted from one side of the microwave (where the emitter is located) and bounce off the opposite side, creating standing waves. The anti-nodes (crests) of the standing waves are the ‘hot spots’ I mentioned earlier. The marshmallows will burn along these anti-nodes.

3. Measure the distance between the burn marks. This distance is the wavelength of the microwaves emitted by your microwave.

4. Use this simple wave equation to verify either the speed of light (if your microwave lists its frequency on the back panel) or to determine the frequency of your microwave (given that the speed of light is approximately 3×10^8m/s).

wave equation wavelength = velocity/frequency

Don’t forget to convert your units!

The ANI Programming Language

November 12th, 2010

Oh man, I just read about ANI on hackurls.com and it looks amazing. I can’t wait to get my hands dirty.

http://code.google.com/p/anic/

Smugmug Gallery Viewer – Javascript

November 8th, 2010

I wrote a smugmug gallery viewer in javascript. To my knowledge it’s the only js gallery specifically geared at viewing smugmug account galleries. Clone the git repo (or download a tarball) here. I’ve used two js libs that I wrote recently, go (an evented control flow based on callbacks) and heyjacks (an asyncronous jsonp request helper). Let me know what you think.

No longer freelancing

October 8th, 2010

I’ve signed on with my long time client Synapse Group Inc. This means more time coding for work (and maybe less time coding for fun). I have a couple speed projects in the works though, like continuing work on RTAudio bindings for Node.js. I’ve also switched names at github, which is inconvenient – but hopefully beneficial in the long run.

Blender 2.5 object export to Javascript for WebGL

September 8th, 2010

I’ve written a small python script to export a blender object to javascript for use with WebGL (or whatever else you might be running 3d in). It currently copies the entire file output to the clipboard, and only works on mac, but stick around for a write-to-file cross platform version shortly. You can get the script at my github.
blender 2.5 to javascript

Bourtange Postmortem (ILGE 2010)

August 11th, 2010

Bourtange @ github

Overall I’m satisfied with my lisp game. My major goals were to learn lisp (to a shallow yet useable degree), learn a little about functional programming and last but not least to end up with a playable game. I feel I hit those goals and as an added bonus I’ve enjoyed programming in lisp so much that I’m looking for another project to start working on. That said, here is an explanation of what went into the game, what went right and what went wrong.

Built with
I made the bulk of the game using sbcl with cl-opengl for graphics and TextMate for editing. I wrote some custom ‘build’ scripts to send my monolithic game file to the sbcl repl. The development cycle was similar to what you’d expect from programming in C, ‘write->compile->test’. Later on after my first version I got help from the guys at #lispgames (irc.freenode.net) (sykopomp, xristos, 3b) with setting up emacs and using slime-connect, as well as setting up a .asd for my game. Using the interactive dev env that emacs + slime enables is really a liberating way to program.

What went right
* My game is playable! More often than not I leave my game projects in an unplayable (sometimes not compilable) state. I’m proud to say that this game is playable.
* The difficulty of the game goes up over time.
* I tried to program in a very functional way, which worked most of the time. It enabled my program to easily reset, and should allow for a fairly easy save function, but I never got into file i/o to finish that.
* The colors are cool

What went wrong
* Writing in a functional way messed me up a little. I tried my best to make things functional, without really having a firm grasp on what that means. I would give up on writing functionally and go back to just making things work when the going got tough. This means that in the end, I feel the code is naive and dirty.
* Collision detection is very simple. This would be fine if things didn’t move very fast, but when using gravitational equations for motion, things get very fast when they get very close. In order to keep the collision detection simple I put limits on how fast things can move. It works, but it’s dirty.
* After something gets hit I recalculate 360 points of an arc to display the life left. Halfway through development I wanted to have all the circles be drawn using ONE list of points generated ONCE. I could draw some percentage of the points to represent life lost. When I tried to refactor for this, drawing became very, very broken. If I had more time to work this out I think the game would be much faster and much smoother.

All in all, I’m pleased. I hope you play my game, and I hope you have fun playing it!

My Lisp Game is Done!

August 9th, 2010

I just checked in the ‘final’ code to github. Check out my first program in lisp!

Bourtange, a fort defense game writting in Lisp

Bourtange!

Lisp Game Progress

August 1st, 2010

So after my first (almost) 30 days of learning lisp, I have a playable game. The gameplay is a cross between tower defense and orbient. You control a planet-base (the core) in the center of the screen. This core comes equipped with one weapon, the core-blast. Enemies are generated at the edge of the screen, in the spawning-belt, and are drawn toward your core by gravity. When enemies collide with the core, the core looses life. Life is displayed as a green outline around the core and when your core is out of life, it explodes. When an enemy dies, which happens either by colliding with your core, being hit by a blast or being thrown past the spawning belt, you gain resources. Resources are displayed by purple boxes in the upper left. You can spend these resources on extra cores and weapons in the weapon-store, which is displayed in the upper right. Below is a screen shot of the game in action.
Screen Shot
A lot of work still remains to be done, but I hit the 30 day deadline with this first draft. Luckily, the contest hosts have extended the due date to August 10th. By then I plan to fix some bugs, add more weapons, enemies, a game-over screen and do some optimization. I feel accomplished after learning lisp, though I know I’ve only seen the tip of the iceberg and have found my new favorite language. To the hosts of the competition, thanks! You guys have made me a better programer.

The source to the game is here and you can download and build the game as you please. Send me a message with your thoughts on my game or my code!




Follow me on GitHub
Follow me on Google+
Follow me on Twitter