The Palavering Proffitt

Clojure Cup 2014 Post Mortem

Sun, 19 Oct 2014 00:00:00 -0400

I participated in Clojure Cup again this year, making it two years running. I worked on a team with hlatki on a simple in-browser number game slightly influenced by the style of 2048 called Number Chain. I've migrated the final source to be under my Github profile and a more recent version of the game can be found here.

The Idea

I had been interested in making a game based on numbers since 2048 became popular earlier this year. The simplicity was appealing, and for a 48 hour competition with a focus on the browser, it made sense to try to build something like the original game 2048 browser game which worked great on mobile devices, but using ClojureScript as the core technology.

What Went Well

The Clojure Cup sponsors did a great job of providing the participants with development resources. We were provided servers from CloudSigma, a private Github repository to host the code, Flowdock access for team communication, among many other things. I call out the three above as they were the three provided services we used for developing Number Chain.

In addition to the provided services from Clojure Cup, we used a Trello board as a way to organize tasks and coordinate our work. It was very effective. Before the cup began, I populated the board with what logical tasks I could think of, haltki setup our Flowdock, and I setup a CloudSigma Image. I created a skeleton repository based off of the Perfection skeleton project on Github, which would allow for quick development of our application.

Since React.js has been such a popular library for web development this year, we decided that we should use one of the ClojureScript libraries that wraps it's functionality. We narrowed it down to Reagent and Om. In the end we chose Reagent for it's lower learning curve.

Reagent ended up being a great choice. All you really need to do to get started with it is refer it's atom into your namespace and use it when creating your application state. You then simply write functions that render the various pieces of the DOM (using hiccup style templates), and when anything in your application mutates the state of your atoms, the components that are using those atoms derefenced values are re-rendered.

A good example of this is the code used to implement the score, found in the score namespace:

(ns number-chain.score
  (:require [reagent.core :refer [atom]]
            [clojure.string :as string]))

(def score (atom 0))

...

(defn score-component
  "Reagent component for the current score and high score."
  []
  [:div
   [:div.score (str "Score " @score)]
   [:div.high-score (str "High Score " @high-score)]])

As you can see, the score-component dereferences the score atom that is defined at the top of the namespace. In the core namespace of the application the score-component is mounted like so:

(reagent/render-component [score-component] (get-element-by-id "score"))

With the (get-element-by-id "score") returning a DOM element for the component to be rendered into, which in this case is a div. With that done, anything in the application that modifies the score atom will cause the score-component to be re-rendered automatically.

Overall, Reagent fit our needs well for Number Chain as the scope of the project was relatively small. I can see a stronger argument for Om for projects that are going to be significantly more complex, but for something quick and simple Reagent really shines, in fact it ships default with the Luminus Clojure Web Framework.

What Didn't Go Well

For the portions of the competition that didn't go well, one thing really sticks out: CSS. I've always avoided CSS as for the most part I've not done a significant amount of front-end web development. That really bit me for this project. hlatki has more experience in this regard, and ended up getting the look and feel of Number Chain to where it was. Despite this, it still took a significant amount of time for both of us, time that could have been better spent working on some of the stretch goals we had for the application.

Another pain point related to the front end web development was timing quirks and events. The simple case of clicking just worked, and that is how we trigger a selection toggle on the cells when you use your mouse:

(defn small-cell
  "Takes a single value from the :numbers app-state value and produces the cell
   that represents that number. Properly sets the bg color and data-id tag
   fields."
  [{:keys [value id]}]
  [div-grid-col {:style {:border "1px solid #d3d3d3"
                         :background (if ((:selected @app-state) id)
                                       (:selection-color @app-state)
                                       "#009bcc")}
                 :data-id id
                 :id (str "grid-" id)
                 :on-click toggle-selected}
   value])

As you can see, this is embedded into the actual HTML generated when the reagent component is rendered, so it just works. Unfortunately, for a mobile based environment we have to add the touch listener in raw Javascript, which we did with this function:

