Saturday, June 26, 2010

Developing a video game without a "computer"

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.

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 and 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.

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.