Thursday, May 3, 2012
TMoD episode 4: Space Shield
When researching different disasters the idea of a solar flare was high on the list. The big problem was finding a classic-style arcade game that would work with the theme. Thinking about how to stop a solar flare lead to the obvious placement of satellites, even though realistically you would need way too many. Placing satellites immediately got me thinking of the space junk problem that we are having. This immediately got me thinking about the road-crossing games I played on my cousins Atari 2600 so the game was set.
One of the big issues with the game was the collision detection. Unfortunately, Flash does not have per-pixel collision detection (at least not built in to Flash Player 10, I haven't researched Stage 3D or Starling enough to know if Flash Player 11 does). The object detection is bounding box based. Point based detection does support a per pixel option so I set off on my task to write a simple per-pixel collision detection routine. I originally opted for a simple brute force approach. Flash let's you find the bounding box of a clip relative to a container, so getting the bounding boxes of the two colliding objects then finding the intersection of the two objects is easy. My thought was then to look though the points in the intersection rectangle to see if they both flag collisions at the same points and are therefore overlapping.
In my tests this worked great. The problem is that my tests used vector shapes. When bitmap images were used, anything within the bitmap bounding box was flagged even if it was transparent. There is really no excuse for this other than lazy or incompetent programming at Adobe. This meant that I would have to look at the bitmap data myself. Sadly, this is not a very efficient thing to do.
To get the pixel information, I need to draw into a bitmap data object. This first requires getting a copy of the transformation matrix used to draw the display object. Thankfully this is easily accessible. Next, a translation is applied to only draw the intersection portion of the image. The drawing is done. Repeat for the second object in a second BitmapData object and then compare the pixels in the two bitmapData objects. As this is done using a getPixel function call repeatedly, I honestly can't see this as being very efficient. Then I remembered an article I read about using color filters. This got me thinking about how I could get rid of one of the bitmapData objects and combine the two images into one.
First, you set the bitmapData background color to black. The draw function supports color filters making it possible to max out or clear a color channel. By maxing the red and green channels while dropping the blue channel of the first image then dropping the red channel of the second image while maxing out the green and blue channels of the second image while drawing it over the first image using the ADD filter you will end up with white pixels where the two images overlap. There is actually a built in routine for finding a bounding box containing a particular color so finding the overlapping pixels is easy.
This is not the best way of doing the collision detection, but it works. There are some edge cases where it won't work, but that isn't a problem in this game. It is sad that such a straightforward thing requires so much work.
Thursday, April 19, 2012
Porting Deadly Dodge Ball
I have been slowly moving away from Flash towards HTML 5 for a while with 12 Months of Doomsday most likely being my last Flash project. It is certainly possible that Flash CS6 will somehow convince me to keep developing for Flash, but Adobe has pissed me off quite a bit the last few months so CS6 would have to have extremely impressive features (or a really cheap upgrade from CS5.5) in order to keep me as a customer. For this reason I decided to port my Friday the 13th project from Flash to HTML 5. If porting from Flash to HTML 5 wasn't enough, I thought it would also be a good opportunity to play around with EaselJS, which is a Flash-like animation library for JavaScript.
The reason I thought about using a third-party (open source) library instead of cleaning up and building on top of my own is simply due to the fact that going forward I am going to have less time to spend on my site as I am going to be focused on developing some mobile games. By using a third-party library, I don't have to worry about the low level graphics code and can focus my limited time creating games. There are a lot of choices available, but I decided to go with EaselJS because it is similar to Flash and is being used by a couple of other projects so it has some chance to stay around.
EaselJS is not vector based, but instead relies on image strips. Flash has a feature that lets you export an animation as a series of image files so I used this feature to create the fireball. This left me with a large number of files that had to be combined into an image strip. Sure, it is possible to load the images by hand into a paint program and assemble the image strip but there must be a tool that does this. A quick search for such a tool lead me to Texture Packer. While this is a paid tool, it does have a free version that simply restricts you to the more essential features. This provides enough capability to create image strips for games. As I happen to write a development blog, the author of the tool was kind enough to give me a key for the full version. With that disclaimer out of the way, I do suggest that if you need to take a number of individual frames of animation and turn them into an image strip that you take a look at this tool.
With the movie clip converted into an image strip it was fairly easy to move the code over to JavaScript. The big difference was that the stage does not automatically update itself but requires you call an update function. This is not that huge of a deal as there is a built-in timer class that lets you call a tick function which can be used to call the stage update function. Of course, you also have to remember to change getTimer() into Ticker.getTime() and a few other minor differences, but overall the library feels enough like Flash that it was not too difficult to transition to. It is certainly a library that I will be playing around with in the future.
For those of you interested in either of these tools, EaselJS is located at EaselJS.com and Texture Packer is located at www.texturepacker.com.
The reason I thought about using a third-party (open source) library instead of cleaning up and building on top of my own is simply due to the fact that going forward I am going to have less time to spend on my site as I am going to be focused on developing some mobile games. By using a third-party library, I don't have to worry about the low level graphics code and can focus my limited time creating games. There are a lot of choices available, but I decided to go with EaselJS because it is similar to Flash and is being used by a couple of other projects so it has some chance to stay around.
EaselJS is not vector based, but instead relies on image strips. Flash has a feature that lets you export an animation as a series of image files so I used this feature to create the fireball. This left me with a large number of files that had to be combined into an image strip. Sure, it is possible to load the images by hand into a paint program and assemble the image strip but there must be a tool that does this. A quick search for such a tool lead me to Texture Packer. While this is a paid tool, it does have a free version that simply restricts you to the more essential features. This provides enough capability to create image strips for games. As I happen to write a development blog, the author of the tool was kind enough to give me a key for the full version. With that disclaimer out of the way, I do suggest that if you need to take a number of individual frames of animation and turn them into an image strip that you take a look at this tool.
With the movie clip converted into an image strip it was fairly easy to move the code over to JavaScript. The big difference was that the stage does not automatically update itself but requires you call an update function. This is not that huge of a deal as there is a built-in timer class that lets you call a tick function which can be used to call the stage update function. Of course, you also have to remember to change getTimer() into Ticker.getTime() and a few other minor differences, but overall the library feels enough like Flash that it was not too difficult to transition to. It is certainly a library that I will be playing around with in the future.
For those of you interested in either of these tools, EaselJS is located at EaselJS.com and Texture Packer is located at www.texturepacker.com.
Friday, April 6, 2012
Easter Egg Hunt
I am a bit late writing this this week. I normally post my site and this blog on thursday evening as that way I can keep my friday's free. This week I ended up going out on thursday. Last week on Blazing Games, I posted the open source version of my Easter Egg Hunt game where you navigate a 3D maze in order to find a dozen easter eggs. The eggs are randomly generated. The 3D maze was generated using a very old technique known as the painter's algorithm. I was thinking that none of the techniques used in the game are overly noteworthy then I realized that a lot of the techniques in the game, while not useful when you have OpenGL (including ES and WebGL) to work with, may still be relevant if you were limited to a 2D drawing system like the HTML 5 Canvas. HTML 5 developers, at least the ones that are targeting Internet Explorer, may need to fall back on these old techniques. This is due to MS deciding not to support WebGL.
The egg is simply a palette swapping varient. There are 12 patterns for the eggs, but the two colours that are used to draw the pattern are randomly selected. This is a really old technique that you will see in older video games where the same monster sprite is used repeatedly but given different colours so the same artwork can be used for a large number of monsters. This would be a little tricky to do with the HTML 5 canvas as I don't recall a way of changing an image's palette. I would have to look into this, but if you can't change the palette, you can use the image data to manipulate individual pixels.
The 3D maze uses a technique known as the painters algorithm. Essentially you treat the 3D maze as a series of blocks. You draw the furthest away blocks first, then the nearer blocks, and so on until you are painting the close blocks. The downside to this is you are potentially overdrawing many times. The nice thing about this technique is it is very easy to implement and the results can look very good. Of course, you aren't going to get 360 degrees of smooth scrolling movement, but it is something that can be done on any browser that supports the canvas.
It would be nice if there was a hardware accelerated 3D standard that would work on all browsers, but even if that does happen, it won't be for years. Perhaps for next Easter, I will port the game to HTML 5, though I am hoping I come up with a far better idea for an Easter game before then.
The egg is simply a palette swapping varient. There are 12 patterns for the eggs, but the two colours that are used to draw the pattern are randomly selected. This is a really old technique that you will see in older video games where the same monster sprite is used repeatedly but given different colours so the same artwork can be used for a large number of monsters. This would be a little tricky to do with the HTML 5 canvas as I don't recall a way of changing an image's palette. I would have to look into this, but if you can't change the palette, you can use the image data to manipulate individual pixels.
The 3D maze uses a technique known as the painters algorithm. Essentially you treat the 3D maze as a series of blocks. You draw the furthest away blocks first, then the nearer blocks, and so on until you are painting the close blocks. The downside to this is you are potentially overdrawing many times. The nice thing about this technique is it is very easy to implement and the results can look very good. Of course, you aren't going to get 360 degrees of smooth scrolling movement, but it is something that can be done on any browser that supports the canvas.
It would be nice if there was a hardware accelerated 3D standard that would work on all browsers, but even if that does happen, it won't be for years. Perhaps for next Easter, I will port the game to HTML 5, though I am hoping I come up with a far better idea for an Easter game before then.
Thursday, March 22, 2012
TMoD episode 3 Invasion
Before I begin, I would like to thank Andreas for providing me with keys for Texture Packer Pro and Physics Editor ( http://www.texturepacker.com/ ). I will be using and reviewing those tools in future posts.
This week I am going to take a bit of a look at Twelve Months of Doomsday Episode 3: Invasion which was released last week. As I said before, when creating a game that is paying homage to an existing (old by modern standards) game, I like to have my own twists to the game. Anybody familiar with classic arcade games knows the game "Space Invaders". In this game an army of aliens march back and forth across the screen trying to get to the bottom of the screen. The obvious twist for this game is to have a number of formations. This is clearly not an original twist to the game as there are numerous games that did just this. My personal favorite Space Invaders variant would be Gorf.
To me, this is not enough of a twist, so I thought about having a different movement pattern. This got me thinking about another classic arcade game known as centipede. The neat thing about that game was that if you shot the centipede in the middle, half of the centipede would continue on it's existing course while the other half would immediately drop down a row. This would also give me the chance to have lines moving in different directions at the same time.
Implementing this movement logic was a bit more challenging than I originally expected. The core movement logic is easy enough. The aliens are put into "lines" where they follow the head alien which determines the movement for the line. Each alien simply tries to move to the location of the alien ahead of them. Dividing the line into two is simple enough. The new line gets flagged to move down so that is simple to handle. The problem is determining where the aliens can move to and if they have a clear shot. Checking against every alien to see if a collision was going to happen would be very inefficient. Granted, todays computers are more than fast enough that I could probably have gone this route. Instead, I break the play field into a tile grid and mark the location of aliens on the grid with the ability to reserve a tile so you don't end up with multiple aliens trying to go into the same tile.
As I didn't want aliens shooting through each other, this made checking if an alien was in the clear and could take a shot at the player was very simple. The grid is checked to see if there are any aliens in the same column as the alien. If not (and reserved tiles in that column count as aliens) we know that the alien can take a shot without hitting another alien.
This week I am going to take a bit of a look at Twelve Months of Doomsday Episode 3: Invasion which was released last week. As I said before, when creating a game that is paying homage to an existing (old by modern standards) game, I like to have my own twists to the game. Anybody familiar with classic arcade games knows the game "Space Invaders". In this game an army of aliens march back and forth across the screen trying to get to the bottom of the screen. The obvious twist for this game is to have a number of formations. This is clearly not an original twist to the game as there are numerous games that did just this. My personal favorite Space Invaders variant would be Gorf.
To me, this is not enough of a twist, so I thought about having a different movement pattern. This got me thinking about another classic arcade game known as centipede. The neat thing about that game was that if you shot the centipede in the middle, half of the centipede would continue on it's existing course while the other half would immediately drop down a row. This would also give me the chance to have lines moving in different directions at the same time.
Implementing this movement logic was a bit more challenging than I originally expected. The core movement logic is easy enough. The aliens are put into "lines" where they follow the head alien which determines the movement for the line. Each alien simply tries to move to the location of the alien ahead of them. Dividing the line into two is simple enough. The new line gets flagged to move down so that is simple to handle. The problem is determining where the aliens can move to and if they have a clear shot. Checking against every alien to see if a collision was going to happen would be very inefficient. Granted, todays computers are more than fast enough that I could probably have gone this route. Instead, I break the play field into a tile grid and mark the location of aliens on the grid with the ability to reserve a tile so you don't end up with multiple aliens trying to go into the same tile.
As I didn't want aliens shooting through each other, this made checking if an alien was in the clear and could take a shot at the player was very simple. The grid is checked to see if there are any aliens in the same column as the alien. If not (and reserved tiles in that column count as aliens) we know that the alien can take a shot without hitting another alien.
Thursday, March 8, 2012
The future is collapsing.
When I wrote my original version of Color Collapse last millenium, it was in C++ for Windows 95. At that time the shareware scene was still strong and I had noticed that there were a lot of Tetris and Columns clones appearing. My personal design philosophy is that if you are going to "pay hommage" to a game, you should always have something original or new to add to the game. Obviously, there are exceptions to this rule (such as for existing card and board games) but I've always tried to put my own twist on any game that I am developing. With Color Collapse, that twist was to have the game board filled in at the start and the goal of the game was to clear the board. I don't know if I was the first person to come up with this idea, probably not, but I was not aware of any other game that did this when I originally created the game.
When I finally decided to play around with web development a few years later, I ended up having to port the game from C++ to the then relatively new Java platform. Last year I was going through the games I have created for the BlazingGames site with the goal of seeing what games could have enhanced versions created for it and came up with a lot of new play modes and special tiles that could be added to Color Collapse so decided it would be a good upgrade candidate. Unfortunately, before I got that project started properly, my mother was hospitalized and later died of cancer. The fact that my mother really enjoyed this game both has me wanting to finish this enhanced version while making working on it emotionally hard. The fact that the 2012 meme can only be exploited once dictated my plans for 2012 so this years releases are pretty tied up.
For this reason, I have decided that 2013 would be the year I really focused on properly enhancing this game. My 2011 plans were to write the game in Flash. Now that everyone is writing Flash off, even though I personally think it will be at least until 2016 that Flash will remain strong, I am thinking that HTML 5/JavaScript is probably the route to go with this game. The game is not overly complex so there should be no issues moving the game to JavaScript.
The sad thing is that even that decision is not a straightforward decision. I can use my existing (BGLayers) library for the game. I can switch to another open source library which would probably provide me with better performance and more already implemented features. I could also wait and see what Adobe's Edge tool does. From the tiny amount I have played with an early demo of the tool it does seem like a JavaScript version of Flash but different enough that I would probably have a lot of re-learning to do. All this is assuming I want to write JavaScript using JavaScript. As it turns out, that is not the only option.
Alternatives to writing native JavaScript is Google's PlayN which converts Java into JavaScript and has a game library as well. Also from Google is their Dart language which is in early stages. Then there is CoffeeScript which seems to be gaining a fairly large following.
This is one case where having too many options is just as bad as not having enough. About all I can say at this point in time is that the Color Collapse Plus project will be the site focus of 2013 (subject to change due to unforeseen factors or the incredibly unlikely event that the world really does end) and will be in HTML 5. The how is the tough question.
When I finally decided to play around with web development a few years later, I ended up having to port the game from C++ to the then relatively new Java platform. Last year I was going through the games I have created for the BlazingGames site with the goal of seeing what games could have enhanced versions created for it and came up with a lot of new play modes and special tiles that could be added to Color Collapse so decided it would be a good upgrade candidate. Unfortunately, before I got that project started properly, my mother was hospitalized and later died of cancer. The fact that my mother really enjoyed this game both has me wanting to finish this enhanced version while making working on it emotionally hard. The fact that the 2012 meme can only be exploited once dictated my plans for 2012 so this years releases are pretty tied up.
For this reason, I have decided that 2013 would be the year I really focused on properly enhancing this game. My 2011 plans were to write the game in Flash. Now that everyone is writing Flash off, even though I personally think it will be at least until 2016 that Flash will remain strong, I am thinking that HTML 5/JavaScript is probably the route to go with this game. The game is not overly complex so there should be no issues moving the game to JavaScript.
The sad thing is that even that decision is not a straightforward decision. I can use my existing (BGLayers) library for the game. I can switch to another open source library which would probably provide me with better performance and more already implemented features. I could also wait and see what Adobe's Edge tool does. From the tiny amount I have played with an early demo of the tool it does seem like a JavaScript version of Flash but different enough that I would probably have a lot of re-learning to do. All this is assuming I want to write JavaScript using JavaScript. As it turns out, that is not the only option.
Alternatives to writing native JavaScript is Google's PlayN which converts Java into JavaScript and has a game library as well. Also from Google is their Dart language which is in early stages. Then there is CoffeeScript which seems to be gaining a fairly large following.
This is one case where having too many options is just as bad as not having enough. About all I can say at this point in time is that the Color Collapse Plus project will be the site focus of 2013 (subject to change due to unforeseen factors or the incredibly unlikely event that the world really does end) and will be in HTML 5. The how is the tough question.
Thursday, February 23, 2012
There and Back Again
After taking a look at a number of potential cross-platform solutions for my future larger-scale development plans, I was hit by a wave of nostalgia which has me thinking about my programming path. What I find most interesting is that there is a noticeable trend which may just be starting to reverse itself, but first, lets start the journey at the beginning.
When I was a kid, I first got my exposure to the concept of computers from science fiction. Saturday mornings had re-runs of TV shows such as Star Trek and Space 1999. Star Wars was the big movie that had me wanting to build my own R2D2 and Video Games were starting to appear. My cousin had an Atari 2600 a couple of years after they came out but my parents wouldn't get me one. This is when my oldest sister started taking a course in high school called "Computer Science." After looking at her homework I realized that it wasn't anything difficult so I got the brilliant idea that if I got a computer instead of a game machine I could create my own games that would be better than anything my cousin could buy for his 2600 so I changed my plans to try and convince my parents that subsidizing my purchase of a computer would be a good educational opportunity.
To cut the story short, a few years later I managed to get a Commodore 64 with a tape drive that I was able to hook up to an old black and white television set (the Apple II I wanted was simply way too pricy). The language that my sister was learning in school was the same language my computer used. BASIC. As it turns out, the Commodore 64 was great for games and could easily blow away anything the 2600 was capable of (due to the rather limited hardware of the 2600) but it also turned out that creating games was not easy. Still, thanks to magazines like Compute and Commodore as well as books like 101 BASIC Games, I was able to learn a lot about how to create games. The big thing I learned, however, was BASIC was just too slow. Reading the programmer reference manual hinted at the solution to my speed problem. Something called Machine Language.
The Commodore 64 used a RISC-like processor known as the 6510 so my first entry into the world of assembly language was the 65xx dialect. This became my predominant programming language. I loved assembly language as it was so much faster than BASIC though was still not fast enough for what I wanted to do and required a lot more work than BASIC. As many programmers at that time did, I compromised by taking advantage of a 4K block of memory located at $C000 (49152) to store small assembly language routines that could be called from BASIC.
When I reached high school, our school was a test-bed for a new type of computer known as the Macintosh which we were programming using a structured programming language known as Pascal. The BASIC that my sister took was no longer part of the curriculum. This was probably the best thing that could have happened as if nothing else, it taught me the evils of spaghetti code and taught me how to better structure my programs.
When the Amiga 500 came out, I was able to get one as part of a bundle that included a huge suite of software including Deluxe Paint 2. The store owner was able to sell me a discounted copy of Latice C as it had been opened and returned. This lead me to discovering the C programming language which my Computer Science teacher did not care much for as I would constantly tell him that it was way better than pascal as it had all the structure plus was much closer to assembly language. In fact my compiler had an option to compile to assembly language so you could write the program in C and then fine tune the resulting code.
In College my language repertoire was increased and my Amiga started having random reset problems. As our computer science lab used IBM machines anyway, I decided to move to a 386 running DOS 5 and Windows 3. When Visual C++ came out, I switched from C to C++.
The big thing that happened in the mid nineties was something called the internet. As I was living in a small town, it was hard to get internet access but thankfully the phone company decided to give my town free long distance to a nearby larger town so I was able to get online (30 hours a month at 14400 baud initially). I was disappointed by how limited browsers were but in 1996 Java came out. The language was enough like C/C++ that I had no problems using the language and had the huge advantage that it would allow you to create programs that could run on a web page without requiring the user to download any type of plug-in or perform some type of installation which I felt would turn away most average users.
For various reasons, Java never worked out quite the way I had hoped. This was largely due to Microsoft wanting an incompatible version of Java to run on their machines which effectively ended up causing Java to stagnate on the browser. For the best compatibility, Java developers essentially had to stick with Java 1.1 instead of being able to take advantage of the new features available to server side developers. This is when an animation tool called Flash added a scripting language known as ActionScript so I started experimenting with Flash.
Now we are at another interesting transition point. With app stores everywhere and Flash starting it's decline, I am looking at which direction to head. One direction is towards HTML 5 which is far less feature-rich than Flash making it a step backwards. The other is a return to C++ and a shift of priorities to phone/tablet/mac store/windows store development. Looking at the trend, I started with a low level language and went higher and higher level till I ended up with a scripting language. Now as Moore's Law is finally starting to show it's head, I suspect that there will be a shift back to C++ and possibly even hand-written assembly language to optimize the critical parts of a program may even start becoming the trend. Who knows what the future holds. Maybe Adobe CS6 will have Flash development tools that actually produce good code for mobile devices. I suspect, however, that I will be shifting back to C++ with some JavaScript for my smaller games.
When I was a kid, I first got my exposure to the concept of computers from science fiction. Saturday mornings had re-runs of TV shows such as Star Trek and Space 1999. Star Wars was the big movie that had me wanting to build my own R2D2 and Video Games were starting to appear. My cousin had an Atari 2600 a couple of years after they came out but my parents wouldn't get me one. This is when my oldest sister started taking a course in high school called "Computer Science." After looking at her homework I realized that it wasn't anything difficult so I got the brilliant idea that if I got a computer instead of a game machine I could create my own games that would be better than anything my cousin could buy for his 2600 so I changed my plans to try and convince my parents that subsidizing my purchase of a computer would be a good educational opportunity.
To cut the story short, a few years later I managed to get a Commodore 64 with a tape drive that I was able to hook up to an old black and white television set (the Apple II I wanted was simply way too pricy). The language that my sister was learning in school was the same language my computer used. BASIC. As it turns out, the Commodore 64 was great for games and could easily blow away anything the 2600 was capable of (due to the rather limited hardware of the 2600) but it also turned out that creating games was not easy. Still, thanks to magazines like Compute and Commodore as well as books like 101 BASIC Games, I was able to learn a lot about how to create games. The big thing I learned, however, was BASIC was just too slow. Reading the programmer reference manual hinted at the solution to my speed problem. Something called Machine Language.
The Commodore 64 used a RISC-like processor known as the 6510 so my first entry into the world of assembly language was the 65xx dialect. This became my predominant programming language. I loved assembly language as it was so much faster than BASIC though was still not fast enough for what I wanted to do and required a lot more work than BASIC. As many programmers at that time did, I compromised by taking advantage of a 4K block of memory located at $C000 (49152) to store small assembly language routines that could be called from BASIC.
When I reached high school, our school was a test-bed for a new type of computer known as the Macintosh which we were programming using a structured programming language known as Pascal. The BASIC that my sister took was no longer part of the curriculum. This was probably the best thing that could have happened as if nothing else, it taught me the evils of spaghetti code and taught me how to better structure my programs.
When the Amiga 500 came out, I was able to get one as part of a bundle that included a huge suite of software including Deluxe Paint 2. The store owner was able to sell me a discounted copy of Latice C as it had been opened and returned. This lead me to discovering the C programming language which my Computer Science teacher did not care much for as I would constantly tell him that it was way better than pascal as it had all the structure plus was much closer to assembly language. In fact my compiler had an option to compile to assembly language so you could write the program in C and then fine tune the resulting code.
In College my language repertoire was increased and my Amiga started having random reset problems. As our computer science lab used IBM machines anyway, I decided to move to a 386 running DOS 5 and Windows 3. When Visual C++ came out, I switched from C to C++.
The big thing that happened in the mid nineties was something called the internet. As I was living in a small town, it was hard to get internet access but thankfully the phone company decided to give my town free long distance to a nearby larger town so I was able to get online (30 hours a month at 14400 baud initially). I was disappointed by how limited browsers were but in 1996 Java came out. The language was enough like C/C++ that I had no problems using the language and had the huge advantage that it would allow you to create programs that could run on a web page without requiring the user to download any type of plug-in or perform some type of installation which I felt would turn away most average users.
For various reasons, Java never worked out quite the way I had hoped. This was largely due to Microsoft wanting an incompatible version of Java to run on their machines which effectively ended up causing Java to stagnate on the browser. For the best compatibility, Java developers essentially had to stick with Java 1.1 instead of being able to take advantage of the new features available to server side developers. This is when an animation tool called Flash added a scripting language known as ActionScript so I started experimenting with Flash.
Now we are at another interesting transition point. With app stores everywhere and Flash starting it's decline, I am looking at which direction to head. One direction is towards HTML 5 which is far less feature-rich than Flash making it a step backwards. The other is a return to C++ and a shift of priorities to phone/tablet/mac store/windows store development. Looking at the trend, I started with a low level language and went higher and higher level till I ended up with a scripting language. Now as Moore's Law is finally starting to show it's head, I suspect that there will be a shift back to C++ and possibly even hand-written assembly language to optimize the critical parts of a program may even start becoming the trend. Who knows what the future holds. Maybe Adobe CS6 will have Flash development tools that actually produce good code for mobile devices. I suspect, however, that I will be shifting back to C++ with some JavaScript for my smaller games.
Thursday, February 9, 2012
TMoD Episode 2 Moon Run
Moon Run, the second episode of my Twelve Months of Doomsday series, was - like all the episodes of the series - inspired by classic arcade games. The big difference with this game from the other games in the series is that it was inspired by only a single game and I never actually played the game in which it was inspired by. I suppose to be perfectly clear, it wasn't actually the game that inspired me but the advertising for the game. This requires a trip back to my childhood where the stray memories came from.
When I was a kid, arcades where a profitable business with video games being the big draw. The home video game consoles were just starting to emerge with the Atari 2600 being the big thing as it would allow you to play arcade games on your TV. Of course, the quality difference from the arcade machines to the home version was huge. A large part of the decline of the Arcade is a byproduct of video game consoles ever-growing power as after a certain point the home versions of the game were good enough that it was no longer necessary to go to the arcade to get the full experience.
Video games at that time were thought of as kid's things. Far too many politicians still think they are as many politicians are too ignorant to realize that a person might continue to play video games after they have grown up. Sort of like how people learn a sport as a kid and still play it as an adult. The point being that something aimed at kids requires advertising aimed at kids and that meant comic books. Comic books are also like video games in which there are many adults who read them. Even back then. But that is a different pet peeve. One of my aunts was a huge comic book fan. She was also an insomniac who would read dozens of comics before going to bed. This was actually a good thing for me and my cousin as my aunt would give us boxes full of the comics she had read. She was a particular fan of Marvel comics which is probably why I am a Marvel fan.
The comic advertisements for video games where often in the form of mini-comics outlining the story behind the game. The concept presented for Moon Patrol was one of driving a moon buggy jumping over craters while shooting down aliens. As a kid this sounded great. From what my friends told me, however, the concept was much better than the game so I never actually bothered with the game. Advertising didn't always fail, however. The D&D ads in the comics actually got me interested in role-playing games.
So, the game was technically not inspired by a classic arcade game. It was inspired by an advertisement for a classic arcade game. Proof that inspiration can come from unexpected sources.
Subscribe to:
Comments (Atom)
