LD#25 postmortem

As is becoming a regular feature with Ludum Dare challenges, shortly after the challenge I like to write a postmortem of the game I created. The theme for Ludum Dare #25 was "You are the Villain." The game that I created for the challenge was "Evil Gnome's Revenge." This game has you playing the Evil Gnome from one of my earlier Christmas games (Santa's Snowball). As the gnome is not able to steal toys, he is instead going to release Santa's reindeer from the corral that he keeps them in.

What went right

The first thing that I did right was choosing a simple game to develop.  Even simple games take longer than you think they will to create. As polishing games is one of my weaknesses, I figured that the sooner the game was functional the  sooner I could start polishing the game and perhaps end up with a really great game. While I was able to get the basic chase mechanics working right away, I still spent a lot of time coding so didn't get as much polishing done as I would have liked. Missing features include fully animated reindeer, idle actions for the reindeer, and an evil version of a Christmas song for the theme.

The second thing that went right was getting proper rest. As Todd was having his 24 hour podcast while the challenge was going on, I had plans on listening to the whole podcast while I was fine-tuning the game. When I realized that I simply was not far enough along. There is a big difference between an hour of work done when exhausted and a productive hour of work. By spending a few hours sleeping I was able to regain my focus and get the game done. I honestly believe that the extra productivity gained from getting a few hours of sleep more than made up for the hours lost.

What went wrong

While I  liked the theme when voting, shortly before the announcement there was a major high school shooting which really  put a damper on it.  When I heard the theme I knew that I wanted a non-violent game.  It took me about an hour to come up with an idea that would fit the theme yet would not be violent. Had the shooting not happened I would have gone with one of my other ideas which probably would have resulted in a more entertaining game.

The other big problem that I had was the realization that I was writing far too much code. A lot of the code I was writing was fairly straight-forward and should be handled by my GameJam library. The library is in a early state so this is understandable, but I am going to have to find ways of creating classes that incorporate a lot of the generic code that I was writing into them.  Basic movement logic and collision detection are common to most games so having that inheritable in a generic game screen class would be a huge time-saver.

Conclusion

While I ended up with a fairly solid game, it simply is not quite as polished as it should have been. I am going to have to find spare time  before the next game jam and update my library to incorporate a lot of the more generic game elements so rapid game development will be easier.

GameJam library release 0.01

For 2013 I plan on focusing more on my larger scale potentially commercial projects with Blazing Games content coming from game-jam competitions such as the Ludum Dare challenge that is taking place this weekend. As these challenges allow for use of your own libraries as long as they are shared before hand, I am planning on creating a GameJam library to make it easy to create games quickly. The first release of this library is located at http://blazinggames.com/other/openLibrary/html5Libs.php but I don't recommend anybody use it yet. This is still a very primitive release. For those who are curious, I am going to outline my plans for this library.

First, I want to get basic 2D game elements, such as scrolling maps and multiple layers of sprites fully working. This is mostly there but the code needs a lot of cleaning yet before I would be happy with other people using it. I suspect that seeing where things need improvement while participating in a couple of game-jams will get me to the ready for consumption point.

Once this is done, I will add a couple of kits to the game focused on the major elements of common Genres of games. The idea here is that there would be core mechanics for a number of types of games that can be mixed and matched. That way if I go into a game-jam and think that a RPG would be ideal, the core elements such as character sheets, inventory systems, conversations, dice rolls would all be ready to go so I could get the game skeleton done in a few hours and spend the rest of the competition focusing on the content of the game. Essentially, I want the ease of a game-making tool yet with the flexibility of total control of the code. More important, at least to me, I want the library to be mine. I am making a slight exception to my-own-code ideal by using the starling library for 3D acceleration of the 2D graphics but when I get to my final step in this project, that will not be the case.

Once I have the ActionScript library in a stable state, I will port the library to HTML5. The decision to develop the library in AS3 initially is due to the fact that I can get something useful much quicker as I am far more comfortable with ActionScript. As the world is shifting to JavaScript, it only makes sense to shift development to that platform. I will probably have both Canvas and WebGL versions of the sprite/map renderers to take advantage of hardware on browsers that support WebGL while still allowing IE users to play the games.

I have no timeline for the library (and am actually not putting in as much time towards the library as I hoped) but plan on updating the library before every game-jam that I plan on entering.

Simple RPG Postmortem

For the Mini-Ludum Dare#38, the Charity Game Jam, there was a theme of NES-Style games with the restricted size and palette of such a machine.  I created a simple RPG, creatively named Simple RPG. So lets have a mini-postmortem of that challenge.

What went wrong

The biggest mistake made with this challenge was going with such an ambitious project. Creating a role-playing game relatively from scratch is a huge undertaking even when you have lots of time. I suppose that if I had an existing RPG engine that I was building on, this would have been a different matter. But if I had started with an existing RPG engine (such as my Coffee Quest 4 engine) then I wouldn't be creating a game but instead would be making a mod.  Still, when I think of the NES, my thoughts immediately go to RPGs as that is the type of game I gravitate towards. Had I not have created RPGs in the past and had an extremely clear vision in my mind this project would have been a failure. As it turned out, I ended up with a playable game though one that clearly  needs balancing and more content.

