Schrodinger's Kitten Postmortem

My Ludum Dare 28 entry was a game-show style game involving kittens. As usual, here is the postmortem for that game.

What went right

Kittens. What? That's not a good enough explanation? When the theme was announced my first thought was "great, another theme that almost any game could meet with only minor changes." Then I started thinking of all the possible games and not only were there too many options to choose from but most of the ideas were too big for a weekend. With a need to narrow things down I went to One Game A Month and picked one of their three December themes. Kittens lead me to thinking about Schrödinger's cat which lead me to zombie kittens. Not entirely sure how this led to a Bayesian logic game but that is what came into my mind.

Mixed blessings

One of my biggest weaknesses is sound. Having a Gameshow theme allowed me to at least have sounds that I could actually handle. The results were not what I would call good, but neither was it overly bad. I did learn the importance of having a decent mike as my headset clearly does not qualify. The biggest issue was as I moved there would be clicking sounds caused by head-motions. I tried using audacity to remove the clicks but there were still some clicks that snuck through. Considering I had to use myself as voice talent, I don't think I did too bad. I tend to speak in a monotone so had to put effort into making sure that wasn't the case. I didn't quite get the Gameshow voice I wanted but I am not entirely sure what is wrong. I am thinking it is an issue with my delivery speed but I am not a sound guy so that is just a guess.

What went wrong

Time management was by far the biggest issue this time. Part of this was my fault as I really had a hard time getting into my programming groove so spent far too much time with distractions. Part of my time loss was the result of interruptions. Phone calls, relatives with computer problems, and neighbours that can't comprehend what a game jam is took up a good chunk of my time.  Considering the time of year, I suppose this is to be expected.

Overall, this was not too bad of a game but could have used a bit more graphical polish and a theme song. One of these days I am going to have to start playing with some of the music software I own. Then again, considering my sound skills, the world may be better off if I don't.

Game Making Glut

I am a coder. I like writing code. Probably too much. My biggest problem when it comes to coding is suffering from Not Invented Here syndrome.  This is when a programmer prefers to write his own code instead of using third-party libraries. There are a lot of really good low-cost (some even free) game engines and game-related libraries out there.  When it comes to cross-platform development, the big problem with developing your own cross-platform engine or library is testing. When each of the platform that you wish to support also has a wide variety of devices with different specs, it is clear that this is not a good idea for a one-to-three person team to attempt. Instead I am going to be looking at existing tools and engines to use for my cross-platform projects.  The list of platforms I am looking at is a lot larger than anticipated as I have acquired a lot of game making tools the last few weeks.

I found AGK  2.0 (App Game Kit) on Kickstarter a few months ago and should be getting a beta of this library fairly soon. This is an interesting tool as it comes with a BASIC language compiler as well as a C++ library so you can use either language. Their BASIC does not seem to have any Object Oriented extensions in it so I would probably only use it for rapid prototyping, with C++ being my development language. It supports a variety of platforms with Windows, OSX, Android and IOS on the list so clearly meets my needs. Once the beta is in my hands, I will be able to better decide but on paper this looks like a good choice.

While looking into AGK, I discovered  FPS Creator Reloaded as well as the original FPS Creator. As these came with a large number of free model packs, I figured I would grab them if only for the extra models. While Reloaded looks like a neat tool, especially if they use Lua as their scripting language, it is sadly Windows-only. For game-jams it might be a handy tool so I may end up playing around with it.

Unity is a very popular 3D engine. My focus is mostly on 2D so it seemed like this was overkill for my needs. Now that they have added 2D, it may be worthwhile looking at it. This is an expensive option, though they do have a free indie version which seems fairly capable. Scripting is in C# or JavaScript which is tolerable. While  technically this is probably a better choice than AGK, it is my second choice but I definitely want to play around with this.

The above is more than enough but the Steam autumn sale had RPG Maker XV Ace on sale for 75% off so I had to grab it. This is Windows-only but might be great for prototyping. Right after acquiring this, Humble-Bundle had a bundle that included Multimedia Fusion 2, a game maker I had never heard of but that has optional cross-platform support modules. Then there is Game-maker pro, but unless there is an extremely good deal on the masters bundle this is just not worthwhile for me but my experimentation with the free version showed me that this tool has a lot of power. These are just the tools that I have access to at the moment. There are many additional tools that are available to those willing to look for them.

Coin Drop Turbo postmortem

Just submitted my Charity Game Jam 2 entry so here is the postmortem.

What Went Right

While I seem to have no problem finishing weekend game jams, the same can not be said for the week-long jams that I enter. While I usually end up with a playable game,  the result is quite far from what I plan on. Figuring that the main reason for this is vastly over-estimating how much time I will have to work on the game, I took the approach of designing a game that I would do during a weekend jam and spending the extra time polishing the game. I would probably have spent a bit more time polishing had it not been for what went wrong. This proved to be fairly successful, especially considering that I missed a couple of evenings as well as had to watch the Doctor Who anniversary special and go to a CFL party. Had I gone with the game I was thinking about developing when the challenge was announced it would have been a total failure.

