Plans for porting Java to JavaScript

When I heard that Oracle is changing their Java numbering convention because all the bug-fixes in Java are causing them problems with their existing scheme, the idea of porting my older Java games to HTML5 gained a lot higher of a priority. While the Canvas is simply not quite there yet, for the games that need to be ported it is more than adequate. I started porting the Ultimate Retro Project as a bit of a test project. Right now my results are mixed. I am using the CreateJS library instead of writing my own low-level library. This gives me the advantage of a class library that is similar to the Flash class library that I am familiar with but the disadvantage of a library that is a work-in-progress.

Unfortunately, there are quite a few old Java games that will need to be ported, so this project will take quite a while. At the same time, I am starting to port my GameJam library to HTML5/createJS and will hopefully start working exclusively in HTML 5 for my web games. I am going to be adding quite a bit of functionality to my GameJam library as I port my older games as there are many classes that can be broadened and added to the library.

In addition to playing around with createJS, I am also starting to look into WebGL. Rumours of Microsoft caving in and supporting the standard would be nice if they turn out to be true, but I have a functional canvas ray-caster that I can always fall back on so a certain series of games will yet again be revisited and hopefully this time I will get around to actually finishing the 5th and 6th instalments.

while I still think that ActionScript3 (Flash) is superior to HTML5, it is clear what direction things are heading in so I am thinking that now is the time to start focusing on HTML5. I am not sure how long JavaScript will last as the dominant web language. If the comities in charge of the language get their act together and create a better version of the language for the next iteration then it could last a while.

Loot Run Postmortem

While I did not particularly like the theme of Ludum Dare #26 as  it was far too general, I did have Saturday free to work on so I created a quick game. To me minimalism means eliminating all that is unnecessary. For games, this means graphics and sound. The idea is to focus on the essential gameplay. Loot Run is a platform game done entirely with text.

What Went Right

Keeping with the theme, I wanted to keep the gameplay as simple as possible while still being fun. While scrolling would have been easy to do, keeping levels limited to a single screen seemed to fit the theme better. The player needs an objective. Collecting money is a very obvious motivation and is something that most players can relate to.  Having just the environment as the obstacle did not seem like enough so monsters were added. While the original plans called for title, instructions, winning and about screens, it became obvious that these things could be integrated right into the game levels.

What was Both Right and Wrong

Using just text was the right decision, but in hindsight it would have been more efficient to use a canvas with the letters as a tile set. This would have resulted in a lot less garbage collection. While this had little impact on the game, knowing that all the needless garbage collection is happening does bother me. For those not familiar with JavaScript, let me briefly explain.

JavaScript strings are immutable. This means that every time you modify a string you are actually creating a new string and essentially dumping the old string onto the garbage heap. When there are enough dead strings lying about the garbage collector gets called and frees up the memory. As generating a frame results in numerous dead strings, this is not very efficient. It is kind of ironic that faking strings by using tile-maps would have been more efficient.

What went Wrong

The controls for the game were probably the biggest problem. The method I used was to track whether keys were up or down and during the main event loop adjusting the player based on the keys. For most games this would be fine but because I am only updating the frame every 150ms this can result in too big of a lag between the players key press and the processing. For instance, if a player hits up to jump and releases the key within the 150ms it is possible that the jump will be missed. What I should have done is had an array for next actions as well as key states. The next action would have been set as soon as a key was pressed, and every interval the actions would be ORed with the keys that are still down.

Pink unicorns

While I did successfully finish a prototype, I decided that it would be best not to release the game so instead of a postmortem this week, I am going to get on my soapbox. Feel free to skip the rest of this post.

I have noticed that there seems to be an ever-growing number of people who don't seem to know the difference between facts and beliefs. I have written the following to help shed light on this issue.

Let us say that I had an invisible rock. It is just a regular rock with no special properties other than being invisible. Let us say that I believed this invisible rock was an invisible rock. My beliefs would be correct but without evidence they would still be just beliefs.