The second mistake with this project was using a very early build of my GameJam library. This is a library that I am developing  for use in future GameJam competitions as I am planning on participating in GameJams frequently over the next few years. Partially because they are fun, but mostly so that I will have content for my Blazing Games site while developing some of the larger-scale games that keep being put on my back-burner. The problem with the library at this time is that it still is missing a lot of functionality, has bugs, and still hasn't had it's API locked down. Lack of any type of console support was a big issue as I ended up spending the first few hours of the competition creating a console as the RPG menus rely on console-text. The few hours lost to not having this code could have been spent on balancing the game and improving the artwork.

What went right

While the library was one of my mistakes, it was also one of the things that went right. By having a library of common game functionality, I was able to save a number of hours when it came time to creating the game maps. Ultimately, I want to get my GameJam library to the point where it has the power of the game-creator programs that are available yet still being flexible code that I have created. As it has been a long time since I have played a NES RPG, I couldn't remember if it had smooth scrolling so opted to make the map movement more chunky. Now that I think about it, I probably could have taken advantage of my smooth-scrolling maps. Still, having major functionality  readily available in a library makes rapid development much easier.

Finally, keeping the scope of the game down as much as was reasonable was a huge help.  Multiple multi-level dungeons, stores, a vast array of equipment, and side quests would have been nice to have but was unrealistic with only 48 hours of real time. By limiting the world to only 3 maps, I knew that the game was a reasonable size to finish within the short development time. Even when you have an overly-ambitious project, or rather specifically when you are biting off more than you can chew, keeping the scope of the ambition as small as you can get away with is always a good idea. After all, you can always add more content in the future if the project is successful, but when you throw away partially created material you are throwing away the time invested in that material as well.

Eating Trees

While it is clear that Alien Bugs was inspired by the classic arcade game centipede, the games are quite different. Instead of the worms-style long insect bouncing off of mushrooms, these are giant individual insects who eat trees while bouncing off of each other. Instead of just being able to shoot up, the player is able to shoot in any direction. And the biggest difference is that the playing area is larger than the screen so the player has to hunt down the insects. Actually, old horror movies such as "Them" is probably as much of an inspiration for this game as centipede was. Come to think of it, they haven't made a giant insect movie in quite a while.

This game was a bit rushed as I was originally going to release this game on the 23rd, but as the Mini-Ludum Dare competition is scheduled for that weekend, I figured that I would get this episode out as quickly as possible. Thankfully, a lot of the code from earlier episodes could be utilized in the creation of this episode.

The most interesting challenge in creating this episode was in the handling of eating trees. If the tree is eaten in four quadrants, the possible eating combinations can easily be represented using binary bits for each quadrant.  This means that 16 tiles are needed to represent all possible eating combinations.

Actually eating the trees initially appeared problematic. The new tree state is based on the current state combined with the eating direction. This would result in overly-complex conditional statements but I quickly realized this work could all be pre-computed. By simply having arrays of next-state for each possible tree-state it is simply a matter of looking up the next state. There are a couple of flaws with this system. First is that when you have multiple bugs eating the same tree, there will be cases where the tree is eaten while one of the bugs will continue eating the tree. Likewise, two bugs eating a single quarter of the tree will not eat that quarter faster than a single bug eating it. These problems are not overly noticeable so it is not worth the effort to solve these problems.

Zombie Starlings

While I might have been able to do more with this game had I used the Alein's Zombie game engine as my starting point, I decided to give the Starling framework a shot so spent a good chunk of time porting my existing code over to Starling. Actually this is probably not a big waste as I am going to be using this code as part of my Game Jam library that I am developing for use in future game jam competitions.

One of the reasons that I have decided to experiment with the Starling framework is simply that it is the sister-framework to the native iOS Sparrow framework. My thought is that I can do my prototyping in Starling as I am still fairly productive in ActionScript. If it proves to be too inefficient,  the option of going native is much easier as the frameworks are similar enough to make the porting of code very quick.

The map rendering was greatly modified when porting my old map code over. The old way I handled the map was to simply create a large sprite made up of tiles and simply moved this larger sprite around to scroll the map. While I am sure this technique could be used for Starling, the larger-scale games I am working on will require really large maps. As the size of these maps could exceed Flashes size limits, I opted to go with a slightly different technique.

I create a large sprite that holds just enough tiles to be one tile larger than the screen will hold. The tiles are set to the map tiles that correspond the top-left corner of the screen. Every time the map is scrolled to the point where one of the edges of the viewport sprite is visible then the map is repositioned and a new set of textures are assigned to the tile. This allows for smooth scrolling while not having to worry about size restrictions. It also requires a lot fewer sprites to be created which helps with memory and speed.

Torchlight II

The best way of improving your skills at something is to actually do it. The old saying that practice makes perfect is mostly true. I am one of those people who don't believe that perfection is possible as there is always room for improvement. The second best way of learning is by learning through others. That is at least the excuse that I use when playing games. Just playing a game is not enough, though. To learn from a game you need to think about why you are enjoying the game. Think about why the elements work. Often even the annoying things serve a purpose. I have found that it is easier to learn from a bad game than a good game as the mistakes that make the game un-enjoyable tend to stand out far more than things that make a game good.

