Spelchan.com Summer 2019

Blazing Games has been closed, at least the home page has. For the moment I am leaving the other pages up so if you know the link to a game then you can still go to the page. This will be eventually changing but I'm in no rush here. I produced a lot of Games so there is a huge amount of porting work to do. I have reviewed the  results of the poll and as a result have made changes to my release plans for this year.

Coffee Quest was released a month early. My holiday games seem to be slightly more popular than I expected.  For this reason I am going to make sure that I have holiday games ported as appropriate. This decision has me in the process of porting my Canada Day flag game for release this Canada Day (July 1st for non-Canadian visitors). Next year I will release my Independence Day game for my American friends.

I have decided that, in memory of my Mother, I am going to only release Color Collapse episodes on Mother's Day but do plan on creating related games once the remaining two episodes have been released. 

I noticed that the voting list of games missed some of the games that were already in HTML5 so those will become filler for when I am too busy to finish porting other games. The first of these will be Sudoku which will be released in August as my card and dice collection are very low in popularity. A beta of Coffee Quest 2  will hopefully be released this September with a Halloween game for October. November’s release is not yet determined yet and will be dependent on my time in September and October and I plan on creating a unique Christmas game this year.

I am not going to have any official release schedule for 2020 (other than a game every month) but do plan on showcasing the games I am working on in whatever game I am going to release in January. Hint, it will not be an updated Calendar NIM game this time.

So hopefully you will enjoy the site. Next fortnight I will start the next chapter of my Creating HTML 5 Games with Animate eBook so hope you continue reading.

Coffee Quest Trilogy Plans

The Coffee Quest (CQ) series started off as an attempt to create a web-based role-playing game using the then-new Java programming language. Java, while a very successful language in many areas, failed in the browser and has been replaced by JavaScript using HTML5 components and CSS3 style sheets. This tends to be collectively called HTML5. My original plans for porting to HTML5 was to simply use an engine that supported HTML5  and finally get around to getting my CQFS engine working by building off the back of another engine. I started experimenting with the Unity engine but really do not like that engine. Then I remembered that for a game jam I participated in back in 2012 that I started working on a FPS version of Coffee Quest. That existing work, while still in an early development stage, would be perfect for the first three games in the series so I decided I would do a Coffee Quest Trilogy game that would combine the first three games into a single package. As this game is developed, the individual episodes will be released on Spelchan.com giving visitors to my site early access to the game.

The enhanced HTML5 version of the game will be mixed-time combining both real-time and turn-based play. I may make the option of an FPS mode where the game would be fully real-time. Each game in the series will have multiple episodes to reflect the different maps, and possibly a number of new maps, that will be made available. I have not decided if in the final game to lock the maps and require players finish other maps to unlock additional maps or if to make everything accessible. A third option would be to have all the Coffee Quest 1 maps initially unlocked to the player and once they have finished any of the maps, to unlock all the Coffee Quest 2 maps. Once a Coffee Quest 2 map has been completed, then the Coffee Quest 3 maps would be made available.  

My ideal release plans, which knowing history are very unlikely to work out, are as follows:

Quarter 1 of 2019 would be the release of the Coffee Quest release candidate with a new map (or two). The goal here would be to have a better automap, better quest status area, and the ability to click on the automap to bring up a full-screen map screen.

Quarter 2 of 2019 will hopefully be the beta release of the Coffee Quest 2 module which introduces monsters and inventory to the game. The Coffee Quest series uses the concept of conditions to weapons where the weapon deteriorates in quality over time and will break if the weapon or armor deteriorates too much. One change that the enhanced version of the game will have is that picking up additional copies of the same weapon will simply improve the quality of the weapon if you already have that weapon instead of filling up slots in an inventory.

Quarter 3 of 2019 will hopefully be the release candidate version of Coffee Quest 2 with a new map and enhancements/fixes made to the game.

Quarter 4 of 2019 would be a new Christmas game using the CQ-Trilogy engine.

