For the backend architecture, we went with a classic client/server model where all events and changes are sent to the server. Upon receiving these messages, the server would record any changes, do any necessary processing, and finally notify all other clients that the change occurred, so that they could individually update their state.

In this way, eightbitbeat's node.js instance primarily serves as a message relay system that sits between all players to make sure there aren't any syncronization issues. It also ensures that there is an authoritative representation of the room that we can send to new user connections. This type of communication model is essentially what node.js is known to excel at, so once we coded and fired up the server, everything ran quite smoothly.

To get the client talking with the node.js server, we simply dropped in the amazing socket.io module. Using socket.io meant that all the we needed to do was establish a clear API and then split off to code our own respective pieces, without worrying about integration issues. During the entire length of the Knockout event, the members that were focused on the frontend coding didn't need to look at the server code -- nor did they have the time to. As long as communication between the client and server followed the "documentation" we outlined on the whiteboard, every piece of the app knew how to interact, and thus worked flawlessly.

Deployment

For deployment we decided to use Linode. Although there were a bunch of great deployment options provided by sponsors that we would have loved to try out, we had experience with Linode from personal projects, and knew that we could quickly get things up and running from scratch.

We were grateful that the Node Knockout team provided easy-to-follow steps for contestants to set up their local and production environments. It was clear that they really made an effort to provide solid resources and documentation to contestants to ensure maximum time could be spent coding and building a product.

We anticipated the main play loop to be one of the more challenging aspects of the project. It had to be optimized since it would be responsible for playing collections of audio samples precisely enough to pass as music to sensitive human ears. We began by looking to the internet for ideas for our implementation, and found this article on Javascript Game Loops by Arthur Schreiber. While the article covers some bits of screen rendering, it served as a solid starting point. The basic requirement of our play loop was that it had to loop through each step in the sequence at a consistent rate determined by a beats per minute (BPM) value and then play every active note in that step. This was easily achieved with the following:

    // Pseudo javascript for demonstration
    Player.play = (function() {
        // Set up timing variables
            var skipTicks = 60000 / 4, // 60000ms per min over 4ticks per beat
            nextTick = (new Date).getTime();

            return function() {
                while ((new Date).getTime() > nextTick) {
                    // While it's time to tick, tick until it isn't time anymore.

                    // Do the work
                    $.each(Player.notes, function(note) {
                        note.play();    
                    });

                    // Increments nextTick by the correct ms per tick
                    nextTick += skipTicks / Player.bpm; 
                }
            };
    })()

    // Start the loop
    Player.loopInterval = setInterval(Player.play, 0);
                        

However, we noticed that it did not perform very well with a reasonable amounts of notes, so we built a sound manager object to collect every sound that needed to play on a given step, and only play each unique sound once. We achieved this by throwing every sound into a makeshift hashset (we used an associative array) and then triggering a play on each of those sounds at the end of the loop. Then we had the idea for the manager to pre-cache the notes in the coming step ahead of time, so that they would be ready to play immediately upon each new time step.

    soundManager = (function () {
        // Make-shift HashSets
        var toPlay = {};  // Sounds to play for the current step.
        var cache = {};  // Sounds to cache for the next step.
        return {
            // Add a file if it’s not been added.
            addFile: function(file) {
                if (!cache.file) {
                    cache[file] = file;
                    // This value should probably just be set to true.
                }
            },

            // Play the collected sounds.   
            play: function() {
                // Play sounds if we have them
                if (!!_.size(toPlay)) {
                    _.each(toPlay, function(name) {
                        playSound(name);
                    });
                }

                // Update the sets.
                toPlay = $.extend({}, cache);
                cache = {};
            }
        };
    })();
                        

This was as far as we got with the loop optimizations in the allotted 48 hours. We would have liked to spend a bit more time tinkering with the loop, but it is currently holding up with 4 to 5 users worth of notes. By nature, sequencers are intimately bound with loops. At the highest level, they contain the user-facing music loop, while further down they rely on precise "tick" timing loops. Game loops were a relatively new topic to most of us. We had fun learning about them and are excited to correct our mistakes in coming versions of the application.