What Went Right and Wrong

Once I knew what the game was going to be, I had planned out a system for having different levels. This was based on the types of coins that were in the bank, the target goals, and the pig speed. This sort of worked, but was not as effective at controlling difficulty as I would have liked so the game is a lot easier than I had anticipated.  Had I not used real currency I could have had much closer point values for the different items that had to be collected that would have given me more control over the difficulty but that was not an option so the Loony and Toony kind of throw off the game balance. I suppose I could have gone with not using those coins but those are my two favorite coins. I suppose the lesson here is not to let your emotions get in your way of good design.

What Went Wrong

I should be polishing the game some more, perhaps fixing the difficulty issue by getting rid of the Twoony and replacing the Loony with a 50 cent coin but I am calling it a week due to Steam. This is also causing me to spend a lot more money than I should be. The worst part about Steam sales is that I already have a huge library of games so really have no need to buy more but the newer games that I want are on sale for a really good price so I end up caving in and buying some games and simply have to play them right away so I don't feel guilty for buying and then not playing them. Speaking of which, the game I just bought today has finished downloading so I had better finish writing this!

Jam Party

I keep hearing a lot of good things about Unity, but as I really don't have the resources necessary to develop 3D games and feel that using a full-blown 3D engine for creating 2D content to be the equivalent of using a chainsaw to slice bacon that I pretty much dismissed it. Now that the 4.3 release has 2D support, I am thinking that I might give it a try. The problem is that I really don't have the time to do that this week as the tiny amount of spare time I have will be put towards creating a game for the GameJolt jam. The following weekend is the second Charity Jam which, depending on the theme, I will probably want to participate in. I highly doubt that a few evenings during the week will be long enough to learn even the 2D portion of Unity, so I probably will not be doing anything with Unity until the December Ludum Dare event.

I missed the November Mini-Ludum Dare so when I went to combohub.org I spotted the GameJolt contest#10. I had never heard of it before so figured I would take a look. The theme of the challenge is Party, and when I think of parties I think of a group of adventurers going on a quest so have gone with the overly ambitious plan of creating a party-based RPG. The problem with longer duration jams is that it is far too easy to overreach. I have created a fairly simple RPG core for this game with the plans of using this core for the bases of a NES RPG.

I am fairly confident that I will have a playable game by the end of this weekend, the question is how polished the game will be. Sadly, I suspect the answer to this will not be the one I want. Still, I am quite impressed at how such a simple RPG engine can be as flexible as this one is turning out to be. In all honesty, I highly doubt I will be able to utilize all the potential for this game even if things go as smooth as I hope. If I am lucky, the Charity Game Jam 2 might have a theme that lets me use my RPG engine though I fear that CGJ2 will have "fighting game" theme and creating a game like Dust in a week is even too ambitious for me.

I am thinking, though have not decided for sure yet, of creating the NES RPG in this blog. Essentially, creating a series of articles about creating a home-brew NES game that covers the creation of this game. I really do want to create a NES RPG and this would give me the excuse to at least continue to slowly create such a beast.

Gamemaker

One thing I have noticed while participating in Game Jams is that there seem to be a lot of people using tools like Gamemaker to create their games. As Steam has a free version of it available, I figured that I would take it for a spin. The free version has a lot of restrictions on it, such as the number of sprites, sounds, and rooms that the game can contain so the free version is pretty limited but is enough to give you a taste for the tool.

While the idea behind Gamemaker is that you can create games without programming, this is not entirely true. Objects in the game support a number of events. When an event happens, it triggers a series of actions. While these actions are assembled through a drag-and-drop interface the actions are essentially function calls so the user is just programming in a simplified manner. The nice thing is that you can actually select a command that brings up a code editor and write C-like code to handle some more complex logic.

With the pro version supporting a native compiler option an support for a number of platforms such as iOS and Android, it seems like YoYo games is trying to attract more serious developers. The problem I have is that their editors are actually very primitive and from what I can tell, their tile support is very limited so for the bulk of the games I like to create there is very little this tool adds for the amount it would cost me.  Still, if there is a decent enough sale, I would probably consider buying it.

As it is free to try, I would recommend anybody looking for a simple to use 2D engine give this a brief look. It is a lot more powerful than I had expected. I could actually see it being good enough for a large variety of games. As a coder, however, the key reason I would buy a tool like this is for editors tied to a powerful scripting engine. As the editors are somewhat lacking, going with a cross-platform library and tools such as tiled is probably a better (and cheaper) bet.

Game Difficulty

As a byproduct of Steam trading cards, I have been playing a number of games to get the free trading cards and to make myself eligible for free card drops. As I  have a bad habit of buying lots of bundles due to the cheap price, there are a lot of games I haven't played. Some of them are games that I am not particularly interested in but as there was a game I wanted in the bundle the other games in  the bundle are "free" games. Getting trading cards have motivated me to at least try the game long enough to get the cards. I have heard that you don't even have to play the game but simply need to have the game running to get cards but I really don't see the point in doing that.