Quarter 1 of 2020 would be the beta of the Coffee Quest 3 game which would introduce multi-floor towers.

Quarter 2 of 2020 will be an easter-themed game using the CQ-Trilogy engine.

Quarter 3 of 2020 will be the final build of the Coffee Quest 3 module.

Quarter 4 of 2020 will be the beta release of the combined game and will have some new maps as well as a halloween themed game.

If I fall behind on one of the quarter objectives then I will release additional maps for that quarter’s release. This would delay the final release of the game by a quarter. If things go smoothly I will finish the enhanced version of the original Coffee Quest Trilogy by the end of 2020 but odds are there will be a couple of quarters that I will miss so most likely this project will not be completed until 2021 or 2022 in the worst case situation. Depending on my situation once this project is completed, I will look into doing a similar project for the porting of Coffee Quest 4 and the final creation of Coffee Quest 5 and 6.

Coffee Quest 2600 postmortem

The Mini-Ludum Dare for this month had the theme of Demakes so I decided to create a version of Coffee Quest as it would be had it been created or ported to the Atari 2600. The link is http://blazinggames.com/gamejams/2014/MiniLD50/ but  it is going to be my April game. That means it is time for a postmortem.

What went right

For rendering the 3D view, the program emulates the play field graphics of the 2600 by having a function that takes the pf0, pf1, and pf2 registers along with 3 alternate values for the right side of the screen. While writing the rasterizer as if I was really coding for the 2600 took a lot longer than I like, it ensured that the resulting game was actually something that could run on the machine.  For me, the whole purpose of this challenge was to create a game that could actually run on real hardware. With a bit of work, it would be quite possible to create a full-fledged RPG along the lines of Coffee Quest IV on the 2600. Sure, the graphics would not be that great and a pretty big cartridge would have to be used but it is doable.

Mixed blessings

While the rendering is done the way it would have been coded for the 2600, the map is not. The map is 32x32 bytes which is far too large. If this was coded properly, the map would have been broken into a wall bitmap (which would have only taken 128 bytes of ROM) with an additional 16 bytes to hold the coordinates of the objects. The time taken getting the renderer working made this impractical so I went with a traditional tile map approach so the game could be finished over the weekend. As I know my reduced memory approach will work, this is not that huge of a deal as the game is clearly still possible.

What went wrong

I simply did not have the time necessary to create this game for the 2600 so had to roughly emulate the limitations of the system.  Having researched the 2600 before starting this project, I found the limitations of the platform really intriguing so was sad that doing this project for real hardware (or at least a properly emulated version of real hardware) was not practical. The problem is justifying the amount of time that would be required to create this game on a 2600 emulator. Even considering that modern tools allow for much greater efficiency in creating the game, I suspect that it would take at least a solid month of work to finish this game. With no real way of recouping the value of my time, this project is sadly not worth doing. If enough people were interest (or if someone was willing to sponsor the game) then I might reconsider this project. So, if anybody wants to see this project running on a 2600 emulator, email me at spelchan at blazinggames dot com and let me know.

Next week, partly as a continuation of this topic and partly to demonstrate how different machines can be when it comes to assembly language, I will be going over the Hello World program that I wrote for the Atari 2600. Just quickly going over what is required to do that simple program will give you much more respect for those poor 2600 programmers.

Thoughts on Coffee Quest 5/6

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

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

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

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

7DFPS Postmortem

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

What Went Wrong

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

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


What Went Right

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

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


The future

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

Thoughts on Forever

I am going to delay my series of articles on the creation of episode 3 of Dozen Days of Tiles for a couple of weeks so I can touch on a couple of other topics. The big news in computer gaming (and to a lesser extent video gaming) circles is the release of Duke Nukem Forever (DNF). The reviews have been more negative than positive. Some of the negative reviews are negative because of the games play mechanics and other game play issues. These are fine and I consider them valid criticism. Other reviewers are those people that incorrectly think the game should be better because it took so long to develop. These people annoy me because the development time for DNF has nothing to do with its quality. There are a large number of reasons for this, but lets just look at the top three reasons.

