Saturday, December 25, 2010

Merry Christmas

This is the time of year when  things are the most hectic so I apologize for the lack of progress in Dozen Days of Tiles. I will continue the series next week and plan on releasing the first episode on Blazing Games in March. I am only going to create half the episodes as 2012 will be devoted to a 12 part game. Yes, the end of the world is overused but I want to do a series around that theme anyways. Besides, Alein the Alien has been idle too long.

Merry Christmas (or whatever else you celebrate) and have a happy new year everyone.

Sunday, December 12, 2010

DDTe1 Hour 2 to 4 - Tiles

Creating the tiles necessary for sudoku seems like a simple enough process. After all, only 10 tiles are needed. However, the check mark note system needs to be incorporated into this as well as the hint system. This makes the task a bit harder to accomplish. My decision was to got with 40 tiles. 10 for normal (blue), ten for incorrect (red) ten for correct (green) and 10 for locked (black). I am also considering an additional ten for locked but incorrect but for now am not going to bother with this but may do so later if time permits.

The easiest way of implementing the tiles would be to use text. This would not have the visual impact that I want so instead the ImageLayer class will be taken advantage of to create to display bitmap tiles that can be made as fancy as desired. The tiles were quickly created in fireworks using a nice marble image for the backdrop. This image was created quickly but may be touched up a bit later. Likewise, it will be easy to replace numbers with other symbols if so desired.

Next, the Sudoku.Tile class was created. This holds the state of the tile, the current value of the tile, if the tile is locked, and two arrays of 10 representing the state of the checkboxes. While I could use 9, because all the labelling starts at 1 I figured it would be less confusing to me to have element 0 being unused and elements 1 through 9 representing the actual number. A ImageLayer is used to draw the tile and 9 additional (small) image layers are used to represent the notes.

The combination of the two sets of numbers determine which color to set the note tiles to, if they are displayed. The decision to show them or not is dependent on the value that the tile is set to. If this is a non-zero value, the hint tiles are all made invisible. Otherwise, visibility and color get determined by the two check arrays.

The  next step is to actually make it possible to set the notes and value for tiles. There are no built in user interface components in the HTML 5 canvas so I am going to have to either roll my own or use HTML markup outside of the canvas to handle things. This decision will be the topic for the next post.

Sunday, December 5, 2010

DDTe1 Hour 1 - Planning

As tempting as it was to take the day off and play Recettear, work has finally begun on Dozen Days of Tiles. I happen to be a big fan of the Sudoku puzzles that appear in the free paper that is delivered here so while solving the puzzle in todays paper thoughts of how to create my own sudoku player game started coming to mind. I grabbed a piece of graph paper and spent about an hour planning out the game. This is probably more time than I usually spend planning out a small game such as this. Usually scratches on scrap paper is what my planning for small games consists of. Larger projects, especially when multiple people are involved, require much more planning but a game that can be finished in under 24 hours of development time shouldn't need much planning otherwise you may be too ambitious with your plans. As I am separating the player from the puzzle generator I am hoping that I am not being too ambitious with this project but we will know for sure soon enough.

Even before starting on this project, I had decided to separate the generator from the player. The reason for this is that clearly the generation of random sudoku puzzles is going to be a difficult enough task on its own without the requirement of having a player component as well. The player should be designed so it can easily accept the puzzles generated from the generator, have other puzzles (hand created or from third parties), and even a blank puzzle so the player can be used for playing puzzles from a newspaper without the user having to create some type of data file.

As a player of the game myself, the requirement that I have, one which the computer sudoku games that I have seen often fail at, is being able to easily mark up the blank tiles. I tend to write the possible numbers down and if it is clear that some numbers must belong to one or two tiles (required by a row or column, for example) will underline those numbers.  My thoughts would be to solve this by having a notes block that appears for the currently selected tile. If the tile is empty then the notes will appear as mini-tiles within that tile.

Here is the planned layout for my sudoku player. I think it is clear enough how it will be used, but I am biased. The next step is to start creating the basic tile class which will probably take a few hours.

Sunday, November 28, 2010

Recettear

My original plans for this weekend were to start working on the first episode of Dozen Days of Tiles. I still am up in the air as whether I should start with my Mah Jongg effort or if Sudoku would be the better starting project. Sadly, neither have been started as Steam has their Thanksgiving sale going on and one of the games on sale (92% off) was an indie story pack that contained a game I wanted. Since the pack was less than the cost of the single game, I grabbed the pack and a game called Recettear caught my eye. It was different enough that I figured I would install it on my windows machine and try it out for a few hours. The game was so enjoyable that I am writing this post about it since it ate up my DDT time.

You play the game as a young girl named Recette. Your father ran off to become an adventurer and left you in debt. To pay off your debt, the fairy Tear is helping you turn your house into a store. Because the town you live in is a haven for adventurers, it is an item shop. While you can buy items wholesale, the fun of the game comes from hiring adventurers and then going into a dungeon to "acquire" the items so you can sell them for a 100% profit.

The game is surprisingly addictive. The only real complaint that I have about the game so far is the weekly payment. It is a skewed payment scheme where the first payment is 10000, the second 30000, the third 80000, the fourth 200000 and a final payment that I haven't seen yet but from the progression would guess 500000. While the idea here from a designers perspective is to keep the game challenging, I think the game would have been more enjoyable if the debt could be paid off at a slower pace. When I screwed up and was not able to make the 200000 payment, I discovered that instead of having to go back to an earlier save and replay the week the game would automatically restart you on day 2 but with all your stock and experience. Still, I think a better approach would have been to tie the expansion of the store to the debt. As each chunk of debt was paid off (minimum payment perhaps but small enough so game could be played leisurely) a store upgrade would start causing the loan to start again.

Still, for a low cost indie game, this is quite a fun title. My recommendation, however, is not to start on this game if you have other things to do as like many strategy games this game has a one-more-turn syndrome that causes hours to mysteriously vanish into the game.

Sunday, November 14, 2010

DDT project starting

A few years ago I started the Dozen Days Pentalogy. This was planned to be a set of 5 series of a dozen small games. Each game in the series would be developed in a day. I originally started this project after hearing about a game in a day competition. As a lot of the games on Blazing Games were developed with  a very short time-frame, this seemed right up my ally. The first series of games were developed in Flash and actually done in a day. This was not very easy to schedule and things like family problems made it harder for me to justify locking myself up for a day. For that reason, the second series was set up to be a maximum development time of 24 hours which could be spread out so I could work on it whenever I had a few hours to spare. This was done in Flex, which is a more code oriented variant of Flash (it produces the same swf files that Flash does) as I felt it was more open to being open-sourced as the tools were freely available while Flash Professional is very expensive. The last two episodes of the second season, however, were my attempt at moving to HTML 5.

It is now time for me to start on the third series of games. The remaining categories that I plan on covering are Tiles, Cards, and Board. All three are interesting and are the type of games that should be able to be created in a short period of time. Still, my current interest in Sudoku and Mah-Jongg means that I have decided that the third series is going to be tile-based games.

There are going to be a few changes on how I create these games. First, I am going to use my BGLayers library and develop the game using HTML 5 (no big surprise here). Second, while the time limit will be 24 hours, this will only apply to work on the code. As I finish up a block of work on a project, I plan on writing a detailed post about the work. The time spent writing these articles will not count towards the time-limit of the game. I will, essentially, be developing the game "live on the Blazing Games Development Blog" though may get a few weeks ahead of the articles if I am on a roll and can put the time in. Finally, some of the games may be broken into two or three separate games. For instance, Sudoku will have a player project which will be separate from a generator project.

I hope the few of you who actually read this will find this interesting.

Sunday, November 7, 2010

Animating the Canvas part 10: Cleaning up the Dirt

Creating a library is a bit different type of programming than normal application creation. When you are creating a class for an application, the only thing you have to be concerned about is that it meets the needs of your application. When creating a library, you have the extra burden that not only must your class do what it is suppose to do but it has to be flexible enough and bullet proof enough to be used by other people who are unrelated to your project.  Lack of protected and private variables, as well as the namespace issues, makes creating a library in JavaScript more challenging. My goal today is to go over BGLayers and try to clean it up so it will be useful to others. At this point I highly doubt anybody is actually using my library (other than myself) so I don't have to worry about backwards compatibility. The biggest part of this effort will be to make protected variables more obvious so other programmers will know when they are messing with a variable they shouldn't be. From my brief examination of other JavaScript projects, I have noticed that the underscore is often used to indicate a protected variable. This is common enough and the underscore is distinct enough that it should be adequate to act as a warning to people wanting to modify variables directly. It's not the best solution but it is easy enough of a change.

The Dimension and Point classes don't have any changes necessary. The Rectangle class does have a bit of confusion in it. The contains function is for points while the containsRect is for rectangles. This could be confusing and result in someone using contains with a rectangle parameter and never getting proper results back. To eliminate this possible problem, I am changing contains to containsPoint. To make it even friendlier, both of the contains functions will take advantage of different parameter sets so point and rectangle objects can be passed to the respective functions as well as raw coordinates.

