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.
Showing posts with label Coffee Quest Revenge. Show all posts
Showing posts with label Coffee Quest Revenge. Show all posts
Tuesday, October 2, 2007
Thursday, September 13, 2007
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.
Monday, September 10, 2007
Cruel Weekend
The weekend was a failure for my work on Dozen Days of Dice. While I easily finished the original game I conceived, it just wasn't fun enough. Meanwhile, my plans for Coffee Quest Revenge have changed and progress is finally being made.
I really need to write a proper explanation about what I am doing with Dozen Days of dice. The detailed explanation can wait for another day, but the short summary is that I am doing a series of Game in a Day challenges. I am doing one challenge on every weekend I don't have other plans for. While ideally all twelve games in a series should be done over a block of 12 days, right now that isn't practical, so weekends will have to do. While I could release the game I did finish, I instead am going to cheat and declare it a bonus game. It will be used as filler for when I don't have a game ready to release.
The story behind Coffee Quest Revenge is quite interesting. While I was going to do the 3D stuff using Papervision 3D, I was having too much problems getting what I needed to do working. It is certainly possible that what I wanted to do could be done, I don't know the library well enough yet. I keep running into culling issues for which I suspect the solution would be to write a new camera that automatically subdivides partially culled triangles instead of removing them. Of course I would have to familiarize myself with the source code before undertaking such a task, so instead I opted to port my existing ray casting code over to flash.
The existing ray casting code is designed for a step based game not for 360 degrees of freedom. Still, I had started making a 360 degree ray caster for the ultimate retro project so I figured if I could fix the issues I was having with that version it would be simple to port that code over to flash. When I started looking at the code, my mind lead me to a potentially better way of doing the casting. As this was a new algorithm I figured I would do the initial tests of this algorithm as part of the Coffee Quest Revenge. It has been a while since I released a build of CQR so if you go to http://blazinggames.com/games/coming/ you will see the 5th build which features a test over top of the auto map of the casting. I should point out that this is pre-alpha software and it is kind of fragile. The cursor key movement seems to work fine on Windows but the Mac doesn't seem to automatically repeat keys. Likewise, clicking on the auto map captures the keyboard causing the keyboard keys to stop working.
I really need to write a proper explanation about what I am doing with Dozen Days of dice. The detailed explanation can wait for another day, but the short summary is that I am doing a series of Game in a Day challenges. I am doing one challenge on every weekend I don't have other plans for. While ideally all twelve games in a series should be done over a block of 12 days, right now that isn't practical, so weekends will have to do. While I could release the game I did finish, I instead am going to cheat and declare it a bonus game. It will be used as filler for when I don't have a game ready to release.
The story behind Coffee Quest Revenge is quite interesting. While I was going to do the 3D stuff using Papervision 3D, I was having too much problems getting what I needed to do working. It is certainly possible that what I wanted to do could be done, I don't know the library well enough yet. I keep running into culling issues for which I suspect the solution would be to write a new camera that automatically subdivides partially culled triangles instead of removing them. Of course I would have to familiarize myself with the source code before undertaking such a task, so instead I opted to port my existing ray casting code over to flash.
The existing ray casting code is designed for a step based game not for 360 degrees of freedom. Still, I had started making a 360 degree ray caster for the ultimate retro project so I figured if I could fix the issues I was having with that version it would be simple to port that code over to flash. When I started looking at the code, my mind lead me to a potentially better way of doing the casting. As this was a new algorithm I figured I would do the initial tests of this algorithm as part of the Coffee Quest Revenge. It has been a while since I released a build of CQR so if you go to http://blazinggames.com/games/coming/ you will see the 5th build which features a test over top of the auto map of the casting. I should point out that this is pre-alpha software and it is kind of fragile. The cursor key movement seems to work fine on Windows but the Mac doesn't seem to automatically repeat keys. Likewise, clicking on the auto map captures the keyboard causing the keyboard keys to stop working.
Friday, August 3, 2007
Revenge 3D plans
Last week's vote on Blazing Games was about posting my PaperVision 3D tests to the coming soon area of Blazing Games. The coming soon area is a page where I post the current build of the site selected project. Currently this page has a pre-alpha build of Coffee Quest Revenge on it, but with 100% of the few people who voted wanting to see my Paper vision tests you can expect to see spinning cubes soon.
Some regular visitors to Blazing Games may remember what I did with Coffee Quest GL. This was my attempt at using JOGL and required that I spent time re-learning Open GL. In fact, had there not been a lot of people who for some reason or another had problems running Coffee Quest GL, I would have stuck with Java for my Coffee Quest development instead of switching to Flash.
What I am going to do is follow the same basic steps used for Coffee Quest GL. I am going to start with a spinning cube. Figure out how to texture the cube. Turn the single cube into the basic structure of the level. Add doors to the mix at which point the 3D code can be incorporated into Coffee Quest Revenge and game development for that game can continue.
The current Blazing Games poll is about the movement speed already in the game. With the poll being out less than 24 hours, I have already received an email pointing out that 2D movement doesn't reflect what 3D movement is like. I suppose that is a valid criticism, but once the game is further along I can always revisit the issue.
Some regular visitors to Blazing Games may remember what I did with Coffee Quest GL. This was my attempt at using JOGL and required that I spent time re-learning Open GL. In fact, had there not been a lot of people who for some reason or another had problems running Coffee Quest GL, I would have stuck with Java for my Coffee Quest development instead of switching to Flash.
What I am going to do is follow the same basic steps used for Coffee Quest GL. I am going to start with a spinning cube. Figure out how to texture the cube. Turn the single cube into the basic structure of the level. Add doors to the mix at which point the 3D code can be incorporated into Coffee Quest Revenge and game development for that game can continue.
The current Blazing Games poll is about the movement speed already in the game. With the poll being out less than 24 hours, I have already received an email pointing out that 2D movement doesn't reflect what 3D movement is like. I suppose that is a valid criticism, but once the game is further along I can always revisit the issue.
Thursday, July 26, 2007
Paper Coffee Quest
Just a quick post today. The vote about taking part of the Coffee Quest Revenge time to learn PaperVision 3D resulted in 92% of the vote for taking the time. I can only assume that people want the game in 3D as soon as possible. I am hoping that the game will be at least half as good as the game in my mind is, though development is taking a lot longer than I thought. Granted, a vast amount of the time is spent creating general purpose code that will hopefully be used by many future projects.
Wednesday, July 4, 2007
Tiles in games
For a while I have been trying to figure out the best way of covering this topic, which is fairly important to the understanding of how Coffee Quest Revenge in particular and tilemaps in the CQFS engine will work. My problem is that I want my blog to be of interest to three different groups of people. Those who are curious about how games work but don't want to actually make games themselves. Those that want to make games but are just learning how to program. And those who know what they are doing. All three groups require different levels of detail so trying to please all three groups is not an easy task. So what I am going to do is focus primarily on the second group with a hope that I can make things interesting enough that the first group can skim through the posts and get an idea of what is going on. The third group can consider this a refresher or a drive down memory lane.
Tiles are actually quite common among games. Especially 2D games developed for older game machines and computers. In their most basic form they are simply a way of making an image out of a series of blocks. Why is this useful? From a graphics perspective, this allows you to potentially greatly reduce the size to an image. A 256 pixel by 256 pixel image requires that you define 65,536 different pixels. If you were to break this image up into 8x8 tiles, you can describe the image using only a 32x32 grid of tiles meaning you only need information for 1024 tiles.
When your machine didn't have very much memory to begin with, this was a significant savings. "But Billy, aren't you forgetting..." Yes, there is an important detail I am forgetting, but will talk about that next post.
Tiles are actually quite common among games. Especially 2D games developed for older game machines and computers. In their most basic form they are simply a way of making an image out of a series of blocks. Why is this useful? From a graphics perspective, this allows you to potentially greatly reduce the size to an image. A 256 pixel by 256 pixel image requires that you define 65,536 different pixels. If you were to break this image up into 8x8 tiles, you can describe the image using only a 32x32 grid of tiles meaning you only need information for 1024 tiles.
When your machine didn't have very much memory to begin with, this was a significant savings. "But Billy, aren't you forgetting..." Yes, there is an important detail I am forgetting, but will talk about that next post.
Monday, June 18, 2007
Flash Bitmap automap
At the moment the amount of spare time I have is very low, and to make matters worse I am taking a drawing class. I am hoping that they will help me get my artwork up to a much better quality than it currently is. As with every other skill, the key is practice but knowing what you are doing wrong certainly helps.
I am still going to put an effort into getting my 10 hours of work on the site selected project, with any slippages of hours being rolled over to the next week's total. I did manage to finish a rough automap render but it only paints a test pattern as the map classes aren't developed yet because I decided that I wanted to make sure there would be something to post this Friday. This was done a bit different from the way I have normally handled such maps in Flash. Flash 9 has a Bitmap Data class which I am taking advantage of. Technically, this was introduced in Flash 8, but I am jumping from flash player 7 content to flash player 9.
The BitmapData class lets you use an image which is loaded with a separate loader class. I am not sure why you need a separate class that handles the loading of an external image, as it would make more sense to me to have this functionality part of the Bitmap or BitmapData class. Once copied into a BitmapData class, clips from the image can be easily copied to the bitmap used for the automap. This should be fairly fast as I believe the BitmspData class is able to use hardware acceleration, or at least native code for bitmap clipping.
At this point I have a test pattern being displayed, using the 16 tiles that the game uses. If I get around to finishing the map classes before Friday (assuming they can be done in less than 10 hours) I may have a proper map this friday, but if not I will at least be able to post the game running the test pattern.
I am still going to put an effort into getting my 10 hours of work on the site selected project, with any slippages of hours being rolled over to the next week's total. I did manage to finish a rough automap render but it only paints a test pattern as the map classes aren't developed yet because I decided that I wanted to make sure there would be something to post this Friday. This was done a bit different from the way I have normally handled such maps in Flash. Flash 9 has a Bitmap Data class which I am taking advantage of. Technically, this was introduced in Flash 8, but I am jumping from flash player 7 content to flash player 9.
The BitmapData class lets you use an image which is loaded with a separate loader class. I am not sure why you need a separate class that handles the loading of an external image, as it would make more sense to me to have this functionality part of the Bitmap or BitmapData class. Once copied into a BitmapData class, clips from the image can be easily copied to the bitmap used for the automap. This should be fairly fast as I believe the BitmspData class is able to use hardware acceleration, or at least native code for bitmap clipping.
At this point I have a test pattern being displayed, using the 16 tiles that the game uses. If I get around to finishing the map classes before Friday (assuming they can be done in less than 10 hours) I may have a proper map this friday, but if not I will at least be able to post the game running the test pattern.
Tuesday, June 12, 2007
General purpose
While my tile class is not finished, it is finished enough for what Coffee Quest Revenge needs. To be perfectly honest, I have probably spent more time on the tile system then was needed. I could probably have gotten away without having a tile class and having a fairly simple map class (what I am working on this week, or at least will be working on Thursday through Saturday). I am writing a more elaborate class for both maps and tiles. The reason being is that these classes have uses with a large variety of games so having general purpose classes will allow me to use these classes with many additional games in the future. The obvious advantage is that once the work is done, the work does not have to be re-created for slightly different versions used in future games. While cut and paste coding can also be used to gain this advantage, it is probably better to have a proper set of classes. The key disadvantages to creating general purpose classes is the extra time required, the speed, and the overhead.
Obviously, if you are creating a class that is going to be used for a very specific thing, you only need to write the code necessary to do the particular thing that is needed. When you are creating a general purpose class, you have to take into account all sorts of uses for the class. This takes time to figure out and time to implement. Of course, nobody says that the whole class needs to be implemented, so only the functions that Coffee Quest Revenge needs have been implemented, with a todo list of additional functions that can be added when they are needed, so the time requirements are not as bad as they could have been.
Speed is another issue and is one reason may game developers, especially in the early days, would avoid using common libraries. Because you are doing things in a more general way, there is less code optimization and shortcuts that can be taken. This means that overall, the common libraries will run slower than something that was written for a specific purpose. In the old days, this could have a significant impact on a game. With the speed of today's computers, this is much less of an issue.
Finally, there is some overhead in getting the general purpose classes to work the way you need them to. In the case of Coffee Quest Revenge, the tileset used is pretty hard set so could have easily been hard coded into the game. Other CQFS engine games will not be so lucky and need to have much more flexible tile sets. This means that Coffee Quest Revenge needs to set up the tileset information to use the common classes even though this work could have been avoided if I would have wrote special purpose code for handling the map.
One final note. I have plans for Wednesday night so won't be getting any work on CQR done. This means that the second build will be delayed another week, though I will be putting in my ten hours on Thursday night, Friday night, and Saturday with hopes that I don't fall behind in my ten hour commitment again. This also means that I will not be posting tomorrow, but will try to post Thursday evening.
Obviously, if you are creating a class that is going to be used for a very specific thing, you only need to write the code necessary to do the particular thing that is needed. When you are creating a general purpose class, you have to take into account all sorts of uses for the class. This takes time to figure out and time to implement. Of course, nobody says that the whole class needs to be implemented, so only the functions that Coffee Quest Revenge needs have been implemented, with a todo list of additional functions that can be added when they are needed, so the time requirements are not as bad as they could have been.
Speed is another issue and is one reason may game developers, especially in the early days, would avoid using common libraries. Because you are doing things in a more general way, there is less code optimization and shortcuts that can be taken. This means that overall, the common libraries will run slower than something that was written for a specific purpose. In the old days, this could have a significant impact on a game. With the speed of today's computers, this is much less of an issue.
Finally, there is some overhead in getting the general purpose classes to work the way you need them to. In the case of Coffee Quest Revenge, the tileset used is pretty hard set so could have easily been hard coded into the game. Other CQFS engine games will not be so lucky and need to have much more flexible tile sets. This means that Coffee Quest Revenge needs to set up the tileset information to use the common classes even though this work could have been avoided if I would have wrote special purpose code for handling the map.
One final note. I have plans for Wednesday night so won't be getting any work on CQR done. This means that the second build will be delayed another week, though I will be putting in my ten hours on Thursday night, Friday night, and Saturday with hopes that I don't fall behind in my ten hour commitment again. This also means that I will not be posting tomorrow, but will try to post Thursday evening.
Thursday, May 31, 2007
Roadmap to 0.1
As visitors to Blazing Games already should have found out, the 2D only option won the vote. It was actually a very close user poll, and actually resulted in a different outcome than I had expected. What I had sort of hoped for was that the compromise of a step based 3D render and a 2D auto map that was free-scrolling would win out. What I had expected was the 3D option to win. What actually happened was the 2D option won out by a single vote. No, I am not making this up, even though we are talking about a Hollywood style vote result. Of course, such close races are common when there is under a score (20) worth of votes. Still, I do appreciate the tiny fraction of my visitors who do vote.
Doing a 2D map view of the game should be very quick, though I still have the larger task of finishing the tile and map classes before the viewing code can be implemented. As I am only going to have one type of monster in the initial release, I don't need the partially completed CQFS entity system, so the monster will be fairly quick to implement. The status bar has already been roughly implemented. This means that the 0.1 release might not be that far off. At 10 hours a week, though, I suspect the earliest that I could possibly have the release ready would be for June 22, though early July is probably the more realistic target.
The 0.2 release will be mostly the integration of the entity system, though other features may be added based on upcoming Blazing Games polls. Still, once I have the 0.1 version out, I can get some feedback on what the game needs so my plans might change.
As for anybody who cared about my post yesterday, I bought my first album on iTunes (Smashing Pumpkins -- Mellon Collie and the Infinite Sadness) so I am officially voting with my dollars when it comes to DRM free downloadable music. It actually worked out to only 89 cents Canadian a track (roughly 85 cents a track US) so buying entire DRM free albums on iTunes does make sense. Though eMusic is still significantly cheaper and a better solution if the bands you like are on independent labels.
Doing a 2D map view of the game should be very quick, though I still have the larger task of finishing the tile and map classes before the viewing code can be implemented. As I am only going to have one type of monster in the initial release, I don't need the partially completed CQFS entity system, so the monster will be fairly quick to implement. The status bar has already been roughly implemented. This means that the 0.1 release might not be that far off. At 10 hours a week, though, I suspect the earliest that I could possibly have the release ready would be for June 22, though early July is probably the more realistic target.
The 0.2 release will be mostly the integration of the entity system, though other features may be added based on upcoming Blazing Games polls. Still, once I have the 0.1 version out, I can get some feedback on what the game needs so my plans might change.
As for anybody who cared about my post yesterday, I bought my first album on iTunes (Smashing Pumpkins -- Mellon Collie and the Infinite Sadness) so I am officially voting with my dollars when it comes to DRM free downloadable music. It actually worked out to only 89 cents Canadian a track (roughly 85 cents a track US) so buying entire DRM free albums on iTunes does make sense. Though eMusic is still significantly cheaper and a better solution if the bands you like are on independent labels.
Tuesday, May 29, 2007
Weapons of Revenge
I have all the weapon icons finished for Coffee Quest Revenge. More accurately, I have the weapons that will appear in the 0.1 release of CQR ready. At the moment the weapons will consist of the same set of weapons as Coffee Quest 4. For those of you who can't remember CQ4, the weapons are the dagger, short sword, long sword, enchanted sword, magic sword, arrows, enchanted arrows, fire arrows, and energy arrows. While there will be spells in the game, these will be different from the ones in CQ4 and will require items in order to cast them. These will not be part of the 0.1 release of the game. There is still a huge amount of work to do (how much will depend on the results of the Blazing Games poll which is still underway) but the 10 hours allocated for this week have been used. I may put in some extra hours later this week, but I have some other stuff I want to work on first and don't know if I will be able to put extra hours into Revenge this week.
Sunday, May 27, 2007
Revenge of the Tween
Development on Coffee Quest Revenge has now officially started. While it will be a while before I have something that is remotely playable, I am going to be trying to post the latest build of the game every Friday so anybody who is interested in this game will be able to watch how the game evolves. As I need something to start with, I am working on the game's status bar. This bar holds your current health, shield status, armor status, weapon, usable item, quest items, and map. The health, shield, and armor status are animated condition indicators that will also have a bar and numeric indication of the value. The animations were created today and bits of the rest of the bar have been worked on so there will be something for sure this Friday.
The animation was done by taking advantage of Flash's shape tweening ability. While this is a really neat feature of Flash, it is also an extremely annoying to use feature. The big problem with shape tweening is how stupid it can be. For instance, I had a tween that removed a corner of the shield. While the bulk of the shield had the same start and end, the entire shield was involved in the animation. In order to fix this problem, you have to strategically place hint spots on the shape being tweened. These hints help the tweening process along by telling Flash which parts of the shape are suppose to end up where. While the process of adding hint spots is much better than earlier versions of Flash, it can still lead to a strange disappearing image problem. What I am talking about is a situation where the hint spot that was created causes the entire middle portion of the tween to disappear.
My solution to this was to try and keep all the hints in a clockwise order of definition. I would place the hints one at a time, and then make sure that the image was not disappearing. If the image did disappear, then I would move the position of the hint until I got the image back. Watching the animation segment between the addition of each hint helps you figure out where there are still problems. Still, the shape tweening is much faster than hand animating the entire transformation.
The animation was done by taking advantage of Flash's shape tweening ability. While this is a really neat feature of Flash, it is also an extremely annoying to use feature. The big problem with shape tweening is how stupid it can be. For instance, I had a tween that removed a corner of the shield. While the bulk of the shield had the same start and end, the entire shield was involved in the animation. In order to fix this problem, you have to strategically place hint spots on the shape being tweened. These hints help the tweening process along by telling Flash which parts of the shape are suppose to end up where. While the process of adding hint spots is much better than earlier versions of Flash, it can still lead to a strange disappearing image problem. What I am talking about is a situation where the hint spot that was created causes the entire middle portion of the tween to disappear.
My solution to this was to try and keep all the hints in a clockwise order of definition. I would place the hints one at a time, and then make sure that the image was not disappearing. If the image did disappear, then I would move the position of the hint until I got the image back. Watching the animation segment between the addition of each hint helps you figure out where there are still problems. Still, the shape tweening is much faster than hand animating the entire transformation.
Subscribe to:
Posts (Atom)