My sister got me Torchlight II as an early birthday present (yes, she told me I could install and play it before my birthday this Sunday) so I decided to take a look at why this game is getting such good reviews. I am only a few hours into the game but have enjoyed the game so far. The biggest lesson to be learned is that small cute dogs can be extremely vicious.

The game supposedly randomly generates the maps to increase the replay-ability.  The levels I have played so far are pretty good but I have noticed that a lever puzzle was repeated making my second attempt at getting the treasure exceedingly easy as I knew exactly what steps were needed to solve the puzzle. What I suspect is going on is that the random dungeon uses a mix of random dungeon generation and canned chunks of dungeon.

This is actually a good approach to take, as it gives the replay-ability of randomly generated dungeons while also giving the much more streamlined and thought out designs that human created maps have. For me, and probably a large number of Torchlight players, this random generation of maps is lost on me as I have such a backlog of games that it is unlikely I will be replaying the game multiple times.

One advantage of hand-crafting the maps, at least in theory, is that it gives the designer more control of the game difficulty. Torchlight II appears to have solved this problem by using the player's current level when generating the quest map. So far every map I have come across has had the levels exactly mach my current level. I am not sure if this is actually the case or my exploration has just coincidently matched the level suggestions. I am hoping the later as one advantage that canned levels have is that it is possible to grind if the game gets too difficult. If all the levels are based on the level I am when I reach the quest then if the game is getting too hard, I am going to have problems.

MiniLD#37 Postmortem

As anybody who read the previous blog post already knows, I entered the Mini-Ludum Dare #37 challenge. This had the not-a-game and real-time themes. My entry was Musatic, which was a rhythm game but with the twist that you create your own song and dance in real time. As the initial phase of creation was in real-time and the focus was on the creation of music/dance instead of the actual game, I feel that both themes were at least loosely met. Now that the challenge is finished and I have had time to reflect on it, this post will be my mini-postmortem.

What went Right

Choosing music for my theme seemed like a really risky thing when you consider how little I know about the subject. Still, I believe that the best way of learning something is by doing it so writing a game that revolves around music would at the minimum give me some working experience. My goal behind this project was to create something that someone who knows nothing about music could use to create a short song. The first step was to create notes. As Audacity has a pluck generator, a range of notes were created. I decided that the easiest way of handling music would be to have all the notes that make up the song the same length. This made editing and replaying the music much easier as I would only need a grid that indicated what notes to be played at what interval.

This lead to my first day of work being focused on the creation of the music editor. My original thought was this would be a cheat mode, but I wanted to have the editor functioning for testing. When it took far longer than I originally anticipated to get the editor to a functional state, I had thought that focusing on the editor was going to be a what went wrong entry, but as I started playing with the editor, I realized that it was kind of fun so upgraded the editor to a main-menu item.

What went Wrong

Yet again, I made the mistake of not having a library ready. As creating a game engine, even one for such a simple game, is time consuming, it would be wise to go into a game jam with an existing game engine. I've noticed that a number of participants use game creating tools such as Game Maker, but I would prefer to have my own engine. Something that handles all the basics of a game so that the 48 hours (less with sleep) can be focused on the game not on the plumbing of the game. Some people may point out that I am using the Starling framework, which could be considered a library. This really is not the case as Starling is more for giving Flash a 3D acceleration boost rather than adding new capabilities.

Speaking of Starling, using an unfamiliar framework would be my second mistake. While I had been playing around with Starling before starting on this project, I had not actually finished a project using it. As a result, there are a lot of things that I did not know about the framework so did not know what issues there were. I actually did run into an issue with the way I implemented the editor. I am not sure what exactly the problem was, but suspect that I simply had too many objects with listeners attached to them. Had I been more familiar with the framework, the approach I took towards creating the editor screen would have been different and the performance of the editor would probably have been much greater.

Going forward

I actually really enjoyed this project and learned a lot. It is a project that most certainly be expanded upon so is probably something that will be revisited if only to enhance the music editor so quick and dirty music scores can be created for future game jam projects. If I do decide to update the full game, I suspect that it would take the form of an AIR application so that it would be easy to save and play levels.

Mini Ludum Dare #37

