Wednesday, October 31, 2007

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.

Tuesday, October 30, 2007

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.

Monday, October 29, 2007

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.

Thursday, October 25, 2007

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.

Wednesday, October 24, 2007

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.

Tuesday, October 23, 2007

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.

Monday, October 22, 2007

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.

Friday, October 19, 2007

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.

Thursday, October 18, 2007

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.

Wednesday, October 17, 2007

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.

Tuesday, October 16, 2007

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.

Monday, October 15, 2007

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.

Friday, October 12, 2007

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.

Thursday, October 11, 2007

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.

Wednesday, October 10, 2007

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.

Tuesday, October 9, 2007

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.

Friday, October 5, 2007

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.

Thursday, October 4, 2007

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.

Wednesday, October 3, 2007

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.

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

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.

Tuesday, October 2, 2007

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.

Monday, October 1, 2007

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.

About Me

I am a programmer who can program in a large variety of programming
languages (including some Assembly Language) but am currently focused
on interactive web development which means my current focus is on Flash
and JavaScript. When I am not programming for clients, I am working on my
game site.