2008

Happy New Year everyone! While I have decided that I am going to make the home page change I mentioned months ago on January 4th, that is about the only thing that I have decided. I still have a huge number of decisions to make about the direction that I hope to take the site in 2008, though the paramount thing I have to start doing is to try and be much more focused on my development. Even though I try not to, I tend to have way too many projects on the go at the same time. This is a personal flaw that I really have to solve because I know if I could focus a decent amount of my time on a single project instead of spreading that time between a dozen projects then that single project would be great. That being said, this is not going to be my new year's resolution because that would just curse my efforts.

Sprites

Games, of course, require a lot of motion. Characters and bullets need to be able to fluidly move even if the background is static. To accomplish this, video game hardware makers came up with the concept of sprites. While I have yet to find a definitive reason why the term sprite was chosen, it is the word used to describe images with partially transparent regions that can be moved on the screen without destroying the image behind it. While this can be done in software, doing so in hardware is much faster and is often the way that game consoles handled sprites.

In theory sprites can be any size, though console hardware tends to use uniform sprite sizes and requires programmers to combine multiple sprites if they want one larger than the default size. 8x8, the same size as tiles on the tile map, is the common default size. The next question is how many sprites? This is actually a more complex question than it sounds. Hardware sprites commonly had issues with there being restrictions on how many could be displayed on a single line at the same time. I am going to assume my chip designers are really good and managed to allow for 16 sprites all of which could be displayed on the same scan line. More importantly, the sprite data can be changed on the fly so by using raster-line tricks, more than 16 sprites can be displayed. In case you are wondering, the specs for the various 8-bit systems that I looked at supported 64 sprites (4 times as many as I am going to support) but only were able to display 8 sprites per scan line.

Merry Christmas

For those of you who celebrate Christmas, Merry Christmas. For those of you who do not celebrate Christmas, Season's Greetings. And I wish everybody a happy New Year.

Console Resolution

While for the B8VGC we are treating the television as having a 640x480 resolution, this is not going to be the resolution that the console displays. While I know that the virtual nature of this project allows me to do things that were not possible back when 8-bit was the order, I want my virtual game system to at least be theoretically possible for the time period. This leads to the question of how much memory is available. If you look at the specifications for any of the 8 bit consoles that were on the market, the answer is not very much. A black and white 640x480 image requires 38,400 which is more than half of the address space available to 8 bit processors. In fact if you have the 16 bit address space that most 8-bit processors used, the total accessible memory would be 65536 bytes. Memory was expensive back in those days, so 64K would have been a luxury. To simplify my design, I am going to assume that all the hardware shares the 64K of address space that is available. How much of that memory is available to the graphics system will then be game dependent. A more important point would be that only some of the memory would be ram, with the rest of the addressable memory being ROM. My design goal has to be to allow the graphics to comfortably fit withina small amount of memory, say 8 or 16K.

The first obvious thing that we can do is to reduce the number of pixels that make up the display. By simply doubling up the pixels we can reduce the display requirements to 320x240, which uses 9,600 bytes of memory. While that is on the high side, it will fit within our 16k limit, with room to spare. While this sounds like the perfect solution, remember that this is only a single bit-plane so we are talking about a monochrome display. While most games are not going to be using a bitmap mode, having this capability on our graphics processor can't hurt, though 9600 is not a nice number. If we letterbox the display and get rid of the top and bottom 20 pixels, we can get a nice 8,000 bytes. Combining two bit-planes, for an excessive 16K, would give us a four color mode which would be good for title screens and games that don't need rapid re-drawing.

Remember that 8-bit graphics aren't exactly speed demons, so a faster way of having graphics on the display would be nice. Of course, the logical choice is tile maps. I've covered this concept before. The display is broken into 8x8 blocks, with each of these blocks represented by a single byte. While a display may only have 256 distinct 8x8 blocks, the blocks can be used multiple times. As a nice bonus, using a tile map that is larger than the display, say 64x64, allows for smooth scrolling. The best part is that 64x64 is only 4K! The data that makes up the tiles aren't likely to change so can easily be stored in ROM. A tile map, some palette information, and some sprites could easily fit within 8K making this the mode most likely used in any games.

Curse of the vacation

I must assume that anybody reading this is a regular visitor to BlazingGames.com and as such knows that I am taking Christmas week off, at least I am not posting anything on the 28th. I was going to continue working on a few releases for the site that would appear next year but have instead been sick the last few days. That is the reason there have been no entries in my B8VGC blog project. I am not sure why I always seem to get sick just when I am going to take things easy, though it may just be coincidence. Observant Blazing Games visitors may have noticed that the date ends on the 31st not the 29th or January 5th, which would be the logical end dates. Am I planning something for the 1st? Well, I was, but it now depends on how quickly I get over this cold so don't be disappointed if there is no update on New Years day.

Forever coming soon?

There was an interesting trailer, or should I say teaser trailer, that was released today. It appears that Duke Nukem Forever, a game that started development in 1997, is still in development and they have released a sneak preview of the trailer that they will be releasing soon. Their site is http://www.3drealms.com/, and if you are a fan of Duke Nukem you will be pleased by this news. How can a game take so long to create? I am sure Coffee Quest fans want to know this as well, though in my defense I can point out that I am a single person working on multiple projects without a budget in my spare time. In Duke's case, I believe it is the marketing equivalent of an infinite loop. The quality level required for a AAA commercial game is very high. When a project takes longer to develop when the game is near ready, the quality level may no longer be AAA levels so the decision is made to take a bit longer and up the quality of the graphics, sound, game play, or whatever it is that is lacking compared to other titles. Since you have more time, the coders might as well add new features to the game as well. This feature creep causes the revised game to be late and when it is finished it is no longer AAA worthy so the cycle starts again.

Raster graphics

While there are alternative ways to display images, the predominant displays (televisions and computer monitors) are what as known as raster devices. This means that the display is broken into a number of horizontal lines. Each horizontal line can then be broken into discrete chunks which are known as picture elements or pixels for short. While we know that the best resolution in HD televisions is 1080P which means there are 1080 horizontal lines with each horizontal line having 1920 pixels. For the B8VGC project, we are going to have to assume that non-HD televisions will be the display device.

Being in Canada, television broadcasts are in the NTSC (National Television Standards Committee) format. This format has 525 scan lines which are refreshed at 30 frames per second. Television broadcasts are interleaved, meaning that each of the 30 frames are broken into two fields. The odd lines are drawn first, then the even lines. This is what is known as interlacing. Not all the scan lines are visible, as some are used for the vertical blanking interval so the real visible resolution is roughly 480 lines. NTSC isn't the only format, there is also PAL (Phase Alternating Line) and SECAM which has 625 lines 576 visible at 25 fps.

The horizontal resolution of the display is a bit different beast. Because television signals are analog in nature, there is no absolute resolution. Instead, the number of pixels on a scan line is determined by the timing of the signal. DVD uses 720 pixel scan lines. These, however are not square pixels. If you want square pixels, then you will want 640 pixel scan lines. Programmers prefer square pixels so we will go with a television resolution of 640x480. That, unfortunately, will not be the resolution that the console will be using due to memory issues.

Classic Cribbage Instructions finally posted.

I was at java.net reviewing the task list for the Ultimate Retro Project and I discovered that I have not posted the instructions for Classic Cribbage. This was completed a while ago, but was not done on my Mac (the predominant machine that I use for work on UR). In fact, thinking back, I had forgotten to write the instructions for the classic game and only remembered when I started posting the game. I use Dreamweaver for the Blazing Games site, but my CS3 license is for Windows as that is the OS I originally purchased Flash for and Adobe requires that upgrades are for the same OS as the software being upgraded and their software is too expensive to re-purchase. I quickly wrote the instructions on my Windows machine with the intention of posting it to the repository later. As you can tell by this post, later is much longer duration than I originally intended. For that I apologize. For those of you who are actually interested in the Ultimate Retro Project, I am going to try and start spending a couple hours every weekend working on it until the project is complete. I am also going to try posting to the repository more frequently instead of just when I have finished a game.

One of those decisions

I've decided that it doesn't make sense to repeat content. For that reason, I am not going to post articles that are going to appear on the Blazing Games site in this blog. While there certainly may be some overlap of material, articles that are going to appear on Blazing Games will no longer be written here. That being said, I have no problem with the idea of releasing some material early and providing an early access link to that material, but I obviously didn't do that for chapter 20 of Making One of those Weeks which was released on Blazing Games today.

Five sub-projects

With five different components to design and develop for B8VGC, I am going to tackle each of them separate. The first most logical starting task from my perspective is the graphics processor. This may come as a surprise, but if developed properly it should be flexible enough that with slight modification it could be used for the development of a number of other games. Perhaps even that arcade series that certain people keep asking me to develop. Next will come the memory management unit since the virtual CPU we are developing will be dependent of it. The CPU is going to be the big task so I will develop that once the MMU is finished. At this point we have a usable system with no way of controlling it, so the virtual gamepad will be the next task. Finally, the sound system.

