7DRL Postmortem

My 7DRL project was not what I consider a success. While technically I had a playable game, it was more of a random maze game than anything else. While the RPG code was mostly done (if you look at the source you can see a couple thousand lines of rpg related classes) it simply was not integrated into the rest of the game. This work will be done and the finished version of the game will be releases eventually but it was not finished within the 7 days of the challenge so it is not a success. That said, here is the postmortem.

What went wrong

Memory is a faulty thing. As this game was to be based on an existing Java game, I was thinking about the project as if all the code was already ported to JavaScript. For this reason I never really took a look at how much code there actually was for the original game. I really don't remember the project being as big as it is. Part of the reason for this is due to the fact that the orignal Dungeon Romp was built on top of the other games in the Ultimate Retro Project as well as borrowing a lot of code from the Coffee Quest series so a lot of the work was already done. I really should have reviewed the code before I started and started porting the common libraries beforehand. Ultimately, I made the rookie mistake of taking on far more than was realistic for a one week period. Next year I will be more prepared.

What went both wrong and right

Porting the code was a mixed blessing. As I mentioned above, there was a huge amount of code that I ended up hand-porting to JavaScript. There are some tools that will cross-compile from Java to JavaScript, but when I looked at them the results were not very good. I want to be able to modify and use the JavaScript code not to work in Java and publish the results as hard to read/modify JavaScript that requires large amounts of support libraries to work. While hand-porting is a lot more time consuming then running code through a tool, it has two huge advantages. You really understand the code that you are porting after you have finished porting it. You are able to take advantage of certain features of JavaScript (dynamic classes, for instance) that a cross-compiler simply will not.

What went right

While I suppose this is not the most significant thing, the thing I am most proud of is my pre-loader. This is the first JavaScript game I wrote that really needed some type of pre-loader. After doing a bit of testing, I found that the code started running before all the script files were loading, so the pre-loader could also include the loading of the scripts as long as the pre-loader script was before the other source script tags. Even if this is not a feature in all browsers, the image loading code will still take the bulk of the loading time though there will be a slightly longer delay before any activity happens. To get something on the screen as quickly as possible, a text message is rendered while the title-screen image starts loading. Once the title screen image is loaded, the other images (condensed into a number of image atlases) are loaded.

While finishing the game in a part-time week was not in the cards, the game will eventually be completed. I am hoping for an April release, but am not committing to anything at this point.