First of all, the number of years a project is in development is not related to the development years of a project. A development year is one person working full time on a project for a year. If I spend 4 years working on a game and a team of 4 perfectly coordinated developers worked 1 year on the same type of game, the amount of time spent developing the two games is the same. My game should not be better because it took 4 times as long to develop because it didn't. Therefore, looking at the development time of a game strictly based on the number of years it has been in development is just stupid.

Second, the game changed game engines and major subsystems multiple times during development. This is not something that can be considered lightly as porting code from one platform to another is going to take a good chunk of time. In some cases, you may even need to spend a good chunk of time to recreate functionality if the features of the new engine are different. This is why very few games change their underlying engine mid-stream.

Finally, a huge part of the repeated delays of the game was a result of playing catchup. Many programmers, myself included, have worked on projects that have a moving goalpost. What happens is that you have your initial specifications and you work hard to reach these. Months before reaching the goal there is a review of the project and the big-wig decides that things have changed so new specifications are created requiring major changes to the existing code so the project is delayed and just before the project is finished, the big-wig shows up again and ... repeat until either the big-wig or the project (or both) are dead. DNF was clearly caught in the trap of trying to stay ahead of the game market. Every time it started getting near completion, enough time had passed that the game was no longer meeting the cutting edge requirements of management so the game would be delayed to allow time to catch up with the rest of the industry.

This is similar to what has happened with my Coffee Quest 5 project, the difference being that CQ5 has not been in development for all this time. My problem with CQ5 was more of a wanting a browser based game that would be able to use technology that simply was not available in browsers. The few times I did start on the project, it was quickly put on ice again as the technology simply wasn't there. While there were some Java 3D libraries, they simply did not work well within the browser as I discovered when a huge number of people had issues running CQGL. I had considered porting Coffee Quest to Flash and use PaperVision, but found that it had issues and  Flash Player 10 was going to have some limited 3D support. So I waited for Flash Player 10 only to discover that the 3D effects had major sorting issues. Now  there is the upcoming Mole-Hill version of Flash in beta as well as Web GL so the possibility of finally developing CQ5 is in my mind again.

Had I not had unrealistic expectations for the speed of browser development, I probably would have just enhanced my existing ray-caster or possibly even developed a simple software 3D library and released CQ5 many years ago. Sadly, I had Hardware 3D in the back of my mind and CQ5 ended up on the back-burner as I waited for Adobe or browser venders to finally put proper 3D into browsers. Something that really should have happened a decade ago but still hasn't happened.

While DNF may suck, I wonder how much of it has to do with overly high expectations and how much has to do with poor game play. I won't know the answer to that question until I see a copy of DNF in the bargain bin, as going by the reviewers I trust the game is not worth full price (and probably not worth bargain bin prices either but I am curious).

April Fools 2010

Here is the text of the April Fools message that was posted on Blazing Games. Note the first letter of each sentence and the date at the bottom. I (Billy D. Spelchan) am still president of the company, and as this month's release shows, we are still slowly transitioning to HTML 5. Flash will probably be our main development tool for the next few years, though.

At Blazing Games, we are proud to announce a deal between ourselves and Microsoft. Sadly, Billy D. Spelchan has agreed to sell his shares of the company and has terminated his position as President of the company, we wish him best of luck with his future endeavours. 

Part of the deal will require that all of our Java and Flash games be replaced with Silverlight versions of these games. Work on this transition has already begun and the non-silverlight games should be removed from the site by the end of this week.

Rich Internet Media in the form of Silverlight is the future of the internet. HTML 5 features simply do not match the power and potential of Silverlight. Our former president's views on open standards clearly are outdated.

