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