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.