Internet Explorer will become the browser of choice for viewing Blazing Games. While we will not be taking any moves to prevent users of other browsers from accessing our site, testing will only be done on Internet Explorer 8 running on Windows 7. We recommend that visitors upgrade their machines to Windows 7 as soon as possible.

Lots of people, such as our former president, have the mistaken feeling that making a deal with Microsoft is the equivalent to selling your soul to the devil. We hope that crazy superstitions such as that are not going to impact our existing visitors enjoyment of this site.

For those of you who feel you can no longer support the site, we thank you for your consideration for other people by making site bandwidth available for the countless new users we will be receiving from a high placement on the Bing search engine. Clearly Bing is vastly superior to that googol thing that our former president used.

Our open source efforts will continue, though we will be switching from the virus-like GPL license to the much more business friendly Microsoft Public License (Ms-PL).

OSX users do not have to worry about Silverlight as Microsoft has assured us that they will always support the OSX version of Silverlight. While not all the advanced features of Silverlight will work on the Macintosh, OSX users always have the option of purchasing a copy of Windows and installing it on their Bootcamp partition.

Linux users are urged to give up their anti-capitalist ways and install Windows on their computers as that is what their machines were designed for. Those Linux users who are running old, obsolete hardware should do their part to restore the economy by purchasing new hardware capable of running Windows 7.

Small changes to our games, such as changing the One of those Weeks' Blue Screen of Death into the Linus the Penguin of Doom and changing Coffee Quest into Clippy Quest will be done at the request of our generous corporate partner but feel that such minor changes will not alter the enjoyment of those games.

M. Caton
President,
Blazing Games Inc.
April 1, 2010

Making Coffee chapters 4 and 5 released

The making of Coffee Quest eBook has finally been updated after a few years hiatus. I have added chapters 4 and 5 which finishes the creation of Coffee Quest 1 and the Coffee Quest GL experiment. I am deeply considering doing another 3D experiment using a new web technology that Google is testing. This would be done by porting Coffee Quest 2 to the javascript-based technology.

I was also hoping to have a pull down menu based poll for selecting which game my visitors most wanted to see enhanced. I never got around to writing the code earlier and as it is getting late I figured I would hold off on the official pull-down version of the poll (which I may make a permanent part of the home page) in the future. Still, email opinions are welcome.

Happy New Year

Just a quick update to let you know that I have finally finished posting the first game of the new year. Of course, I could not resist starting off the year with the first episode of the second season of the Dozen Days Pentalogy, Dozen Days of Words. Even though the year has just started, I am thinking of altering my plans for the year. That would require me finishing Coffee Quest 5 first, so the every other week schedule will continue as planned for a while. I am hoping to prove all of you who are thinking "Yea, like that's likely to happen" wrong, but only time will tell.

June starts out with a dozen days of dice

The Blazing Games site has been updated and the schedule for the month has now officially been posted. The first game to be posted this month is actually two. Episodes 5 and 6 of the Dozen Days of Dice are being released as open source. More importantly, all future episodes, which will return to a monthly release schedule, will be open source from the outset. The games will be shifting from being developed in Flash CS3 to being developed in Flex and being compilable with the freely available Flex3SDK. The reason for this shift is the simple reasons that a free tool (that is also open source) is available to everyone who wants to use it while Flash CS3+ is an expensive package that not everyone can afford. In addition, Flex is entirely text based which is much nicer to work with for open source projects.

The second week of the month is the release of Thirteen Spikes Unlimited. This game is also going to be released as open source from the onset. It is also going to be developed over more than one release. In fact, the version being released is the 0.2.0 release, and simply consists of the playable unlimited mode of the game. Future releases will add skinable graphics, campaigns, and a construction set. In case you didn't guess, all the future releases have a Friday the 13th release date.

The third game for June is episode 39 of One of those Weeks. It is my last Flash CS3 project, with all my future projects being developed in Flex using Flash for asset and animation.