This has resulted in me realizing how poor a lot of game tutorials are. It also reminded me that if you can't quickly capture a player's interest in a game, you will probably lose that player as there are lots of games to play. The biggest obstacle to keeping a player playing is the difficulty of the game. I am not talking about how hard a game is, though that certainly is a factor, but how hard it is to figure out how to play a game. Far too often I have seen potentially great games overwhelm the player with far too many things all at once.  In some cases, such as 4X space games (eXplore, eXpand, eXploit, eXterminate) it is understandable that there is so much complexity as there are so many elements to the game. Even then, however, it should be possible to create a tutorial campaign that automatically handles the bulk of things for the player and slowly gives control of them back to the player as they work their way through the campaign.

This leads to the game-too-hard issue. It seems that far too many games seem to expect the player to have played similar games. The person who doesn't play these games all the time, or have never played that type of game before, are not going to have the skills or knowledge that a regular player of a genre has. Not allowing non-hardcore players into a game due to reliance on skills learned in other similar games only results in a genre shrinking and eventually dying. It is important to make a game accessible to newbies. The trick is figuring out a way to do this without boring the hardcore players.

Difficulty levels are one way, but far too often a easy level only gives the player  more health, it does nothing to ease players into the more complex game mechanics. Foe example, in a platformer have extra blocks that only appear on easy difficulty that prevent players from falling all the way to the beginning if they fail a more complex jump. If you have a section with a time-limit, perhaps the easy level should have a longer limit as people playing on easy probably aren't good at the precise jumping needed to reach the target in time. And any game with boss fights should probably give the player a way of bypassing the fight after the boss has trounced them a dozen or so times. I am sure some people are looking at my suggestions and saying "but games are too easy" without also noting that I am talking about games set to an easy difficulty level. People playing on an easy difficulty level are probably not that good at that type of game otherwise they would be playing the game on a harder difficulty level.

Of course there are cases of the opposite. Too much handholding is annoying, but I personally have never given up on a game because it has a tutorial that goes overboard. That said, if I am playing a game on a hard difficulty level, I probably don't need hints. Creating a tutorial that eases new players into a game while not being overly handholding for vetran players is a hard challenge that few games manage to do. Still, games like "Plants vs Zombies" and "Portal" prove that it is possible.

Treasure Run postmortem

As I mentioned the Mini-Ludum Dare last post, it should be no surprise that this fortnight is the postmortem of my efforts.

What Went Right

I love 65xx assembly language. It has been decades (damn, that makes me feel old) since I last used it yet the instruction set is so simple that I was back to programming it with very little effort. This would very likely not be the case for the Pentium line of processors in use today. I have yet to try writing ARM assembly language so that might be nicer. Still, I would recommend that anybody who wants to learn assembly language should probably start with the 6502 so they can learn the core concepts before going on to more modern processors. I know from experience that while the instruction set may not transfer, once you know one assembly language it is very easy to pick up other ones. I suppose one could argue that the Z80 is also fairly easy to learn and it has an instruction set that is closer to the Pentium one but my point would be to learn on a simple chip so you get the core concepts down before trying to take on modern behemoths.

Mixed Blessings

As those of you who read my previous post already know, I discovered that the NES worked quite different from the Commodore 64. The C64 shared memory with the VIC-II and the SID chips. You would simply write to a chunk of memory that the graphic chip accessed (this was flexible allowing you to place screen and tileset memory in which bank you wanted). The downside to this was that the more advanced graphics mode would eat up a lot of your available RAM. With the NES, the PPU has it's own memory which has to be set by going through a small number of port addresses. This is not overly difficult to work with, just different. Instead of copying data from one memory address to another, you simply set the high-low address in the port and then continually write data to another port as the address is automatically incremented for you. The lesson here is simply that different hardware is different.

What Went Wrong

My original game was going to be one large map that would take advantage of the NES scrolling hardware. The problem is that without using a memory manager, the scrolling is limited to only two pages aligned horizontally or vertically. I didn't want to get into memory managers for my first NES game so opted instead for single page maps. I am not sure this is that big of a loss, but I may have to experiment with memory managers in the future and create a larger map. I suppose what I could have done was keep my larger map idea and simply switch screens when the player walked off the edge of the screen but I never thought of that at the time.

Overall, I think learning a new platform and writing a game in assembly language in under a week is not that bad. I actually kind of like the NES so may play around some more with it taking advantage of Memory Managers for proper 4-screen scrolling and learning to use the sound chips. Of course, with so many other things I want to do, this may never happen but we will see.

Learning NES

This month's Mini-Ludum Dare has a theme of Low Level. The idea being that the game created should be created in a language like C so that the developer can learn something about how computers work. I figure the learning part is the key to this challenge so developing a game in C/C++ wouldn't really teach me anything. Then I thought about creating a game for a platform I haven't worked with before. This immediately got me thinking about the NES. I like 6502 assembly language so figured it would be a fun challenge.

