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 25, 2010
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.
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.
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
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.
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.
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.
Subscribe to:
Posts (Atom)