(defn attach-touch-listeners!
  "Add the touch listeners to all of the grid-cell divs in our game. Needs
   to happen after each rendering of the game grid."
  []
  (let [els (get-elements-by-class-name "grid-cell")
        size (.-length els)]
    (doseq [e (range size)]
      (.addEventListener (aget els e) "touchstart" toggle-selected))))

;; Actually called via:
(js/setTimeout #(attach-touch-listeners!) 50)

The timeout above was needed to handle issues we saw due to a delay in when the applications state was modified to start the game and when the actual grid cells were rendered. Without the delay, there were no element to attach the touch listeners to. Unfortunately, it took a bit of time to discover this, and then fix it.

In the End...

We had a great time. It was a nice way to spend a weekend working on something for fun, trying out new things, and having something (semi-)polished to show off. I look forward to the next Clojure Cup! In the mean time I'm going to be looking at CSS a bit more, in addition to all the exciting things happening in the Clojure/ClojureScript space.

Getting started with ClojureScript

Thu, 21 Nov 2013 00:00:00 -0500

I recently attended Clojure Conj and had a wonderful time. I've been doing things in Clojure whenever I can find a good fit for it, but at the conference I was inspired to take a look at ClojureScript when I saw MarcoPolo's Transcience game which was written in ClojureScript.

I sat down last night with aspirations to dig in and get something started (likely a game for the Github Gameoff) but quickly realized that ClojureScript development didn't flow quite as smoothly as Clojure development. My impression so far has been that this is mostly due to the short time ClojureScript has been in the wild. With that said, I wanted to outline my first steps, where I went wrong, and specifically: how to get a browser attached ClojureScript repl going.

Getting Started

I'm going to assume that you already have lein installed. If not, the installation is very simple and can be found on the leiningen github page.

The first step, as always, is to create a new project.

lein new try-cljs

We next need to edit our project.clj file to pull in ClojureScript. This can be done by adding [org.clojure/ClojureScript "0.0.2030"] to the :dependencies vector. We will also want the lein-cljsbuild plugin. Add a :plugin keyword with [[lein-cljsbuild "1.0.0"]] as the value to accomplish this.

The lein-cljsbuild plugin is configured via the :cljsbuild key, taking a map as the value. We'll use something similar to what's found in the simple example project of the lein-cljsbuild github repo. It looks something like:

:builds [{:source-paths ["src-cljs"]
          :compiler {:output-to "js/main.js"
                     :output-dir "out"
                     :pretty-print true}}]}

At this point your project.clj contents should look like:

(defproject try-cljs "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :url "http://example.com/FIXME"
  :license {:name "Eclipse Public License"
            :url "http://www.eclipse.org/legal/epl-v10.html"}
  :dependencies [[org.clojure/clojure "1.5.1"]
                 [org.clojure/clojurescript "0.0-2030"]]
  :plugins [[lein-cljsbuild "1.0.0"]]
  :cljsbuild {:builds [{:source-paths ["src-cljs"]
                        :compiler {:output-to "js/main.js"
                                   :output-dir "out"
                                   :pretty-print true}}]})

Now run lein deps to pull these dependencies. Once that has finished, it's time to write some ClojureScript! Since we have specified in our project.clj that our cljs src is in src-cljs, we must make this directory. mkdir -p src-cljs/try-cljs/. Now, using your favorite editor, let's create hello.cljs in this new directory.

Add this to the contents of the file:

(ns try-cljs.hello)

(js/alert "Hello World!")

Save that, and run the lein cljsbuild once which will compile this file, placing the output into js/main.js and out/. This is nice, but now we need an html file to get this going in a browser. Create a file in the root of your directory hello.html:

<html>
<head>
</head>
    <body>
        <script src="js/main.js" type="text/javascript"></script>
        <script type="text/javascript">goog.require("try_cljs.hello");</script>
    </body>
</html>

Now, you should be able to open this page in your browser. When you do you should see the javascript alert pop up with "Hello World!" as the message.

That was fun, but...

So, now we have some ClojureScript compiling to javascript and running, but we're missing an important piece of our tool chain that makes Clojure a joy to work with: the REPL. Let's get that up and running next.

There are a few ways to get a repl running, for this post we will use the repl-listen option provided by lein-cljsbuild. First we must modify our hello.cljs file to look like:

(ns try-cljs.hello
  (:require [clojure.browser.repl :as repl]))

(repl/connect "http://localhost:9000/repl")

(js/alert "Hello World!")

Save and run lein trampoline cljsbuild auto. This differs from the lein cljsbuild once in that we are only keeping the java instance that lein requires long enough to get our clojure process in proper order and for cljsbuild to monitor the cljs files for changes and auto compile them when they change. This is particuarly useful as we do not have to wait for the JVM to fire up everytime we want to compile, but at the price that a JVM instance stays alive until we kill the process.

Next, run lein trampoline cljsbuild repl-listen. This will fire up a ClojureScript REPL and you should see:

Running ClojureScript REPL, listening on port 9000.
To quit, type: :cljs/quit
ClojureScript:cljs.user>

Now, it's time to try out our page again. Instead of opening hello.html directly, navigate your browser to http://localhost:9000/hello.html. You should now see the same javascript alert from earlier. Now, in the ClojureScript REPL, we can interact with the page we just navigated to. Run (js/alert "The REPL works") from the REPL. The message should appear as we would expect.

All your browsers are belong to us?

That is culmination of the knowledge I gained while working through the documentation for getting a ClojureScript REPL running in the browser. I particuarly struggled with connecting to the REPL as it was not immediately obvious how the connection was made. Google ended up not being much help, until I found this google group thread. I discovered that all I needed to do was navigate to the http://localhost:9000/, not http://localhost:9000/repl. I was also using index.html instead of hello.html last night, hopefully this distinction is helpful in the URI's as I did not realize that port 9000 was serving pages from the root of my project.

I'm excited to experiment more with Clojure and ClojureScript. I'm likely going to give cemerick's Austin a go next. I've created a github repository here that contains the complete code written in this post, so if you don't want to type it all out, go ahead and clone it!

Ludum Dare 27 Post Mortem

Wed, 4 Sep 2013 00:00:00 -0400

This time around I've managed to get to writing this in a more timely fashion. Ludum Dare 27 was almost two weeks ago, and so the judging is still going on for my entry "Get to the Choppa!". Overall this Ludum Dare went much smoother than the previous. The theme this time around was "10 Seconds" which lent itself to the game idea I had in mind.

The Idea

Learning from the experience I had in Ludum Dare 26, I decided that having a better defined idea for the game before the theme was announced would make the development go much smoother. I had been playing Organ Trail when I had time to kill in July and August, and I was enjoying the simplicity of the scavenging missions. I knew that I wouldn't be devoting the full weekend to this Ludum Dare like I had the last, so I thought aiming for gameplay similar to this for my entry would be reasonable. I also loved the retro style of Organ Trail, and so I wanted the game to be visually similar.

The Saturday before Ludum Dare I happened to re-watch this awesome Predator video and "GET TO THE CHOPPA!" popped into my head. I knew now what the goal of every level of my game would be: Getting to that choppa! Since CoffeeScript and Crafty.js hadn't been a bad experience, I decided to use them again for implementing the game. I described the idea to some of my friends and luckily they wanted to help. When it came time for the theme to be announced it could not have been more perfect: "10 Seconds". More like: "10 Seconds to get to the choppa!".

Getting to the Choppa!

We didn't get started until late in the day Saturday. I wanted to reuse any components that we could from MetroGnome, however the way most were implemented they were not easy to drop in the way I had hoped. In the end we used this code as a reference for where to begin when we had questions with how to do something. Specifically, I had not touched anything with sprites when we worked on MetroGnome, so being able to see how this was implemented in MetroGnome was awesome.

Since the team working on Get to the Choppa! was smaller this time around it was much easier to divvy work out and implement features concurrently. While I was working on loading assets and animating the sprites others were working on enemy movement and bullets. Since we had an idea of what we wanted the game to play like and how it should look, the art quickly came together, in fact it was finished two or three hours after we started working.

What that went well:

Graphics
Having a concept before the theme was announced
Gameplay
Smaller team
Smaller scope

What could have been better:

CoffeeScript/JavaScript can resemble insanity
We still need more experience with Crafty.js
No sound