The layers class is where we have a lot of variables that should be private. The logical size of the layer is used to determine the real position so changing it outside of the class will not be noticed resulting in incorrect results. As there currently is no way of altering this, a changeSize function will be created. The logical position variable is similar, but already has multiple functions that modify it so the only new function needed here is a getPosition function. The real position, children and dirty rectangle variables are already adequately handled with functions. The solid variable, on the other hand, is really layer dependent and should not even be seen by the user. Visibility, though, is important so a setVisible function will be added. The only variables left "visible" to the user then are the background color and id. I suppose changing the background color should force a redraw so I will add a setBackgroundColor function and make it protected as well.

Finally, for the ImageLayer class, both the clip and image variables should probably be protected. I debated if it was wise to allow changing the image but ultimately decided there was little harm in allowing it so a setImage function has been added.

With this bit of cleaning up, I think that BGLayers is good enough for now. Certainly, as I am using the library internally, it will have enhancements added to it over time so expect the occasional article about new features in the future. As for future posts, I want to focus on the creation of games so have decided that this blog will be used as a detailed journal for the development of a number of future BlazingGames.com games. More on that next week. The source for the BGLayers library can be found at http://www.blazinggames.com/other/openLibrary/html5Libs.

Monday, November 1, 2010

Animating the Canvas part 9: Getting Dirty Quicker