My thoughts for developing a graphics subsystem for the console would be to develop a general purpose flexible system and then design the consoles memory representation in a way that it would be fairly easy to write an emulator of the graphics processor that converts the necessarily more restricted console data to the more flexible general purpose system. While this may not be the most efficient way of doing things, we are talking about an eight bit console being emulated on very fast hardware so the overhead shouldn't be that big of a deal. Still, I am going to have to keep the 8-bit restrictions in mind.

Canadian DMCA withdrawn for now

Shortly after posting my entry yesterday I found out that the Canadian DMCA Bill was withdrawn. As I had already posted my entry, I figured I would wait until today to let the few of you who read my blog know the good news. While I highly doubt my letter was the reason for this, I suspect the public outcry combined with a minority government is what caused the temporary delay. I am sure that another attempt will be made in the future, but I can at least hope that due to the outcry that the next attempt will at least try to keep with the spirit of Canada and will at a minimum address fair use issues properly. I'll probably be writing more letters to my MP.

Apricot project started

While I normally only discus my own projects on this blog, after all it is the Blazing Games Development blog, today I am going to make a bit of an exception and point you to another project that while I am not involved in is one which I will be keeping an eye on. This project is none other than the Apricot project (http://apricot.blender.org/). This is an open source project that is attempting to develop a commercial quality game using just open source tools. In particular, they will be using Blender and the Crystal Space game engine.

Blender is a 3D modeling/animation program that is quite powerful if you can get past the atrocious user interface. That may not be a fair comment since it has been a while since I played with it so things may have gotten better. I just installed it on my Ubuntu machine though doubt I will have a chance to play around with it any time soon. There are also windows and OSX versions available. Still, if you want to create 3D movies, Blender is certainly more than powerful enough and considering it's price it may be the perfect choice.

Crystal Space is a 3D engine. If I recall correctly, it is portal based. I had considered it in the past and may yet use it for a future project. That is assuming I decide to develop a download only game which is probably something I should do since applet development is so restrictive. Sure there are some game engines designed to run on browsers, but their installed bases are small and system requirements are high so right now Flash and Java are the only real choices for web games.

What is really interesting about the project is that the goal of the project isn't the commercial quality game, but instead the goal is to develop a proper pipeline for developing games. This means that both Blender and Crystal Space will be improved to allow for better game development work flows.

Canadian DMCA

There is proposed legislation for a Canadian version of the DMCA. The problem is that fair use rights are not addressed in this law. For this reason I have mailed my members of parliament.

As the creator of vast quantity of copyrighted works I certainly understand the need for copyright laws. Though I personally feel that the length of copyrights are way too long, that is a separate issue. What is at issue is the omission of fair use rights from the proposed Canadian DMCA. These rights are of tantamount importance and must be present in any DMCA bill that is put forward. If you feel it is necessary to delay addressing these concerns, then the introduction of the Canadian DMCA should be delayed with them.

As both a creator and consumer of digital content, it is my opinion that consumers should be allowed to copy, time-shift and format-shift material as long as it is strictly for personal or educational use. If digital locks prevent such things, consumers should be allowed to use any tools available to bypass those locks. Likewise, parody and the ability to criticize works is of up-most importance to citizens and not even the most vile of police states would try to make such practices illegal. Also, when you consider that the entire Technology Industry was built on top of the practice of reverse engineering it is vital for our economy that this practice is allowed in the future.

If you are under pressure from trading partners to pass a DMCA bill into law, it would be best if you incorporated the broadest possible fair use laws and then have a Copyright Review Panel to consider if the fair use rights are too lenient and restrict those rights in the future if the majority of Canadian Citizens felt that it was necessary.

Alternative Christmas Special

The Christmas special is potentially the first of two Christmas releases, though I won't guarantee it. It is also being dedicated to my mother who's birthday it is. For those who are wondering, the graphics are scaled down versions of graphics that would have been used in the originally planned three part Christmas special, though the scaling does not do justice to the original images.

HotSpot answers some questions but others remain

GameSpot's weekly podcast, the HotSpot, discussed the firing of Jeff Gerstmann. The podcast is free and available on their site. I assume everybody knows that you do not need an iPod to listen to podcasts. It is still not clear why Gerstmann was fired, but it is clear that the GameSpot staff were devastated by cnet's decision to fire him. I am not sure I like the direction that cnet is trying to take GameSpot and will be distrustful of all cnet owned properties for a long time. This whole situation was handled very poorly by cnet, and GameSpot really is going to have a tough time rebuilding their reputation. The podcast was a good start, with the best part of the podcast being a listener phone comment, "Jeff Gertsmann got released before Duke Nukem Forever."

What makes a game console?

As I said a few days ago, I am doing the B8VGC project entirely in this blog and only when I have nothing more pressing to talk about. At least, that is the plan for the design stage. When I get to coding, things may change, but we will cover that part of the project after we have reached it. The first thing is the design, and when I am starting the design on any project the first thing that I do is break the project down into more manageable components. So, what are the components that make up a game console?

Obviously, the heart of a game console is the CPU that powers it. This CPU will be the 8 bit virtual machine that we will be designing. Being able to run code doesn't do much by itself. We will also need a way of handling input and output. The input requirements can be very simple since we can make the assumption that the virtual console is uses a virtual ROM cartridge. Of course, the cartridge, to allow for a reasonable amount of storage, will allow for some type of overlay memory management so some type of simple memory management chip will have to be emulated. Of course, the player(s) of the game console is also going to be a source of input via 1 or more controllers. The output comes in two forms. We are going to need a graphics system and a sound system.

Santa progress report

I had to come to a hard decision today. As readers of this blog already know, I have started development on a Christmas special that will be sharing a lot of code with my Android project. With less than a week left to finish developing the game I am at the critical juncture where I have to decide if I focus on finishing the game for this year or put the game on hold until December 5, 2008. After taking a look at everything I want to be in the game, I am quickly realizing that everything that I want to do with this game is not possible within such a short time frame. It is certainly possible at this point in it's development to rush something out the door, and there are numerous companies that would do just that. In fact, I suspect there are more companies that would rush something out than delay a project for a year. Still, I have an alternative christmas special and some One of those Weeks releases so I don't think my regular visitors will be overly disappointed with this December's releases.

The gamespot website has finally posted something on the firing of Jeff Gerstmann, though the news article doesn't give any details or provide any useful information. They do say "However, contrary to widespread and unproven reports, his exit was not a result of pressure from an advertiser." That may be true, but then why edit the review? It will be a long time before I start trusting reviews on cnet owned sites again. Had they left the video review alone and made a statement right away, I would be a lot less leery of them than I currently am.

Actions speak louder than words

While cnet has said that they do not let advertisers have any say on editorial content, it is interesting to note that their gamespot site has re-posted the kane & lynch review with the content edited to remove some of the legitimate criticism that Jeff made about the game. To me this just confirms the fact that cnet is a sellout.

The bigger issue is how did this situation happen? My personal view is that there is a cycle of greed. Sites initially start off small with only a few people working for them. The only thing they have is their integrity. As a result, they have honest reviews. As they start to grow, they start needing to hire people and spend more on their structural costs. This costs money. As today's generation don't want to pay for anything, the only real choice is to have advertising. Some sites have subscription services that don't have ads, but too few people are bothered enough by ads to pay for such a subscripion. This means that the bulk of their money must come from advertisers. While this does not have to be a problem, far too often the advertising department, which is bringing in the money for the company, gain too much power and slowly editorial integrity is forgotten in favor of appeasing advertisers. This is when people who care about integrity have to find new sources for their information.

As there are no reviews on Blazing Games, I don't really have to worry about this issue. What would I do if Blazing Games somehow managed to grow to the point where advertisers wanted to control the content of my games? If advertising is the only real revenue stream it is a very tough decision. I am sure I have a price, and that price is probably a lot lower than what I think it would be. That, however, does not change the basic fact that if advertisers can dictate the reviews that their games get, the reviews are no longer worth the electricity that transmits them across the internet. What is sadder still is the fact that this will continue to get worse until people decide that content should be paid for which would decimate any say advertisers would have as then they would be only a small portion of revenue. After all, it is the content that drives traffic.

Has gamespot becomes a whore?

I use to like the gamespot site but with my favorite reviewers leaving the site I was finding the site to be less and less reliable. Today I found out (thanks to the Penny Arcade comic http://www.penny-arcade.com/ ) that my favorite reviewer, Jeff Gerstmann, not only was leaving gamespot but was being fired for writing a negative review of one of their larger sponsor's games. If this turns out to be true, this act alone means that no gamespot review can be trusted. They have gone from a trusted semi-reliable source to a site to be avoided overnight.

Apparently gamespot is claiming that it was the tone of the review that got him fired. Having watched the review, which now seems to have vanished from the site, I can only say that the review was very well done. Any site that would let let advertising revenue determine the rating a review receives is clearly not worth bothering with. I should probably point out that gamespot is owned by cnet and that I will have to assume that all cnet owned sites are tainted likewise. I should also mention that eidos is the publisher of the game being reviewed, though as they haven't made a good game in a long time there is not much to boycott.

I am still holding out hope that this is all one big misunderstanding. Game reporting has been steadily dropping in quality everywhere so seeing my last semi-decent source of gaming news vanish is a sad day. I guess editorial integrity is a thing of the past. Sadly, other than not visiting or supporting the sites above, the only other thing I can do is show my disrespect of them by purposely not capitalizing their names, which sadly is only going to be noticed by English teachers.

Revealing my hand

With the release of the fourth game in the Dozen Days of Dice series, I feel obligated to reveal some of my plans with the series. Next year I will be developing the 5th episode and posting the diary on the site as the game is developed. January 12th is currently the scheduled date but that could change if something comes up. Depending on how well things go, that may become a monthly event. Even if I fail to finish the game in a single day, work will continue on the game until it is done, but it will be marked "failed to finish within time limit".

Billy's 8-Bit Virtual Game Console

All of this talk about virtualization and virtual machines has me wanting to create my own. While I am certain that I know more than enough about how computers work to do it, there are quite a few VMs in existence already so writing yet another one really wouldn't serve much of a purpose from a practical point of view. From an educational and self exploration point of view, however, this would be a great project to undertake. In fact, if I took it an extra step and tried to create a virtual game console it would fit in with this blog. So, when I am not discussing site related development or giving you my opinion about the latest game/development related news I will be taking anybody who bothers to read this along with me on my few minutes a day virtual game system side project. I don't want to byte off more than I can code so this will be a simple 8-bit machine. Every project needs a name, so I will give this project the generic name of "Billy's 8-Bit Virtual Game Console" or B8VGC for short.

Virtualization

While virtual machines are related to virtualization, those are slightly different things. Virtualization generally refers to creating a virtual instance of a computer that runs inside of another operating system. For instance, Macintosh users that need to run Windows software may use an inexpensive program such as Parallels or VMWare to create a Windows instance. This allows the user to run both OSX and Windows at the same time. The best part is that since intel based macintoshes have hardware virtualization support, the speed is almost as fast as if you were running the operating system on it's own machine. That is assuming that you have enough ram. With a Virtual Machine, however, you are actually emulating a non-existant processor. Actually, there are Java processors, but I haven't seen them and don't know how they compare speed wise to running a virtual machine on a fast processor.

VMs are everywhere

One of the interesting things about Android is that Google is using their own virtual machine, called Dalvik, which is not the same as the Java VM but JVM code can be converted to Dalvik code using a tool included with the Android SDK. This started me thinking about how virtual machines have taken off. You have JVM, Microsofts CLR, and Flash forming the big three with many other's such as YARV (Ruby's upcoming VM) and Parrot (Perl 6s VM) also starting to take off. While VMs have the advantage of being processor and operating system independent, ultimately the code has to be converted to native machine language. There are three basic ways of doing this. Interpretation, JIC, and re-compilation.

Interpretation is the slowest of these techniques, though when combined with specialized compilation (which is essentially what Hotspot does) can actually be the fastest. The idea is that the program converts the program to machine language by converting the code every time it is executed. Hotspot improves this by detecting the parts of the code that run frequently and compiling those sections into highly optimized native machine language. When you consider that most code runs rarely, this can be very efficient.

JIC, which stands for Just In-time Compilation, compiles the classes into native machine language as each class is needed. There is an initial delay when a class is first used, but once compiled the class will run fairly fast. This has largely become the way of creating virtual machines. Often optimization of the native code is not done due to the fact that the compilation is happening as the program is running so it has to happen quickly.

Finally there is re-compilation. This is essentially a compiler that takes virtual machine bytecodes as input and outputs native machine language. This could be a good way of distributing code as you could do the translation from bytecode to native code as part of the program's installation. In this particular case, when you install a program, part of the installation is compiling the virtual machines code into native code. There is no overhead when ran as the compilation was done before hand. While the initial installation of the program on the machine would take longer, most people wouldn't notice and this only has to be done once.

Fragmenting Java

One of the biggest issues with Android is the issue that it fragments Java. As Java ME is already different from Java SE one can argue that fragmentation has already happened. What I was originally hoping for Android would have been support for Java SE which would have made porting to Applets much easier. Right now, I am going about projects in a similar way to when I was doing C/C++ coding. Cross platform coding consisted of writing a lot of generic classes while putting platform specific code into it's own classes which can hopefully be accessed in a generic way. The problem with this technique is that when you are under a tight deadline, you suddenly stop worrying about cross-platform compatibility and just start writing for the biggest platform with plans on making the code cross-platform when you have time. Of course, you never have enough time and the code base gets more platform specific and your initial noble goals vanish.

The API for Android is very clearly for Android. All the android specific classes are in packages with the Android prefix, so people who are claiming that Google is doing what Microsoft did are quite mistaken. Microsoft's platform specific extensions were not clearly distinguished making it very easy to accidentally write code that was platform specific without realizing it. More to the point, with Android, you are not actually writing java code but are just using java as your programming language and generating Dalvik code instead of JVM code.

Christmas special Officially in development

I am working on the Christmas special which will be a three part game. The first part will either be released on December 7th or December 5th, 2008. I already have alternative releases if I fail to finish the game on time for release this year. The Christmas special will be a Java game, as a large chunk of the code for that game will be used with my Android project.

Final thoughts on Modern Maze

I have pretty much covered everything that you need to know about Modern Maze. There is a lot of room for improvement, but with today's hardware I am not sure it is worth any of the optimization. I should point out that the raycaster will be used with the upcoming Modern Dungeon Romp 3D that will be appearing next year (though it will probably be posted to the repository well before it is released on the blazing games site for those of you who can't wait and don't mind compiling programs yourself). The raycaster is going to be indirectly used with my Android plans. As the Android API has support for Open GL ES, I will be taking advantage of that for the rendering of the Android version of the game. The applet version, however, will need a different solution. While I could use JOGL to do this, too many visitors had problems with my test game (Coffee Quest GL). For that reason, I will have to use some form of software rendering for the applet version of the game.

Maze Raycasting

Modern maze uses a raycasting engine. I believe I have discussed raycasting in the past but review never hurts. Essentially raycasting is a simplified version of ray tracing. You follow light from the camera (the player's eye) to the nearest wall. The size to draw the wall is based on the distance the ray had to travel to hit the wall. A texture strip is then drawn based on where on the wall that the ray hit. Lighting could be applied to the texture also based on the distance, but this adds a lot of time per pixel plotted and we are using software rendering which is slow already.

The method that I used for doing the casting is a bit different from the other methods I have seen described. I calculate the stepping distance between entering different tiles. I then just take steps picking the x or y step based on the distance. Only one of the steps is adjusted each iteration since obviously the farther crossing distance hasn't been reached. The one that is crossed gets the distance needed to travel across the tile added to it.

Texturing

Texture mapping is an old 3D graphics technique. It is a way of cheating by faking the details there are in a 3D scene. The basic idea is that you can make a 3D model look like it is made up of many more polygons than it is by wrapping an image around the model. This effectively means that you are distorting an image, such as a photograph, so that it fits the shape you are texturing. More advanced rendering engines will even take account of the z distance of the different points on the polygon.

The texture class that was created for Modern Maze was designed for use with a ray casting engine. As such, the texture class is designed to draw vertical strips on a memory image source. It has two drawing methods. The first one draws a solid strip, while the other one will check the alpha channel not drawing transparent pixels. There is a lot of room for optimization within this class. If I was going to create a more advanced 3D rendering engine, I would add a function that would allow the drawing of a horizontal strip using any two endpoints on the texture. This would allow one to easily create 3D textured polygons.

Repository thoughts

I decided that even though it is a large blob of code that I would post all the code for Modern Maze to the repository at once. I know that I should post to the repository more frequently but don't want to post code until it is fully functional. I suppose I could create branches, but it is far easier to have it on my local repository and only post to the real repository when I have final code. That being said, I am considering switching my local repository over to git, which has the great advantage that hosting a git repository is much easier than hosting a CVS or Subversion repository so I would be able to do so on BlazingGames.com. The disadvantage of git is that it is still largely a Linux thing. As more Windows and Mac tools come out, the decision to switch will make more sense. If I had something called "time" then I would probably contribute some towards developing cross-platform tools as it would be an interesting project. I'll review the code that I posted starting Monday, unless something more news-worth comes up.

Modern Maze

While I have a few flash games yet to post this year, I am shifting my development to be more Java focused due to Android. In fact, I just released Modern Maze to the site and am going to slowly post the code for it to the repository over the next few days. Along with each post, I will have an entry here explaining what the code is and how it works. Today I posted all the graphics that the game uses. These consist of a picture for the title screen, four 256x256 images that are used as textures in the game, a start sprite and an exit sprite.

Android Decision

The big problem that I had with Java ME, which also happens to be the same problem with Android, is that the API used for the user interface is different. If it was just a subset of the standard edition, then things would be fine because you would only have to write code for the lesser API. Sadly, the drawing commands and user interface are kind of important for games, with a lot of code going into this. Still, I would probably be able to share between 70-80% of the code between an applet version and an android version and would possibly even be able to do a third application version that would take advantage of 3D hardware. In fact, one of the features Android has is OpenGL ES support. Despite it's many flaws, I've always liked the Java language so moving my development to Android and porting to Java SE might not be that bad of a move. While I am not likely to win money, entering their contest might not be a bad move exposure wise. If I am lucky enough to have my game win one of the 50 slots, then it was a really good move otherwise I still have the option of finishing off my entry and attempting to sell it commercially. I would also break the game into a bunch of chunks and release it episodically on the Blazing Games site for those who don't want to (or can't afford to) pay for the game.

Android SDK Released

Android has been released. My initial reaction was that the API was a modified version of Java ME and that the amount of work to write code that could work both in an android phone and as an applet was probably more than it was worth. Then I noticed that Google was giving away $10,000,000 to encourage Android development. The first contest runs from January 2 and submissions end March 3rd, with 50 winners getting $25,000 and a chance to get $275,000. While I am unlikely to win, even if I don't I'll have a bunch of code that can be pushed towards a commercial project and can be used on the Blazing Games site. Granted, applet versions will be a bit more work than I would like, but the potential payoff does change the factors a bit. I will be sleeping on this decision but will update you tomorrow.

Remeberence Day

Today is the day when we are suppose to remember the past and the sacrifices that were made to bring about a relatively peaceful world. The saying that "those who forget the past are doomed to repeat it" is most appropriate today. Sadly, our current leaders seem far more interested in petty greed than in making the world a better place to live in.

One of those Chapters

As people following the Blazing Games site may have noticed, the open source release of One of those Weeks episode 19 was released along with chapter 19 of the Making of One of those Weeks eBook. I would have released early drafts of the sections here, but I never started writing the chapter until a couple days ago so never bothered. This has me again thinking about whether I should be posting the early drafts here or not. Of course the reason I was so late writing the chapter was because I knew I could do it quickly so was working on other projects that needed time spent on them. It is quite possible that this will be the last article that I release on Blazing Games this year. I do plan on fulfilling my one episode a month commitment to One of those Weeks, though next year I might only release a single day's worth of episodes. Again, non of my plans are finalized so if you are a big OotW fan you might want to complain early before my plans for 2008 are finalized. Granted, looking at how well my 2007 plans went, I'm not sure there is that huge of an issue anyways.

Can a SDK change anything?

The Android SDK that is suppose to be released on the 12th could affect my plans far more than people would think. In particular, the rumors that Android will be using the standard edition of Java for it's programming environment would probably start my development pendulum swinging away from Flash and back towards Java. The sad thing about this is that even if the phone is an open platform, most of the phones would probably end up being locked down meaning that phone users would still be limited with what they could run on their phones. That is the problem with monopolies. They make the rules and if you don't like those rules you are stuck with them anyway because you don't have any real alternatives. Heck, even with computers I tend to cater to Windows machines due to their dominance. Yes, I test on macs and linux machines but the majority of my visitors are slaves to the OS monopoly. Will an open platform for cells change the cell phone landscape? While I would like to think so, I am not so sure.

The gPhone is an Android

Rumors about Google creating a gPhone have been around for quite awhile so it came as little surprise to me that today they announced the open handset alliance (http://www.openhandsetalliance.com) which is an open standard for phones that would allow developers to easily create applications for phones. I have briefly looked into mobile Java and Flash lite so next week when the SDK is released to the development community I will be taking a look at this standard as well. Phones that support this open platform will not be out until next year.

Threes - Final build

I've covered the creation of the pre-alpha, alpha and beta versions of the creation of this game (which was officially released on BlazingGames.com today) in previous posts. This post looks at the completion of the Threes game.

20:30 Three and a half hours of time remain, though I am getting pretty tired already so a couple of hours is more likely going to be the case. At this point my tests seem to indicate that the game is functioning fine, so it is time to start fine tuning the game. The first piece of tuning that I am want to do actually requires some code work. The problem I found when playing the game is that once the player has moved all the dice into a hold position, the game still displays a click to roll message. What I want to do is have the game be able to detect this particular case and change the message in this case to Finish the Game. Of course, the button I am using is a simple button that has a graphical message. While it is possible to modify the button to make this dynamic text or switch to a different type of button, I am instead going to go the cheating route and simply create a second button right on top of the first button. Only one of the buttons will be visible, and both buttons will result in the same event being triggered. Another piece of obvious tuning is to better represent the shoot the moon event. This is a rare event and deserves special attention so I changed the win results display to detect this condition and display a shot the moon result instead of win. Of course, testing this proved very challenging as it truly is hard to shoot the moon. This is where debuggers come in. I added a break point to the Six Sided Die class and manually forced the dice to roll 6's to test this special case, though I got a lot of testing in before I caved in and opted for the easy way of testing. This is my first release candidate!

22:00 I have now finished the game with time to spare. Not enough time to do anything major, but a better animated title screen would be nice. This is fairly simple though time consuming motion tweening work. Once set up, a bit more testing and I decided that there should be some gap between the dice. Right now the dice are a good size as they are bitmaps so you ultimately want them to be even resolutions to reduce the stair step look that often results from scaling bitmaps. So instead I cheated and simply added a layer over the dice and added lines between them. An additional tweak to the results message as it blocks the human/ai toggle. Things look good so at 22:57 I make the final build of the game.

23:00 While I suppose I could do a bit more tweaking and fine tuning, an hour isn't very long and I am getting pretty tired so I will call this game complete.

Happy Halloween

I never did a Halloween themed game this year and am still trying to decide if I will do a Christmas themed game. Next year I will try to make sure that I can have a proper Halloween game, but for those who missed me having a special game for Halloween I apologize. Lets just hope that all of you have a happy Halloween.

KVM Switch

My dad just got a warranty replacement TV due to problems that he was having with his old TV. While the TV was great when it was working, there were issues. It is my opinion that the issues were with the repair company and not the TV (other than the first instance). The problem was that every time the TV needed repair, it would go into the repair shop and my parents would end up without a big screen for months while the repair company fixed the problem. My mother only has good sight in one eye and even then needs glasses so this is not a good situation for her. My father finally got angry and phoned the store that sold them the TV and when they looked into the problems decided they would replace the TV. Of course, the old TV had a DVI port for the HD content while the new TV used newfangled HDMI ports. So I of course had to find a converter that would let him use his DVI device on the new TV. This was simple enough, but while I was in the store I found that the store actually had a KVM switch. I have been looking for one for a while so when I spotted them it was an instant purchase. I know I could have ordered them online but just never got around to it. Still now that I have the switch, I am wondering why I didn't make getting one a higher priority.

For those of you who are scratching your heads saying what the heck is a KVM switch, this is a switch box that takes keyboard, video, and mouse inputs and hooks them up to two (or more) computers. This means that instead of having a cramped desk with two monitors, keyboards, and mice on it, I only need one of each and can easily switch between using the two computers. While it may not sound like a big deal, not having to figure out which keyboard you are using and having both computers use your good LCD monitor which runs at a higher resolution then the second monitor to me is very convenient. While the time savings probably are not worth the cost, when you have accidentally trashed something you have been working hours on by mistakingly using the wrong keyboard, the sanity saved may be worth while.

I hate schedules but I still need them

When I am being paid by a third party, schedules are very important. I have to complete things by certain dates and that makes perfect sense. After all, that is why I am being paid. When it comes to Blazing Games things are different as it is done in my spare time. However, the new home page that I want to switch to is going to require that I be much more tied to a schedule. In fact, I am going to have to be over a month ahead of schedule with regards to the games that I am going to be releasing. This would be a lot easier than it sounds if every release took the same amount of time. This is not the case. Some releases only take 5 or 10 hours to put together while other releases can take over 80 hours. To make matters worse, software is not the easiest thing to schedule as a cleverly hidden bug can easily turn an hour long task into a day long head banging session.

With all that taken into account, while I was banging a goomba on the head, a potential solution to my problem and as a result I have worked out a better way of handling my Blazing Games scheduling. Sometimes taking a break is the best way to come up with a solution. I am going to try out the system for a few months to see if it works as good as it looks on paper. If it does, I'll put the details on the blog for those of you who may also have similar scheduling issues. If not, I'll have to work something else out.

Threes - Beta

Lets continue my Threes Development Diary. I have already covered the pre-alpha and alpha stages in previous posts, so lets look at how I reached the beta stage.

19:15 The only thing left in the game to complete before the game is actually complete to the desired specs is to finish the AI. This should be interesting. I am thinking that a two pass AI would be best. First pass for each roll the lowest die is kept. The second pass then keeps any one or threes. The key question is where do I put the AI? Having the AI in the player does make sense, but will require that I add some extra functionality to the game class. That being said, the game class could handle the algorithm very simply as it has all the information needed. This would result in more efficient AI at the possible cost of making it much more difficult to swap out AI for future versions of this game. As I am not likely to make future versions of the game, the person who does can always move the AI out of the game class into it's own class when there is time. My time limit is rapidly approaching so I am going to go with the fastest approach. This is putting the AI inside the game class. Of course, while testing the AI, a bug was discovered with the red player. It seems that when red won or tied, they never got notification or points. It turned out to be a simple case of starting the loop with 1 instead of 0 and the reason I used 1 instead of 0 was because the above loop used the red player as the first score to beat value so that loop had to start with 1. At this point, I have all the stuff that I wanted in the game so we can officially consider the game a beta. Beta Build 1 has now been compiled.

Considerations for Christmas

My biggest problem is that I have far too many ideas and not enough resources (time or money) to bring those ideas to fruition. I have been trying to only focus on a few projects and not starting any more until those projects are finished. My biorhythms game was an exception to this, but it only took a few hours to put together so I am not really concerned about it. The two logical offshoots to that game, a horoscope and a tarot card reader, are a bit too big of projects to take on. While I am certain that I would be able to create these fairly easily, they would probably take more than a week of development time without giving me multiple weeks worth of releases.

Another ambitious mini-project I am thinking about doing is a Christmas special. This one is dividable into multiple parts and would be using large chunks of the CQfs code that I am developing for a variety of games. I know that people are waiting for me to get back to work on Coffee Quest Revenge so I haven't entirely decided if I will be doing this special. The best part is that all the CQfs code is code that I need anyway so I can simply work on that code and decide closer to Christmas if I can quickly assemble the pieces I do have into a game.

Site changes for 2008

As is often the case, I am always thinking about ways to improve the Blazing Games site. While there are no major overhauls planned, I do have a slight change to the home page that some people might consider a major change. While I am positive that I want to make the change, I am not sure when I should target the change for. As older Blazing Games visitors already know, the site was started on an April Fools day and usually April is the target date for any major changes to the site. This isn't always the case and certainly making the beginning of the year the target time does make sense. If anybody reading this has a preference, you can email me at spelchan at blazinggames period com.

The changes are designed to both make it easier for people to know what is coming in upcoming weeks while also allowing those people who only visit the site every month or so a much easier time of finding out what they missed.

Turning 29 yet again

Well, my birthday has come and gone. While this is suppose to be a game development blog, it is also my personal blog so readers will have to put up with some personal junk today (or you can simply skip this entry which is what I am guessing everybody is doing this very moment). I suppose from a strictly technical point of view I was only a day older yesterday, not a year older. I don't really care about birthdays because they are a reminder of how poor I am doing in the game known as life. At my age I should be married and either have kids or be thinking about having them. Instead of trying to find a wife, I spend whatever spare time I can find developing games for Blazing Games Inc. with hopes of getting the company off the ground so that it can start paying me. Right now the company is technically profitable, but if I was to take the salary that I should be getting the company would be in the red. Living off of money earned from various consulting jobs might sound glamourous, but really is isn't. The only really nice thing about consulting work is that between jobs I can focus on my own company and hope that my plans for getting the company profitable enough to pay me will actually pan out so that instead of working for other people I can take a salary and devote all of my time to Blazing Games.

I did get Paper Mario: The Thousand Year Door as well as Mario & Luigi Superstar Saga for my birthday since it is obvious that I am now a fan of the Paper Mario series. Don't worry though, I am not going to have long drawn out reviews of those games in this blog though I will probably be mentioning them from time to time. I am going to play through the second paper Mario game first, even though M&L was released earlier. I'm not far enough along in the game to make any comments.

For my birthday supper I had a ten pound pizza and black forest cake. No, I didn't eat the entire pizza by myself, nor despite how much I like pizza could I. If any of my Californian friends ever visit the Okanagan, I'll have to order one for them as then they will see what a real pizza is. Sorry, but thin crusts with thin toppings don't cut it for me. Overall, I would say that my birthday was pretty good.

What's wrong with Dvorak

John C. Dvorak had an interesting column about what's wrong with Open Source . I would link to the column but people who are familiar with his writing already know where to find it and introducing his writing to those of you who are not familiar with him would result in bad karma. My personal thoughts is that he is desperate for hits and was hoping that a controversial column would get slash dotted. I haven't seen the article linked to from slashdot, though that is easy enough to miss. Still this is interesting to see a master devil's advocate at work. First, he insults and stereotypes his targets. Then he makes the blatantly stupid assumption that the fanatics who post to his various blogs actually represent the whole community. Then he makes some semi-valid comments to give his article the air of legitimacy. In this column's case he is saying that open source is worse than commercial software because just like commercial software it is getting bloated. Then he makes a mis-conception which I am assuming he is planning on writing a follow-up article about. This misconception is that open source is about forking when anybody who knows anything at all about open source knows that forking is considered to be a last resort as forking just results in duplication of work. Finally he concludes with a final jab at the target group he is trying to annoy.

Clearly he is trying to get a rise out of the open source community, and I am sure that he will but I hope that the majority of open source advocates are smart enough to notice all the gaping logic holes in his column and if they feel they have to read it will not fuel the flame by responding directly to the column and instead just comment about it on their own blogs if they feel they have to. Sadly, I think fans of open source are going to be suckered in just like the Mac fans are time and time again. Still, you have to admire Dvorak for his ability to state blatantly stupid and wrong things yet get people to react to him instead of ignore him. On the bright side, the open source community must have reached pretty good numbers for him to focus on them.

Threes - Alpha

Let us continue my development diary for the threes game. The alpha build of this game is now on the blazing games coming soon page.

12:30 Time to break for lunch.

13:15 The next phase is to get the player scores and overall multi-player management code into the game. This consists of creating a rough version of the player class and a rough version of the game management class. As with my earlier 36 game, this game will support up to 6 players, with the option of having the computer take as many positions as desired. Color coding seems to work great for separating players. The order will have to be randomly selected, but the first goal is simply to lay out the game.

14:45 Now we want to get the player class actually working. There are five pieces of information that needs to be dictated to the player. The rolling order is going to be randomly determined for every round of the game so that bottom colors do not have an advantage over earlier players. By randomizing the order every round, no position has an advantage over others over the long run. There are 6 players and there are 6 sides to a dice, so having a die indicate the order would be ideal. Next to the order indicator is the human/ai toggle. Then we have the point score followed by the score for the round. Finally, there needs to be a message for indicating if the player has won or tied the game.

16:00 We are still not ready for a new build of the game as we still need for the manager of the game to actually manage the game. First task is to determine the proper order. This uses my basic shuffle algorithm where each item in a list is randomly swapped with another item in the list. Next we have the manager send notice to the player in control a notice that it is their turn. The game will alert the player when the final score is reached. The player then is suppose to call the manager once the game is done. Just before my supper was ready, I compiled the second pre-alpha build.

17:00 Supper.

18:00 We last left with the game flow not quite working so our first goal is to make sure that the next player is properly accessed. Once this is done, the problem with the dice not properly reseting themselves is obvious so that bug is fixed by simply having the start game reset the dice positions. Finally, we add support for ending the game and make the two buttons on the bottom activate themselves. Now that the game is fully playable, I am changing the designation of the game to alpha and have made the first alpha build.

Birthday project - drawing waves

Thanks to the Drawing API that was added to Flash MX, this game is possible to do in Flash. While the drawing API is not as robust as the one found in Java, it is very efficient and is a lot more powerful and flexible than a quick glance at the list of function calls would have you believe. The drawing API is aimed at the creation of vector shapes, while Flash 8 added bitmap support so all that is needed now is support for hardware 3D graphics.

For my birthday project, I am essentially drawing sine waves. Plotting these is fairly simple as you simply use the basic formula of sin( 2*PI*(days_since_birthday+ skew)/period). Multiply this by your hight then plot the point. I drew the graph by simply moving to the first point on the graph then using the lineTo command to connect all the points together. For my purposes this was quite adequate. I could have created a better looking graph by using the curveTo command instead, but that was overkill for my needs.

The graph draws very quickly so I am easily able to update the graph in real time as any of the date or wave control values are changed. This is one of the cooler aspects of this program and is quite fun to play with. This concludes the development of this project. I think there is more then enough information to reveal what this project is, but for those of you who were unable to guess it will be posted tomorrow evening.

Birthday project - Wave Periods

This project, unlike other similar versions of this game, is flexible allowing you to change the math used behind the 3 main parts of this game. It also lets you specify the math to use for a fourth field. Because what we are generating are wave forms, we have to worry about 3 factors. The period, the amplitude, and the initial skew of the wave. We can ignore the amplitude as we just represent that as a %. This means that the user needs to be able to adjust the period and the skew.

As with the date component, this is simple enough to do by creating a movie clip that has two components. Any changes then get caught and the main movie gets a period change event that causes it to update the the graph, which we will be describing tomorrow.

To distinguish the four different controls, on the main screen they are placed over a solid color box. This is where the alpha blending that the default skin uses turns out to be a huge advantage for this program as the controls appear to be tinted in the color of the property being changed. A really nice look with almost no effort required to get it. What else could you ask for.

Birthday project - Date selection

On the weekend I completed another Game in a Day challenge for my Dozen Days of Dice series. The game that was completed was poker dice and it will be released roughly a month after Threes is released, sooner if my other planned releases are not finished. I think that I will continue doing what I am doing with threes and release the early builds of the game and the design diaries here.

Speaking of design diaries, I should get back to the game I am developing for my birthday site release. While game is not the best way of describing what I am releasing, it certainly can not be considered as something serious, though I am sure a few people out there may put too much faith in what I am going to release. I am going to have to be sure to explain my views on the matter in the instructions.

The project needs the user to enter two dates, which is such an obvious thing that one would assume there was a standard Flash component for doing this. If there is, I couldn't find it in the list of components that come with Flash CS3. Still, I am sure that there are countless libraries out there that include a component for getting a date from the user. One could even get really fancy and have the component display a calender that has pages that flip as the user changes the month or year and the selected date could be highlighted in a different color when the user clicks on it. While this wouldn't be a difficult component to create, it would be time consuming to create, and with a weekly release schedule and only limited hours (varying based on how much paid work I have at the time) this is going way overboard for what I need. Searching out for a free component that does this would probably take more time then it would to create my own simple date selector so that is what I chose to do. Yes, the fact that I am a NIH type programmer probably largely factored into my decision as well.

This is actually an incredibly easy thing to create if you use the user interface components that Flash CS3 comes with. The month is a simple combo box that has the names of the months pre-set into it. The month and year are simple number selectors with the min and max values set to logical limits. The date can be created just by grabbing the values from these three components. In fact, by grouping the three components into a movie clip it was simple to create my own date changed event that gets broad casted every time the date changes, which means that as soon as the user touches the date, the X gets updated on the fly. I'll explain what the X is on Wednesday, though I suspect anybody reading this who is up on various superstitions will know what my birthday project is tomorrow, if they haven't guessed already.

Birthday project - Date issues

As the results of a conversation I had I am developing a special program for my birthday. While there are other programs that do what mine does, I didn't write them and they don't allow for the modifications that I desire so I wrote my own version. I have decided that it might be a neat idea to spend the few days before the official release releasing my development diary for this "game". I am not going to reveal what the project is, so readers can have fun trying to guess what exactly it is that I developed.

The first issue with the development of Birthday is dates. In particular, this project needs to know the difference between two dates. The problem is that the ActionScript date class doesn't have built in comparison functions for getting this information. It does, however, have a function for getting the number of milliseconds that have passed since January 1, 1970. By using this number, you can very easily calculate differences in the date. The problem is what happens if you need a date that is before 1970? While for personally using this project this is not an issue, some people who are using this could easily have been born before 1970 (both of my parents were). Looking at the date class, it lets you enter any year that you want, so what would happen if you entered a date before 1970 and then grabbed the milliseconds?

The answer was actually exactly what you would expect. The millisecond value returned was a negative value! This actually works for me. By having a negative value, you would still be able to calculate the number of days between two dates, which is exactly what I need to do for this project. This is a simple calculation as if we subtract the smaller date from the larger one and then divide the result by 86,400,000 then we will know how many days there are between the two dates.

Threes pre alpha 1

I am going to try something different for Thursday posts, and tomorrow will be the start of another experiment. What I am going to start doing on Thursdays is releasing segments of my design diaries for upcoming games. The segments will follow the development of a game up to a logical build point. For people who want to see the actual builds of the game they can go to http://blazinggames.com/games/coming/ to see the build (at least for the week that it is there).

The diary is for the game Threes which I finished a few weeks ago.

08:00 This is actually my second attempt at the third day. While I finished my first attempt, I simply didn't think that my original game was fun enough to be released and decided to delegate it to the extras making this series a baker's dozen worth of episodes. I have decided to make sure that this is at least a worthy of playing game by taking an original street game and making a computer version of it. I have never actually played the game myself and are therefore basing the game design on rules that I have heard so my version may be different from what you would encounter on the street so don't take this version as any type of authoritative version. I am going to be doing the diary and challenge a bit different today. First of all, I am going to be using the real world time (rounded to the nearest 15) not the working time for my entries. Second of all, to make sure the challenges are accurate to what I could do if I was working on the dozen days on consecutive days, I am going to limit my time to under 16 hours. Third, I am going to be taking screen shots and keeping copies of older builds which I may bundle together sometime in the future for people who are interested. So lets get started.

08:15 Let us start by getting a skeleton ready. As you should already know, the logo is canned so is just copied over. A simple title screen for now, though I want it clear that this is a pre-alpha build. I am allowed to use assets from prior dozen day of dice games, which really isn't very much except for the big ticket item for this series. That, of course, is the dice.

09:00 With a skeleton in place, it is time that we start building the game. You may notice that the time jumped by 45 minutes even though I only did 15 minutes of work. I had to take a biological break and decided to grab some breakfast while I was on break. While this is obviously a multi-player game, each of the players essentially play their own game and just the scores are compared. For that reason the first step has to be to get the main game working so I will put together a rough version of the main game. If I have released my screen shots, you will notice that the program I am using does not look very much like Flash CS3. In fact, it is not. I really dislike the CS3 editor, so I use jEdit which is a really nice open source editor that has code coloring support for a variety of languages, including ActionScript. The first version of the game movie was created. It takes advantage of an external class file which contains my ThreesGame code. The actual CS3 movie contains 5 copies of the die which I labeled _die1_movie through _die5_movie. Over top of these I add a button that has an empty normal frame and a alpha highlight for the over and down states. These buttons are labeled _hold#_btn and are used for toggling the hold positions of the dice. I also create a simple roll button that the player uses to initiate the rolling. The game activates the roll button. When it is pressed, a roll of all dice that are not held is done. Any held dice are marked as locked and can no longer be unheld. The game then enters the keep state where the roll button is hidden until at least one die is held. While there is a bit of cleanup needed yet, the game does function so my first pre-alpha build is officially done at this point.

Implementing an automap

There are a number of ways to implement an automated mapping system, with the requirements of your game being the biggest determining factor on how you implement the automated mapping. There are two parts to an automapping system. You need to store the data for the map, and you need to display the map.

Marking the areas of the map that are known to the player is very dependent on how your map is organized. If you have a simple tile map, then you could go with a very simple system of having a flag for each tile indicating if if has been seen or not. More complex structures can be broken into separate visible areas with each area assigned a bit. Another method of creating an automap is to just create a new map as the player journeys through the map. This takes significantly more memory, but has the advantage that structures such as secret doors can remain secret until the player actually enters them without increasing the complexity of the automap renderer.

Determining what parts of the map has been uncovered has it's own challenges. The easiest way, which is the method I usually choose, is to simply unveil a block of the map that surrounds the player. If you have more time to spend on the automap, then you could actually do visibility checks to mark all the areas that the player can possibly see as uncovered. You could also increase the complexity of the automap data by tracking where the player has actually been and what they have seen. The renderer could then display known but non-entered areas as grayed out.

Displaying or rendering the map is simply the matter of drawing the parts of the map that the player has seen. In flash, tile methods can be fairly simple to implement, but if you are using later versions of flash, creating the automap as a bitmap is more efficient. The thing about automaps is that the map doesn't need to be generated. If you wanted to, you could hand draw a map and then use the automap data to slowly uncover portions of the hand-drawn map.This could add a really neat feel to the game, and for games who's maps are not logically laid out would allow for an automated mapping system.

Why do people hate maps?

Back when I was a kid, when I was playing an adventure game or a role-playing game, drawing your own maps was simply considered to be part of the game experience. Not only did many early role-playing games not have auto maps, but the designers often went out of their way to make sure that creating a map was a challenge. There would be nifty things like tele-porters and twisters and lots of interruptions by wandering monsters just to make sure you couldn't concentrate on figuring out why your map was wrong. Some of the text adventure games I played were even worse as often the maps were not logically put together. The first role-playing game that I played that had a map feature was Ultima 3, which happened to be the first Ultima game that I played. Even that game didn't have an auto map. Instead you had to buy things called Gems (which were expensive) and then peer into the gem (destroying it) to get a map of the current level of the dungeon.

More modern games now make the map for you. I can't exactly say when this started to happen or why, but I have a couple of theories as to the reason for this. The first theory is that a few role-playing games had this feature while others didn't. The games that didn't have an automated map feature started receiving complaints due to the lack of the feature. The companies getting the complaint letters added the auto map feature to their checklist of requirements. I come to this theory from personal experience. People rarely email me to tell me that they enjoyed any of my games, but if they have a complaint they are much less reluctant to email me and air the complaint. My games are free, so you must wonder how much worse it must be for the companies that actually charge people for games. My other theory, which might be the more accurate one, is the keeping up with the competition theory where other games had the feature so the marketing department added that feature to the list of required features so their games could remain "competitive". This is also the primary reason why so much software is bloat-ware.

The key question here is why exactly don't people like making maps? As a kid I found it to add to the gaming experience. Yet going by my email it is clear that people want an automated map feature. I have broken this down into three possible reasons and suspect that each gamer who insists on automated mapping falls into one or more of these three categories: too much like work, too prone to errors, or last page syndrome.

From a technical standpoint, map making is quite a bit of work. The reason I didn't mind it is that at the end of the game you had a physical object that could be used to show to your friends that you really did finish the game. Perhaps it is a sign of my age, but a home made map of all the levels of a game seemed to be an accomplishment that was much more satisfying than the end of game screen.

Anyone who has tried to make their own map has probably run into the second reason. In some cases the game just doesn't map out logically. In other cases, all the combat that takes place has made the map wrong because you forgot to mark a square or accidently marked a square twice or were mapping in the wrong direction. Figuring out where you made the mistake can be time consuming and very annoying.

The last reason probably is the most common. Today's society is very attention deficit, thanks largely to commercial television. Many players don't want to have to take all the time necessary to go through the level and make maps as they play. They want to get through the map as quickly as possible so that they can get to the next stage of the game as quickly as possible so they can finish the game as quickly as possible so they can spend their money and get the next game as soon as possible like good consumer sheep. With there being so much good quality content available I suppose that this attitude does reflect the current reality while when I was a kid I could only afford to get a few games a year so what games I got had to last. It wasn't that long ago that I was a kid so certainly things are changing fast.

One of those Weeks episode 18:Completing the Quest

The Canadian Thanksgiving long weekend is this weekend. This means that I am probably not going to be making another post until Tuesday. That also means that I have to worry about having enough time to finish the game that I plan on releasing next friday. I am hoping to have episode 32 of One of those Weeks ready, but if I can't finish it in time, I need an alternative to release. While I suppose I could use Threes as my alternative, I want to keep the current flow of having One of those Weeks content every other week continuing so I am going to make sure that chapter 18 of my making of One of those Weeks eBook is ready to be released.

Episode 18 is a rather interesting episode due to the fact that the predominant scoring factor of the game is a feature that I just didn't have time to implement in earlier episodes due to my usual time constraints. It is also the first time that the entire outdoors areas that the island comprises of are available to the player. Actually, three "rooms" are not present as they do not add anything so instead of including the walnut areas of the game, the player is instead thrown into the forest.


While solving this episode is fairly straight forward, getting a perfect score may elude a few people, so I will walk through this episode with the goal of getting a perfect score. When you wake up in the cockpit, make sure you pick up the pen and the notebook before leaving. In the orchard grab some oranges because as was revealed in the opening thought balloon, the oranges you picked the previous day are mysteriously missing. Next head into the forest. Make sure you map the entire forest, as part of the score is based on how much of the forest you mapped. When you reach the beach, head to the right and examine the big rock that is there. Head to the left twice to reach Charles's cave. Click inside the cave to notice the similarities between that cave and the one in the forest. Talk to charles to end the episode.

For those of you who prefer some type of scoring table:

• 5 points for getting pen and notebook
• 5 points for grabbing oranges
• up to 5 points for exploring the forest
• 3 points for finding the launching point for your raft
• 2 points for making the cave connection.
  

And that is all there is to this simple episode.

Why don't I use C

With all my ranting about the limitations of Java applets and Flash, one must wonder why I simply don't use C. I use to do a lot of C programming in the past for the simple reason that it is a lot faster to write code in C than in Assembly Language and the code is much easier to port. While Java and ActionScript are easier than C, they are not that much easier so one has to wonder why I am being such an idiot and sticking with Flash when if I moved back to C I could quit complaining about the limitations and start writing multi-threaded games that took advantage of hardware 3D.

The biggest factor has to be the simple fact that I want people to play my games. If people had to download the games and run them on their computer, the number of people who would play my games would drop, probably drastically.

The second reason is that I then have to worry about which operating system I am writing the game for and have to deal with porting the game to other operating systems when it is done. This is starting to become a non-issue as there are many cross-platform libraries now available and many of them are open source.

The third reason is that by having the game on my own site, I never have to deal with versions of the game. If I make an improvement to a game (or fix a bug, not that my games have any of those) then that version gets posted and everybody is immediately using the latest and greatest version. Anybody who has had to answer complaints about version 1.0 when the issue was resolved in 1.1 and the current version is 3.0 knows what I am talking about.

Still, once I have finished my current list of projects (One of those Weeks, Coffee Quest revenge b4 5 and 6, Dozen Days Pentalogy, and the Ultimate Retro Project) I will probably take another look at going to C for my next project.

Astro and the dragon

I have heard some people saying that the 3D in Astro is software 3D. From watching the video clip of the announcement the words "native support" mean that it is a feature built into the player which means that even if it is software, the action script api would be making calls to native code graphics functions which would still be considerably faster than doing the work entirely in ActionScript. Nobody will know for sure what the real speed and capabilities of the 3D support will be until after the beta is released and there is no announcement as to when that will be. So even if the simple 3D support is entirely in software, it will be faster than what can be done in ActionScript and libraries like PaperVision3D or Sandy should be able to take advantage of the API to get a speed boost. Below are links to keynote videos for those who want to see them yourself.

http://www.youtube.com/watch?v=ympeCv8lLmw
http://www.peterelst.com/blog/2007/10/03/adobe-max-chicago-sneak-peeks/

Another thing that Flash player 10 is going to have is support for Adobe's Hydra programming language. I don't know why the language is named after a multi-headed dragon but Hydra is a graphics processing language that will take advantage of the hardware shading languages that many 3D cards support. The technology preview that is currently on Adobe Labs requires 3D cards that support hardware shading but they say that software based rendering will be in the future releases for people who don't have high-end video cards (like me). If you do have a high end video card and want to experiment with Hydra, the link is

http://labs.adobe.com/wiki/index.php/AIF_Toolkit

While the upcoming 3D features of Astro may not be robust enough to be the end of projects such as Sandy or PaperVision3D, I am hoping that there is hardware 3D support in Flash Player 10 and that it is good enough to make the existing 3D libraries irrelevant. While this may sound harsh, if there was a standard native library for doing 3D in Flash that was better than the existing software libraries, then everybody would benefit. Though going by personal experience, the Flash Player releases are just better enough to force me to have to upgrade but not good enough to do everything I want to do. At least this is better than Java, which basically abandoned the applet. Yes, FX looks neat but it really seems to be too little too late.

Astro

Adobe had a really interesting announcement at their Max 2007 conference which I was not able to attend. Thankfully there were press and bloggers to attend the conference so that I could find out about the next version of the Flash player. It appears that Adobe is taking Silverlight and Java FX as serious competition and have decided to raise the stakes with the version 10 of Flash. The best part is that it appears as if they will be giving me exactly the feature that I want.

Flash player 10, which is code named Astro, is going to have much better text support. Wait...that's not it. Astro is going to support 3D. The demo only showed manipulation of sprites and movie clips using x, y, z coordinates and rotation along all three axes. I am assuming that this will be done using hardware 3D acceleration. No mention about support for 3D models was mentioned, but if there is hardware accelerated rendering of 3D sprites, it would probably be fairly trivial to port Papervision3D's Collada support.

I am not aware of any estimated release date or if there is going to be a public beta. If there is, I will certainly try to participate in the beta program. Right now I am trying to make sure that the renderer that I am developing for Coffee Quest Revenge is modular so that it will be easy to swap out with a better one if Astro is released significantly earlier than I am anticipating.

On the weekend 1+1=3

I managed to accomplish a lot this weekend. Not only did I successfully finish my game in a day challenge for the Dozen Days of Dice series, but I also got Modern Cribbage to a pretty functional state.

The game I chose for the dozen days challenge is a street game called Threes. The game seems simple but actually has a surprising amount of strategy involved. Of course, it is a dice game so luck is also a big factor in playing the game.

Cribbage is fully playable, but could use a bit of fine tuning. This leads to the question of whether I should try to quickly tune up the game for Friday, or if I should release Threes on Friday and hold Cribbage back until the 19th? If any of the few people who actually read this have a preference, they can determine my choice by emailing me (spelchan) at my BlazingGames.com email address.

Not playing Halo 3

While I am going to be busy the next few month's so will not be updating this blog as often as I would like (I am still going to try to post a couple of times a week) I will say right out that it is not due to Halo 3, as I do not have an XBox 360 nor have I plans to get one in the short term. That being said, Modern Cribbage is under way and is starting to look nice, but it will not be finished this Friday. After looking at the news archive for Blazing Games for the last few months, I have decided a couple of things.

The first thing, which actually was decided a few weeks ago, is that I am going to start combining Open Source releases with other things and will only have one open source release every four weeks unless there are special circumstances.

The second thing is that I will try to make sure that other series are represented between releases of One of those Weeks related items. Obviously, for the next while at least, the open source releases will be for One of those weeks. There will then be a game from a different series. Then there will the new episode of One of those Weeks, followed by another game from a different series.

Spam

I have not had too much problems with spam since I moved my blog over to Blogger. Still, when I was checking my mail earlier today I noticed a spam comment was posted (I have blogger set up to email me if there are any comments posted). I am hoping that this is an isolated case and that the amount of spam that my posts get will continue to be a minimal amount. Thankfully if worst comes to worst then I take advantage of Blogger's moderated comments feature. The problem with this feature is the simple fact that I only check my email once or twice a day. This is probably all moot since this is a blog about game development and has very few readers. Sill I want to leave the possibility of comments open to readers.

Another thing that I was thinking about is changing the way my feed is set up. Right now only the first 256 characters are sent in the feed. I am thinking of changing that to the entire post. While this would probably eliminate almost all of the visitors to my blog, it wouldn't eliminate readers as they would be subscribed to the feed. If you think this is a good idea, email me through the BlazingGames.com contact page and I will make the change.

Your BDS is in My GPL

There is an interesting debate going on in the open source community about the use of code under the BSD license with code under a GPL license. If you actually read the BSD license, or better yet have your lawyer read it, you will see that certainly is allowed. If you follow the BSD license to the letter, and include the BSD license with the BSD code you are using then you can certainly use BSD code within a GPL project. What confuses me is the fact that die-hard BSD fanatics have no problems with BSD code being uses in commercial projects from which no code is returned to the open source community, yet have a problem with the code being used within a GPL project.

The issue, I believe, is that the GPL is a more restrictive license than the BSD license because it forces you to share changes. This means that GPL code can not be used within BSD programs due to the basic fact that the code sharing requirements are not covered by the BSD license. This means that any changes to the BSD code within the GPL project would be under the GPL license. While someone could strip out all the GPL code and be left with BSD licensed code, they would not get the improvements. As the BSD license does not require sharing of improvements, this is a non-issue. If the author of the code wanted to make sure that improvements had to be shared, then they should have gone with a license that requires this, such as the GPL.

I tend to be a NIH (Not Invented Here) type programmer meaning that I tend to want to write as much of the code myself as possible. While I have no problem using the libraries that are a standard part of a language, I tend to avoid using third party libraries whenever possible. This is largely a result of bad experiences with closed source libraries. As code complexity continues to grow this is becoming less possible to not use third party libraries and I suspect that future projects will likely be built on top of other peoples code so issues like the one above are going to become increasingly important to me. My thoughts are that if changes are made to a third party chunk of code, those changes should be offered to the original project.

There are al lot of BSD fanatics who seem to live in an alternate universe where big businesses are honest and give back to the community as much or more than they take. My experience with big business is quite the opposite which is why most of my projects tend to be released under the GPL or LGPL for the very simple fact that I want any source code that I release to stay open. I think that most people who do go with a GPL license feel the same way which is why there is such a vast amount of projects that are licensed under it.

A Weekend of Cribbage

This weekend I decided that I would finally finish the Third volume of the Ultimate Retro Project. The only outstanding game in that volume of the series is the final Cribbage game. I was partially successful and managed to finish the classic version of Cribbage which will be released this week. As most of the code in the game is shared between both the classic and modern versions of the game, it is quite likely that the modern version will be finished quite soon, though my evenings are going to be put towards getting texturing into Coffee Quest Revenge.

One of the problems I ran into, a problem I am going to refer to as the final 10% problem, is the fact that once you have a game running, the fine tuning of that game always seems to take forever. You find that there are a bunch of loose ends so you tie them up only to find that a new bunch of loose ends have been exposed. What I do is have a to-do list that starts off with the list of all the things that need to be done. Every time I run the game, I add any new tasks to be done to a new to-do list. Once all the tasks in the original list are done, I do a complete play through of the game which inevitably will lead to a few more entries in the new to do list. I then look at the new list and decide if another iteration of tuning is warranted.

I would like to think that if I was actually being paid to develop these games, that the "good enough" threshold would be much higher so more iterations would happen. Sadly, having worked on third party games I know that is not always the case. In real games it is often not the developers who have the final say but the managers and company executives. While one could argue that they are paying for the development of the game so of course they should have the final say. In some cases, such as with free promotional games, that is true. In most cases, though, they are going to sell the game to customers so it is really the customers who are paying for the decision.

Do I have a point? Well, there is the obvious one that if you are not paying for a game, don't complain about it, but I honestly don't mind getting complaints about my games because that helps me improve future games. I suppose what I am really trying to say is that consumers should be more choosy about the games that they buy because if they were we would have fewer rushed-out-the-door-to-make-a-quick-buck titles on the market.

Jigsaw puzzles

One of those Weeks episode 17 revolved around what is essentially a jigsaw puzzle. Creating such a puzzle, both in the real world and on the computer, is a fairly simple task. The nice thing about jigsaw type puzzles is that not only is almost everyone familiar with them but there is a lot of flexibility in how the puzzle is put together.

If we look at making a real world jigsaw puzzle, it is a fairly simple task. You simply take a picture and glue it to cardboard or wood. Alternatively, you can create original artwork directly on the cardboard or wood. Once you have the artwork on the wood or cardboard, you take a cutting tool, such as a jigsaw, and cut the picture up into pieces. If you are using wood, you may want to carefully sand the pieces so you don't get slivers. You then have a unique puzzle.

I should point out that the shapes of the pieces do not have to be the traditional shape that most purchased jigsaw puzzles are, though that familiar shape has it's advantages. If you find some really old jigsaw puzzles, you may notice that many of them have more of a wavy shape to the pieces and often there are size variations in the pieces. The problem with this style of puzzle is the simple fact that the pieces don't stay together. The more modern puzzle piece have interlocking holes and tabs so that when assembled they do not easily come apart.

When writing a computer version of a puzzle, the biggest obstacle is with the graphics. It is always easiest to work with blocks of pixels, so often shapes are blocky in appearance. Another potential problem is the positioning of the pieces on the board. If all pieces are the same size, this can be treated as a grid (even if you are not using square pieces). Variable sized pieces are a bit trickier in that you would have to break the results grid into pieces that are the lowest common denominator in size and have pieces be aware that they are taking up multiple slots.

CQR Pre-Alpha Build 6

The new episode of One of those Weeks is up. For those of you following the development of Coffee Quest Revenge, the renderer used in the episode of One of those Weeks is the one being developed for CQR. In fact, pre-alpha build 6 is now up at the coming soon page which uses alpha blending to render a view on top of the automap. I think it kind of looks neat. I forgot to fix the keyboard bug. For those who are curious, the keyboard bug is caused because I am attaching the keyboard listener to the main movie clip instead of the stage. When you click on something, focus is given to that and the result is no more keyboard events being broadcast. By attaching the listener to the lowest level stage, all keyboard events get passed through to the program.

FLOSS - The LGPL

My discussion about open source continues with a look at the LGPL license. When you are modifying large programs, the GPL is quite fair. In the cases of libraries, things are a bit different. A library is a collection of functions that are used to make writing new programs easier. The problem is that if you are using a GPL licensed library, you are using GPL code and have to release your project under the GPL. While one could argue that nothing but development time is forcing you to use that GPL library, some programmers feel that the library should be considered a separate entity from the main program and understand that some people don't want to release their source code. For those people there is the LGPL.

The Lesser General Public License was at one time known as the Library General Public License as the whole purpose of the license was to make it possible for library creators to allow other people to use their libraries in the project without forcing the project into the GPL. This license effectively treats the code within the library as a separate project from the main code. Any changes to the source code of the library are treated like changes to a GPL project. However, the project using the library can be released under any license or even kept as closed source.

The reason that the name was changed from Library to Lesser has to do with Richard Stallman's basic philosophy when it comes to open source software. Richard wants to see everything released under an open license, and as such the LGPL fails as it can be used as part of a closed source project. At the same time people who do use this license tend to do so because they want their source code to be usable by as many programmers as possible while still wanting the code they release to stay open. Some companies won't use GPL code but will use LGPL code so the LGPL programmers do have valid arguments. Likewise, certain types of projects really can benefit financially only if they are closed source so the LGPL allows those developers to at least contribute part of their work to the open source community which would be something they could not financially do if the GPL was their only choice.

What is ray casting?

I am sure some of you are wondering what this ray casting thing I am talking about is. Essentially it is like ray tracing except with only one ray per column of pixels instead of one ray per pixel. So the next questions would have to be what is ray tracing and what are the advantages of ray casting over ray tracing.

Ray Tracing is one of the oldest forms of 3D graphics generation. The concept is simple. What we see is made up of light. This light comes from one or more light sources and bounces off objects that absorb some of the lights energy causing it to change color. Eventually the light reaches our eyes where we see the results. Some brilliant person came up with the idea of doing this process in reverse. If you start from the eyeball, you can mathematically work out the path of the light as it travels through the world and trace the route the ray of light took back to it's original light source. By doing this, you can generate incredibly realistic looking images. The down side to this is that there are an awful lot of calculations, and the more complex the objects in the scene the more calculations have to be performed.

The advantage ray casting has is that it is done in a much simpler environment. In fact, it is often done on two dimensional maps that get projected into three dimensions. Because the geometry being calculated is so much more predictable, the amount of calculations that have to be performed are drastically reduced. In fact, ray casting can be done fast enough that it can be used for a game without requiring any 3D hardware support. When you are using Flash, at least as of Flash 9, you don't have 3D hardware support or for that matter any type of standard 3D library. The popularity of open source Flash 3D libraries is growing so eventually Adobe may finally add 3D support. I know for a fact this is a feature that a lot of developers have asked for. Until there is proper 3D support in Flash, all 3D will have to be done in software which means that the speed will be significantly slower meaning that the experience won't be anything like you could achieve if you had hardware 3D support.