Thirteen Spikes Unlimited 1.0

Thirteen Spikes Unlimited is now finished and has been on the Blazing Games site since Friday the 13th. As I have mentioned before, there was some plans to port the game over to HTML 5. ActionScript and JavaScript are very close as they are both variations of ECMAScript. This makes the game logic very quick to port, even if JavaScript does not have as nice of class or variable support as ActionScript. The other thing that ActionScript has that JavaScript lacks is the Flash library. Because Flash was created as a streaming vector animation system, this library is greatly tied to graphics and animation. The HTML 5 Canvas simply does not have these classes, but there would be very little stopping someone from writing them. In fact, to implement Thirteen Spikes Unlimited, only a small subset of the class library would be needed.

This would require a bit more time than I have, so the port to HTML 5 didn't happen and instead themes, campaigns, and sound were added to finish off the 1.0 version. This does not mean that the next Friday the 13th won't have a HTML 5 version of this game. That would be May of 2011, so depending what is happening with my current projects (one which may be doomed) this might be an interesting project. So, while Thirteen Spikes is finished for now, it may resurface in the future.

Hurry up and Stop

One of the most frustrating things about doing third party work is that often you are in a hurry up and stop situation. Clients seem to always be in a rush to get things done. This is to be expected. What confuses me is the same client who is rushing you to get on things seems to continually do things that slow down progress. I am not sure why this is the case, but it probably largely is the result of people still having no clue what programmers actually do and how software development works. Considering how important computers and computing devices such as iPhones and Android phones have become, this really is inexcusable. Here are some of the pet peeves that I have had in the past.

When material is needed before programming can begin, then not getting that material to the programmer is going to delay the project. This is especially true if the required thing is legal documents. Programmers are probably more anxious to start work then you are, but I don't start work until all the legal matters are (or appear to be) settled. Assets that the project depends on are almost as vital. While it is certainly possible to work around missing images or databases, this generally requires more work on the programmers part. First, temp artwork or data has to be created. Second, when the real materials come in, the real assets then have to be integrated and far too often this requires changes to the code due to the fact that often clients don't follow the specs that were sent to them.

Real programming is very mentally taxing. Sure, there are a lot of "programmers" who just assemble other peoples code together, but if you are actually creating code it requires a lot of thought. Having someone wanting to phone you or message you every half-hour is a sure way to kill productivity. When a programmer is in the middle of coding or debugging, any interruption breaks their train of though. This train of thought takes time to recover, so you are costing the project at least 5 or 10 minutes, possibly more, every interruption.

Changes are to be expected, but when a build is sent to you to evaluate, have the courtesy to actually look at the build asap. Waiting months to tell the programmer about a problem is beyond stupid. The longer a bug is in your code, the harder it is to find. Likewise, if you are not actively working on code, it takes longer to get back in the mindset you were in when you wrote that code. And worst of all, adding features to a project when the deadline isn't increased is just asking for a project to enter doomed status.

I could go on, but I think that I've stood on the soap box long enough.

Plans for the remainder of 2010

I am about to embark on a rather interesting third-party project while continuing my own project so the amount of time that will be dedicated to the Blazing Games site will be reduced in the short term. The third-party project will probably appear on Blazing Games once it is done as will my own project but as both of those are large-scale projects. Thankfully, 3 of the 5 months are mostly done, one of the months can be done in a day, and the final one can be reduced from 4 layouts to 2 layouts.

I really don't like posting my release plans as things have a way of changing quickly causing my plans to be altered. Still, I suppose it won't hurt as long as it is clearly understood that these plans are subject to change without notice.

The August game will not be released until the 13th as it is the 1.0 version of Thirteen Spikes Unlimited. I am thinking of porting it to HTML 5, but am not sure about that plan now that my time has been reduced even further. September will be the final episode of Dozen Days of Words. October will be the Vampire Attack 2 open source release. Thoughts of porting to HTML 5 are there but again I doubt there will be time. November will be a couple more Tarot layouts. Finally, Dungeon Romp Christmas Edition in 3D will finish off the year.

Why Tarot?

Sorry for the lack of posts the last couple of weeks but travel, funeral, and other events have kept me busy. This isn't even counting negotiations that I am involved in but I definitely  don't want to talk about that. Instead, I will briefly explain why somebody who is often considered a skeptic is spending so much time creating a Tarot fortune telling game. I don't think that Tarot cards can tell the future, but I do think they can be a mirror to the soul. By soul I am referring to a persons true nature. Why I believe this will take a bit of explanation.

The Tarot consists of 78 cards. 21 cards form the Major Arcana, 56 cards form the Minor Arcana which are essentially a deck of playing cards, and 1 Card (the Fool) is between the two and represents the average person. These cards all have a symbolic meaning attached to them. The thing is, when I was researching the Tarot I discovered that the cards had a variety of meanings attached to them. The meaning of the cards are whatever the reader attaches to the card. More importantly, because the cards are highly symbolic in nature, cards can have a wide variety of meanings. This is where the mirror metaphor comes in.

When reading a layout, it is not just the symbol on the card that matters, but the person for whom the layout is for. Because the person is associating themselves and their situation with the cards, they are looking deeper into themselves to find meaning. What you then have is an essentially random set of symbols that get meaning attached to them. Some people may believe that "spirits" or other mystical forces are influencing the shuffle, but pure randomness works just as well. Ultimately, what you have is a brainstorming tool that is designed to work on the emotional level.

So, in summary, I like the Tarot because I think it is a really neat brainstorming tool. Unfortunately, the mysticism surrounding it may have obscured it's true value. I am sure that many fortune tellers really do believe they are foreseeing the future (and if they know the person whom they are doing the reading for well enough they may in fact be able to predict that persons future actions) but I do have to wonder how many of them are just in it for the money and are just playing on the mysticism to draw the crowd?

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.

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.

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.