The last few days I have spent my evenings researching the NES. There is a surprisingly large amount of info on it, most of it poor. I suppose this is not too big of a surprise considering that the big N didn't want anybody programming their platform without their blessing so most information was the result of  hobbyists digging into the system on their own and learning how it worked by disassembling existing games. There are some really good tutorials and tools available, but a lot of the stuff is old DOS tools. I ended up finding NESAsm for my 6502 assembler and YY-Chr for editing the 2-bit tile-based graphics.

I have put together a simple skeleton (a title-screen and gamepad controlled spite screen) that I will use as my starting code for this weekend. the link is http://blazinggames.com/gamejams/minild45/miniLD45.php and while it is far from the best assembly code I have written, it isn't too bad for first-project code.

The sad thing is that I was expecting it to be programmed more like the C64. With that you simply had a range of memory that the graphics unit used so simply wrote to that ram like it was regular memory. On the NES, the PPU's (Picture Processing Unit) memory is separate so you have a small number of addresses that you use to communicate with it. You set the address of PPU memory you want to write to by writing to a register with the hi then the lo (which is strange as the 6502 is lo-hi for addressing) then write or read from another register which increments the address that you are looking at.  The way colors are selected is also over-complicated. You have 4 palettes of 4 colors that are chosen from 64 colors. Sprites have another 4 sets of 4 palettes but each of the 64 sprites have their own choice of colors. For background tiles, 2x2 blocks share the same palette. This isn't overly convoluted, so to make things more confusing the attribute byte for selecting the palette is grouped in 2x2 blocks of the 2x2 tile blocks (which probably explains why mario seemed to be broken into 4x4 chunks of tiles).

The gamepads for me were the strangest thing. They have 8 buttons so you would assume you simply read a gamepad port and get back a byte with each bit being the state of a button. Nope. You first have to strobe an address to get the gamepad to start transmitting bits. You then have to read each of the 8 bits separately.

Even if I don't finish my game, I have certainly learned a lot from this challenge so consider it a success. If nothing else, it reminded me of how different similar-looking things can be.

Apple Harvest Postmortem

For the August Ludum Dare #27 I released a simple game called apple harvest. The game was simpler than I would have liked due to what went wrong but it was finished and isn't too bad of a game all things considered. Here is my postmortem of the game.

What went wrong

Unfortunately Ludum Dare #27 happened to take place the same weekend as one of my cousins' was getting married. This meant that instead of having 48 hours to work on a game I only had about 8. This greatly reduced both my options for what type of  games I could develop and the amount of polishing that could be applied to the game. As I really need to work on my polishing skills, this was disappointing.

What went right and wrong

I have been moving away from Flash preferring HTML 5 solutions as they do not require plug-ins. Right now my choice is to use Dart, but depending on what happens with ECMAScript 6 this could change. Still, when there is a limited amount of time, Flash is a bit faster to work with. Part of the reason that Flash is more efficient is simply due to the fact that the art/animation tools are built right in so you are not switching between multiple tools and writing code to load the various assets into the game as that is all handled automatically for you. While I would have preferred a HTML 5 solution, using Flash allowed me to finish the game at a relatively reasonable time so I wasn't overly tired for the Wedding.

What went right

The first thought that I had when I read the theme was a money booth type game. The kind radio shows like to have where you have a short amount of time to grab as much money as you can. Playing around with air dynamics would have been great fun but probably would have taken me more than 8 hours so I had to apply a  Keep It Super Simple approach. I replaced harvesting money with apples. Why apples? I wanted some type of motion to the harvesting and falling apples is what came into my head so I just went with it. The apple life cycle was fairly simple with a flower, then a growing green fruit then a transition to a mature fruit. The transitions had a per-frame probability of  happening adding a slight random element.  Spawning new blossoms was also easy as I just pick a random spot on the trees. If there are no apples near enough then it takes otherwise, no spawning happens that frame. The simple artwork for the apple also got co-opted into the buttons for the menus.

Conclusion

For a very rapid game I think it turned out good. If I do revisit the game I would add multiple levels with quotas per level, and possibly different types of fruit trees.

7DFPS 2013 Postmortem

The 7DFPS 2013 challenge is over. Since the first game-jam that I ever entered was the original 7DFPS, I felt that even though I was only going to be able to put in around 40 hours towards a game that I would still try and get an entry this year. Moon Base Z chapter 1 is my entry. It is in a lot rougher state than I would hope but is a fully playable game. As usual, here is my postmortem for the challenge.

What went right

I quickly came up with a story for the game but almost immediately realized that the story was way too ambitious for a week. This gave me two options: break up the story into chapters and just focus on getting the first chapter done for the challenge or re-work the story so it can fit. As much as I wanted a complete stand-alone game for the challenge, going with the chapter route would not only allow me to finish a playable level, but would give me months of extra time to properly create the game I jotted down. Seeing how I barely managed to get a single chapter finished, this clearly was the correct choice.

