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:

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();.

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).

wavelength = velocity/frequency

Don’t forget to convert your units!

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

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!

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!

My good friend Aaron Maus is a lisper, and wanted to make a game. I’ve never programmed in lisp. We have 30 days to program a game for this contest. Super fun.