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