Battle City

Server-side code is based on
The client side is an old (rather crappy) code base, orignally targeted for Node.js,
which was ported (sort of) to Google Closure.

The thing uses many tools rather heavily, so I prefer to keep js code apart from erlang code.
The code organization for a release might change significantly.

Development environment


    * Make sure there is an Erlang/OTP distribution in your system
    * Also make sure SVN, Mercurial and Git clients are present (yes, all of them)

  Getting started

    * pull dependencies:

          $ ./
          $ cd server && ./rebar get-deps
          $ cd deps/socketio && ./rebar get-deps   # this will pull from git submodule

    * start serving javascript
          $ client/ serve

    * (re)compile the backend and start it (better do this in a separate terminal from the previous one, lots of output)

          $ cd server && ./rebar compile
          $ server/              

    * open the resulting page in the browser at http://localhost:7878

  A handful of details

  * JavaScript is processed and served with plovr, there is a few configurations for plovr,
    the one used in dev mode is client/config/config.js
    It emits a lot of warnings and errors but does not compile anything
  * CSS is produced from LESS.js format with the less tool and is further minified
    with YUI Compressor (note that YUI Compressor is never used to minify js in this environment)
  * Unit testing with Google Closure is awesome, but the setup is very tricky, plovr introduced
    some utilities for unit testing as of November 2011, but this has not yet been incorporated in our tool set.
  * Most tasks including final compilation is done via script. We might switch to makefiles any time soon.
  * If you have pulled the code from somewhere first build the server side code.

        $ cd server
        $ ./rebar get-deps
        $ ./rebar compile

  * Server can be started with 
        $ cd server && ./

  * In order for the flash-based websocket fallback to work the swf file should be served by a server, not necessarily
    the one. But I use the same for both serving static files and processing requests. This is rather possible that I 
    try another approach soon.