The final game for June is the classic version of Monster Hunt. It is part of my Ultimate Retro project which is my last Java project. That being said, JavaFX is suppose to be released this fall so it is always possible that I will choose Java for some future projects. CQ Fans should note that CQ5, as it currently stands, is being developed in Flex but that is all I will say about it until this fall.

Friday February 8th update and the reason for February 1st

The One of those Weeks episode 22 source code and making of chapter have posted. If my current plans actually comes together the way I hope then this will be the last OotW chapter/source release for quite a while. I don't want to go into too many details about my underlying plans due to the likely fact that they won't come together the way I want meaning that I will have to make changes to my plans.

As for my decision to focus on One of those Weeks and Ultimate Retro Project instead of Coffee Quest, my thought process went along the following lines. First, Coffee Quest needs to be a primary project because there is no way that working a few hours every Sunday would work. Therefore Coffee Quest must be a primary project. One of those Weeks could be developed on Sundays, but doing so would make it difficult to ensure that I can maintain a monthly or better release schedule. This is something that is important to me so that means that One of those Weeks has to be a primary project. I can only have one primary project as that is the whole point of my trying to be more focused on my projects. When looking at all the work that has to be done, One of those Weeks has the shortest development time. As much as I want to get Coffee Quest 5 developed once and for all, the logical choice was to go with One of those Weeks.

February in Focus

Those of you who read my 2008 plans on Blazing Games know that I want to be more focused on my game development. I also had an informal email poll about what I should do when I don't have enough material to fill a month. I know I would have got a lot more responses if I made it a form that readers could simply submit, but I figured I only wanted to hear from the people who actually care enough about Blazing Games to write an email. In hindsight, anybody who is willing to read that article really must like the site so I should have used a form. Four people emailed me with last month with the results being:

25% for extra open source releases
100% for more game in a day challenges
75% for strategy guides
25% for FLOSS third party game reviews
25% for Technical articles

Game in a Day Challenges don't impact my project plans but do take away a Saturday so I was glad to see a lot of interest in strategy guides. Strategy guides are nice because they can be written in 10 minute chucks so whenever I have one of those small chunks of time between other tasks I can work on that. As I said a couple of days ago, though, I am going to be focusing on one project(10-50 hours a week depending on my real work workload) with a second personal project being done on my day of rest (Sunday) if I am in the mood for coding. This personal project is going to be the Ultimate Retro Project. The primary project was a toss-up between One of those Weeks and Coffee Quest with OotW getting the final nod but I hope to be finished that project by April at which point the CQ series will gain my full attention.

Voting results

The poll results are in. 53% of the voters voted to have a Coffee Quest game as part of the site selected poll whenever a new game was to be selected. 26% of the voters wanted to have Coffee Quest games always being worked on. The remaining 21% of the voters did not seem to like Coffee Quest, or at least didn't feel it warranted special privileges. I suppose that the results are in line with what I was expecting. Another game that a lot of people like, though I am not entirely sure why, is One of those Weeks. The Blazing Games poll this week is deciding if the remaining 18 episodes (episode 28 is going to be released shortly) will be released on a monthly bases like they currently are or if the episodes will be part of the site selected game vote.

Magic Coffee Beans

The results from last week's Blazing Game poll are in. Roughly 75% of the voters wanted magic in the game but didn't feel it was needed in the 0.2 release of the game. Of the remaining voters, 75% of them thought that magic should be a must-have feature of the 0.2 release. This means that I will try to have magic in the 0.2 release, but it will not be a release-delaying factor, so if I am finding that implementing it is taking too long, it will be delayed for the 0.3 release.

The poll for this week should prove to be interesting. For quite a while I have been putting 10 hours a week towards the project of my visitors choosing. Whenever a Coffee Quest game is on the vote, the results are heavily favored towards the Coffee Quest game. Other projects only win due to vote accumulation over multiple votes. For that reason I am thinking that perhaps I should have a bigger focus on Coffee Quest. I would still finish all my other projects, but Coffee Quest games would alway be worked on for 10 hours a week.

Engine Search