What went both right and wrong

As people who have been following this blog already know, I am getting heavy into using Dart as my web programming language. The decision to use Dart was actually a good one as I find myself far more productive using Dart than JavaScript. The plan to port my earlier 7DFPS engine to Dart, however, took far longer than I had anticipated. What is intersting, is that some of the bugs I was looking into in CQFPS were clearly marked as errors or warnings once the code was ported over. I find I am really enjoying Dart as a language, even with its idiosyncrasies and really hope that the language does take off.

What went wrong

I was going to get help with the artwork for the game. Sadly other things happened making it impossible for my artist to contribute directly to this game. Instead I had to cut-and-paste existing artwork and create new artwork.  I also did not have the time to experiment with HTML5 sound, which is something I really need to do.

Conclusion

Overall not as good of a showing as I would like, but the game is far from finished. As I finish off the remaining 3 chapters I do hope that the resulting game will be much better than this first chapter indicates. My plans are to release each chapter as a beta each independently playable. Once all the chapters are out, I will do a final reworking of all the levels and combine it into a single game. I have no timeframe for doing this but do hope that it is sooner rather than later.

Steam Trading Cards

I have been thinking about the Steam Trading Cards quite a bit lately as my free evenings have been spent playing games in order to collect the free card drops for games that have trading cards. I have received quite a few cards and have been selling the duplicates on the steam marketplace. Overall, I think it was an interesting marketing idea but at it's current implementation is a flawed system. As a programmer, I am use to debugging things so figured I would debug the Steam trading card system. Unfortunately, I do not work at Valve so my thoughts will lead to nothing but the exceeding remote chance that someone at Valve will somehow read this post and agree with my opinions.

Marketing wise, I am not sure that the addition of trading cards will actually sway any purchasing decisions very much for most people. That said, interest in the game generated by people playing the game more to gather trading cards will lead other people to buy the game so from an extended sales perspective this system could be potentially valuable. Unfortunately, due to the way the system is designed, it does not really do this but instead focuses on making commission profit from the marketplace. Why do I say this, well lets look at how the cards work.

There are a set of cards for a game, the number of cards varies but I have seen 5 to 15 Half that number of cards are earned by card drops from simply playing the game. This is the brilliant part of the scheme as poorer players earn stuff simply for playing which encourages them to play. There is the problem of people simply running the game and not actually playing it, but I don't consider it a real problem as the vast majority of people will actually play the game. Once the player has earned the drops from the game, they need to trade with other people, buy cards from the market, or wait for booster packs. Booster packs are only eligible to people who have used all their drops. This actually is a good idea. The problem is that the booster packs gives you cards immediately instead of adding more card drops. This means that once you have received all the card drops you never have to play the game again. This means that instead of encouraging players to play games longer and benefit from the word-of-mouth sales from people continuing to play older games, they are only making a few cents of commission from the marketplace when people sell cards.

The obvious solution is to make booster packs card drops. Still, I am not sure this is the best solution. Getting free cards is really nice and encourages people to continually log on to Steam which could lead to more sales. A much better solution is to keep the random booster packs, but also to give people an extra drop each week capped at the half-the-cards limit. People with drops would no longer be eligible for booster packs which would encourage players to play the older games keeping the communities for those games more active and resulting in more sales. While this would mean more people would earn badges, it would also mean more people trading cards on the market so the market commission profit would not go away plus there would be more sales of trading-card related games.

Such a very simple change would actually make the trading card scheme interesting instead of resulting in people simply playing games to gather the trading cards then not bothering with that game anymore.

Metal Galaxy Postmortem

I am a few days late with this blog post as I decided to wait and see if I participated in the 7DRTS before writing it. Due to other obligations I was not able to spend a week, or for that matter evenings during the week, to work on the 7DRTS challenge but having worked out a simplified 4X game in my mind I wanted to give it a go. This is not that game but hints at what I had in mind are all throughout this postmortem. The game was posted on Ludum Dare, but is going to be August 2nd Blazing Games release. For those who don't want to wait a few days, here is the link to the page so you can try the game out right now. http://blazinggames.com/gamejams/minild44/miniLD44.php

What Went Right

In addition to the Mini-Ludum Dare theme of 7DRTS, I decided even before I started that I would try and incorporate the One Game a Month theme of Metal into whatever game I designed. Massive space fleets battling each other on a galactic map fit this theme but when I had to reduce my scope as it was probably not realistic, fitting that theme into colonizing planets was a bit trickier. Coming up with the amount of metal different stars have affecting the production rate worked really well as it definitely determines which strategies are most effective. The most effective strategy is focusing on heavy metal stars but bottlenecking the opponent by taking advantage of the 10 light-year limit is also effective.

What Went Right and Wrong