As M.A.D. is a very simple game, I figure that instead of looking at how it was made I would instead discuss the upcoming Ludum Dare mini event that I hope to participate in this weekend. The mini-events are far-less strict than the regular events and are for fun. While judging gives you feedback on your game (something I really don't get enough of) I have been entering game-jams for the fun of creating games. As I am starting to focus on much larger-scaled games, game-jam releases will probably become a much more regular feature on BlazingGames as that will allow me to continue to have regular content on the site yet still be able to put the time necessary to create larger games.

The theme for the game was announced early so I have had a few days to think about what I will do. This is a mixed blessing. On one hand I am able to plan out the game in my mind. On the other hand I am anxious to get started.  The theme for this challenge is not a game. An alternative theme is real-time. After sleeping on it, I came up with a game idea that fits both themes and also focuses on my two biggest weaknesses. My interpretation of the themes might be a bit different than other peoples, but that is part of the fun.

The no-game game makes me think about sandboxes. There are a number of games where the player is given tools to build things. There is no goals or win condition but instead the player has fun creating things.

The real-time game to me has two different meanings. The first is that time passes in real time so what takes a minute in the real world takes a minute in the game world. This is where my idea fits the theme. A more interesting meaning of the theme is to tie the date and time to to the game. I have seen a number of games that do this and if done well adds to the game. This can detract from a game as well as some players may only be able to play a game at a certain time and as a result be limited with what they can do.

The focus on my weaknesses is the best way of improving my skills. More to the point, I am hoping that by the end of the challenge I will have the start of a tool that will allow me to better overcome my weakness in future projects.

While I do want to shift to HTML development, the game will initially be written in Flash as despite the similarities between JavaScript and ActionScript the later is still faster to develop in. For me, Flash professional CS6 and Flash Builder 4.6 are the tools to use for Flash development with Flash pro also being adequate for my art needs. While I don't absolutely need the starling framework, it will be used. Audacity will be used for sound editing.

Ludum Dare #24 postmortem

People who have visited Blazing Games last week or who are following me on Google Plus already know that I recently participated in the Ludum Dare #24 challenge. This is a challenge where you have 48 hours to develop a game that reflects on the theme of the challenge. This theme is announced at the start of the challenge and this time was Evolution. For this fortnight's post, I have decided to write a mini-postmortem of my entry.

What went right

This was my first Ludum Dare but I had participated in the 7DFPS challenge so I was aware of how quick time goes by in these type of challenges so from the beginning decided that the best way of proceeding was to quickly get a functional game and then iterate on it. The theme of evolution immediately gave me the idea of missing links so the first pass of the game was simply a search of the map for the missing links. I then cleaned up the game to make sure I had something to release before the deadline. Finally I added the combat to the game.

My other wise decision was to take advantage of the photography rule. The challenge allows use of photographs and generated sounds as long as they are created during the 48 hours of the challenge. By quickly taking some photos and using a sound effects generator I was quickly able to come up with good looking game assets in a really short period of time. This gave my game a more polished look without the time burden.

What went wrong

The biggest mistake I made was not having a library of game code ready beforehand. Writing an engine from scratch is not really a good idea when you have time pressures. When you consider that one of the complaints for my game was the sluggishness of the scrolling, Having an optimized map class to start with would have been much nicer and would have given me more time to fine tune the game.

The combat was a bit too last-minute so ended up being a bit more difficult than what I would have liked. I should have listened to the voice in the back of my head telling me to cut the speed of the spiders down and lengthen the whip. I didn't and as a result a lot of people found the game too challenging to finish.

I am thinking that entering game jams will become a bigger part of my life. I really don't care if I win, but do enjoy the challenge and can use the resulting game on my site while I start focusing on the development of larger scale games that can actually turn Blazing Games into a real company instead of a hobby.

Making Jupiter Battle

This fortnight I am going to take a look at episode 8 of Twelve Months of Doomsday. It shared a fair bit of code with an earlier episode in the series (I'll leave determining which episode as a challenge to you) so development was fairly quick. The big thing with this episode was the addition of gravity. Some people who have played this game didn't think I made the gravity strong enough, but at the same time I didn't want it too overwhelming. If there is a future release of this game, I may tweak it a bit more.

In physics, gravity is actually the weakest of the known forces in the universe. It, however, acts across the length of the universe. The further away from an object the less gravitational influence that object will have. The formula for determining this is Force = Gravitational_constant * (object_1_mass * object_2_mass) / distance^2. For the game this is simplified. The planet's gravity is divided by distance squared of the ship from the planet in question resulting in the attraction to the planet. This is treated as acceleration. All five moons and planets are calculated and applied before any ship motion is done. The nice thing is that simply changing a planet or moon's gravity value is all that is needed to alter the gravity.

Originally, gravity was also applied to the alien ships as well. The problem is that the alien ship adjusts it's course every interval so it automatically corrects it's course. While there may have been a slight slowing down of the alien ships due to this correction vector being applied, the amount was not really noticeable. As this is a lot of calculating for no real result, I removed the gravity from the aliens. The result is a bit faster of a game, but on most systems this wouldn't be noticeable anyway.

The only other issue that really came up with the development of this game was the zooming in issue. My idea was that when the player came too close to a planet, there would be a crash animation. This was coded as the planet zooming towards the player. The problem was that the zoom animation code would for some strange reason zoom up and to the left of the planet. It took me a while to realize that I was pre-calculating the screen-offsets from the ship to keep the ship centred. While the zoomed play field scales, the size of the screen does not so the centring of the screen have to be done after the scaled coordinates of the ship are calculated. A simple enough mistake that should not of taken the hour it took find. A debugger may be your friend, but when the calculations look correct it is sometimes hard to see what the tool is showing you.

Other than playing around with gravity and alien shooting accuracy, about the only other change I would consider making to this game would be to rework the alien movement system so that alien ships appear to  also be affected by gravity. Not quite sure how I would go about doing this but if I revisit this game I will try to come up with something.

Some thoughts on Zynga

I have been hearing a lot about Zynga in the news lately. While I am not a big fan of the company, who to me seem to be far more interested in extracting money from their players than in actually creating compelling games, I actually have taken their side on some of the issues. Yes, they may be an evil company that clones other peoples game, copyright does not protect ideas just the implementation of the ideas. I can make a clone of Asteroids if I want to as long as my version of the game has some new and unique elements to it. People may complain about this, but in reality it is far easier to sell a game that is 10% unique and 90% similar to other games people have played than it is to create a game that is 90% unique. Far too often people want a new game that is "just like the game I just finished except different".

When I heard that EA was suing Zynga over copyright infringement I was ready to take Zynga's side  but when researching the EA versus Zynga lawsuit  I came across the following article: http://dlr-law.com/3/post/2012/08/zynga-slammed-again.html . It seems that there actually may be something to EA's lawsuit. When you hire people away from a company in order to produce a game that is similar to the one that they are producing, you are only asking for trouble.

There are actually a few game ideas that I have abandoned due to people I have done consulting work for planning a similar game. My thoughts are that even though my version of the game may be 100% mine, it would be easy for the company to claim otherwise and they tend to have far more resources than I have when it comes to lawyers. It is best to avoid potential legal entanglements, especially since I happen to be the type of person who would not back down if it came to legal action and so would end up having to spend way too much money on my legal defence.

Perhaps one of the reasons I am not as successful as companies like Zynga isn't my total and complete lack of marketing skill, but the fact that I actually have ethics. To me, making money isn't the important thing. I created Blazing Games because I wanted to create games. I think that far too many of the successful game companies are successful for the wrong reasons. Worse, these companies have a tendency to buy the companies who exist to make great games. Bioware is just the first example to come to my mind.

The sad reality is, despite my claims to be ethical, if Zynga came to me and offered to buy me out I would jump on the opportunity if there were enough zeros in front of the first non-zero digit. I would make up excuses such as "They will properly market my games" and "It would be nice to actually have a budget." Yes, those excuses would actually be true, but the reality is that everybody has their price. In my case that price is probably not as high as I would like to believe, especially in this economy.

Alien Chase road generation

My Twelve Months of Doomsday Alien Chase game was released last week on Blazing Games so this week I am going to briefly go over road generation. This is not the first time I have created a randomly generated map, but is the first time that I have created a car driving game.

I wanted a road that was randomly generated to give the game a bit more replay-ability. More important, the size of the map would be huge and I really didn't want to create a really large road map by hand. Creating a map by hand has the advantage of giving the designer a lot more control over the difficulty of the game and often can result in better looking maps, but if done properly you can get fairly good results from a randomly generated map.

The first task, which is necessary for both random and hand-mad maps, is to come up with the tiles that the map is made up of. As I didn't want an obviously tiled look to the road and grass, I decided that there would be a number of tiles for each piece of road which would be textured slightly differently. I opted for 10 tiles for each root type of tile. The root tiles in the game were grass, trees, curb, road, dashed road, lined road, dividers (left, centered, right). In addition to this, I realized that transitions for increasing or decreasing the road size and the divide size would also be needed.

The road is then broken into sections. To keep the generator more manageable, the sections only allow a single change to the road. The four changes are increases in lanes, decreases in lanes, increasing the divide, and decreasing the divide. If any transition is impossible, the road remains the same as it was for that section. Divides consider a double-line and a concrete separator different types of divides.

While in practice this system worked okay, I found that additional transition tiles would have been nice to have, such as a road curving as the divide is increased. I did not have enough time to add this extra transition, but may do so when this game is revisited in the future.

Making Alien Espionage

One of the nice things about creating small projects is that it gives you a chance to play around with new techniques and try out new things. This is especially the case when the game is a type of game that you normally don't create.  For this episode I played around with a different way of handling animation.  I also experimented with vehicle systems. Finally, I tried a new way of spawning enemies.

The animation subsystem for this game is table driven with canned clips. Normally I use animations centered around the current coordinates of the object being animated.  This has the advantage that it is easy to move the object as you can simply use linear interpolation.  With the canned animation the motion is part of the animation meaning that the  animation plays through with the coordinates not changing until after the animation has completed.

Making the animation system much more complicated was the number of different sequences. To handle all the different transitions necessary without needing a huge number of animations, only the core animation segments are created. The transitions then stored as a table of sequences. Each segment in the transition then gets played in sequence. This approach works great for more complex character animations.

The elevators were an interesting challenge. My first thought on handling the elevators was to treat them as platforms. This lack of control simply did not feel right so I opted instead to treat the elevators as vehicles. Players "enter" the elevator by jumping or crouching while standing in front of the elevator. The player then exits the elevator by moving left or right. While inside the elevator jumping and crouching become the up/down controls.

Because the main theme of the game is about moving through a building infested with aliens, having aliens pop out of the doors seemed to be a really good way of handling the spawning of aliens. Each door has a set number of aliens (based on the level) that it can spawn. To prevent too many aliens from showing up, there is a per-floor limit (again based on level).  Finally, I decided to make the spawning of aliens time based.

If I had more time, I would have created a number of towers. I would also consider making the player retrieve a number of cases by entering multiple doors and then return to the first floor to complete a level. If I ever revisit this game, I may make these enhancements.

Thoughts on Coffee Quest 5/6

Working on Coffee Quest FPS has really got me thinking about giving my cursed Coffee Quest 5 project another go. I suppose cursed is really not quite the right word, but I have started on CQ5 a number of times in the past only to have the project go to the wayside as other things came along to eat my time. Needless to say, paying work always takes precedence over my game development hobby. As much as I would like to be able to turn my hobby into something that will pay the bills, I lack the proper marketing skills and tend to work on a large number of smaller projects instead of one really large project. I am trying to remedy the later problem but my twelve months of doomsday project just was something I had to do so my plans were derailed (and the games took a lot longer to code than I anticipated). Still, Coffee Quest 6 is a game that could work on something like the iPad and Nexus 7 and it is large enough of a game that I could justify charging money for.

For those who are unfamiliar with my Coffee Quest series, it started out as a Java game written for browsers. I drew up a roadmap of games that would lead to the ultimate role-playing game. This was broken into 9 games with the last 5 games being broken into a large number of episodes. The first game was simply getting a 3D maze working in Java (which at the time was a new language to me). Next came monsters, then multiple-levels and proper inventory. Coffee Quest 4 was the first true RPG featuring magic and more of a story.

Coffee Quest 5 was going to be a multi-part story that added NPCs and Stores to the game. Coffee Quest 6 was going to be a huge continent spanning epic with the player in control of a party of characters. CQ7 through 9 was more  of a 3 part story arch with no planned elements other than the vague idea of taking advantage of all the cool technologies that would appear when I finally got around to creating the game. Needless to say, the browser technology kind of stagnated until recently and Java has been replaced with JavaScript. This is something I could never have imagined happening.

I still have a few months of work to do before I can even consider taking another stab at a large-scale game. Coffee Quest is still in my heart so it is a project I would like to do but I suspect as soon as I get into the project something else will come along. Hopefully a high-paying project that will occupy far too much of my time. Still, it might be worth another shot and perhaps this time the games will see the light of day. As someone who isn't that big of a FPS fan, it would be rather surprising if a FPS is the catalyst that finally resulted in CQ6.

7DFPS Postmortem

This week's blog post was delayed by a couple of days as I was participating in the 7 Day First Person Shooter challenge. The idea of the challenge was to create a FPS in a week. My entry was Coffee Quest FPS, which is kind of fun but was not as polished as I would like. I will be polishing the game up a bit more and releasing it on Blazing Games. This week I would like to do a mini postmortem. The game is roughly 2K lines of JavaScript (including comments, spacing, and data) with roughly 120 art assets spread across 8 sprite sheets.

What Went Wrong

The biggest issue for me was the time. This was made worse when most of my Sunday ended up shot and by the fact that I kept up my exercise regime. The problem with short deadlines is that they simply go by far quicker than you think they will. At the end of the challenge I had a finished game but not a polished game. My list of things I want to do for the Blazing Games release of the game is 0xF items long so at least a few more days would have been necessary to meet my minimum goals for the game. Notice that I said minimum goals? In fact the original idea I had in my head was a lot more than I knew that I could realistically implement so I focused on just having a single level competed by the deadline.

The second biggest issue, which may have largely caused the first issue, was developing the game and game engine at the same time. For me, the whole idea of developing a game in a week is the whole game. Just creating content for an existing engine makes the challenge more of a level design or modding challenge. The honest truth is that we have reached the point in game development where games are built on top of existing engines. This saves a lot of development time, at least half of the week in my case. If I ever do another challenge like this, I would write my own engine well before the challenge began and build the game with the existing engine. This would allow a vast amount more time to be put towards the actual game. Still, there is nothing like the feeling you get when you have created a fairly complex game from scratch in a week and if I had used an existing engine (mine or especially a third party engine) I simply would not have been as satisfied even if the resulting game was ten times better. In other words, I am glad I chose to write my own engine during the challenge but it was still the wrong decision.


What Went Right

While my new JavaScript ray casting engine has a ways to go before it is "finished", it is a very flexible engine. What I was able to implement is only a subset of what the engine is capable of. Earlier ray casters that I developed had fixed texture sizes. Part of this was designed to speed up the rendering and insure that integers were used for calculations. Now floating point is almost as fast as integer math and JavaScript uses floating point for its numbers anyway so allowing for variable texture sizes was easy. There was a bit more work getting the rendering to work, but I found myself using 256x256 textures for the walls but a variety of sprite sizes (64x64, 128x128 and 256x256 though power of 2 isn't even a requirement anymore). This actually made implementing the game easier. It will make future games that use enhanced versions of this engine easier to write.

The second thing that worked well was building on known IP. Using a known universe makes a lot of the design decisions very straight-forward. While there are often restrictions when using existing IP, in this case it is my own universe so I could do whatever I wanted with it. When your time is limited, working out background information and trying to figure out what works with the universe you are creating is a dangerous time sink. Granted, if I would have used an existing game engine instead of creating my own there would have been plenty of extra time to create a new universe. I suppose that is another reason why my decision to create my own engine during the challenge was a wrong decision. More to the point, at least in this case, it was a while since I played around in the Coffee Quest universe and really enjoyed myself.


The future

As I convert my older Java and Flash games to HTML5, this engine will be utilized in porting all the games that use their own ray casters or similar technology. What I am ultimately planning on doing with this engine is reworking it to use WebGL for the rendering, but falling back to ray casting for browsers that do not support WebGL. This way I will get great performance yet sill have my games work on the vast majority of browsers. Before I can do that, I have to actually learn WebGL so it might be a while. Coffee Quest FPS will have at least a couple of updates so eventually you will see what I originally was planning for this game.

Twelve Months of Doomsday episode 5: Asteroid Attack

Episode 5 of my TMoD series has been released on Blazing Games so this fortnight I will discuss some of the design decisions that went into the development of this game. While this game is clearly inspired by the classic arcade game Asteroids, it is much more inspired by one of my favourite movies: The Empire Strikes Back. While Asteroids had aliens in it, they were more of an afterthought. I wanted my game to focus on battling aliens not on shooting asteroids. To do this, I made the asteroid field much bigger so the player would actually have to navigate through it and I made the rocks much harder to destroy.

The big problem with making asteroids hard to destroy is the basic fact that navigating using momentum based movement like the game uses makes rapid dodging difficult. To address this problem, I decided that giving lasers some form of impact value would be a good way of solving this problem. Shooting an asteroid will then either alter the course of the asteroid or cause it to break apart.

One of the great aspects of being a game developer/programmer is that you control the laws of physics. I based the amount of impact that a laser has based on the radius of the asteroid instead of the mass of the asteroid so lasers will have a much greater effect on larger asteroids than they should. This decision was made largely based on intangible factor: the feel of the game. This is actually one big advantage of doing small games. You are able to finish the game while the game is still enjoyable so playing the game yourself actually gives you meaningful feedback. When you are spending years working on a game, unless the game is one of those rare exceptions, you will be sick of the game as you reach later stages of it's development.

Originally the game was going to give the player a limited number of lives and the player would not re-appear until the coast was clear. That really didn't fit well with the story, so I decided that the player would only have a single life but would have a shield that would flash when they were hit with a limited amount of shield. This also allowed me to make it less damaging to bounce off an asteroid than to be hit by an alien laser.

Aliens were a lot more dangerous in earlier builds of the game as they would home in on the player and would start shooting at a fair distance away from the player. This difficulty was reduced by making the aliens wander randomly while trying to keep away from asteroids and not shooting at the player until they were fairly close to the player.

While I am sure there are a lot of people who disagree with me, I was quite happy with the way the game turned out.

Flash Professional CS6

I was really considering staying with CS5.5 unless there was a compelling reason to upgrade. Flash CS6 really didn't provide that reason, but as the upgrade price for CS6 for CS5.5 owners was half the price of the normal upgrade price, it was pretty compelling. When I found out that the Web Premium package was being combined with Design Premium, it would mean that a program that I wanted but couldn't justify was now part of my upgrade. InDesign is a desktop publishing application. With all the additional features in the other apps in the suite, the upgrade became a no-brainer.

If I only had Flash, not a suite, I doubt even the reduced price would have been enough to justify upgrading. I hope that I am wrong, but I really get the feeling that Adobe is abandoning Flash. Still, it is a tool I see myself using for many years to come. Perhaps not as a game development platform, but definitely as a tool for creating animations for the games. With Air packagers and Stage3D, it is possible that Flash will remain a platform for game development. As I have the tools, I have decided that I will play around with the starling framework and possibly try some low-level stage 3D work.

Still, for web development, the move to HTML5 is clear. Thankfully, Flash CS6 provides some tools for aiding in this migration. A few weeks ago I looked at a tool for creating image strips. This functionality is now built right into Flash. Likewise, there is a plugin for converting animations over to the CreateJS suite (which EaselJS is part of). While it is a great feature, it does not convert the ActionScript into JavaScript. Had this capability been in CS6, Flash professional would have instantly become the best tool for HTML5 development. ActionScript is a far nicer language to work with than JavaScript so the ability to write in ActionScript and compile to JavaScript would be well worth the price of Flash Professional. Yet another case of Adobe being blind to what they already have.

The thing is, both ActionScript and JavaScript are derived from the ECMAScript standard. ActionScript just happened to be based on a specification that was abandoned due to politics and infighting. Personally I think JavaScript would have been a much better language for web development had ECMAScript 4 passed. Since the underlying language is the same the version would have been backwards compatible. While I understand that some people think JavaScript should be easier, as the web moves towards JavaScript even larger programs will be created in that mess of a language so thoughts of dealing with large scale programs should be at the forefront as that is what the web ultimately needs.

In fact, the languages are so close that I think a quick porting tool could easily be developed so as a side project for this development blog, in future weeks when I don't have other things to discuss, I will look into the issues of writing such a tool. Even though I don't want to add yet another project to my overflowing plate, I just might develop such a tool as part of this blog. I know in the past I had looked for such a tool and while some projects existed they did not work the way I needed. Perhaps it is time for another look.

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.

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.

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.

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.

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.

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.

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.

What if piracy vanished?

There is a saying that you do not know how important something is until you no longer have it. With thoughts of SOPA and ACTA still in my mind, I wondered what would be the results if Santa Claus came down from the North Pole and gave old media the silver bullet for stopping piracy (hint, it is not SOPA or ACTA as those won't work anyway and is as like to exist as Santa)? If piracy were to become impossible, what would happen? Personally, I try not to pirate anything so for me little would change other then knowing that all the stuff I buy is fully legit. Looking at the excuses I have heard for piracy, lets look at the outcome based on the excuses. Percentages are an estimate of how many times I have heard the excuse and don't add up to 100% because most people have multiple excuses.

1. Can't afford to buy the stuff (80%). After piracy is gone, these people will still not be able to afford it. That means that they will not be buying it because they don't have the money to buy it anyway so it is not lost revenue. No extra sales from these people. Granted, some of these people are young and would likely buy stuff once they started getting money but they would have probably done so anyway the difference is that many of these also fall into point 3 even if they don't realize it so the negative sales would apply to these people as well. Net result is a harm to old media and a gain to new media in the long term.

2. Not worth the price (60%). These are people who think the price is too high. Quite often what they want to pay is much lower than what the price will ever be so the result is no sales. In the cases where the price does drop to the point that these people will be willing to pay for the item, some of them will buy the item but most will have found other (new media) equivalent stuff. Net effect is a big gain for new media. While there is a small gain for old media, it comes at a cost of exposure (see point 3) so a tiny short term gain but long term losses.

3. Wanted to see if it was any good (60%). This is the most interesting category as it is where the arguments against piracy fall apart. When you look at it logically, it is obvious that people do not want to buy something they are not going to like. Unless the price is really low most people won't take the chance. This means that there is no net gain from these people. This leads me to a personal example. Steve Gibson recommended the Honor Harrington series but when I looked at the book covers I took a step back. I know you should never judge a book by the cover and this series is an example of why. I would not have grabbed the series had the first two books not been freely (legally) available at  http://www.baen.com/library/ . The free books got me to get past my hesitancy about the series and resulted in much more of my money going to Baen. There are a lot of cases I personally know of where a person has become a fan of something due to a pirated copy. Often these people don't buy copies of the stuff they have pirated (sometimes they do) but they usually end up buying new stuff that comes out from that series/author. If they had never pirated, they would not know they liked the series/author and not buy new stuff. Net result is a huge loss for old media.

4. Already Bought It in different format or DRMed (40%). The result of DRM is often products that don't work as good as the pirated version. Some people don't care for the less-functional version so will find a non-crippled pirate version of the product. These ARE NOT lost sales as a copy was legitimately paid for. Likewise, people who have an old record or tape collection do not want to buy yet another copy of something they already own so will "pirate" the stuff they already bought. I assume Santa's solution would cover both these issues so the net result is no gained sales as the pirated numbers were artificially bumped up anyway.

5. Because I can (10%). These are those people who pirate for the sake of pirating. The few people I know who fall into this category either are also in group 1 or buy an awful lot of stuff legitimately so if they were no longer able to pirate they would simply do something else. Possibly a gain for new media. No change for old media.

After looking at the world after the silver bullet I see old media dying at an even faster rate then they are now and new media growing at a faster rate then they are now. Not exactly the outcome that RIAA/MPAA and other MAFIAA type organizations are after. All I can say to the people from these organizations is to be careful what you wish for because you might actually get it and the results are not what you think they will be.

TMoD Twelve Months of Doomsday

What better day then Friday the Thirteenth to resurrect my Game Development blog. After all, Jason managed to rise from the dead quite frequently. True, a month between posts isn't exactly dying but I had to have a Friday the 13th reference. For 2012 I am planning on updating this blog every other week. To be a bit more precise, weeks that do not have new content on BlazingGames.com will be the weeks that I post articles here. When appropriate, these articles will provide details about whatever was posted on BlazingGames the previous week. If for some reason you want to read more of what I have to say, feel free to follow me on Google+.

The big game series that I am running throughout 2012 is Twelve Months of Doomsday (TMoD) which is my way of having fun with the 2012 end of the world theme. Statistically speaking, there is a small chance that the world will end in 2012. To my understanding, the end of the Mayan calendar didn't actually represent the end of the world but the beginning of a new cycle. Perhaps the 21st of December will be the beginning of the singularity that many science-fiction writers are predicting.

TMoD is a collection of classic-style arcade games tied to a twelve part over-arching story about how the cast from One of those Weeks try to prevent the end of the world. I actually enjoyed bringing back the characters from my 46 episode adventure game. The design of this series not only had to tell a story, but had to fit in arcade games similar to those I played as a child. All the games I write are my original code and I try to make the games as original as possible while still bringing back the feel of the old days (well, at least if you are 30+).

The first game in this series was actually chosen not because it was an arcade game but because it was one of the first games I ever typed into my Commodore 64. Lunar Lander was a text based game found in a book containing 101 BASIC Computer Games. While BASIC was not the greatest of languages, it came with the computer so it was the language of choice for learning to program back then. I probably still harbour some bad programming habits as a result. The game gave you a distance from the surface and you had to type in the amount of fuel you wanted to burn. This determined your speed as you approached the surface. There were a number of arcade versions of this concept which I modeled my game after.

You will notice that a large portion of the games deal with threats from space. This is partly because the main villain is an alien, but more because the childhood arcade games that I played tended to have science-fiction themes. There are a lot of really good games that I am planning on releasing as part of this series so please give the series a chance if you find you don't like the first few games.