Let us say that you believed my invisible rock was an invisible pink unicorn. Your beliefs would be wrong. If you got together a number of friends who also believed the invisible rock was an invisible pink unicorn, the invisible rock would still not be an invisible pink unicorn. No matter how much you believed that the invisible rock was an invisible pink unicorn it would not change the fact that the invisible rock was just an invisible rock and not an invisible pink unicorn.

Let us say that everybody in the world believed that the invisible rock was an invisible pink unicorn. That would still not change the fact that the invisible rock was just an invisible rock.

Without compelling evidence a belief is just an opinion. Compelling evidence should be focused, as blindly tested as possible, independently repeatable, and statistically significant.  Compelling evidence is sometimes hard to find and some things are simply not provable even if they may be true. If you can not back up your beliefs with evidence, then they are just your opinions.

In other words, when I say I think the invisible rock is an invisible rock, telling me that my denying the pink unicorn means that I am a follower of the nightmare and that will be denied from entering ponyville is probably not a very compelling argument. A rational response would be to provide evidence supporting your view. If the evidence doesn't exist (or worse, exists but doesn't support your beliefs) then the belief may need more scrutiny.

Whale of a Tale postmortem

Last week I released Whale of a Tale for Mini-Ludum Dare #41, so that means that it is time for my postmortem. I kind of like the right, right & wrong, wrong approach that I used for my last postmortem so think that is the format I will use for future postmortems.

What went right

Part of the reason for doing game jams is it lets you branch out and try something different with the only loss being a weekend. So when my first thought for this game was a combat game done underwater, I decided I didn't want the player to do anything violent, but the only blood in the game would be from the player or other innocent bystanders. I was thinking of sharks being hunted for their fins but sharks are vilified so didn't think the player would sympathise with one. Then I thought of a whale and the game immediately came together in my mind.

What went right and wrong

The game does need a bit more balancing. In theory more and more ships appear but I chose to go with a random spawn approach rather than a specific interval which makes the difficult ramp-up sporadic  Likewise, running out of energy only makes you move slowly so to emphasize the need to eat (and move into greater danger) I should probably have energy coming out of the player's health bar once the energy bar has been depleted.

What went wrong

A relative going into the hospital almost killed this game. Had this been a regular game jam it would have. Thankfully the lax rules allowed me to so I did the second day of work a few days later rather than consecutive days. The person doing my art simply didn't have the time to do all the art that was planned but enough of it was done that I am happy with the look. Still, a better ocean, moving clouds, fish that look like fish, animated waves, would have added to the look of the game.

Conclusion

I actually like this game so am thinking about putting it on my ever growing revisit list where I would spend another day or two fine-tuning the game and touching up the graphics. Not sure if this will happen but you never know.

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.

Lots of Jam

The next few weeks are going to be interesting as there are a bunch of game jams that I am thinking about participating in. The mini-Ludum Dare this weekend is a game based on the real world. I have a simple but interesting idea for this game. What I haven't decided is if I am going to do the game in Flash or in JavaScript. I do want to move away from Flash and towards HTML5 but I am far more productive in ActionScript.

Shortly after that is the Game in Ten Days #30. This is a longer duration challenge which actually puts me at a huge disadvantage. Clearling out a weekend is something that is easily done.  10 days, not so much. People who have 10 solid days to work on a project will clearly be able to do better than 10 part-time days so winning the prize is probably not remotely likely. Still, if the theme is interesting then it may be worth losing my weekends and evenings. Besides, I really should start trying to take advantage of Kongregate which is something I have never done.

After that challenge is another week-long one. As there is no prize other than a completed game there is no real disadvantage to working on it in my spare time. That said, my plans for this are not to create a new game but to create a JavaScript sequel to a Java game that I created. As a lot of the game logic exists, this should be fairly quick to implement, and I really do want to start porting all of my older Java games to HTML5 especially since there seem to be a lot of vulnerabilities with Java lately.

As I created a twitter account for the One Game a Month challenge, I will post frequent progress updates to my twitter feed, not that anybody actually cares. Still, I figure there may be somebody who does decided to follow me on twitter and if not I will have a record of my work for my personal use if I get around to writing postmortems on any of these challenges.