Flash Image Atlas Animation System. Why?

This was suppose to be posted on Sunday, but with my mother going into the hospital, I kind of forgot about posting it. Sorry for the delay.

As part of my larger project, I have decided to develop my own animation system. As this larger project is currently being done in Flash, which is essentially an animation system with a powerful programming language tacked on to it, this may seem redundant. If I knew for sure that the project was going to be exclusively done in Flash, it would be. The truth is that I may end up having to port the game to other devices. While Flash is sort of runnable on portable devices, the performance currently isn't quite there. If, when my game is in a near finished state, the game runs fine on the target devices then there is no issue. However, this is not necessarily going to be the case so I have been looking into what would be involved in porting a game by creating a native version for certain devices.

OpenGL ES is pretty much the standard for all the devices I am thinking about targeting. While studying OpenGL one common optimization that comes highly recommended is to combine the textures that one is using into something called an image atlas. As it turns out, an image atlas is a more advanced version of image strips (aka sprite strips) and image grids (aka image sheets or sprite sheets). Image strips/sheets are what I was using for my Java games so I am well versed in the technique.

A lot of the artwork for my larger-scale game is bitmap graphics so  creating a library that allows for an image atlas to drive an animation would be convenient and make porting easier. Spending a development week or two to get this functionality is really not much of a loss while the benefits are potentially great. I define a development week to be 40 hours which is a typical work week in Canada. As my work on the large scale game is part time, it may take two or three weeks in real world time for a development week. I plan on porting it to HTML 5 and possibly other platforms. Not too long ago I created a simple image atlas class for my HTML 5 JavaScript graphics library so an HTML 5 port so the HTML 5 version should be fairly quick to develop. This will give me a common set of components that will make it much easier to switch between platforms. While I personally believe that Flash will be around for a while, having an easy path to other platforms doesn't hurt.