When I first heard of the RTS component of the challenge, my first thought was a galactic conquest game with a focus on fleets. As I only had a couple of the seven days this wasn't possible, at least not the way I had in mind. While playing with my galaxy generation code I added code to detect clicking on stars and making sure that a star was within 10 light years of a star the player already owns. This is when I realized that a race to colonize the galaxy is ultimately what the game is about and by eliminating the combat it becomes easy to finish the game over the weekend. Of course, by not having any type of production choices, or fleet dynamics, the strategy element of the game is significantly reduced. My what went right added a bit of strategy back to the game so while still simple on the strategy level, the game is fun and fairly quick to play.

What Went Wrong

As was already mentioned, the original plans for this game was to be a strategic space combat game so I spent time working out a simplified fleet management system. Had there been a full week to work on this game I have no doubts that I would have been able to pull this off. As it was, after spending a few hours of putting together some basic fleet management code, I quickly realized that the game simply was too large for a weekend so scrapped the code. Except that I still want to do the original game. Yet another game in my ever growing list of projects. Ah well.

Creating NIM

When you look at the tag-based syntax that make up a HTML page, it is fairly clear that the format was designed more for static documents rather than interactive games. What you can do with pure HTML is rather limited. To get the interactivity necessary for all but the simplest of games, an additional programming language is need. This can take the form of the scripting language JavaScript which is built into all the major browsers. There are a number of other languages, such as Dart, that compile to JavaScript that can also be used but compiling to JavaScript is not quite the same as writing in JavaScript.

When I got a trollish email saying that JavaScript is not part of HTML5, which is only true on the most purest level, I decided to create a simple game using only HTML. A number of the tags that HTML5 added are clearly designed for use with a scripting language so to utilize HTML5 you really need to utilize a scripting language. Now if the email was complaining about WebGL, I would not have considered it a troll but still hope that Microsoft does start supporting it (as the rumours suggest).

The first problem that needs to be overcome when creating a no-script HTML game is finding a game that is simple enough to implement using only the markup language. This essentially means that the game needs to be representable using static pages with the interactive element switching between pages. While this is a huge restriction,  I actually came up with a number of games that could be created using a number of static pages. These include 3D mazes,  path choosing adventure games, combination puzzles, restricted move games such as Tower of Hanoi, and many of the various NIM style math games. Obviously I chose NIM.

The game must be broken into a number of pages. If we go with the traditional 17 objects, then we will need 17 pages for the player landing zones.  The problem is that the computer needs to make a move. There are at least two ways to deal with this. The obvious solution is to add an additional 16 pages for the computer moves. When you think about it, the only thing that happens during the computer move is that the number of objects it is going to take is revealed so the only thing the player is doing is clicking to continue. While merging the computer results with the landing page adds a slight bit of complexity, it cuts the number of pages necessary in half.

The easiest way of implementing the game is to create the 17 item page, clone it, remove an item and repeat until all 17 pages have been created. A slightly faster, though more complex way of doing this would be to write a script to generate the pages for you. Each page simply consists of images and  links to the lower-numbered three pages so this is really simple to create.  That really is all there is to it. Sorry for boring you this week.

Binary Prerequisites

I recently released an educational game where you play with logic gates. The inspiration for the game came from a JavaScript book that didn't even bother covering logical operations. Logic operations are used to manipulate bytes at the per-bit level making them very useful for optimizing the memory-footprint of data structures. Now that everyone has multiple gigabytes of RAM in their computers, optimizing memory is not as high of priority anymore even if it is fairly easy to do. Instead of preaching about this, I am instead going to give an example of its use and the non-boolean-logic alternative.

