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.
Sunday, March 28, 2010
Monday, March 22, 2010
Negotiations are a gamble
JavaScript and the HTML 5 canvas are the things that were going to be discussed yesterday but too many other things prevented me from writing the post. I wrote an interesting email today. The contents of that email was "I did not authorise or send any press release as the project was still being negotiated and is currently in an impasse. I assume that this press release was sent by my potential client prematurely, for which I apologise." Perhaps it is best that my "weekly" post was delayed as I have a different topic now.
There is a song about poker that states "you have to know when to walk away, and know when to run." This applies to negotiating as well. There were many warning signs that should have been picked up on, but I don't enter negotiations very often so never acted on them. The problem is that the project sounded rather interesting and if successful would have really given a boost to Blazing Games. When there were more and more misunderstandings, I should have walked away. The problem appears that I came at the project from a web developers perspective while the potential client was looking at the project through a commercial game perspective. Our assumptions simply did not match.
While it is possible that things could have been worked out, this morning I found some strange emails about a press release that I did not send. Worse, the emails were to my private email address that I rarely give out and would never use for a Blazing Games related press release if I ever made a press release. The press release was about the proposed game. It is possible that this was a mistake and that whoever issued the press release did so by mistake. The cynical side of me, which sadly is right far too often, thinks other things. Too many false assumptions when combined with this premature announcement clearly are telling me it is time to run.
Sadly, the only time negotiations are worth-while is when they end in a deal. The rest of the time they just waist time. Time is my most precious resource so it is truly a sad day today. At least Penny Arcade cheered me up.
There is a song about poker that states "you have to know when to walk away, and know when to run." This applies to negotiating as well. There were many warning signs that should have been picked up on, but I don't enter negotiations very often so never acted on them. The problem is that the project sounded rather interesting and if successful would have really given a boost to Blazing Games. When there were more and more misunderstandings, I should have walked away. The problem appears that I came at the project from a web developers perspective while the potential client was looking at the project through a commercial game perspective. Our assumptions simply did not match.
While it is possible that things could have been worked out, this morning I found some strange emails about a press release that I did not send. Worse, the emails were to my private email address that I rarely give out and would never use for a Blazing Games related press release if I ever made a press release. The press release was about the proposed game. It is possible that this was a mistake and that whoever issued the press release did so by mistake. The cynical side of me, which sadly is right far too often, thinks other things. Too many false assumptions when combined with this premature announcement clearly are telling me it is time to run.
Sadly, the only time negotiations are worth-while is when they end in a deal. The rest of the time they just waist time. Time is my most precious resource so it is truly a sad day today. At least Penny Arcade cheered me up.
Sunday, March 14, 2010
Canvassing HTML 5
As I am sure most people who read this already know, HTML is the file format that Internet browsers use. While it is certainly possible to create a web site in php, perl, python, jsp, or a myriad of other server-side languages; these languages ultimately send an HTML file to the browser. HTML 5 is currently a draft standard, which means it is still being developed. In fact, it probably won't be an official standard until 2012 so my starting to use HTML 5 might seem strange. I had planned to stick with Flash/Flex which requires a proprietary plug-in to work but is very widespread. Apple, Google, Opera, and Mozilla are pushing for the new standard and have support for many of the features already. Notice that Microsoft is absent from this list. While I personally don't like Internet Explorer, it is very commonly used. Thankfully, a lot of the HTML 5 features that are not supported directly by Microsoft have had open source implementations so it is possible to use these features. When I discovered ExplorerCanvas (http://excanvas.sourceforge.net/) last year, I figured it was time to start playing with HTML 5, or at least the canvas portion of the upcoming standard.
I remember how excited I was going to Star Wars Episode 1. I had seen the other Star Wars movies many times and was thrilled that a new Star Wars movie was finally coming out. While Episode 1 was not as bad as many old-school Star Wars fans claim, it certainly did not meet my overly-high expectations. This is the way I feel about the canvas tag. For general purpose drawing, it is really good. From a game developers perspective, however, it is lacking. The biggest flaw is there does not appear to be double buffering support. While it is possible to create off-screen buffers of pixels which let you manipulate each pixel individually, these buffers are glorified arrays and don't have any advanced drawing support. In most animated applications you do not want people seeing the frame being drawn which is why double buffering is used. Still, there are a number of ways around this problem so all is not lost.
I have not played around with this idea, but one way to emulate a double buffer would be to simply have a hidden canvas that all the drawing is done to and then the contents of that canvas get copied over to the visible canvas. I have heard of tricks like this being used before, and it would be a simple solution if it can be implemented in a cross-browser compatible way. Dirty rectangle algorithms could also be used, especially since there is really good clipping support built into the canvas class. I suppose writing some low level per-pixel drawing methods and doing the drawing inside the ImageData objects would work, but JavaScript is really slow so I can't see this being a good solution unless your game already has to do a lot of per-pixel work. A raycaster come to my mind immediately. Sadly, I suspect that flicker will be a part of a lot of future HTML 5 games, but computers are very fast now so lets hope this is one thing I am proven wrong about.
I remember how excited I was going to Star Wars Episode 1. I had seen the other Star Wars movies many times and was thrilled that a new Star Wars movie was finally coming out. While Episode 1 was not as bad as many old-school Star Wars fans claim, it certainly did not meet my overly-high expectations. This is the way I feel about the canvas tag. For general purpose drawing, it is really good. From a game developers perspective, however, it is lacking. The biggest flaw is there does not appear to be double buffering support. While it is possible to create off-screen buffers of pixels which let you manipulate each pixel individually, these buffers are glorified arrays and don't have any advanced drawing support. In most animated applications you do not want people seeing the frame being drawn which is why double buffering is used. Still, there are a number of ways around this problem so all is not lost.
I have not played around with this idea, but one way to emulate a double buffer would be to simply have a hidden canvas that all the drawing is done to and then the contents of that canvas get copied over to the visible canvas. I have heard of tricks like this being used before, and it would be a simple solution if it can be implemented in a cross-browser compatible way. Dirty rectangle algorithms could also be used, especially since there is really good clipping support built into the canvas class. I suppose writing some low level per-pixel drawing methods and doing the drawing inside the ImageData objects would work, but JavaScript is really slow so I can't see this being a good solution unless your game already has to do a lot of per-pixel work. A raycaster come to my mind immediately. Sadly, I suspect that flicker will be a part of a lot of future HTML 5 games, but computers are very fast now so lets hope this is one thing I am proven wrong about.
Sunday, March 7, 2010
Programming, the Coming of Language
(Continued from Programming, the Early Years)
The thought was that if the languages would be more human like so it would be easy for people to create software then there would be no need for programmers. The earliest programming languages were created to allow scientists and researchers the ability to write programs themselves which is why FORTRAN is considered to be the first high-level programming language. The idea here being that The programs in these higher level languages would be run through a tool called a compiler which either converted the program into assembly language (which would then have to be ran through an assembler) or straight into machine language.
While higher level languages made it easier to create programs, learning how to program was still a chore. The fact that the programs were ran in batches so there was a long delay between writing code and seeing the results was the biggest culprit. Computers, thankfully, continued to grow in power to the point that there were a lot of waisted computer cycles. To better utilize the hardware, time-sharing systems and terminals started appearing. This lead to the obvious idea of having programming languages that were interactive in nature. By interpreting the code instead of compiling the code it was possible to write programs in real time. The downside to interpreters were that they were significantly slower than compilers.
Another issue that was becoming bothersome was the fact that every machine had a different machine language. Sure, you could simply write programs in high level languages and compile it for the different computers that the program had to be ran on, but different compilers for the same language would compile the code differently so idiosyncrasies were common place. The term for moving code from one computer to another is porting. The fact that a term was created to describe this problem (which still persists today) should tell you that it was not a trivial problem. UCSD Pascal solved this problem by compiling code to a virtual p-machine language. The computer would then interpret this virtual p-code. Because p-code was essentially machine language, the computer could interpret this code much faster than an interpreted language could be ran. Still, it was slower than code compiled for a particular machine. When micro-computers started taking off, the speed difference became a big factor in commercial software sales.
While it seemed that compiled code won, computers continued to grow faster to the point where they were more than fast enough to accomplish most common tasks. At the same time, the internet started taking off. Sites wanted to be more dynamic but had to be not only cross-platform but cross-browser compatible. Both interpreters (JavaScript) and virtual machines (Java) were used to accomplish this. To make the virtual machine fast enough, a new technique called Just-In-Time compiling was developed. The idea here is that the virtual machine code is compiled into native machine language as it is ran so code will run much faster.
The concept of a virtual machine running on the browser seemed to me to be the best solution. Sadly, for a variety of reasons Java never became the browser language of choice but instead ended up largely on the server. Flash is currently the virtual machine of choice for browser programming, but JavaScript is probably the most common choice for web development. The only thing holding JavaScript back is the lack of some of the Rich Internet Application features, but HTML 5 is pretty much solving those issues. It will be a few years before HTML 5 becomes the standard, but with Google, Apple, and Mozilla pushing for the standard it is possible to take advantage of a lot of HTML 5s features right now.
So we have gone from writing code in machine language to compiling the code into machine language to running the code in an interpreter. What is really interesting is that changes in hardware is what drove programming evolution. Computers are now so fast and have so much memory that programmers no longer need to concern themselves with writing efficient code. What matters now is that the code that is written is finished quickly. Sure, many programmers want to write efficient code but they only have to write efficient code in the increasingly rare case where the program runs too slow. What is worse is the fact that programming has moved further away from machine language that there are many programmers who don't really understand what the computer is actually doing. That, however, is a subject for another day.
The thought was that if the languages would be more human like so it would be easy for people to create software then there would be no need for programmers. The earliest programming languages were created to allow scientists and researchers the ability to write programs themselves which is why FORTRAN is considered to be the first high-level programming language. The idea here being that The programs in these higher level languages would be run through a tool called a compiler which either converted the program into assembly language (which would then have to be ran through an assembler) or straight into machine language.
While higher level languages made it easier to create programs, learning how to program was still a chore. The fact that the programs were ran in batches so there was a long delay between writing code and seeing the results was the biggest culprit. Computers, thankfully, continued to grow in power to the point that there were a lot of waisted computer cycles. To better utilize the hardware, time-sharing systems and terminals started appearing. This lead to the obvious idea of having programming languages that were interactive in nature. By interpreting the code instead of compiling the code it was possible to write programs in real time. The downside to interpreters were that they were significantly slower than compilers.
Another issue that was becoming bothersome was the fact that every machine had a different machine language. Sure, you could simply write programs in high level languages and compile it for the different computers that the program had to be ran on, but different compilers for the same language would compile the code differently so idiosyncrasies were common place. The term for moving code from one computer to another is porting. The fact that a term was created to describe this problem (which still persists today) should tell you that it was not a trivial problem. UCSD Pascal solved this problem by compiling code to a virtual p-machine language. The computer would then interpret this virtual p-code. Because p-code was essentially machine language, the computer could interpret this code much faster than an interpreted language could be ran. Still, it was slower than code compiled for a particular machine. When micro-computers started taking off, the speed difference became a big factor in commercial software sales.
While it seemed that compiled code won, computers continued to grow faster to the point where they were more than fast enough to accomplish most common tasks. At the same time, the internet started taking off. Sites wanted to be more dynamic but had to be not only cross-platform but cross-browser compatible. Both interpreters (JavaScript) and virtual machines (Java) were used to accomplish this. To make the virtual machine fast enough, a new technique called Just-In-Time compiling was developed. The idea here is that the virtual machine code is compiled into native machine language as it is ran so code will run much faster.
The concept of a virtual machine running on the browser seemed to me to be the best solution. Sadly, for a variety of reasons Java never became the browser language of choice but instead ended up largely on the server. Flash is currently the virtual machine of choice for browser programming, but JavaScript is probably the most common choice for web development. The only thing holding JavaScript back is the lack of some of the Rich Internet Application features, but HTML 5 is pretty much solving those issues. It will be a few years before HTML 5 becomes the standard, but with Google, Apple, and Mozilla pushing for the standard it is possible to take advantage of a lot of HTML 5s features right now.
So we have gone from writing code in machine language to compiling the code into machine language to running the code in an interpreter. What is really interesting is that changes in hardware is what drove programming evolution. Computers are now so fast and have so much memory that programmers no longer need to concern themselves with writing efficient code. What matters now is that the code that is written is finished quickly. Sure, many programmers want to write efficient code but they only have to write efficient code in the increasingly rare case where the program runs too slow. What is worse is the fact that programming has moved further away from machine language that there are many programmers who don't really understand what the computer is actually doing. That, however, is a subject for another day.
Subscribe to:
Posts (Atom)
