Wednesday, October 10, 2007

Implementing an automap

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

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

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

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

Tuesday, October 9, 2007

Why do people hate maps?

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

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

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

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

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

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

Friday, October 5, 2007

One of those Weeks episode 18:Completing the Quest

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

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


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

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

  • 5 points for getting pen and notebook
  • 5 points for grabbing oranges
  • up to 5 points for exploring the forest
  • 3 points for finding the launching point for your raft
  • 2 points for making the cave connection.
And that is all there is to this simple episode.

Thursday, October 4, 2007

Why don't I use C

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

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

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

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

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

Wednesday, October 3, 2007

Astro and the dragon

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

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

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

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

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

Tuesday, October 2, 2007

Astro

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

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

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

Monday, October 1, 2007

On the weekend 1+1=3

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

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

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