For a number of games under development, I have a skill system where players select their bonus skills. Many of the skills have prerequisites. Each skill gets assigned a bit within  an integer (if there were more than 32 bits, more than one integer could be used, though for me this isn't an issue as skills are grouped into set that contain 16 skills so only 16 bits are needed). Each skill record has an integer for prerequisites. The character class has an integer for each skill set indicating what skills are known. To see if a skill can be learned, a simple logical AND can be done on the prerequisite and the characters skill set. If the result equals the prerequisite, the skill can be learned.

This can be done without binary logic operators by using an array of booleans.  Checking prerequisites the becomes a bit more complicated. First, a meets-prerequisites flag is set to true. A for loop looping through the prerequisites array  checks if the corresponding skill flag is set. If it is set, the array of skills in the character sheet then gets checked. If the character sheet skill is false, the meets-prerequisites flag is set to false and the for loop is exited.

As many languages use integers to represent Boolean variables, this is a potential  waste of 31 bits. In our example, this would be a memory increase of 16 times the amount. Some compilers have optimizations for memory use in which case the compressing of the bits into a single integer will be done by the compiler, but even in that case the compiler will still have to use the looping code for checking prerequisites with the rather significant speed difference as a result. Of course, in addition to having lots of memory, computers also are very fast now so such concerns can be overlooked. But as writing the code to be efficient in the first place is so easy there really is no excuse for such a waste of memory and CPU cycles.

Thoughts on Dart

I have mixed feelings on the new languages that compile to JavaScript such as Dart and CoffeeScript. The problem with these languages is that by producing JavaScript there are people who seem to think they are creating JavaScript projects when they are not. It is possible to take the JavaScript output and edit it as if it were a JavaScript program, but unless those changes are also done in the language source code, those changes are either not part of the project or make the project much harder to maintain. This effectively means that once you start a project in one of these languages you pretty much have to stick with the language. This is not necessarily a bad thing but it does reduce the number of people who can use the source code.

Dart is a bit different from other languages that compile to JavaScript. The compiling to JavaScript is a backwards-compatibility feature designed to allow programs written in Dart to work on browsers that do not support the Dart language. The idea is that eventually browsers will start supporting Dart as one of their script-tag languages. The dart programs then would be run using their native JIT-compiler resulting in better performance. Right now there are not any browsers that support Dart, but Chrome is going to soon as the Dart SDK includes a beta-build of Chrome that has Dart support.

When Dart was first released, I briefly looked at the language but decided I would wait for the 1.0 release before trying it. A Google IO presentation on the language got my curiosity peaked and when I discovered StageXL (which like the CreateJS library is modelled after the Flash API that I am familiar with) I decided that the JavaScript issues I was having with CreateJS might be solved if I used Dart and StageXL. This in fact was the case so I have decided that I will be using Dart to port my Ultimate Retro Project to HTML5.

The Dart language is a proper Object-Oriented language with optional type support. All the type-related issues I have with JavaScript are gone and having proper classes makes working with code great.  My favourite feature surprisingly was the switch statement. Dart requires that each case statement within the switch block has a break, continue or  return statement making the issue of accidentally forgetting a break statement a thing of the past. This is one of my pet-peeves with all the C-like languages so discovering this feature made my day.

While I am still new to the Dart language, I suspect that by the end of the Ultimate Retro Project port I will be close to an expert with Dart. If like me you are coming to JavaScript from real programming languages, Dart may be the solution.  I will be continuing my discussion of Dart as I continue to work on my port, but as this is a side project I am not sure how quick the work will proceed. Perhaps by the end of the project I will have changed my mind, but my current impressions of Dart are exceedingly positive so there will have to be major issues to make me change my mind about the language.

Towels for Earth Postmortem

As a fan of Douglas Adams since I was a kid, there was very little chance of me not partaking the Towel Day Mini-Ludum Dare. I find it really interesting that Mini-Ludum Dare#42 happened to occur just in time for Towel Day but as Douglas Adams has repeatedly said "42 seems to show up a lot." For those not familiar with The Hitchhikers Guide to the Galaxy, 42 is an important number as it happens to be the answer to "life, the universe, and everything". I decided to take the challenge a bit further and make it a Towel Day challenge instead of a weekend challenge. Here is my postmortem.

What Went Right

Making Towel Day an important part of the project was my personal goal of this challenge. Technically, the theme was "Earth will be Destroyed" to make the challenge accessible to those sad souls who are not Douglas Adams fans.  I managed to incorporate the reason Earth is being destroyed, a two headed alien, adding nutrient enrichment to a towel, towels and 42 . Not too bad for a rushed project.

What Went Right and Wrong

The decision to create the game on towel day was a mixed blessing. A game jam is short enough without artificial restrictions. In this case there simply wasn't enough time to add sound and other minor gameplay enhancements such as an unlimited mode. Time limits and other restrictions do help build creativity and let you refine your skills so the extra self-imposed restrictions are useful. To be perfectly honest, though, the real reason for the extra restrictions were the emotions related to creating a game on Towel Day.

What Went Wrong

When I first heard about the challenge, my plans were to create the game using HTML5. I figured that work porting my GameJam library would be useful as it would make it easier to finish the game in time. As creating the functionality of the Flash libraries in JavaScript would be a lot of work, taking advantage of the existing CreateJS library seemed like a good plan. From my experience with this library, it works great but it is still in development. When I ran into issues with the event handling, it became clear that rethinking the jam plans was in order. While I think these issues are JavaScript issues related to the way I am creating classes, they could be CreateJS bugs or some  other code issues I am unaware of so the time needed to solve or work-around the issues was too random to chance it. With not enough time to solve the issues I resorted to my Plan B and created the game in Flash.

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. 

CRA Agent Postmortem

David S. Gallant was fired for the dreadful sin of creating a game about his job. Ludum Dare decided to host a game jam related to this. I created my CRA Agent game as part of this CRAJam. Now I am writing my postmortem about the development of this game.

What went right.

I had a very clear vision of the game I wanted to make. Having clear and realistic goals made getting the game done fairly quickly. The fact that the game was fairly simple from a coding perspective was a bonus. While I had hoped to have the adventure game kit portion of my GameJam library ready, it simply was too far from completion to contemplate using it which may have been a blessing as I probably would have spent far more time working on my generic adventure game library than on the game.

One big change from my original plan did occur, which is why it is always good to have some flexibility with your designs. Instead of the single inevitable ending I was planning for, I decided that the underlying score systems could be tweaked to allow for three different endings based on how the player plays. It actually didn't take very long to tweak the numbers and I think the game benefited from this change. It is still a short game that can be finished in a couple of minutes but now it has enough replay-ability that it allows more exploration of the theme.

What went wrong

Politics. I hate politics so having a politically themed game was certainly an issue for me. While I think my political opinions can be discerned from this game, some of the decisions that the player could take clearly went against my beliefs. I think I handled both cases with enough humour that the game should be enjoyable even by people with differing opinions than mine, but the fact that politics happens to be one of those subjects that invoke strong irrational emotions from people I am sure I have pissed some people off.

Too much art.  Instead of creating unique art for the agent, the 8 people being audited, and the boss, I may have been better off creating a face-making program that would generate a huge number of faces based on a small number of art pieces. I could have then spent more time creating text for people being audited which would have added a lot more content to the game.

Conclusion

I think even though this game is likely to piss some people off, it turned out pretty good.

Mini-Ludum Dare #39 Postmortem

The theme for this challenge was Hindsight. A chance to redo a challenge or to partake in a challenge that was missed. While there are a lot of Ludum Dare's that I missed, so I had a lot of choices, a redo of the previous challenge was my immediate thought. While my last game was not a bad game, it was not the game that I wanted to do with that theme but with a school shooting taking place right before the challenge I simply couldn't bring myself to create an overly violent game. Interestingly enough, there was another shooting a couple of days ago so it is a good thing that I took on this challenge when I did or I may never have created Zombie Forever. The goal of the game is to form a zombie army by enlisting all the campers near your secret lair. As usual, now that the game has been released, here is the mini-postmortem.

What went right

Even though the Mini challenges have very lax rules, I try to treat them like a regular challenge. When offered help with the art, I decided that it would be acceptable to go with a Jam entry. The extra time, having someone else handle some of the art and ability to use existing art really helped me get quite a bit done. I  may have to take the Jam option with some of the future Ludum Dare challenges. At least in cases where the theme is one I can interest other people in joining me.

While I suppose the second point is a subjective one, I really think I got the feel of building a zombie army. I think slowing down as the zombie takes damage really adds to the feel of being a zombie. Likewise, when you have a large number of zombies slogging toward your next victim,  it has that zombie hoard feel.

What went wrong

The downside to switching to the Jam format is that having more time and help means that more can be accomplished which means that my  over-ambitious tendencies have a chance to surface. My original plans called for three levels and 9 character types. I would have been better off just focusing on the secret base and having just the zombie, scientist, and security guards. Still, I do plan on finishing the extra game levels so the original design will eventually see the light of day.

The AI also ended up taking more time than anticipated. Working on the AI resulted in one of the most humorous bugs I have had. The random walk state originally would only check the map tile in the direction it was heading to make sure the character could enter the tile. When the desired moved was passed to the game core, it would interpret an attempt to enter an occupied tile as an attack on that character. The best part was not only would humans attack other humans, but if they killed that human, the victim would become a zombie!

Conclusion

I know that there are a lot of people who don't like turn-based strategy games, but I personally really like them. I am planning on releasing an additional two maps, and if the game proves to be popular would consider doing a sequel game with more abilities and challenges.

2013 Plans

I am sure that anybody who regularly reads this blog already has a good idea what my plans for 2013 are, but I figure I should go over them anyway for the record. While I was originally planning on developing Color Collapse Plus over the year, that was before I actually started participating in game jams. I may still work on that project as it was my mothers favorite game, but my priority for 2013 will be on a number of larger commercial projects. As I want to have regular content for the site, I am planning on participating in game jams such as Ludum Dare. The games developed during these challenges will make up the bulk of the site game releases, with the remaining releases being updates of already existing games until I actually finish one of my larger projects.

My larger projects will be targeted towards tablets and possibly smart-phones. The target platforms will be iOS and Android, though I may also port to Windows 8 tablets/phones if the effort will not be too great. Once the tablet releases are done, I intend on porting the game to the browser (probably Flash but HTML 5 isn't inconceivable). The browser versions will be broken into a number of episodes and released in installments.

My game jam work will initially be done in Flash but as my GameJam library reaches maturity (hopefully by this summer) I will port it to HTML 5 and transition to using that if the performance is adequate. While ActionScript and JavaScript are very similar, I am just way more comfortable with ActionScript as it has language constructs that make it much nicer for working with larger-scale projects. Still, JavaScript is quickly becoming the language of the web, though a lot slower than the experts predicted. I personally think Flash will be viable for at least another 3-5 years. If Adobe gets their head out of their butt and create an ActionScript to JavaScript compiler it may be significantly longer though the resulting Flash programs would be "native" HTML 5. Sadly I suspect that Adobe will let Flash whither away and instead try to turn their new Edge Animate software into the replacement for Flash.

I have not decided which games I will be updating, so if anybody reading this feel free to email me with your favorite game and I will put that game on the top of my update list. Updating will include cosmetic updating as well as (for Java and Flash games) porting the game to HTML 5.