Home | Rules and Guide | Sign In/Create Account | Write a Post | Reddit | #LD48 | #ludumdare on irc.afternet.org (Info)

Ludum Dare 31 — Coming December 5th-8th 2014! — Join the Mailing List!
  • October Ends: in 31 days, 0 hours, 15 minutes, 30 seconds
  • Ludum Dare 31 begins: in 66 days, 1 hour, 3 minutes, 30 seconds
  • (FYI: Clock might be off) | Ludum Dare 31: Real World Gatherings (Now Open!) | October Challenge 2014!


    My first (near) submission to Ludum Dare

    Posted by (twitter: @Mokona34)
    January 19th, 2013 4:52 am

    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.

    GoldKeeper

    (this post is an english translation of my original post on my blogĀ  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 commoin 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, writting 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.

    Tags: ,

    Leave a Reply

    You must be logged in to post a comment.


    All posts, images, and comments are owned by their creators.

    [cache: storing page]