Coffee Quest fans will probably be disappointed when they read this entry, as I have very little progress to report on Revenge development. In fact most of the ten hours allocated for this project this week have not been used so I can't even tell you if a new build will be happening this week. Work this week is revolving around finally implementing a tile class (in AS3) and if there is enough time I will try to get a map class also finished with a very simple viewer so the result would be a map viewer. I honestly don't think that I will get all that done in the allocated time, which means there probably will not be an update as there will not be a second build until I get the map view functional. While I normally get most my hours in on Sunday, yesterday was spent looking at a variety of game engines which would be used to develop a commercial game when I am between contracts again.

A game engine is what you use for building a game. This is essentially what I am creating with my CQfs project that is being used for the creation of CQR, CQ5 and CQ6. The engine used for these games, due to the fact that it is being written for online Flash games, is much less capable than what is necessary for a commercial quality game. Once Flash has proper hardware 3D support and better resource management, it may be possible to expand CQfs into a much more powerful engine. Even with the FS project, I am planning on using a 3rd party software 3D library. The problem with software 3D is that it is so limiting. A commercial game that uses 3D hardware can throw huge numbers of polygons at the screen allowing for incredible looking images. In addition, hardware supports all sorts of effects and special per-pixel shaders that simply is not practical to do in software.

All of this fancy stuff comes at the cost of complexity. While I could certainly write my own game engine, it would be a multi-year task. Using an existing engine saves a huge amount of time and allows me to focus on making the game. The problem is that there are so many engines that choosing one is quite a challenge in itself. My lack of a budget is actually not that big of a factor, as many of the engines are low cost (for instance, the C4 engine is only $200) with a lot of them being Open Source (Crystal Space being the big one here). The best way of cutting down the options was to require Mac, Linux and Windows support which cut the field down to about fifty. I will go over my short list of entries in future posts.

Apple did get back to me, which was nice, but they basically didn't tell me anything. I don't know why the Smashing Pumpkins albums are no longer available as plus (DRM free) albums, but do know that they are trying to work out some issues. Not sure who has the issues but do hope that this gets resolved as I do like Smashing Pumpkins and don't want to have to remove them from my favorite bands list.

Revenge wins the vote

As I suspected, my action oriented version of Coffee Quest -- which is called Coffee Quest Revenge -- has won the vote. This is a fairly large project which is partially the reason that the vote was for the 0.1.0 version. This point may confuse some people not use to the various ways of indicating versions (and there are many different ways, not a single standardized way which makes the issue more confusing). The first number in a version is the major release. The 0 indicates that this is not the finished game. The second number is the minor version, which when not zero indicates a minor revision has been released. It is common, at least in the open source community, to have a zero release with the minor release being the number of the release. This means that the 1 means that this will be the first playable release of the game. The game will not be fully complete (because if it was, this would be a 1.0 release) but will be fully playable.

That being said, to speed up the development of the first release of CQR, I was thinking that I would do the game up in the 2D automap mode so the game would be a playable 2D top down view of the game. This would greatly speed up the first release because if I had to do the full 3D version it would take significantly longer to finish the first playable release. What I am eventually hoping to do is to take advantage of the PaperVision 3D engine, but don't want to use it in my projects until it is out of private beta. Another option for the 3D engine would be to write a ray casting engine. This would not be as fast as using papervision due to various factors that I don't want to get into today.

The third choice in the poll would to be a hybrid approach. The game would be rendered using the techniques in the various 3D One of those Weeks episodes, which means the 3D view would be step based. The movement on the automap, however, would be the actual free-scrolling movement. This would allow for the game to be played in a chunky 3D like view, but the game mechanics would be implementing the 360 degrees of movement that the final version of the 3D rendering would support. The advantage of this is that it wouldn't add too much time to the development while giving you some of the 3D eye candy.

Of course, the poll covering this issue is going to run the rest of this month on the Blazing Games website, so be sure to vote if you haven't already.