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.

Plans for 7DRL

I was thinking about participating in the Game in Ten Days challenge. When the theme of "Dungeon" was announced, I was still thinking about it but noticed it is very similar to the plans I had for the 7DRT challenge which I want to participate in. I roughed out a different style of game but quickly realized that my plans were unrealistic for the amount of time I would actually have available so will hold out until a future GiTD challenge to participate.

For the 7DRL, I want to do a new version of my Ultimate Retro Project (episodes 59 and 60) game Dungeon Romp. This game will be created in JavaScript (the original was in Java). I haven't decided if the game will be called Dungeon Romp 2, Dungeon Romp II, or Dungeon Romp Deluxe yet. I want the game to focus much more on the randomness that is traditional in a rogue-type game. There are three areas where this will be done.

Obviously, the random map generation is the key. I know the map generator from the original game is not the greatest, but will use that as the starting point. The re-implementation may also be the ending point as the maps from DR were good-enough so reworking the code will be done near the end of development if time allows. As time will probably not allow, expect just a tweaked version of the Dungeon Romp maps.

Items will be the big thing that I will try to focus randomness on. The types of items available will vary from game to game as well as (within realistic ranges) the properties of those items. One game may have swords being the best weapon to have, while the next one battle-axes may have superior models and stats. Magic will have both beneficial and detrimental variants with a possibility of some spells being a mix of both (think of a spell that causes massive damage on an opponent but at the same time reduces the melee skill of the player for a number of turns).

Finally, I would like to have more varieties of monsters. Both in the type of monsters and how powerful those monsters are. In one game you may face level-1 goblins which are easy to defeat, while the next time the goblins will be generated at level 5 stats so the player has to re-familiarize him/herself with the monsters in every play.

That is my plans for this first-ever 7DRL. If nothing unexpected happens, I should be able to put in 50-60 hours durring the next 168 hours available to me so have a good shot of having a finished game.