I had never participated to Ludum Dare. Sometimes because of lack of inspiration, very often because of lack of time, sometimes because when I noticed that the jam had began, it was already ended. For Ludum Dare 25 that was organized last month, I was aware of it just some hours after the launch. The theme was inspiring and I also had a funny (at least in my opinion) idea.

(this post is an english translation of the original post here).

But as it's often the case, I also had a week-end with very little time for this activity. Even in the Jam category, which is specifically organized for those on who the \"real life\" as un impact, which is a day longer and smoother rules, it felt like it was too short for me.

So I worked a bit the subject in my head, but after 24 hours without having the chance to really concentrate and produce something, I abandoned the idea to enter the jam.

Meanwhile, I was looking at what Ebene was doing after she announced her entry on a well known social network.

On Sunday evening, she announced that the developer she found for the project wouldn't be able to finish it. So I've looked closely to what had already been done in terms of Game Design and Graphics. I liked it. On the programming side, it felt it was doable in a week-end of time for someone who can really concentrate. I thought I would be able to found the same number of hours in a week time.

So I told Ebene I'd do what I can. No guaranty. On my side, clean my Javascript and HTML skills on a real project is great for improving myself. So, let's go.

After a week, the game implementation is at a correct level. Some added hours the next week have been added to smooth the rough edges.

In the post-mortem tradition, I'll answer next two questions : what can I improve and what went well?

What can I improve?

Javascript

My former experiences had already given me the taste of it. This is not a surprise to me that language was considered badly before the creation of AJAX then HTML5. Iterations are quick (add a function, reload the page,...) but the number of traps in this language slowed me a lot at the beginning, while I was remembering them.

While developing, stupid mistakes went scarcer but never completely gone.

I was on the run without too much possibility of stopping to build myself a comfortable environment. But at the end of the development, I searched for static analysis programs like jhlint. This allowed me to improve a couple of things, but that would have been really interesting from the beginning of the development to avoid a test when a file has syntax error and is just not loaded into the browser.

My conclusion is that Javascript really needs a toolchain to continuously verify the obvious mistakes. Most of the tools I've tested are heavy to launch, which decrease the raw iteration time, while maybe improving the quality in the long run.

Another way of study would be to study languages build upon Javascript, like CoffeeScript or Dart.

Quality tools

Static analysis or test framework are tools I cannot program without in my daily professional environment. As I didn't know them enough for this project to rely on them, I didn't use any.

Before starting a new session of this kind, I must have found, tested and almost mastered such tools for the Javascript world. These are great time improver and time is a precious resource.

Deployment / Collaboration

We were two on the project. Ebene was producing the Game Design document, the graphic resources, the HTML integrations and the game data. All these data were available on a web server for me to fetch.

On my side, I was providing the zip archive extracted from a Mercurial depot, containing the working (most of the time) game.

The steps for me were:

- updating the new data with wget when an update was available- data copy on my depot- comparing the updates (mostly the HTML/CSS files) and manually update the in the final integration files.- export of game data to the file format used by the program (OSD to JSON)- verify / submit

Then, after a session of work on an improvement:

- archive creation- send the archive by sftp to a HTTP served depot- tell about the update

These are a lot of manual operation that should be automated. What I see for improvements:

- work on a common depot; not a must have, but really interesting- for an HTML game, a better integration process by better thinking how to fetch the new page updates- automated export of data- continuous build system with static analysis and deployment.

What went well?

1. A pretty well detailed game design document and a function first version of the game data. Thanks to Ebene for that. Apart from some written questions on some points, I was able to go fast with a good idea of what would the game look like, even if I really discovered it while programming it.

2. Le platform choice. Even with what I just said on Javascript, using scripted HTML is good for this kind of game.

A test editor, a browser with developer tools (I've used Firefox + Firebug) are ok. The few data needed by the game allowed to start quickly and work by little iterations.

3. Development loop

The development loop I've globally followed was: choice for a missing feature, feature prototype, writing the complete feature, cleaning.

Regularly cleaning the code avoided too much technical debts, even while missing quality tools.

Even on small project, the technical debt can quickly rise and crush any speed in your programming. And what comes with it this decrease in speed is the rise of frustration because of bugs.

This also allowed me to separate the responsibilities in the code. Mainly the game logic from the HTML integration.

4. Developing Time

Because I wanted to know if it was really possible for a dedicated guy to achieve the same amount of work during a game jam, I've tracked the number of hours on the project for the programming part.

The \"Beta\" level for the game (working game with a few minor bugs) took my around 20 hours, 5 of them really dedicated and without distraction.

I guess that for someone with a good environment during the event would have spend 10 to 15 hours. Fair enough for a game jam.

After the beta version, little improvements and bug fixes took me something around 2 to 3 hours spread in a week long period.

Conclusion

This was a really interesting experience and the result is pleasing. I've improved my skills in Javascript + HTML on a real project with new ideas to improve the way I work. My personal objective is to improve on my productivity to get the most of those few little time period I can spend on hobby programming.

And the game? It's here (for a better experience, switch to full screen with, probably, the F11 key)

You can also read: the post presenting the game, explanations, game design and much more or the previous post.