When I was first starting to learn to program, I was told three steps to follow in order to create good programs. The first step is to get your program running. The second step is to get it running correctly. The final step, which is often not needed, is to get it running fast. In the old days (the 1990's) programmers were more concerned with speed (100MHz was fast!) so a lot of programmers would optimize their code before the program was even running. Often, the optimizations used would make their code messier making it harder to actually get the program running correctly or at all.

The big trick to optimizing is simply the knowledge that in the normal course of running only a small percentage of the code being ran is responsible for the bulk of the time. If you can find the parts of your program that most of the executing time is taking place in, you can optimize those areas and gain a fair bit of speed. Tools like FireBug make this very easy as they have tools that do the tracking for you.

Once you know what code needs to be fixed, the key question becomes how to speed it up. My advice would be to learn Assembly language (aka Machine code). While you may never need to use it, which is unfortunate as it is great fun to code in, knowing what the machine is actually doing at a low level will give you a much greater appreciation for what is going on with your program. Another technique, which I don't do as much as I should, is to simply use the debugger to single step through the function in question. This can give you a huge insight into what is going on.

BGLayers have two parts that need focus on. First, is the adding of dirty rectangles. Next is the rendering of things. The addDirty function is relatively minor CPU wise, but during my discovery at how poor Canvas Clipping is I noticed a lot of Rectangles were being created needlessly and wanted to reduce this.  Creating a new instance of an object has some overhead to it so avoiding doing so will speed things up. Right at the start of addDirty, a new instance of a rectangle is created. This was done to support null parameters which add the entire layer, but when you consider that the function will call the same function until the parent is reached, this can be very inefficient.

The problem is that a new instance of the rectangle passed has to be created as it has to be altered to assure it is pixel aligned. While this alteration is minor but could muck up the rectangle if it is used by unrelated parts of the program. When we start clipping the dirty rectangle we use recursion to call the function causing many unnecessary rectangles to be created. The solution is to eliminate the recursion. This is easily done by simply having an array with a list of rectangles that need to be clipped. Initially there is only the initial rectangle in this list. If it is clipped, new rectangles get added to the list instead of having to call addDirty. This eliminates the recursion.

With these simple but major changes, the program is run and no noticeable difference in run time. Well, at least I know there will be less garbage collection. My point about not optimizing where there is no need has proven itself as I wasted almost an hour for no gain. Still, I am happier with the code as recursion has been eliminated making the code nicer.

Next, we try to speed up the part that is taking up over two-thirds of the cycles in my tests. Namely the draw self function. This again leads me back to ancient times (the 90's) when the big bugaboo in graphics programming was  drawing pixels multiple times per frame. In those times, accelerated graphics cards were hit or miss and accessing video memory was costly. Things have changed today but eliminating unnecessary drawing is still a good idea. In fact, this was planned from the beginning and is why there is a solid variable to let the renderer know if a layer is solid. Anything underneath a solid layer is not going to be seen so if the portion being drawn is contained within the solid layer, only that layer and any layers above it need to be drawn. This is done in the render function, which the drawSelf function is called from. The rendering code has been changed to only call drawSelf if no solid layers contain the bounds being rendered.

    for (cntr = this.children.length - 1; cntr >= 0; --cntr) {
        if ((this.children[cntr].solid) && (this.children[cntr].findRealPosition().containsRect(bounds))) {
            startDraw = cntr;
            break;
        }
    }
    if (startDraw == -1) {
        this.drawSelf(ctx, bounds);
        startDraw = 0;
    }
    for (cntr = startDraw; cntr < this.children.length; ++cntr)
        this.children[cntr].render(ctx, bounds);

That simple change has a drastic effect on performance. DrawSelf now accounts for less than half of the drawing time. The next step will be to make the API friendlier. The code for this post is located at http://www.blazinggames.com/other/openLibrary/html5Libs.

Sunday, October 24, 2010

Getting old

With my birthday a few days ago and other things coming up to steal whatever spare time I had, there was simply no time to get to the optimisation and cleaning up of BGLayers. As middle aged programmers are treated the same way as the elderly I wonder if I have the right to blame my age for not finishing part 9? To be honest, I don't understand the trend to hire younger programmers. While they may be more willing to put in overtime, their lack of experience means that things that would take me a few hours to write will take them a few weeks. Still, I hope to have the next part ready for next week, and since Tarot is using this code and is being released next month I have extra incentive to find the time to get the work done.

Sunday, October 17, 2010

Animating the Canvas part 8: Splitting Image

Right now the library is good at drawing solid blocks. To be useful, however, better image support is needed. The one class that would make this library sufficient for the creation of games, which is the goal of this after all, would be an image layer that had support for image strips and image grids. Better yet, an image atlas since image strips and image grids are a subset of an image atlas. This is actually very simple to do.

An image atlas, for those who are not familiar with the term, is simply just a large image that contains smaller images. The idea here is that instead of dealing with a large number of image files, you instead only need to load one image and show portions of that image. This speeds up loading as you only need to request a single file instead of having to request multiple files from the server. It is also commonly used with 3D rendering but that is beyond the scope of this series.

What makes this class so easy to create is simply the fact that it inherits most of its functionality from the Layer class. JavaScript does not currently have support for subclasses so I make use of the inheritProperties function that was created earlier. As it is likely that the image layer will be used to display an entire image, the constructor simply contains the image to use. The portion of the image used is set to the entire image, though this can be changed any time allowing this class to be used as an image atlas.

BGLayers.ImageLayer = function(id, image)
{
    this.supr = new BGLayers.Layer(id, image.width, image.height);
    BGLayers.inheritProperties(this, this.supr);
   
    this.clip = new BGLayers.Rectangle(0,0, image.width, image.height);
    this.image = image;
}

To set the particular portion of the image that should be displayed, the setClip function sets the new portion of the image to be shown. This can be used for animation by simply having a strip or grid of frames and altering the portion being shown every frame.

BGLayers.ImageLayer.prototype.setClip = function(rect)
{
    this.clip.x = rect.x;
    this.clip.y = rect.y;
    this.clip.width = rect.width;
    this.clip.height = rect.height;
    this.addDirty(null);
}

The hard part comes with the drawing as the portion of the image within the clipping bounds. This has to be calculated. This is done in a similar way to the calculation of the real layer position but using the clipping portion of the image. In theory it is possible to just set the canvas clipping region and draw the whole image, but I have had some issues with clipping so figure it is safest to avoid clipping whenever possible. Besides, relying on clipping makes the assumption that the canvas implementation is actually efficiently written where as manually drawing just the clip guarantees that the minimum amount of drawing is being done.

BGLayers.ImageLayer.prototype.drawSelf = function(ctx, bounds)
{
    if (this.findRealPosition().intersects(bounds) == false)
        return;
    var rect = this.realPosition.getIntersection(bounds);
    var scaleX = this.clip.width / this.realPosition.width;
    var scaleY = this.clip.height / this.realPosition.height;
    var boundClip = new BGLayers.Rectangle(
                this.clip.x + (rect.x - this.realPosition.x) * scaleX,
                this.clip.y + (rect.y - this.realPosition.y) * scaleY,
                rect.width * scaleX,
                rect.height * scaleY);
    ctx.drawImage(this.image, boundClip.x, boundClip.y, boundClip.width, boundClip.height,
                rect.x, rect.y, rect.width, rect.height);
}

And that is all that is needed. Creating a new layer is that simple. The atlas functionality of this class should be adequate for most uses so already this library is useful. Still, while doing some debugging on my Tarot project, stepping through the drawing of things did help me notice a lot of inefficiencies in how the library works so I am planning on having an optimization pass. I also want to do a bit of fine tuning to the library to make it clearer what variables are private, even though JavaScript does not support private variables. I may be renaming some things and adding some functionality so there is no need to access private variables. If something is clearly private and somebody modifies it anyway breaking their program it is their problem.

Sunday, October 10, 2010

Animating the Canvas part 7: Dirty Knives

I forgot to mention last week that the source code for parts 6 though 8 is located at http://www.blazinggames.com/other/openLibrary/html5Libs. It is time to start dealing with overlap. This will all be handled by the addDirty function which adds a dirty rectangle to the list of dirty rectangles. As before, this function adds dirty rectangles to the root layer. This time, however, an additional three steps have been added to this process.

The first step is simply to go through the existing list and make sure that the rectangle to be added isn't already in the list. By in the list, we are checking to see if there is a rectangle in the dirty rectangle list that covers the rectangle being added. If there is, our work is done and we can return from the function. This code is simply a traversal of the dirty rectangle list with a call to a rectangle function called containsRect.

ContainsRect is a simple function that simply checks to see if a passed rectangle is contained within the rectangle. This is simply done by seeing if the top left corner is in the bounds of the rectangle. If it is then a check is made to see if the bottom right corner is in the rectangle. If it is, then the rectangle is contained.

If the first step does not eliminate the dirty rectangle, then a second pass through the dirty rectangle list is made. This time, we are seeing if the new dirty rectangle covers some of the rectangles in the list. If it does, those rectangles can be removed from the list. This is why having the ability to remove nodes from the dirty rectangle list is important.

The third part is a really large chunk of code which is a bit too big to dump here so if my explanation is not good enough please review the code. This pass is where we make sure that the dirty rectangle doesn't overlap other rectangles in the list of dirty rectangles. If there is an overlap, the rectangle gets split. The check to find an overlap is simply a traversal of the dirty rectangle list with the traversal being stopped if an overlap is detected.

        var overlap = null;
        nextDirty = this.dirtyList.nxt;
        while (nextDirty != null) {
            var bounds = nextDirty.rect;
            if (dirty.rect.intersects(bounds)) {
                overlap = bounds;
                nextDirty = null;
            } else
                nextDirty = nextDirty.nxt;
        }

If there is an overlap, the goal then becomes to divide the dirty rectangle. First, we see if there is overlap on the left side. If there is, we create a new rectangle that contains the left portion of the dirty rectangle up to the start of the overlap. This rectangle gets sent to the addDirty function so that it gets processed as there may be other overlaps that cause it to be split up further.

The dirty rectangle is then resized to have the dimensions without the sliced portion. At this point we check to see if there is a right overlap. If there is the rectangle is again sliced and addDirty is called for processing the right portion of the rectangle.

The same procedure is done for the top and bottom portions of the rectangle. However, with the bottom portion we do not need to adjust the size of the dirty rectangle because it will be contained by the overlap and can be discarded.

We now have the functioning dirty rectangle system I originally planned. Next week I will actually implement a custom image layer class. After that, I will either conclude this series and start work on a game or will optimise the code. I will decide next week.

Sunday, October 3, 2010

Animating the Canvas part 6: Linking Dirty Rectangles

While the code we have created so far is usable, the big problem with it is that there is a lot of redrawing as dirty rectangles may overlap each other. If you are dealing with only a small number of objects then this may not be a big deal. Still, my original plan was to subdivide dirty rectangles to eliminate overlap. As I started preparing to write the code to deal with this it became clear that arrays were not the ideal mechanism for dealing with this problem. Instead, I needed a linked list. My JavaScript reference has no mention of any type of linked list class in the standard library so I am going to create my own simple doubly linked list class. This is dirty-rectangle specific class right now though I see no reason why this couldn't be modified and extended to create a general purpose class if such a thing was desired.

Linked lists are a useful concept. They simply are a list of objects with each object in the list pointing to the next object in the list. The advantage this offers is that there is no size limits, it is easy to transverse from start to end, and objects can be easily inserted in the middle of the list. Removing an item from the list isn't difficult but does require knowledge of the previous item. Arrays contain splice and slice functions to do this, but these are problematic and probably extremely inefficient. I say probably because it would depend on how the arrays were implemented.

A linked list would probably suffice for my needs, but as one of the key things I need to do is remove objects from the middle of the list, a doubly linked list would be much more convenient. This is the same as a linked list but instead of just pointing to the next object in the list, they also point to the previous object. This means that no knowledge of other items in the list are needed to remove an item.

The creation of an element in the linked list is simple enough. It is, after all, just references to three objects. In the case of our dirty rectangle class, this is the rectangle that is dirty, the previous node and the next node. The nodes are set to null initially with null being used to determine the beginning and end of the list.

BGLayers.DirtyRect = function(rect)
{
    this.rect = new BGLayers.Rectangle(rect);
    this.prev = null;
    this.nxt = null;
}

Having a node is fine but by itself it is not that useful. To be useful, the node has to be added to a list. Adding to a list only requires a node to the list in which the item is being added to. A node can only belong to one list at a time so it will remove itself from any existing list. The node from the list that this node is being added to will be considered the previous element in the list. As the previous item in the list may already have a next item, the first step then is to take the previous node next element and make it the added nodes next element. The node being added to the list then becomes the next node for the previous node. Likewise, the previous node is the added nodes previous entry. At this point everything is correct with this node, but the next node is not pointing to the added node so if the next node is not null, its previous entry will have to be changed to the added node.

BGLayers.DirtyRect.prototype.addSelf = function(parent)
{
    if ( (this.prev != null) || (this.nxt != null) )
        this.removeSelf();
    this.prev = parent;
    this.nxt = parent.nxt;
    if (this.nxt != null)
        this.nxt.prev = this;
    parent.nxt = this;
}

Removing a node is actually very easy. If the previous node is not null, it's next node becomes the removed nodes next entry. Likewise, if the next node is not null then it's previous entry becomes the removed nodes previous entry. Finally, the previous and next entries for the removed node are set to null so that it is clear that this node is not part of a list.

BGLayers.DirtyRect.prototype.removeSelf = function()
{
    if (this.prev != null) {
        this.prev.nxt = this.nxt;
    }
    if (this.nxt != null)
        this.nxt.prev = this.prev;
    this.prev = null;
    this.nxt = null;   
}

Some implementations of linked lists will have a separate class for manipulating nodes which also controls the root node. If you were going to expand on my linked list code this would be a good idea. For BGLayers, I am simply creating a root node which is not an active part of the list. This is not the best solution but it is very easy to do and doesn't require more classes be written. I might do this for a future version of this library as I am starting to think it is the proper thing to do.

Traversing the list is very simple. My implementation of renderDirty is a good demonstration of doing this. It simply grabs the first real node from the root node and then uses a while loop to continue through the list while the next element is not null. If the list is empty, the root nodes next will be null causing the while loop to exit  immediately. Of course, the loop processes the dirty rectangles by calling render, and then removes the node from the list so the list will be empty at the end of this function.

BGLayers.Layer.prototype.renderDirty = function(ctx)
{
    var nextDirty = this.dirtyList.nxt;
    while (nextDirty != null) {
        var bounds = nextDirty.rect;
        this.render(ctx, bounds);
        var curDirty = nextDirty;
        nextDirty = curDirty.nxt;
        curDirty.removeSelf();
    }
}

Now that we have the dirty rectangle doubly linked list class functioning, next time we will get to the fun part of splitting rectangles.

Sunday, September 26, 2010

A Break for Bugs

I am going to delay the planned installment of Animating the Canvas this week. While I have made a lot of progress on the code and thought that I had the rest of this series finished, when using the code within my Tarot project, some bugs were uncovered. While I could continue the series anyway, as the planned topic for today would not have been related to the issue at hand, I have decided instead to take a brief break and discus testing.

Testing and debugging are an important part of programming. The testing requirements largely depend on the project. Being old-school, I tend to use my brain to do the bulk of my debugging. I try and think like the computer to figure out where the problem is and then isolate and solve the problem. I find this approach much faster than the second level of debugging, namely using a debugger. Firefox, thankfully, has an incredible debugger called firebug. Apple has pretty much cloned this tool for Safari. Still, as someone who uses multiple operating systems, I like the fact that Firefox is everywhere so tend to use that browser for my preliminary testing. Single stepping through a program can be very time-consuming but for some bugs it is a necessity.

The big trend now is something called unit testing. It is an approach that is really good and is something that I should be doing more of but as most my projects are small I don't. The idea here is that you write your tests before you write your code. The tests are usually written using some type of testing framework in mind. Because the tests are all automated, you simply need to run the tests before checking in code. The advantage to using this technique is that you know when you are done as all of your tests are successful. For game development, this is only a partial solution. You can test the subsystems that make up the game, but are still going to need human testing for a lot of the testing.

While unit testing is not the silver bullet a lot of people think, the automated tests do help you make progress if you have written them. If you have not and are debugging things, unit tests can still prove useful. Once you have isolated a bug, or started writing testing code to help find the bug, you will have automated tests that make sure you do not re-introduce the bug in the future. While I am sure there are countless JavaScript testing frameworks available, creating one is very simple. Here is the one I wrote after discovering my issues with the BGLayers library I am writing:

function addTestResult(group, desc, result)
{
    var testTable = document.getElementById('testTable');
    var rRow = testTable.insertRow(1);
    var resText;
    if ( result)
        resText = 'Test Passed';
    else
        resText = 'Test Failed';
    rRow.innerHTML = ''+group+''+desc+''+resText+'';
}

Yes, I could have searched out a much better one online, but was simply too lazy to. My own "framework" only took a few minutes to write. I am sure that as I continue to focus more on writing JavaScript, especially as I start larger projects,  finding a better library for unit testing will make sense. For now, my simple test function is adequate for my needs.

Sunday, September 19, 2010

Animating the Canvas part 5: Layers of Paint

Last week we covered the positioning of layers and how to get the real position of the layer. This week we are actually going to draw. To make this class very easy to extend, the drawing of the layer is broken into two separate functions. The drawSelf function simply draws the contents of the layer. No care is given to any children the layer may have. By doing this, we can isolate the drawing of the layer (if any) from dealing with children. This function takes a bounds parameter which indicates which portion of the layer needs to be drawn. The function first looks to see if the bounds that are being drawn are actually part of this layer. This is done by adding a new function to the Rectangle class:  intersects(rect). This is a very simple function that tests if two rectangles intersect with each other. Still, a lot of people seem to find the test confusing so lets go over it in detail:

First we want to make sure that the passed rectangle  is not left of the class rectangle. This is done by taking the class rectangles' x2 coordinate and comparing it to the passed rectangles' x coordinate. If x is greater than x2 is then obviously there can be no overlap so the condition will fail.
    if ( (this.x < (rect.x + rect.width)) &&

Next, we know that the passed rectangle is not to left of the class rectangle so we are now seeing if it is to the right of the rectangle. This can be done by seeing if the class rectangles' x2 coordinate is greater than the passed rectangles' x coordinate.
            ( (this.x + this.width) > rect.x) &&

At this point we know that there is potentially intersection along the x axis so we now need to examine the y axis. This is essentially the same as above except we are checking for top and bottom instead of left and right.

            (this.y < (rect.y + rect.height)) &&
            ( (this.y + this.height) > rect.y) )
        return true;
    else
        return false;

If there is some overlap, we want to get that overlap so a getIntersection function is added to the rectangle to perform this task. It is simply the interior most bounds so no detailed explanation should be necessary.

Once we know what portion needs to be drawn, we simply draws a rectangle in the colour that is contained in the backgroundColor property. Overridden classes may need to do more work to figure out what needs to be drawn and to insure that things are drawn within the clip, you may actually need to formalize the bounds by using canvas clipping operations. It may be a good idea to set a clipping region no matter what as the browser probably has very efficient clipping support so there should be very little overhead.

The other function used for drawing is the render function. This is a very simple function that simply calls the drawSelf function passing the bounds it was passed and then calls the render function for all of the children that belong to this layer.

There is one additional function for painting the display. The renderDirty function is a convenience function that simply calls render for each rectangle in the list of dirty rectangles.  This function will be discussed in a later part as while have a functional system right now, the dirty rectangle management needs to be overhauled to eliminate overlap. We will be starting on this work in the next part.

Sunday, September 12, 2010

Animating the Canvas part 4: Laying out Layers

As I am partially writing these classes for use with November's Tarot release, I am a lot further in the code than I would be if I was just working on this code Sunday afternoons (which is the plan for this blog from now on). I have been packaging up the source as it has reached logical development points but it will be a while before this series of articles catches up with the work. The source code is located at http://www.blazinggames.com/other/openLibrary/html5Libs.

With primitives started it is now time to get to the real code and start implementing the layers class. This class will be a base class for all of the other elements that get added to the canvas. The problem with this is that JavaScript does not currently support superclasses or inheritance. This is something that may come to a future version of JavaScript (ECMAScript version 6 unless it gets delayed like it did when such features were in ECMAScript version 4) but for now we have to manually perform the inheritance. While some browsers support a technique known as prototype chaining by exposing the __proto__ property, this is not always the case so manually copying the properties must be done for browser compatibility. A simple function can handle this making creating subclasses much easier, though at a bit of cost in efficiency and memory.

BGLayers.inheritProperties = function(child, supr)
{
    for (var property in supr) { 
        if (typeof child[property] == "undefined") 
            child[property] = supr[property]; 
    } 
}

The layers are loosely based on the layer classes that I created for Dozen Days of Words Episode 12: Morse Code but with the addition of dirty rectangle support and switching from absolute positions to relative positioning. Relative positioning adds a lot more flexibility for animation as any given layer only has to worry about it's position relative to it's parent. For this reason, a layer can be created with a width and a height which can, with the exception of the root (stage) layer, be any size as scaling will be done when the component is rendered onto the canvas.

The logical and real positions of the layer is dependent on the parent. This means that there should only be a single parent for a layer, though layers can have multiple children.  This means that when you add a child to a layer, that child is being assigned a new parent. If it already has a parent that parent is told that the child is being removed and the new parent becomes the parent. The addChild, removeChild, and setParent functions handle all this work. Note that these functions take advantage of the addDirty function to let the old and new parents know which part of the display has changed.

The addDirty function handles our dirty rectangle list, but at the moment is far from complete as I was more concerned with getting the code functional. Currently the addDirty function simply adds the dirty rectangle, expressed in real canvas coordinates, to the root layer. The root layer is simply the layer which does not have a parent. To find the layer, the parent is called until there is no parent. Right now no effort is being made to cull the list to eliminate overdrawing. This feature will be added in the future.

While for internal work the real size and location of the layer is not that important, for marking dirty rectangles and rendering them knowing the real location becomes vital. This is where the findRealPosition function comes into play. As this is such an important function, lets go over it in detail.

First, to speed things up, we don't want to constantly re-calculate this so we have a flag that lets us know if the real position is known and if so, we return the already calculated position. This means that when the logical position or parent layer position changes the flag has to be set to false so when the final code is put together the logical position information may be marked protected (sadly, there is no such thing as protected variables in JavaScript yet, so we have to go on the honour system).

    if (this.realPositionKnown)
        return this.realPosition;

If this is the root layer then it's logical position and size are the real thing. If it is not, then we need to get the real thing by getting the parent's real position by calling this function on the parent. If the parent is not the root layer it will call it's parent and so on until the real position can be determined.

    var parentPos = this.logicalPosition;
    var w = this.logicalSize.width;
    var h = this.logicalSize.height;
    if (this.parent != null) {
        parentPos = this.parent.findRealPosition();
        w = this.parent.logicalSize.width;
        h = this.parent.logicalSize.height;
    }

Knowing the real position of the parent then gives us the information we need to find our real position. This is done by determining how big we are logically compared to how big of an area we are in our parent's eyes. This results in scaling factors.

    var scaleX = parentPos.width / w;
    var scaleY = parentPos.height / h;

With the scaling factors known, we can simply calculate the position by multiplying the logical coordinates by the scale and adding the parent's position.

    this.realPosition.x = parentPos.x + this.logicalPosition.x * scaleX;
    this.realPosition.y = parentPos.y + this.logicalPosition.y * scaleY;
    this.realPosition.width = this.logicalPosition.width * scaleX;
    this.realPosition.height = this.logicalPosition.height * scaleY;
    this.realPositionKnown = true;
    return this.realPosition;

Now we know where to draw things, the next step is to actually implement the rendering  of things which we will do next week.

Sunday, September 5, 2010

Animating the Canvas Part 3: Getting Primitive

Before I get to the actual article, I will briefly point out that Dozen Days of Words episode 12: Morse Code has been posted on the site and while I never had the time to get dirty rectangles implemented in it, it does use a primitive layers system. In fact, if you are running it on Internet Explorer using excanvas you can visibly see how dirty rectangles could dramatically improve things. This is not noticeable on browsers that support the canvas tag.

As is often the case, before we can get to the good stuff, we need to build the foundation. As this project is going to require a bunch of classes and JavaScript, at least current implementations of it, is not really designed for such a thing we need to think about the best way of handling classes. Everything in JavaScript is thrown into a global namespace which can lead to problems. Looking at how other JavaScript libraries have handled the problem, I am going to follow the same route and put all my classes into a single object which is essentially equivalent to packages in Java or ActionScript.

This is actually very easy to do and to my surprise, it poses no problems for using the prototype variable in class creation. The one disadvantage to this technique is that you are putting the entire library into the package. Two ways around this is to break the library up into separate files that can be individually included, or to use a utility like Google's closure compiler. Setting up the package is simple:

var BGLayers = new Object();

With the "package" set up, it is time to get some of the primitives out of the way. The obvious most primitive graphic objects are the point and dimension. Both of these classes are essentially just structures but they are handy to have.

BGLayers.Point = function(x,y)
{
    this.x = x;
    this.y = y;
}

BGLayers.Dimension = function(w,h)
{
    this.width = w;
    this.height = h
}

The next class is a bit more complicated but is important as it is really the heart of this engine. No, not the layers class (we will start on that next week) but the lowly Rectangle. The question is how to handle the construction of the rectangle as I would like support for a valid empty rectangle, a clone constructor that takes a Rectangle as the sole parameter and copies it, and a Rectangle that lets you specify the four parameters.

Java and ActionScript support multiple constructors and functions by basing which function gets called on the parameters used. JavaScript doesn't do this yet. So how does one have multiple constructors for something like the Rectangle class? This is where I get to play around a bit with JavaScript. Researching this subject I discovered that functions have a arguments variable that holds the parameters. While arguments is not technically an Array object, it does have a length and can be accessed like an array. By using the length, the three different constructors can be combined into a single constructor function as follows:

BGLayers.Rectangle = function(x, y, w, h)
{
    if (arguments.length == 1) { // clone rectangle
        this.x = x.x;
        this.y = x.y;
        this.width = x.width;
        this.height = x.height;
    } else if (arguments.length == 4) { // parametrized rectangle
        this.x = x;
        this.y = y;
        this.width = w;
        this.height = h;
    } else { // default to empty rectangle
        this.x = 0;
        this.y = 0;
        this.width = 0;
        this.height = 0;
    }
}

I have noticed that I am starting to get a bit code-heavy. I want to focus more on the concepts and less on raw code, so I am thinking that for future posts I will link to the source file and just focus on the most relevant code while having an overview of the additional code. This has the added advantage of get through a lot more material and there is a lot of material that I want to cover here. As the Layers class is rather huge, I suspect that it will require more than one post to cover everything in it. Once we get that out of the way we can get to the animation part.

Sunday, August 29, 2010

Animating the Canvas Part 2: Layers of Dirty Rectangles

Today I am going to look at layers and dirty rectangles. These techniques work really well together, though it is certainly possible to use layers without using dirty rectangles. Next week I will start implementing the animation system by getting some of the primitives out of the way and we will continue the implementation in the weeks following that.

Layers, when used in an animation system, can be thought of as cells as used by traditional film-based animation. Cell animation was developed as a way of drastically reducing the workload required to produce an animated sequence. The best way of explaining how, is to start with an example. Lets say we wanted a simple animated sequence consisting of two cars driving past each other on a street. If you had to draw each frame fully, then you would have to draw the background street, as well as both cars for every frame. If the background is not changing, then this is obviously a bit of a waste. In Cell animation, each element of the animation is drawn on it's own transparent sheet of celluloid and each of these sheets are then combined to form the frame which is then photographed.  Because the background doesn't change, it would only need to be drawn one time. If the celluloid sheets that the cars are on are large enough, even the number of car images can be reduced as the only thing changing are the tires.

Layers work the same way as cells. Each layer that makes up the frame is it's own separate image. The frame is created by simply drawing the layers from the background layer up. This is essentially the same thing as the painter's algorithm with the exception that the layers can change over time. Where this technique can become extremely powerful is when you add the concept of having layers being able to have their own sub-layers and sub-layers being able to have sub-sub-layers and so on. In our previous example, each car could have two layers with the tires being separate from the body of the car.

Looking at the above layering system for animating, we can see that layers do not help with the primary problem that was discussed in part 1. The layer system above would essentially require that we redraw the entire image for every frame. This is where dirty rectangles come into play.

What is this magical dirty rectangle? It is simply a rectangular section of the frame that has been marked as being dirty. In other words, it is a rectangle indicating a part of the frame that has changed and needs to be redrawn.  This very simple concept can save a vast amount of redrawing as the only thing that you need to draw each frame is the contents that make up the dirty rectangle(s).

There are a number of ways of implementing dirty rectangles. The easiest is to have a single dirty rectangle which scales itself to fit the entire dirty area of the image. This is very simple to implement but unless the changes to a display are constrained may result in having to redraw large chunks of the image. The approach I will be using will be a list of rectangles with subdivisions to remove any overlapping areas. This means that when something changes on the screen, that area gets marked as dirty. This gets added to the list of dirty rectangles. An object moving results in two dirty rectangles. One for the area where the object use to be and one for where the object is now.  When the display refreshes itself, each of these multiple small regions get redrawn. To prevent redrawing the same portion of the screen multiple times, dirty rectangles that overlap other dirty rectangles will be broken into smaller rectangles so that each dirty rectangle in the list covers a unique portion of the display reducing overdrawing.

That is all there is to it, at least concept wise. Implementing this system may be more complicated then the above makes it sound but then that is why programming is so much fun.

Sunday, August 22, 2010

Animating the Canvas Part 1: The Immediate Problem

This blog has strayed quite a bit from what I wanted when I started writing it. I want to look at game development from both the design and programming view as products are created. This article, which will be divided into an unknown number of parts due to the huge size of the topic, will get me back on track. Here I will look at the development of an HTML 5 Canvas animation system as I develop it. I will be trying to cover my train of thought as the animation system is developed to explain the choices made and why different choices might be beneficial for different projects.

One of the things that HTML 5 brings with it to the mix is the Canvas. This lets you draw things, which makes creating games that don't require a plug-in such as Flash or Silverlight much more possible. At this point in time, HTML 5 and the canvas are draft standards. This means that they are subject to change but since a lot of browsers already implement the canvas, this change would probably not be that drastic. The one thing that I am hoping will change is better support for off-canvas drawing so techniques such as double or triple buffering can be better utilised.

The canvas is what is known as an immediate mode drawing surface. This means that, in theory at least, when you draw something on the canvas it appears immediately. In reality, there are things like frame-rates and implementation issues that can alter this behaviour. Still, when working with the canvas you should always assume that your drawing happens immediately. This leads to a really big problem for animation. Animation works by drawing something in one position, then erasing it, then drawing it again in a new position.  The problem is that the erasing and re-drawing of the object can result in flickering.

The traditional way that I have solved this problem is to do the drawing in an off-screen buffer then replace the current canvas image with what is drawn in the buffer. This might be possible to do by using multiple canvases and hiding one canvas, but it is a trick which may result in all sorts of other issues. The ImageData support that the canvas does currently have can be a partial solution to the problem, but the only drawing support the ImageData objects have are direct pixel manipulation. For some games, especially tile-based games, this can be all that is needed. Other games, such as the Dozen Days series of games that is inspiring this series, require a bit more flexibility than that.

If you can't draw off-screen, then the only other real solution to this problem is to try to reduce the flicker as much as possible. The best way of reducing flicker is to only update the parts of the screen that are changing and to do so in such a way that the updated region is as completely drawn as possible. An older method, known as dirty rectangle animation, is probably the best way of dealing with this. As dirty rectangles happen to work really well with layers, this will be the approach that I will be taking.

In the next part of this series, I will be taking a look at what layers and dirty rectangles are and hopefully start coding some of the primitive classes that will be needed.

Sunday, August 15, 2010

Thirteen Spikes Unlimited 1.0

Thirteen Spikes Unlimited is now finished and has been on the Blazing Games site since Friday the 13th. As I have mentioned before, there was some plans to port the game over to HTML 5. ActionScript and JavaScript are very close as they are both variations of ECMAScript. This makes the game logic very quick to port, even if JavaScript does not have as nice of class or variable support as ActionScript. The other thing that ActionScript has that JavaScript lacks is the Flash library. Because Flash was created as a streaming vector animation system, this library is greatly tied to graphics and animation. The HTML 5 Canvas simply does not have these classes, but there would be very little stopping someone from writing them. In fact, to implement Thirteen Spikes Unlimited, only a small subset of the class library would be needed.

This would require a bit more time than I have, so the port to HTML 5 didn't happen and instead themes, campaigns, and sound were added to finish off the 1.0 version. This does not mean that the next Friday the 13th won't have a HTML 5 version of this game. That would be May of 2011, so depending what is happening with my current projects (one which may be doomed) this might be an interesting project. So, while Thirteen Spikes is finished for now, it may resurface in the future.

Sunday, August 8, 2010

Hurry up and Stop

One of the most frustrating things about doing third party work is that often you are in a hurry up and stop situation. Clients seem to always be in a rush to get things done. This is to be expected. What confuses me is the same client who is rushing you to get on things seems to continually do things that slow down progress. I am not sure why this is the case, but it probably largely is the result of people still having no clue what programmers actually do and how software development works. Considering how important computers and computing devices such as iPhones and Android phones have become, this really is inexcusable. Here are some of the pet peeves that I have had in the past.

When material is needed before programming can begin, then not getting that material to the programmer is going to delay the project. This is especially true if the required thing is legal documents. Programmers are probably more anxious to start work then you are, but I don't start work until all the legal matters are (or appear to be) settled. Assets that the project depends on are almost as vital. While it is certainly possible to work around missing images or databases, this generally requires more work on the programmers part. First, temp artwork or data has to be created. Second, when the real materials come in, the real assets then have to be integrated and far too often this requires changes to the code due to the fact that often clients don't follow the specs that were sent to them.

Real programming is very mentally taxing. Sure, there are a lot of "programmers" who just assemble other peoples code together, but if you are actually creating code it requires a lot of thought. Having someone wanting to phone you or message you every half-hour is a sure way to kill productivity. When a programmer is in the middle of coding or debugging, any interruption breaks their train of though. This train of thought takes time to recover, so you are costing the project at least 5 or 10 minutes, possibly more, every interruption.

Changes are to be expected, but when a build is sent to you to evaluate, have the courtesy to actually look at the build asap. Waiting months to tell the programmer about a problem is beyond stupid. The longer a bug is in your code, the harder it is to find. Likewise, if you are not actively working on code, it takes longer to get back in the mindset you were in when you wrote that code. And worst of all, adding features to a project when the deadline isn't increased is just asking for a project to enter doomed status.

I could go on, but I think that I've stood on the soap box long enough.

Sunday, July 25, 2010

Plans for the remainder of 2010

I am about to embark on a rather interesting third-party project while continuing my own project so the amount of time that will be dedicated to the Blazing Games site will be reduced in the short term. The third-party project will probably appear on Blazing Games once it is done as will my own project but as both of those are large-scale projects. Thankfully, 3 of the 5 months are mostly done, one of the months can be done in a day, and the final one can be reduced from 4 layouts to 2 layouts.

I really don't like posting my release plans as things have a way of changing quickly causing my plans to be altered. Still, I suppose it won't hurt as long as it is clearly understood that these plans are subject to change without notice.

The August game will not be released until the 13th as it is the 1.0 version of Thirteen Spikes Unlimited. I am thinking of porting it to HTML 5, but am not sure about that plan now that my time has been reduced even further. September will be the final episode of Dozen Days of Words. October will be the Vampire Attack 2 open source release. Thoughts of porting to HTML 5 are there but again I doubt there will be time. November will be a couple more Tarot layouts. Finally, Dungeon Romp Christmas Edition in 3D will finish off the year.

Sunday, July 18, 2010

Why Tarot?

Sorry for the lack of posts the last couple of weeks but travel, funeral, and other events have kept me busy. This isn't even counting negotiations that I am involved in but I definitely  don't want to talk about that. Instead, I will briefly explain why somebody who is often considered a skeptic is spending so much time creating a Tarot fortune telling game. I don't think that Tarot cards can tell the future, but I do think they can be a mirror to the soul. By soul I am referring to a persons true nature. Why I believe this will take a bit of explanation.

The Tarot consists of 78 cards. 21 cards form the Major Arcana, 56 cards form the Minor Arcana which are essentially a deck of playing cards, and 1 Card (the Fool) is between the two and represents the average person. These cards all have a symbolic meaning attached to them. The thing is, when I was researching the Tarot I discovered that the cards had a variety of meanings attached to them. The meaning of the cards are whatever the reader attaches to the card. More importantly, because the cards are highly symbolic in nature, cards can have a wide variety of meanings. This is where the mirror metaphor comes in.

When reading a layout, it is not just the symbol on the card that matters, but the person for whom the layout is for. Because the person is associating themselves and their situation with the cards, they are looking deeper into themselves to find meaning. What you then have is an essentially random set of symbols that get meaning attached to them. Some people may believe that "spirits" or other mystical forces are influencing the shuffle, but pure randomness works just as well. Ultimately, what you have is a brainstorming tool that is designed to work on the emotional level.

So, in summary, I like the Tarot because I think it is a really neat brainstorming tool. Unfortunately, the mysticism surrounding it may have obscured it's true value. I am sure that many fortune tellers really do believe they are foreseeing the future (and if they know the person whom they are doing the reading for well enough they may in fact be able to predict that persons future actions) but I do have to wonder how many of them are just in it for the money and are just playing on the mysticism to draw the crowd?

Saturday, June 26, 2010

Developing a video game without a "computer"

As I am heading off on a short trip today, I wont have time for a proper post. I am not taking my laptop but instead will only have my iPod Touch. This got me wondering if it was possible to develop a game using such a device. There are no IDEs or compilers that run on the iPod, but it does have a text editor and source code is just text. This would mean that if I am unable to find a computer to use, I can still create code that can be tested later. In a situation where the idea for some clever code is in my head, I can get it down before forgetting. Of course, entering text on the touch is not a great experience, but in a pinch it should do.

This then leads to the question of JavaScript and HTML 5. The iPod Touch and iPhone have the Safari browser built in so it would be possible to run an HTML 5 game on the Touch. If you have a site hosting service that lets you edit your pages live using a browser, then you could develop a game using an iPod Touch or an iPhone if you were desperate enough. I don't think I would ever get that desperate, but it is a good think to know.

Sunday, June 20, 2010

Punishing Poor Players

Before I get to my point, let me first go over what lead to my current post. I have lost a lot of weight but still have at least another 20 to 30kg to lose. While letting my weight get so out of hand is my fault, had I started dieting the way I am now 20 years ago instead of listening to dieticians and other "experts" I would already be in shape. The experts that I seen were all under the delusion that you can loose weight through diet alone. While from a mathematical perspective, this is possible the small amount of food you are allowed and the fact that your favorite foods are probably not allowed in your diet means that eventually you will fall off the wagon and when you do you will end up gaining more weight than you lost. This is especially true if your metabolism is low like mine is. If I eat the number of calories I am suppose to be able to in order to sustain my current weight, I gain weight. I really didn't start loosing weight and keeping it off until I started to increase my activity level. This was possible thanks to eBooks (see eMusic.com and audible.com) and mp3 players which made going for hour long walks tolerable making it possible for me to shift from watching television to exercising. The weather doesn't always cooperate, so exercise alternatives are nice to have and the Wii has proven to be a good exercise machine. The Kinect sounds even better, but that is not out until November of this year.

While Wii Fit is an obvious choice for exercise, I have found that Sports Active and Sports Active More Workouts are much better. These, however, are ultimately just glorified exercise videos. Wanting something different, I decided to try Dance Dance Revolution House Party 2 (DDR). My thoughts were that in addition to exercise, I might also improve my mediocre dancing skills. Sadly, DDR has about as much to do with Dancing as Guitar Hero has to do with playing the guitar. Still, it is good exercise and there is enough of a game involved to keep you involved. For overly wet or hot days, it is a good substitute for going outside. There is one thing I noticed about the game which leads me (finally) to the topic of this post.

Too many games seem to want to punish players for being poor at playing the game. This to me seems blatantly stupid. While I can understand the idea of making a game more challenging, when such a challenge doesn't make the game more difficult for a person who is good at the game, then you are not making the game more challenging but are instead just punishing the players who are poor at the game. This might motivate some players to keep playing the game to get better, but with so many good games being released, it is more likely they will just abandon the game. While numerous games do punish poor players, and I am sure I complained about this before,  DDR did this in a number of ways that just brought this pet peeve of mine to the for-front. During the campaign, there were levels that you were not allowed to complete on the easiest difficulty level. Then there were challenges that required that you have huge numbers of consecutive great or perfect steps. This means that if 30 steps into the 50 step sequence required you only got a "good" the sequence was over and the count starts again at 0. As the songs are fairly short it also likely means that you have no chance of meeting the requirement have been shot and that no matter how good you do on the rest of the song you are going to have to repeat it.

The most blatant examples of punishing poor players that DDR had, however, were a couple of gimmicks that were particularly targeted at making the game harder for players who were poor at playing the game. The first were arrows that appeared higher than normal on the screen. If you missed theses arrows (which poor players are likely to do while good players are not) then future arrows of these types would appear even higher on the screen making absolutely sure that the poor player would be severely punished because he or she wasn't good at the game. The second one was the minimiser. This would shrink your display making it harder to see and therefore harder to play.

Of course, many arcade games tend to have features that punish poor players. Jumps in which failure sends you to near the beginning of the level so that you have to repeat a large section of the game again are still common. Having too few checkpoints in a level when you can't save your progress anywhere. Time limited sequences are pretty bad if they are designed so that good players barely can complete it in time. The worst time limit in my mind are the breath-holding ones where the superhero I am playing can't hold his/her breath as long as the out-of-shape person playing the game can, but that punishes all players not just the poor ones.

The sad thing is that too many designers are designing games for hard-core players of the genre that they are creating so don't even realise that they are punishing poor players and probably don't care until the number of "good" players for a particular genre gets so small that it becomes unprofitable to make games in that genre any more. At that point the experts think that people just got bored of the genre in question. The reality is that new players wanting to play the games just didn't have the skills and because they didn't have the skills, they got punished even more because of the game trappings designed to only be challenging to people who couldn't play the game well. As a result, the much needed new players never showed up and sales dry up.

Sunday, June 6, 2010

A tool for porting to JavaScript?

Porting code by hand from Java to JavaScript/HTML5 was a rather interesting experience as working with JavaScript is not what I would call a pleasant experience. The language itself is similar enough to Java that writing or porting the code was trivial (more on that later) but the problem I had was with the debugging of the program. JavaScript is not a typed language and doesn't even require that you explicitly define variables. While this makes it easier to write simple programs (which is what a scripting language is for, after all) it has the downside of being very problematic for larger projects. The problem is that you don't have to explicitly define a variable to use it. This means that if you have a variable named java but later in your code miss-type it as jave then the program will sill run but you will have a very hard to find bug. Bugs like this are caught by the compiler in Java and ActionScript. Then there is the fact that JavaScript class support is barely there and largely has to be done by hand reminding me of my C programming days, though not quite as bad as passing structures to functions.

While the rich internet application platforms (Java, Flash, SilverLight) are ideal for such large projects, they are proprietary and are not universally supported. The direction things seem to be going, it appears that JavaScript is going to become the standard way of creating interactive HTML pages.  There is a ECMAScript 6 draft (formerly ECMAScript 4) that comes a long way towards solving a lot of the issues with creating a larger project in ECMAScript derived languages (like JavaScript). ActionScript 3 is based on this which makes it much nicer to work with than JavaScript. This got me thinking about tools for porting from one language to another. If I did my work in ActionScript 3 and then used a tool that ported it to JScript (Microsoft's version of ECMAScript which also happens to be, in my opinion, the worst implementation and therefore the lowest common denominator for porting) then I would have much greater productivity. This got me thinking about how hard such a tool would be. As the languages are so similar, this wouldn't be too hard. Especially if one was only concerned with a rough port and not a perfect port. This then had me look to see if anybody has already done this. I found two projects. Jangaroo and Mascara. Jangaroo is an ActionScript to JavaScript compiler, while Mascara is a ECMAScript 6 to JavaScript compiler.

Jangaroo is closer to what I envision, and is free. Mascara requires commercial users pay for it but is free for non-commercial use. There is also the option of writing my own tool that does exactly what I want. This is probably the worst choice as it eats up my already over-allocated time but I always wanted to write a compiler and this project would at least get me part way there. I will take a look at Jangaroo and hope that it is close enough to what I desire that I don't start yet-another-side-project as I am trying to get out of that really bad habit.

Sunday, May 30, 2010

Dozen Days plans

I am doing something different with the last two episodes of Dozen Days of Words. Instead of using FlexSDK to create the last two episodes, I am switching to HTML 5 and JavaScript. To make this transition a bit easier on me, episode 11 is going to be a ported version of my Java CircleWord game. I am sure that some of you are going to consider this cheating, but really CircleWord is a must-have word game and I have already written it so writing it again doesn't make that much sense. That said, porting the game actually took a bit longer than I thought it would so I didn't have the time for the enhancements that I was planning. The final game in the series will be written from scratch.

Once Dozen Days of Words is done, the next series of Game in a Day challenges will have to be started. Right now I am leaning towards Dozen Days of Tiles as this would allow for a variation of Sudoku as well as Mahjong and Dominoes. These are three games that I really want to develop and I think it would be possible to break the elements of these games down into a set of other games allowing me to build up to these games. These are fairly common games so there is no money in trying and develop commercial versions of any of these, so the Dozen Days project would be a perfect fit for them. The next series will obviously be HTML 5.

Sunday, May 23, 2010

Why ActionScript and JavaScript are Slow

Slow is a relative term. Compared to the Commodore 64 that I use to program, today's computers are incredibly fast. Still, a lot of complaints about JavaScript and ActionScript (the scripting language Flash uses) is how slow they are. While both ActionScript and JavaScript use JIT compilers to greatly improve the speed of the code, there is overhead in compiling. Some proponents of "real" programming languages will say that this is still not as fast as a proper compiled language would produce. As someone who has programmed in a variety of Machine Languages, I should point out that compiled languages do not produce as good of code as hand-coded assembly language will produce. Some compiler makers claim that their compiled code is better than what the average assembly language programmer would produce. This is possibly true if that assembly language programmer was converting the higher level language line by line into assembly language like a compiler does, but if he or she is writing the routine from scratch the results would likely favour the programmer.

While some of the speed difference can be attributed to the nature of JIT compiled code, I think the bigger problem is that both ActionScript and JavaScript were designed to be easy to write code for. Remember that although these languages are now being used for more serious projects, they were intended to be for adding more flexibility to web pages or animations. In theory, these languages are suppose to be accessible to anybody, though if you look at more complex project, it is clear that real programming is still at the heart of these languages.

Concepts like dynamic objects definitely make these languages far more flexible than older languages like C/C++ but flexibility has a lot of overhead. Instead of just calling a function directly, the language has to go to the object in memory and find the pointer to the function (as it may have changed from the default one) before making the function call. It may not be much of an overhead, but it does add up. Then there is the issue of the libraries included with these languages. Using Strings for a lot of things that other libraries would have used integers for has a drastic effect on performance. If you used an integer, you would have one quick comparison to do. When you use a string, each letter of the string has to be compared. Using strings certainly makes it easier to program but there is a big cost in speed.

I could probably go on for pages, but ultimately, what it comes down to is that these languages are easier for humans to write code at a cost of efficiency, but as JIT compilers get better, the difference is not as great as purists would like to believe and the much greater productivity that results probably outweighs the speed costs.

Sunday, May 16, 2010

Why I Use Flash

There has been a lot of negative press about Flash lately, so I thought now would be the ideal time to take a look at why I am using Flash. Before I begin, though, I should first point out that much of the hatred of Flash seems to be oriented around Flash based ads. If you hate Flash for this reason then you are in desperate need for either medical help for your brain or are needing to learn critical thinking skills. Flash is used in advertising because it has the animation capabilities and interactivity that advertisers want and it is in use by over 90% of the browsing public. When HTML 5 becomes that dominant, then all the ads will be done in HTML 5 with its much slower JavaScript eating up processing cycles far worse than Flash ever could. As long as people do not want to pay for the content they are consuming (bandwidth may be cheap but the time to create the content certainly is not) then content creators need to find other ways of getting enough money to put food on their table and advertising is the dominant way of doing this.

The reason I use Flash for my games is that it is currently the best choice available. JavaScript is painful as different browsers run it differently and until HTML 5 it lacked a lot of the necessary capabilities such as the Canvas tag. Even after HTML 5, JavaScript is going to be annoying to work with, but I think that this is where things will eventually lead so I am slowly going to transition to it. Nobody wants to install plug-ins (especially from small companies like Blazing Games) so writing stuff in C is out of the question. This leave the option of relying on a plug-in that people will already have installed on their browser. The two choices here are Java and Flash. An upcoming choice may be Silverlight, which I dread as I do not trust Microsoft ("DOS isn't done until Lotus won't run" among thousands of other reasons). I wish Unity was on this list but don't see this happening. If it does, then there may be a transition to that but since it uses JavaScript that won't be that big of a change.

I choose Flash over Java largely because Java stagnated and has more compatibility problems between versions than Flash. More important, at least for a game development perspective, is that Flash is a really powerful animation system. ActionScript, the language that Flash uses, is based on the ECMAScript standard that JavaScript is and is a pretty decent language. I do wish that it had better thread support like Java and more 3D support (there is some 3D support in Flash Player 10+ but it is very limited).

Sunday, May 9, 2010

A breif update

It's Mothers Day today so I am doing my daily update of Blazing Games and writing this right now because I am going to have to start cooking supper for my mother in about an hour. My copy of Adobe CS5 Web Premium came in so I have switched machines and am now updating the site using Dreamweaver CS5 on my main machine instead of having to do the posting on a different machine. While I suppose I could have moved CS3 to my main machine, I was actually considering just getting Flash CS5 and get it on the mac. Adobe still has their stupid OS specific thing so my upgrade is still the Windows version even though my main machine is a Mac. Of course, my Mac is running Windows 7 (and Ubuntu Linux) as well, so going with the upgrade was the wiser choice as the savings from just getting a Mac version of Flash CS5 was very little and CS5 now include Flash Builder which means that code editing should be nicer. Time is slipping away quicker than I thought so I will keep this post short but will give my opinions on CS5 later.

Sunday, April 25, 2010

A sneak peak at May 2010

Next month is going to be interesting as Blazing Games will be updated daily for 27 days. Sometimes a project turns out to be far larger than it seems. Other times, as is the case with the project that will be revealed next month, feature-creep causes a simple project to balloon in scope. There is an easy way of accomplishing this project, and then there is the more thorough way which is the road I foolishly decided to take. In the past, I would have taken the easy road with the idea of having regular content appearing on BlazingGames.com but my more relaxed release schedule and willingness to release projects iteratively, I have no hesitation in building this project to the more ambitious specifications. The scary thing, is even when I have reached all the development targets for the 1.0 release, there is a lot of room for expansion so this new project may be revisited many times in the future.

The version of the project that will be released next month is the 0.1 version, as it is not close to the final goal of the project. This is really about a quarter to half the way towards the project completion, but the remaining portions of the project will be posted in three other months. While the second month of releases will be June or July, the other two parts that lead to the 1.0 release may be delayed by a number of months. This is being done so other stuff (hopefully stuff that people not interested in next months project will like) can be released.

From a programming perspective, next month's release is very simple. From an asset creation point of view, this is a monster project. This is actually a rather nice change for me as I am spending a fair bit of time doing creative writing. Still, I want to be coding and am hoping that a third-party project that seems to be in a perpetual delay loop will see the light of day. If the delay continues, I will probably re-start my equivalent to Duke Nukem Forever. The difference here is that my DNF project hasn't been continually in development but simply continually goes through fits and starts then gets shelved when paying work or other crisis happen.

Sunday, April 18, 2010

CS5 is coming

Right now I am using Adobe Creative Suite 3 to aid my development, not bothering to update to CS4 due to the fact that while it had a lot of nice features, I didn't think those features were worth the hefty upgrade price. While I can not say whether it is worth upgrading from CS4 to CS5, It seems like it will be well worth the price to move from CS3 to CS5. While I am slowly going to be migrating from Flash to HTML 5, I still think there is enough life in Flash to make one final upgrade. Getting Dreamweaver, Photoshop, Fireworks, and Illustrator also helps but the biggest addition to the package was Flash Builder 4 (formerly Flex Builder) and its integration with Flash CS5.

As I have said in the past, I think that Flash will slowly fade away as HTML 5 starts to take off. Still, there is a lot that you can do in Flash that you will not be able to easily do using HTML 5. Until the still dominant browser is HTML 5 friendly, which IE8 is not, Flash is still important. Even after this point, Flash will still be a good prototyping tool. Especially when you consider ActionScript and JavaScript are both based on ECMAScript.

Adobe, obviously, will not just stand by and let Flash die. The question is what will they do to salvage it? Some suggest turning it into a tool for creating Canvas or SVG code. Others think that new compelling features will be added that the various HTML 5 additions simply can't support. AIR is certainly a factor. While I haven't created any AIR applications yet, that could possibly change. The key question for me, however, is does the added features of a proprietary platform out-weight  the open standards enough to warrant its use? HTML 5 is a balancer, but more weight on the Flash side could tip the scale. It seems we are still living in interesting times.

Sunday, April 11, 2010

Does Apple hate Adobe or Developers?

I was thinking that perhaps I should wait until tomorrow to make a post. April 12th is when Adobe is going to officially announce the Creative Suite 5 lineup. I am hoping that something big is going to be announced tomorrow but think that perhaps the iPhone OS 4 rumors may have dampened Adobe's plans. One feature that they were planning on having for Flash CS5 is an iPhone exporter that would convert Flash apps into iPhone apps. Sadly, the iPhone SDK license agreement (required to use the iTunes store) may be specifying that apps must be written in Objective C or C++ and that API features must not be accessed through third party libraries. This effectively rules out using Flash to develop iPhone apps. It also rules out other tools like Unity.

I think the real reason for doing this is to force developers to develop specifically for the iPhone/iPad. Flash being able to export to iPhone would circumvent this requirement making it easy to develop cross-platform applications. While Unity also allows this, it has a much smaller developer base as compared to Flash so Apple probably didn't even notice it yet. In other words, this attack against Flash isn't actually aimed at Adobe, but it is instead an attempt to make it much more work for developers to create cross-platform versions of their apps. Right now, the iPhone is in a dominant position, so developers pretty much have to support it. This is just like Windows is the dominant platform for PCs which is why there is so much Windows software.

With Android continuing to gain market share, one has to wonder if this is a good long-term strategy for Apple. Right now, the major player is the iPhone, but with all the hassle and inconsistencies with the approval process, how much market share will Android have to gain before it becomes the better choice for initial development? In the computer industry, Apple was the dominant player with the Apple II, but that quickly changed when IBM created an easy to clone PC that numerous companies copied (today's PC) resulting in Apple slowly becoming a niche player. When companies start developing for the Android and then deciding if they should bother porting their app to the iPhone,  we may again see Apple become the niche player but this time in the mobile market.

Thursday, April 1, 2010

April Fools 2010

Here is the text of the April Fools message that was posted on Blazing Games. Note the first letter of each sentence and the date at the bottom. I (Billy D. Spelchan) am still president of the company, and as this month's release shows, we are still slowly transitioning to HTML 5. Flash will probably be our main development tool for the next few years, though.

At Blazing Games, we are proud to announce a deal between ourselves and Microsoft. Sadly, Billy D. Spelchan has agreed to sell his shares of the company and has terminated his position as President of the company, we wish him best of luck with his future endeavours. 

Part of the deal will require that all of our Java and Flash games be replaced with Silverlight versions of these games. Work on this transition has already begun and the non-silverlight games should be removed from the site by the end of this week.

Rich Internet Media in the form of Silverlight is the future of the internet. HTML 5 features simply do not match the power and potential of Silverlight. Our former president's views on open standards clearly are outdated.

Internet Explorer will become the browser of choice for viewing Blazing Games. While we will not be taking any moves to prevent users of other browsers from accessing our site, testing will only be done on Internet Explorer 8 running on Windows 7. We recommend that visitors upgrade their machines to Windows 7 as soon as possible.

Lots of people, such as our former president, have the mistaken feeling that making a deal with Microsoft is the equivalent to selling your soul to the devil. We hope that crazy superstitions such as that are not going to impact our existing visitors enjoyment of this site.

For those of you who feel you can no longer support the site, we thank you for your consideration for other people by making site bandwidth available for the countless new users we will be receiving from a high placement on the Bing search engine. Clearly Bing is vastly superior to that googol thing that our former president used.

Our open source efforts will continue, though we will be switching from the virus-like GPL license to the much more business friendly Microsoft Public License (Ms-PL).

OSX users do not have to worry about Silverlight as Microsoft has assured us that they will always support the OSX version of Silverlight. While not all the advanced features of Silverlight will work on the Macintosh, OSX users always have the option of purchasing a copy of Windows and installing it on their Bootcamp partition.

Linux users are urged to give up their anti-capitalist ways and install Windows on their computers as that is what their machines were designed for. Those Linux users who are running old, obsolete hardware should do their part to restore the economy by purchasing new hardware capable of running Windows 7.

Small changes to our games, such as changing the One of those Weeks' Blue Screen of Death into the Linus the Penguin of Doom and changing Coffee Quest into Clippy Quest will be done at the request of our generous corporate partner but feel that such minor changes will not alter the enjoyment of those games.

M. Caton
President,
Blazing Games Inc.
April 1, 2010

Sunday, March 28, 2010

The path to JavaScript

When I first started web game development last millennium, the landscape was quite a bit different. Java had just come out and was being pushed as the next-best thing in web development. While there are a lot of programmers who hate Java with a passion, a large chunk of my savings account is the result of third party work I have done using that language. At the time, Netscape adopted Java as the way to make the internet more interactive and even altered the browser scripting language they were working on renaming it JavaScript. Sadly, largely due to a battle between Microsoft and Sun, use of Java in browsers never became the dominate force it should have.  Java became more of a server side or back-end language with a lot of businesses adopting it.

On the browser side, Flash seemed to grow. This was largely because Flash was flashy. Flash was designed to be a vector animation program but added scripting and in Flash 5 an ECMAScript based scripting language called ActionScript. ECMAScript is the name given to the standard for JavaScript. Purists are free to correct my oversimplification of this but I am a programmer not a bureaucrat. Still, the scripting language that Flash uses is essentially the same as JavaScript.

I have dabbled with JavaScript in the past, but have never attempted to create a serious project in it. Still, with my ActionScript background, I figured it should be a piece of cake. Syntax-wise I was correct. DOM-wise, I couldn't have been more wrong. The DOM is the Document Object Model. It is essentially the API for browser-based JavaScript. I could not find an Java-Doc style guide to the DOM, which may be part of my frustration.  The part that really annoys me is how different the different browsers are at supporting it. Code that works great in Firefox and Safari does not run in IE. This means that I have to test a lot more than I would like which is why I think it may be a while before HTML5 replaces Rich Internet Applications written in Flash, Java, or other  RIA platforms. This is really too bad as I personally think open standards are better then proprietary platforms.

Still, next month will be my first JavaScript game. Working in it has certainly been interesting. One thing I will be looking into is better JavaScript libraries that make it easier to write cross-browser code. There are a lot of them out there, though the two I keep hearing about are Dojo and jQuery. I am not sure how necessary this will be as most of my stuff will be using the canvas for the user interface. That said, Flash CS5 is probably still in my future but I am going to slowly try to move to JavaScript for my client side programming.