In fact, with Microsoft not supporting Web GL in IE 9, any web-based will have to use a plug-in such as the upcoming Flash 11 to support 3D graphics in a cross-platform way. While Microsoft is claiming security issues (WebGL is fundementally far more secure than Microsoft's Active X which is still in IE), I hear that in Windows 8 there will be browser support for accessing Direct X 11. Since Direct X is essentially a less-secure version of Open GL (what WebGL is based on) I am wondering what Microsoft's true motivations for not supporting WebGL are. Still, I see the future of 3D on the web being Flash. Ideally it will be a WebGL with fallback to Flash future but more likely it will be just Flash with paid iOS apps for Apple users. Thanks Microsoft.

Thoughts on Forever

I am going to delay my series of articles on the creation of episode 3 of Dozen Days of Tiles for a couple of weeks so I can touch on a couple of other topics. The big news in computer gaming (and to a lesser extent video gaming) circles is the release of Duke Nukem Forever (DNF). The reviews have been more negative than positive. Some of the negative reviews are negative because of the games play mechanics and other game play issues. These are fine and I consider them valid criticism. Other reviewers are those people that incorrectly think the game should be better because it took so long to develop. These people annoy me because the development time for DNF has nothing to do with its quality. There are a large number of reasons for this, but lets just look at the top three reasons.

First of all, the number of years a project is in development is not related to the development years of a project. A development year is one person working full time on a project for a year. If I spend 4 years working on a game and a team of 4 perfectly coordinated developers worked 1 year on the same type of game, the amount of time spent developing the two games is the same. My game should not be better because it took 4 times as long to develop because it didn't. Therefore, looking at the development time of a game strictly based on the number of years it has been in development is just stupid.

Second, the game changed game engines and major subsystems multiple times during development. This is not something that can be considered lightly as porting code from one platform to another is going to take a good chunk of time. In some cases, you may even need to spend a good chunk of time to recreate functionality if the features of the new engine are different. This is why very few games change their underlying engine mid-stream.

Finally, a huge part of the repeated delays of the game was a result of playing catchup. Many programmers, myself included, have worked on projects that have a moving goalpost. What happens is that you have your initial specifications and you work hard to reach these. Months before reaching the goal there is a review of the project and the big-wig decides that things have changed so new specifications are created requiring major changes to the existing code so the project is delayed and just before the project is finished, the big-wig shows up again and ... repeat until either the big-wig or the project (or both) are dead. DNF was clearly caught in the trap of trying to stay ahead of the game market. Every time it started getting near completion, enough time had passed that the game was no longer meeting the cutting edge requirements of management so the game would be delayed to allow time to catch up with the rest of the industry.

This is similar to what has happened with my Coffee Quest 5 project, the difference being that CQ5 has not been in development for all this time. My problem with CQ5 was more of a wanting a browser based game that would be able to use technology that simply was not available in browsers. The few times I did start on the project, it was quickly put on ice again as the technology simply wasn't there. While there were some Java 3D libraries, they simply did not work well within the browser as I discovered when a huge number of people had issues running CQGL. I had considered porting Coffee Quest to Flash and use PaperVision, but found that it had issues and  Flash Player 10 was going to have some limited 3D support. So I waited for Flash Player 10 only to discover that the 3D effects had major sorting issues. Now  there is the upcoming Mole-Hill version of Flash in beta as well as Web GL so the possibility of finally developing CQ5 is in my mind again.

Had I not had unrealistic expectations for the speed of browser development, I probably would have just enhanced my existing ray-caster or possibly even developed a simple software 3D library and released CQ5 many years ago. Sadly, I had Hardware 3D in the back of my mind and CQ5 ended up on the back-burner as I waited for Adobe or browser venders to finally put proper 3D into browsers. Something that really should have happened a decade ago but still hasn't happened.

While DNF may suck, I wonder how much of it has to do with overly high expectations and how much has to do with poor game play. I won't know the answer to that question until I see a copy of DNF in the bargain bin, as going by the reviewers I trust the game is not worth full price (and probably not worth bargain bin prices either but I am curious).

DDTe3 Hour 1 Planning and the Puzzle Model

For the third episode of Dozen Days of Tiles, my series where I develop games with a particular theme in under 24 hours of development time, I decided to twist the concept of developing a game in a day and instead trying to develop as many games as I can within the 24 hours. I know that while the work is done in 24 hours, because the work is spread out over multiple days, it is not the same as if I did the work in a single day. Having done the Dozen Days of Dice series as game in a day stints, I know that after twelve hours of coding the mind starts working against you. That said, finding a solid day to work on something is increasingly more difficult and can be easily interrupted even if such a rare block of time can be found. I also want to document my experience in the form of these blog posts. I do not count the time I spend writing these posts towards the 24 hours but I am trying to write the posts shortly after I put in a programming stint so the thought process at the time is preserved.

Part of the reason for the desire to create multiple games for this episode is directly related to the return of a weekly format for Blazing Games. While the weekly format is more iterative than it has been in the past, allowing for games to evolve into more complex games over time, I still prefer having a buffer of material so that if a larger third-party project interrupts my site work, the schedule will not need to be adjusted.

Creating multiple games in a 24 hour period leaves the question what set of games are tile related, and have similar enough game mechanics that the work on one can be utilized in allowing the related games to be created. At the same time, I am looking at some of the older games on the Blazing Games site and am trying to figure out what should be done with them. The Flash games can be enhanced as Flash is going to be around for a while yet. The Java games, sadly, are in a more precarious position so consideration should be made towards porting them to HTML5. Looking at some of the Java games that I have done, I noticed my picture puzzle series of games. These are simple enough games that I don't need to port the games at all but can instead re-write them from scratch without loosing that much time. In fact, with all the knowledge that I have gained over the years, I should be able to get the core picture puzzle game functional very quickly.

With the game in mind, it is time to start on the project. While having a client-model-view architecture is probably a bit of overkill for this series, it doesn't hurt so I will start by creating the model. This class is being called BasePuzzleModel in the project.

The model creates a two-dimensional array to hold the grid. In JavaScript, 2D arrays are created by making an array of arrays. The model could have also simply created a single array the size of the width times the height of the grid and mathematically determined the position of the tile. I chose to go with the the two-dimensional approach because that way the internal structure of the grid more closely matches the problem being solved. Still, as the tiles are then assigned linear values to represent their proper position, in hindsight going with a single dimensional array would have been easier and just as logical. As I write this, I am only 6 hours into the project and could change things but as the internal structure of the model is theoretically hidden from the classes that use it there would be no point changing it.

As briefly explained in the paragraph above, each tile is assigned an index value that is linear based on the row and column. The index is equal to the row * the width of the puzzle plus the column. By having the linear sequence of tile values, it is possible to easily determine if the puzzle is correct by simply seeing if the tiles are in order. Some simple convenience functions were created for manipulating the puzzle and within an hour we have the model up and running. The functions added were getPuzzlePiece(x,y), setPuzzlePiece(x,y, n), swapPuzzlePieces(x1,y1,x2,y2), scrambleBoard() and checkWin(). These are all fairly straightforward so I won’t delve into the details of these.

The next phase is to turn the model into something visible. The obvious class for this job would be something called the BasePuzzleView, which we will look at next week.

DDTe2 hours 16 to 17 Infinite Loop Bug

This is the final installment of my making of Dozen Days of Tiles episode 2. At this point in time, the game has been created but a showstopper bug has been discovered.

Finding bugs is never nice, but the very nature of programming makes bugs pretty much an inevitable thing. Bugs are often the result of a very minor mistake, such as was the case with this bug. Thankfully, with tools such as FireBug available, finding the cause of the bug was very easy. By being able to stop the program while it was in an infinite loop allowed me to take a look at the puzzle data at the time the infinite loop was happening which is where I discovered that the puzzle generation would occasionally result in a puzzle that had invalid data in it.

The solution to this problem was to add a sanity check to the fifth phase of the puzzle generation. Instead of simply returning the finished puzzle, phase 5 added the following puzzle verification checking code:

           var cntrRow, cntrCol;
      done = true; // assume valid until proven otherwise
           for (cntrRow = 1; cntrRow < 10; ++cntrRow)
                   for (cntrCol = 1; cntrCol < 10; ++cntrCol)
                           if (this._model.getValue(cntrRow, cntrCol) == 0)
                                   done = false;
           if ( ! done )
               this._phase = 1;
 
Problem solved. Many programmers would consider their job done. Good programmers, and those who want to become good programmers, know that there is still a bug in the code. This is when a serious look at the puzzle generation phases happens. I like to try and work through what the code is doing to find puzzles, though certainly walking through the code using breakpoints and stepping over/through statements will work.

As I worked through the code in my head, the problem hit me like a flying brick. What a dumb mistake! Setting the phase back to 1 when there is an error is fine, but for some reason, I also set it to the next phase if the row is valid. The next phase change should not happen until after all three rows in the phase have been successfully completed. When I wrote the code I was thinking that I was at the end of the generation, not just the end of the loop. A simple mistake, but that is all it takes.

What was happening was that the first or second row would not be able to generate a valid combination that would work with the puzzle. The loop would continue and if the last row was able to generate a valid combination then the next phase would be triggered. The real bug fix, then, is to take the next phase setting out of the row loop (which it shouldn’t have been in to begin with) and only go to the next phase if the phase has not been set to 1. Likewise, because there may be more iterations in the row loop, when the puzzle is invalid, the row loop should be broken out of.

The problem solved means that the project is finished. For the next episode, I am considering putting a twist on the game in a day challenge. Instead of developing a game in under 24 hours (development time not real time) I am going to instead see how many games I can create in under 24 hours.