What if piracy vanished?

There is a saying that you do not know how important something is until you no longer have it. With thoughts of SOPA and ACTA still in my mind, I wondered what would be the results if Santa Claus came down from the North Pole and gave old media the silver bullet for stopping piracy (hint, it is not SOPA or ACTA as those won't work anyway and is as like to exist as Santa)? If piracy were to become impossible, what would happen? Personally, I try not to pirate anything so for me little would change other then knowing that all the stuff I buy is fully legit. Looking at the excuses I have heard for piracy, lets look at the outcome based on the excuses. Percentages are an estimate of how many times I have heard the excuse and don't add up to 100% because most people have multiple excuses.

1. Can't afford to buy the stuff (80%). After piracy is gone, these people will still not be able to afford it. That means that they will not be buying it because they don't have the money to buy it anyway so it is not lost revenue. No extra sales from these people. Granted, some of these people are young and would likely buy stuff once they started getting money but they would have probably done so anyway the difference is that many of these also fall into point 3 even if they don't realize it so the negative sales would apply to these people as well. Net result is a harm to old media and a gain to new media in the long term.

2. Not worth the price (60%). These are people who think the price is too high. Quite often what they want to pay is much lower than what the price will ever be so the result is no sales. In the cases where the price does drop to the point that these people will be willing to pay for the item, some of them will buy the item but most will have found other (new media) equivalent stuff. Net effect is a big gain for new media. While there is a small gain for old media, it comes at a cost of exposure (see point 3) so a tiny short term gain but long term losses.

3. Wanted to see if it was any good (60%). This is the most interesting category as it is where the arguments against piracy fall apart. When you look at it logically, it is obvious that people do not want to buy something they are not going to like. Unless the price is really low most people won't take the chance. This means that there is no net gain from these people. This leads me to a personal example. Steve Gibson recommended the Honor Harrington series but when I looked at the book covers I took a step back. I know you should never judge a book by the cover and this series is an example of why. I would not have grabbed the series had the first two books not been freely (legally) available at  http://www.baen.com/library/ . The free books got me to get past my hesitancy about the series and resulted in much more of my money going to Baen. There are a lot of cases I personally know of where a person has become a fan of something due to a pirated copy. Often these people don't buy copies of the stuff they have pirated (sometimes they do) but they usually end up buying new stuff that comes out from that series/author. If they had never pirated, they would not know they liked the series/author and not buy new stuff. Net result is a huge loss for old media.

4. Already Bought It in different format or DRMed (40%). The result of DRM is often products that don't work as good as the pirated version. Some people don't care for the less-functional version so will find a non-crippled pirate version of the product. These ARE NOT lost sales as a copy was legitimately paid for. Likewise, people who have an old record or tape collection do not want to buy yet another copy of something they already own so will "pirate" the stuff they already bought. I assume Santa's solution would cover both these issues so the net result is no gained sales as the pirated numbers were artificially bumped up anyway.

5. Because I can (10%). These are those people who pirate for the sake of pirating. The few people I know who fall into this category either are also in group 1 or buy an awful lot of stuff legitimately so if they were no longer able to pirate they would simply do something else. Possibly a gain for new media. No change for old media.

After looking at the world after the silver bullet I see old media dying at an even faster rate then they are now and new media growing at a faster rate then they are now. Not exactly the outcome that RIAA/MPAA and other MAFIAA type organizations are after. All I can say to the people from these organizations is to be careful what you wish for because you might actually get it and the results are not what you think they will be.

TMoD Twelve Months of Doomsday

What better day then Friday the Thirteenth to resurrect my Game Development blog. After all, Jason managed to rise from the dead quite frequently. True, a month between posts isn't exactly dying but I had to have a Friday the 13th reference. For 2012 I am planning on updating this blog every other week. To be a bit more precise, weeks that do not have new content on BlazingGames.com will be the weeks that I post articles here. When appropriate, these articles will provide details about whatever was posted on BlazingGames the previous week. If for some reason you want to read more of what I have to say, feel free to follow me on Google+.

The big game series that I am running throughout 2012 is Twelve Months of Doomsday (TMoD) which is my way of having fun with the 2012 end of the world theme. Statistically speaking, there is a small chance that the world will end in 2012. To my understanding, the end of the Mayan calendar didn't actually represent the end of the world but the beginning of a new cycle. Perhaps the 21st of December will be the beginning of the singularity that many science-fiction writers are predicting.

TMoD is a collection of classic-style arcade games tied to a twelve part over-arching story about how the cast from One of those Weeks try to prevent the end of the world. I actually enjoyed bringing back the characters from my 46 episode adventure game. The design of this series not only had to tell a story, but had to fit in arcade games similar to those I played as a child. All the games I write are my original code and I try to make the games as original as possible while still bringing back the feel of the old days (well, at least if you are 30+).

The first game in this series was actually chosen not because it was an arcade game but because it was one of the first games I ever typed into my Commodore 64. Lunar Lander was a text based game found in a book containing 101 BASIC Computer Games. While BASIC was not the greatest of languages, it came with the computer so it was the language of choice for learning to program back then. I probably still harbour some bad programming habits as a result. The game gave you a distance from the surface and you had to type in the amount of fuel you wanted to burn. This determined your speed as you approached the surface. There were a number of arcade versions of this concept which I modeled my game after.

You will notice that a large portion of the games deal with threats from space. This is partly because the main villain is an alien, but more because the childhood arcade games that I played tended to have science-fiction themes. There are a lot of really good games that I am planning on releasing as part of this series so please give the series a chance if you find you don't like the first few games.

DDTe4 Hours 16 to 18 Optimization

After creating the game, it became clear to me that there are more efficient ways of implementing the game other than using a grid like I did but as I have a short time-limit on the creation of the game, these faster implementations are out of the question. Still, there is some time left for doing an optimization pass. One problem that a lot of programmers have is the desire to prematurely optimize code. While the desire to write efficient code is a good desire, spending a large amount of time on a piece of code that has minimal impact on the performance of the final product is not a good way of spending your time. This is why tools like the profiler that is included in FireBug is such a great feature. The profiler tracks how many times and how much time is spent in every function that is executed while the profiler is running. This lets you know what parts of your program is taking the most time.

In the case of the life game, the code that spent the most time executing due to the huge number of times it was called was the getCell function. The problem with this function is that it needs to support calls outside of the proper bounds in order to properly support the borders. That said, the bounds should only be out by 1 in any given direction which means that if the grid size was slightly bigger and the border was computed along the edges every iteration then we could greatly simplify the getCell function.

To handle this change, the grid size was increased by 2 in both directions, with 1,1 being the top corner internally, though externally 0,0 will be the coordinate passed to get the data. This may not be intuitive, but the downside to optimization is that it can make the code a bit more complicated. The getCell function, on the other hand, becomes a very simple single line of code: return this.grid[y+1][x+1];

This means that if -1 is passed, it goes to the extra bottom or left row and passing the size of the grid as a coordinate will get the extra bottom or right row. To properly fill these rows, the setBorder function has been enhanced. It will fill the border rows and columns with the appropriate data. To make sure the data is correct, it is called at the start of every iteration. To finish up my first optimization pass, the countNeighbors and countCancer functions were quickly optimized by unrolling the loops and replacing the call to getCell with directly obtained cell data as a single line of code is easy to inline.

In JavaScript, there are no explicit types for variables. Variables get converted into whatever type is needed for the current operation. The problem is that this does not always work as planned leading to some real interesting bugs that would not appear in typed languages. In my case, I was using a value from a combo box. The value was a number, but because it is from an html control it's value is stored as a string. When it was passed to my function, 2 gets added to it. The problem is that JavaScript did not convert the string into a number then add two to it, but instead it converted the number into a string and appended it to the string. This resulted in "32" + 2 = "322" which is way off. I solved this bug by flooring the input value forcing it into a number, but finding the bug was a huge problem due to the fact that the code seemed correct (and in a typed language would have been correct). Thank you FireBug.

After fixing the bug and running the profiler again, the getCell, countNeighbors and countCancer drastically dropped in execution time. This optimization pass improved the speed of the simulation quite a bit. The game is quite fun to play with though I am sure there are many features people may want. I can't really think of any features that can be implemented in the few hours left within the allotted development time. For that reason, I am considering the game done. Still, if there is enough interest and suggestions, an enhanced version is something that I would certainly consider working on.

DDTe4 Hours 13 to 15 - Cancer

This is the third (the first two parts were released last week) of a four part article covering the creation of my implementation of Conway's Game of Life. This week I am adding Cancer to the game.

I am not really sure why I decided to add cancer to the game of life. Perhaps it is my strange way of mourning over the loss of my mother or perhaps all the research into cancer that inspired me to create my own version of Conway's Game of Life was still in the back of my mind when I realized that I still had plenty of time to work on the project and add new features.

In the real world there are a number of causes for cancer but ultimately it comes down to either mutation or cell damage. I am limiting the simulation to only one of the two causes for cancer. For simulation purposes, mutation happens with newly formed cells. These are the ones that appear when an empty cell is surrounded by three (and only 3) living cells. Cell Damage is what happens to aging cells so is applied to any cell that is over 10 generations old. The mutation or damage is determined purely through randomness with an odds variable indicating how likely the cancer starting is. The odds value is a floating point number between 0 and 1 just like the numbers provided by the random number generator making the check simple as it is just seeing if the random number is less than the odds.

The problem with using random numbers in a simulation is that it makes it impossible to re-create the cancer. This problem can be solved by the fact that the random numbers are not random but are instead pseudo-random and the sequence of random numbers is repeatable if the original seed number is known. JavaScript doesn't let you seed the random number generator, so to do this you would have to find or write your own random number generator. For such a short time limit on this project, however, that is not realistic so cancer in this simulation will be unpredictable like it is in the real world.

This leads to the problem of how to deal with the growth of the cancer. There are three growth modes in the game. The mode you want real cancer growing in is benign which is simply no growth. Spreading mode is a slower growing form of cancer in which cells that are about to die but that are next to cancer will become cancerous. Growing mode is the evil mode where the cancer will grow into any dead cells next to it.

My initial tests had the simulation treating cancer cells as if they were dead cells. This was the ideal way from a coding perspective to implement the cancer as no drastic changes to the core simulation engine were needed. However, when I watched the cancer progress it just did not have the correct feel. It simply did not seem to grow properly. I altered the code to treat cancer as being alive and ran the simulation again. The results were almost exactly what I was looking for. I simply loved the results of both spreading modes.

From a performance perspective, there was a bit of a hit from the cancer, but not an overly dramatic hit until the cancer started to grow. The hit from the growing cancer is simply the drawing problem that was discussed in the previous article. Too many cells on the screen causes the rendering code to constantly change the drawing color and the HTML 5 canvas has an extremely inefficient way of setting colors.

Having the growth of cancer slow down the simulation is not that big of a concern, but with at least one more hour that I would like to put into this project spending some time speeding up the overall simulation would be a worthwhile endeavor.

DDTe4 Hours 1 to 6 - The Basics of Life

When my mother went to the hospital and discovered that she had cancer, I spent some time researching the subject. Perhaps not as much time as I would have normally spent when researching a topic that strikes my interest, but enough to discover what a truly evil disease it is. Essentially, cancer is when a cell not only decides it does not want to die (I can’t blame it for that), but then starts reproducing replacing otherwise health cells. Thinking of the reproduction of cells got me thinking of Conway’s Game of Life. This is a zero player game as the game essentially follows a number of simple rules. The fun comes from setting up the world and watching it evolve.

There are a lot of features that I would like my implementation of life to support, and will implement as many features as I can within the 16-24 hours of development time allocated to this project, but the first step is to get the simulation running.

The first thing that has to be taken into account with life is the grid. I wanted to have a flexible size of grid but the key question of dealing with the grid is that in theory, the grid is suppose to be infinite. This is not necessarily realistic so the issue becomes how to deal with borders. I decided to support three different types of borders. Always dead, Always alive, and wrap-around.

The border issue makes the getCell function that I wrote for grabbing a cell a bit complicated as it has to see if the desired cell is within the bounds. If not, it then has to figure out how to deal with it, with wrap-around being a bit complex as it has to convert the passed coordinates into valid coordinates. All this condition testing has me concerned about performance, but I figure if it proves to be an issue I can do some optimization later.

Iterations of the game use the existing grid to spawn the new grid so the LifeGrid class actually creates two grids. The current grid and the old grid. Because the getCell function which I am using uses the current grid, the new grid is created in the old grid space and then the two grids are swapped. For each tile in the grid, the number of alive tiles surrounding it are counted. The rules of life are then applied and we know what the cell is going to be in the next iteration. The rules are fairly simple:

1 - If there are less than two neighbors, a living cell dies of loneliness.
2 - If there are more than three neighbors, a living cell dies of over-crowding.
3 - If there are exactly three cells, an empty (dead) cell becomes a living cell (newborn).

Because of some of the features that I know I will want in the future are dependant on knowing the age of the cell, the age is adjusted as well for each iteration.  The LifeGridViewer right now simply draws the cells in red for dead and green for alive. This will change soon, however.
DDTe4 Hours 7 to 12 - Controlling Life

With the game functional, the next step is to implement controls that allow the user to modify the game. While the controls that I implemented could have been completed quicker, I found myself spending a lot longer testing the game then was absolutely necessary as there is just something fascinating about watching the simulation.

Before it is possible to watch a simulation, the simulation must first be animated. In the case of Life, this is simply a matter of displaying consecutive iterations automatically. In browsers, there are two ways of handling the timing. You can set an interval which calls a function after at least the specified time interval has expired. This happens repeatedly until the interval is stopped. For a bit more control, there are timeouts, which work just like intervals except they only call the function once.

To control the animation, a small set of controls are needed. For  this game I opted to use html controls that appear below the game display. This is largely due to the fact that the controls are more for options and the real joy comes from watching the display. For the animation, a combo-box is used to allow for different playback speeds, the play button which will become a pause button when clicked, and a single step button for those people who want to analyze the progress of the simulation.

Once the animation was working and tested, adding more control over the colors became my next challenge. I wanted the ability to see the aging of the cells but also wanted the more traditional monochromatic style of display. To allow for these, I decided to use a color set approach where an array of colors are used to determine what is shown for different ages and states for the cells. By setting all the ages to the same color you can create a monochromatic style display. I created a large number of color sets so players should be able to find a color scheme they like.

With a more colorful display finished, controls over the size of the display and whether or not to show borders were added. As different sized grids were already implemented in the core game classes, this was very simple to implement. However, when the simulation was ran at a higher resolution, the speed slowdown was quite significant. Running the firebug profiling tool showed the problem was with the display code.

This had me confused as the display of the simulation is remarkably simple as all it is doing is drawing a large number of rectangles. These should be drawn exceedingly fast. As I looked over the code to see if I did anything stupid, it dawned on me that the color was changing for every rectangle. This shouldn't be a big issue, and with most graphics API's it would not be a problem. However, the Canvas API uses the DOM color model which is string based. This means that for every color change, the string gets converted into a number. The overhead for all this string processing is very high.

At this point, I was banging my head trying to figure out a way of speeding things up without resorting to the lower level canvas ImageData API. While this API gives you access to the raw color data, it would be a lot of work to implement. Then it dawned on me that most frames consist mostly of long-dead cells. Instead of drawing every cell, I really only need to draw the living and recently killed cells. By blanking the display and drawing only the living cells, the speed of the simulation increased dramatically.

The final feature that I knew I must have before I could consider this project releasable would be the ability to manually add cells to the display. This was handled by simply converting the mouse click to a tile coordinate and setting that tile to alive.

With this done, the project is in a releasable state, but I still have at least four hours to invest into this project so the question is what to work on next? More optimization would be nice to speed things up a bit more, but for some reason the idea of adding cancer came to my mind.

DDTe3 Final Thoughts

This was a really interesting episode to create, as the huge number of articles covering it’s creation clearly shows. Game-play wise, however, I am not as sure. While the individual games are enjoyable for a short-term play, I am not entirely sure there is a long-term play value to the games. To solve this problem, I plan on having a future puzzle gallery project which will let players select the picture to play with whichever game they are interested in. I would also like to add new features such as options to control how the grid is shown, and to give randomly generated images. Additional features such as game timers and move counters may also be added. I am really sure how long it will be before this enhanced version will be created (nor do I know how many releases it will take to get to the final version of the puzzle gallery game) but it is certainly something I will be working on.

Will I do another challenge like this again in the future? As the amount of time I have to devote to the Blazing Games site is being reduced in favour of larger scale games, such a challenge does make some sense. I think, however, if I do such a challenge again it would probably be done slightly different. What I think I would do is create a single game in a 16-24 hour period with as many bells and whistles as can be created within the time limit and then the following episode would add as many variations of the base game as can be created in a 24 hour development period. This would give me both the quality that I would like while also giving me a large number of releases. I would probably switch to a weekly release schedule while all the sub-episodes were released. If there were eight variants like there was for this release it would still result in a couple months for only a 24 hour work period which could be handy if a bigger project is heading into some type of crunch time.

Eight games in 24 hours is still quite impressive. A large reason that such a feat is possible has to do with how much software development tools and environments have improved. I suppose I would be able to develop a couple of games in under 24 hours using basic back when the Commodore 64 was my computer. Assembly language I would be lucky to finish a single game and then only if I was able to rely on code from earlier assembly language projects.

When you get right down to it, JavaScript is the basic of our time, with C++ being the modern equivalent to assembly language. While it is possible to still write in assembly language, the time requirements of writing in assembly language are simply not worth the speed and size benefits that it brings. I still think that it is worth learning assembly language if only to understand what the compiler is actually doing.

DDTe3 Hours 22 to 23 - A Distorted Game

Sorry for missing last week, but I was condo-sitting for my aunt. This is a continuation of my series of articles about the creation of the multi-game Dozen Days of Tiles episode 3 where I tried to create as many games as I could in 24 hours. This part concludes the development of the final (and my personal favorite) game in the episode.

In earlier games created this episode, the game data (model) was separate from the display (view) with the interaction between the two handled by the game (controller). Having three separate classes allowed for a lot more reuse as the model class was used in all seven of the other games and there were only two view classes shared by the seven games. As time is running out and there will not be any other games based of of the radically different model that this game uses for arranging the tiles, I am combining the controller and the model into a single game class. The entire game code is so small that it really doesn’t matter and if fact creating multiple classes to do things properly is overkill.  In fact, despite trying to cut back on the amount of code I post and instead try to focus more on the much more important theory, I am going to post all of the code in the game class.

The constructor stores the image and splitting information. It then sets up the root tile, which is the size of the whole puzzle and contains the whole image. This tile is what gets broken apart to form the final puzzle. An array to hold all the puzzle pieces is created and we call the routine to scramble the board. Since this routine is only ever called once, it could have been placed in the constructor but to make the code a bit more readable (as if such a small program has that problem) it is in a separate function.

PuzzleGallery.DistortionPuzzleGame = function(id, w, h, img, clip, splits)
{
    this.supr = new BGLayers.Layer(id, clip.width, clip.height);
    BGLayers.inheritProperties(this, this.supr);

    this.split = splits;
    this.image = img;
    this.clip = clip;
    this.rootTile = new PuzzleGallery.DistortionTile(id, img, clip, clip.width, clip.height, 10);
    this.rootTile.setTileListener(this);
    this.tileList = new Array();
    this.tileList.push(this.rootTile);
    this.selectedTile = null;
    this.addChild(this.rootTile, new BGLayers.Rectangle(0,0,w,h));
    this.scramble();
}

The heart of the game is handling clicking on tiles. This is very simple as all we do is see if a tile has been clicked on already. If it has not been, the tile gets marked as the selected tile and it’s highlight is turned on. If there is a selected tile then we swap the clipping region of both the tiles and un-highlight the selected tile then we clear the selected tile variable so a new selection can be made. That is all the logic needed to handle the game.

PuzzleGallery.DistortionPuzzleGame.prototype.onTileClick = function(t)
{
    if (this.selectedTile == null) {
    this.selectedTile = t;
    this.selectedTile.setHighlighted(true);
    } else {
    t.swapClips(this.selectedTile);
    this.selectedTile.setHighlighted(false);
    this.selectedTile = null;
    }
    this.addDirty(null);
}

The heart of the game is the scrambling as it also breaks apart the picture. The number of splits passed to the constructor is what controls the number of split passes that the scrambler goes through. In theory, each split doubles the number of tiles in the game, but as there are occasionally tiles that are too small to split further, this is not always the case. One the clips that make up the final puzzle are ready, we loop through the list of pieces and let it know that the true clipping region is it’s current clipping region. Finally, we swap the pieces around. The number of swaps is the split size times the number of tiles to make sure that the puzzle is not straightforward swapping of tiles.

PuzzleGallery.DistortionPuzzleGame.prototype.scramble = function()
{
    // breaking up picture
    var child, cntr, listLen, cntrList;// =    this.rootTile.split();
    for (cntr = 0; cntr < this.split; ++cntr) {
    listLen = this.tileList.length;
    for (cntrList = 0; cntrList < listLen; ++cntrList) {
    child = this.tileList[cntrList].split();
    if (child != null)
    this.tileList.push(child);
    }
    }

    // marking correct clips
    listLen = this.tileList.length;
    for (cntrList = 0; cntrList < listLen; ++cntrList) {
    this.tileList[cntrList].setTrueClip();
    }
   
    // scrambling puzzle
    var swap;
    for (cntr = 0; cntr < this.split; ++cntr) {
    for (cntrList = 0; cntrList < listLen; ++cntrList) {
    swap = Math.floor(Math.random() * listLen)
    this.tileList[cntrList].swapClips(this.tileList[swap]);
    }
    }
}

That is the entire game and with about half an hour left is where we end this episode. But that may not be the end of the puzzle gallery. Next week I will have one final article on the topic of this game where I discuss possible future plans.