Overall this Ludum Dare flowed much better than the previous one. Having a concept before the competition started was huge, as well as having a smaller team and scope. Despite going better overall, I still found myself working on the project up to the deadline. When I reached the point where it was time to implement the level loader, I kept finding bugs. Part of this is due to the dynamic nature of JavaScript. It's easy to develop something quickly with JavaScript or CoffeeScript, but it's a pain to debug.

Despite it's flaws, I'm still happy with the outcome: Get to the Choppa!.

Next Time

So, after participating in the last two Ludum Dare Game Jams, I've definitely found that having a concept prior to the event is huge and I will most certainly have an idea before the next one. I've used Crafty.js and CoffeeScript for both competitions, and despite the rough spots I will likely use them again. I would really like to take some of the pieces that we developed for MetroGnome and Get to the Choppa! and work on their design so that we can potentially reuse them in the next Ludum Dare. I also feel that getting the level loader up earlier (this was the last piece I worked on) would be huge. The game didn't feel like a game until the levels were loading.

The next Ludum Dare will be sometime in December. I hope to devote more time to it than I did for this one.

Ludum Dare 26 Post Mortem

Sun, 23 Jun 2013 00:00:00 -0400

This is coming a bit late... it has been a while since Ludum Dare 26! I have had a lot going on with my family and work so I'm just now getting around to writing this.

For those of you who are not familiar with Ludum Dare, it is a game development competition. It is consists of two events: an individual, two day competition that has a strict set of rules, and a more laid-back, team-based, three day game jam.

We participated in the jam! Our team consisted of five programmers and one artist. This was our first time participating in a Ludum Dare event which made it a fun and interesting experience.

Before going into the minute details, here are the canonical "what went well and what didn't go well" lists.

What went well:

Graphics
CoffeeScript
Sharing the same workspace
Github
Streamlined build process

What could have been better:

Gameplay
CraftyJS
CoffeeScript(!?)
The theme
Inexperienced team
Bottle-necked workload

Prequel

Before the competition, we decided on using JavaScript and Crafty to write the game. CoffeeScript was later chosen over JavaScript due to it's cleaner and more succinct syntax (thanks to a brief love affair with Node Wars). With this knowledge, I prepared a local server that each of us could push our current build to in order to efficiently show the progress we were making. All of us are Vim users so we installed the awesome plugins syntastic and vim-coffee-script to assist us with CoffeeScript syntax, linting, and compiling.

The Game

Minimalism was the theme of this Ludum Dare. We talked through our game ideas and landed on using sound as the core game mechanic. We eventually came up with the idea of using a gnome as the main character. The specifics of the sound mechanic evolved into a metronome-like beat; its' purpose was to signify when the player could move. Thus, Metrognome was born.

In Metrognome, the beat is tied to the movement of the player. The speed of the gnomes' movement was tied to the accuracy of hitting the directional key with the beat. Accurate timing results in the gnome dashing quickly in that direction. With this design in mind, the next step was coding and developing the art.

Since most of us had never used CoffeeScript or Crafty, there was a considerable amount of flailing involved. The vim-coffee-script plugin was useful for the minor mistakes so we slowly made progress. A bigger problem for us was the Crafty documentation; we often had to resort to looking through the source for answers instead of their published docs.

Our team composition and lack of experience plus the short duration of the jam did not work in our favor. The first two days proved difficult for more than two of our programmers to work in parallel; our code base was not large enough for our team. Fortunately, the third day went better in this regard; the code base had grown large enough for each of us to have a task that would not trample others work.

Our experience with Crafty was also an issue. Crafty is built as an Entity Component System and this was a new design paradigm for most of us. Some of the components we wrote resembled objects from the Object Oriented school of thought more than what an ECS component actually should use.

Despite our struggles with Crafty and our inexperience with CoffeeScript, we were able to finish with a semi-working game. The graphics and art style turned out great! It can be found here and the source here.

Hello World

Fri, 12 Apr 2013 00:00:00 -0400

This being my first post, it feels right to include a hello world program.

#include "stdio.h"

int main(int argc, char* argv[])
{
    printf("Hello World!\n");
    return 0;
}