TROGDOR

There seems to be a lot of variation over users' displays. I'm using a high-contrast LCD display, and the playfield appears as a medium brown. It must appear darker on CRTs, or maybe people are just setting their brightness lower. In either case, I changed the background to $F2, so we'll see how that looks on the next release. At some point before making this into a cartridge, I'll thoroughly test it on a TV and real hardware. Supercat, I'm going to hold off on changing the player to a missile. The kernel is currently stable, and there are other things I want to work on first. I have a personal dislike for flicker, even at 30Hz. Must be trauma from playing too much Atari Pacman. The only time I've used flicker in my games is on the 12 character text display of Master of Arcturus, and displaying multiple shots in the shooter games, in which case it's absolutely necessary. vdub_bobby, I can't make the ball bigger without hindering navigation in the tunnels. SpiceWare, to answer your question, the death scene eyes will be changing. I'll be going to black pupils on red eyes, and reshaping the sockets to match the title screen. And again, thanks for the feedback everyone.

Supercat, The dark color scheme is intentional. It's meant as part of the mood of the game. I may try to move the player into a missle some time in the future, but I won't do it unless I can implement it without flicker or skipped lines.

Correct. Also correct. There will be a different animation for the pit death cut scene. I've still got over 1k of ROM to use up. Thanks Bob

I see you. Features: htw09.asm 08/08/06 - Added ominous death sound. - Start player in a safe cavern with no clue. htw10.asm 08/11/06 - Added title screen mode. - Dropping title effect. - Glaring, blinking red eyes randomly move around the title screen. htw11.asm 08/12/06 - Added preliminary title music. (Funeral March of a Marionette by Charles Francois Gounod) To Do: - Expand Wumpus clues so they appear in all rooms that are within 1 or 2 rooms of the Wumpus. - Add the ability to shoot your arrow at the Wumpus, so you can actually win the game. - Add death music and victory music. - Add cut scenes for Wumpus death, Pit death, arrow shooting, and victory. - Add title screen and music. (started) - Add check to prevent player from starting in a hazard room. Known Issues: - There is still one scanline of unwanted black lines at the top of the screen that I haven't cleared out yet, but the rest of the lines are gone. - Most of the scanline bounce has been cleaned up. There are still a couple frames in the death scene that are not 262 scanlines. - There are artifacts in the teeth of the death scene that need to be cleaned up. Development Notes: This release includes the source code, and a new README file that will eventually turn into the instruction manual. Please read the README file to understand how to start or restart a game.

Chris, The PF garbage is actually intentional. The true garbage is coming from the replicated P0 and P1 sprites of the teeth, and the extra PF half-line was a half-assed attempt to compensate the fact that the first line of the teeth start in the middle of the screen. I need to do more research on sprite replication to figure out why the sprites aren't starting clean relative to the left side of the screen. Supercat, Remember that there are 2 pits. It is possible that a single pit clue is referring to two different pits, so even if you figure out where a clue should be pointing, you need to have a good idea where both pits are before you can be absolutely sure. Your suggestion for RAM compression makes sense, but I'm going to stick with an 8x8 grid for now. It would be theoretically 16 clue rooms for the Wumpus, but in practice it would more likely be 12, as some of the clues would overlap in the 2-room-clue scenario. Try drawing out a 16 clue example, and you'll see what I mean. If you misfire your arrow, you die. Hunting Wumpuses is a dangerous line of work. There will be a fictional background story that explains why you only get one shot. The arrow is a magic daemon-slaying arrow, provided by the Frobozz Dungeon Delving Corporation. Those arrows are extremely expensive, and the company is concerned about their bottom line, so you only get one per assignment. If you miss, the fired arrow makes a racket, and the Wumpus is on you in seconds. This may sound harsh, but it's what I'm used to from playing the TI99 version. And it adds a lot more suspense when you do finally decide to take that shot. Thinking more about this, I've come up with another difficulty option, possibly tied to the right difficutly switch. In the advanced position, you don't start with an arrow. You have to search the maze to find the arrow that was fired by the last would-be exterminator, who fired it and missed his mark.

Cybergoth, 7-ZIP takes that long because it has to decode the "Flavor", "Spin", and "Colour" of the quarks on the hard-drive platter. I use 7-ZIP the tool, but never 7-ZIP the format. gz is as fancy as I'll go. Although rumor has it that 7-ZIP can compress a 4K Atari binary down to just 3 bytes, if you've got a couple hours to kill.

Hi Supercat, Unfortunately, (sic) I did have to Google it. I'm familiar with Orff's O Fortuna. I studied it in Latin class in college. But we didn't cover the entire text of Carmina Burana. Still, it's very appropriate given the context. This is playing version 0.08? A bug similar to this was in older versions, but it should be fixed. I haven't been able to reproduce this bug in the current version. Please provide more details of how this happens if you notice it again. Those are interesting suggestions for difficulty. The odd thing about Hunt the Wumpus is that to make it more difficult, you don't add rooms. Rather, you take them away. Or, more specifically, you raise the ratio of tunnels to rooms. The more twisting tunnels you have, and the fewer rooms you have, the harder it is to predict where an expected room will be. Again referring to the original TI99 game, it used the following variables to define difficulty: EASY MAZE: 32 Caverns HARD MAZE: 24 Caverns PRO MAZE: 16 Caverrns The TI99 version used an 8 by 6 maze of tiles, so it only had 48 tiles for all games. Expanding the size of the maze makes the game easier because the more empty rooms you encounter, the easier it is to deduce where the Wumpus is not. The extra rooms essentially become filler. Just extra stuff to explore without much impact on the game. From a more practical perspective, I currently use one byte of RAM per room. I could pack the rooms as you have suggested, but this probably wouldn't be compatible with the kernel, which already has to draw 4 clues, a ball player, and 4 asynchronous playfield bytes every 2 scanlines. The unpacking of data wouldn't fit in those constraints. In a 4LK, I only have 8 cycles that aren't used (out of 76 x 4). Mathematically, it requires a maximum of 23 rooms to cover all the clues. 4 clue rooms for each pit, plus the pit itself = 10 rooms, then another 12 clue rooms for the Wumpus, and one for the Wumpus itself = 13. My difficulty levels, taking into consideration that there are 64 tiles, will be more like: 40 caverns, easiest 32 caverns 24 caverns 20 caverns, most difficult The demo version you're currently playing has a 50 percent chance of placing a cavern (vs. a left or right tunnel), so it's essentially the second level of difficulty (32 caverns.) The other difficulty options will be: Guided arrows: Firing an arrow into a tunnel will automatically follow the path of the tunnel to hit the Wumpus. Non-guided arrows: You must be right next to the Wumpus' lair to hit with your arrow. Bat / no bat: This will use a difficulty switch. As mentioned, I'm not a big fan of the bat, because he can cause random deaths. I prefer to battle the raw logic of the game, where the only thing you have to blame if you die is yourself. 1 room Wumpus clues vs. 2 room: Currently, the game places a clue in all rooms that are one room away from the Wumpus. A more difficult version will place a clue in every room that is 1 or 2 rooms away from the Wumpus (this is where I get the 12 clue rooms calcuation above.) This may sound like it would make the game easier, but it actually makes the game much harder, as it requires a lot more exploration before you can deduce the location of the Wumpus. The TI99 version also had "Blindfold" and "Express" modes. Blindfold meant you could only see the room you were currently in. I never played with that option, because it was taxing to retrace my steps many times over to make sure I was remembering the maze correctly. This revisits the tedium of the original text version, which required pencil and paper (or an exceptional memory) to win. The express mode meant that once you walked into a tunnel, you would automatically follow the entire length of the tunnel and end up in the connecting room. This undermines the exploration aspect of the game, and also prevents the non-guided arrows option, which I think is a better challenge. As such, I'll be leaving both these options out of my game. I have considered the possibility of adding 1 rope, similar to your suggestion of bridges. The rope would be placed randomly somewhere in the maze. When you found a rope, it would be added to your inventory. You could then use the rope on one pit room, making it harmless. You would use it on the room in a similar fashion to how you kill the Wumpus. You would select the rope, and then point in the direction of the room to use it on. If the target room is not a pit, you lose the rope and there's no effect. If it is a pit room, the pit hazard is removed, and you can then move through the pit room safely. The main purpose of the rope would be to access the Wumpus in the random chance that his lair is completely isolated between two pits. In this case, the game would be unwinable without the rope option, and an unwinnable situation isn't very fair to the player.

Thanks for the feedback guys. Supercat, you are correct that the game needs more polish. I've got a new game progress meter in the upper right corner of my blog, and 63% is probably a generous assessment of this game. There are still plenty of things to add, especially given that I haven't even used up 2K of an intended 4K cart. As for running into the Wumpus unexpectedly, I could see that happening at the beginning of the game, but as long as you start in a blank room (i.e. a clueless room), you should be able to use logic to predict when you are at risk of getting killed. I've played hundreds of test games, and I haven't run into an instance yet where the markers didn't match the hazard placement. It is possible to use the Stella debugger to seed a game. Using the same 4 binary numbers in the random number generator will create the same game every time. The number that is in Rand1 through Rand4 just before pressing the reset button will consistently define the resulting map. Currently, I don't seed the random number generator, so the first game is always the same. In fact, if you play four games, and then reload the ROM, and play 4 more games, you'll notice that those 4 games are the same. I'll fix this by occasionally popping a bit out of the generator, and planting a time-based seed when the reset switch is pressed, so that every game will be completely random. I also intend to add another feature such that after you are killed, or win, all the tiles of the maze will be exposed, and you can use the joystick to cycle through the 4 screens to see the maze that you just lost or won. Note that currently death by either the pits or the Wumpus will take you to the Wumpus death scene. At some point in the future I'll add a different cut scene for the pit death. Cignus ustus cantat?

Heh. I'd pick Adventure over Oblivion, Elder Scrolls IV. Atari Adventure is simply the greatest video game ever written.

Death awaits you all, with nasty sharp pointy teeth! Features: htw08.asm 08/05/06 - Added Death by Wumpus cut scene. - Added death detection (walking into rooms with pits or the Wumpus.) To Do: - Expand Wumpus clues so they appear in all rooms that are within 1 or 2 rooms of the Wumpus. - Add death detection (walking into room with Wumpus or Pit) - Add the ability to shoot your arrow at the Wumpus, so you can actually win the game. - Add death music and victory music. - Add cut scenes for Wumpus death, Pit death, arrow shooting, and victory. - Add title screen and music. - Add check to prevent player from starting in a hazard room. Known Issues: - There is still one scanline of unwanted black lines at the top of the screen that I haven't cleared out yet, but the rest of the lines are gone. - Most of the scanline bounce has been cleaned up. There are still a couple frames in the death scene that are not 262 scanlines. - There are artifacts in the teeth of the death scene that need to be cleaned up.

The inspiration for this game is the TI99 version of Hunt the Wumpus, written in 1980. Just as the 1979 Atari version of Adventure is a graphical adaptation of the early 1970s text game Adventure, the TI99 version is a graphical adaptation of the early 1970s text game Hunt the Wumpus. I've played the original text version of Hunt the Wumpus. It's fun, but it's also tedious. It's virtually impossible to win without using a pencil and paper to write down all 20 rooms and the 30 or so tunnels that randomly connect the rooms. The TI99 version did an excellent job of graphically representing the random relationships of the rooms, thereby capturing the essence of the original game, while at the same time effectively removing the tedium of manually mapping out the connections between the rooms. And like the original game, the tunnels are benign. It's only the rooms the player has to worry about. When you play the completed game, this may make more sense. In either case, the gameplay of the TI99 version works. I've played literally thousands of games of Hunt the Wumpus on the TI99. That game has unquestionable replayability, so I'm sticking with it as the model for my game. I do, however, plan a few variations for setting difficulty that haven't been done before. One that I like is no guided arrows. On the easy mode, the arrow is guided, which means once you have determined where the Wumpus is, you only have to shoot into the correct tunnel to kill him. On the hard mode, you will have to be in an immediately adjacent tile space to hit the Wumpus. This means that before shooting, you must determine if there is a tunnel between your cavern and the Wumpus' lair. If there is a tunnel, you will have to follow it until you are just about to enter the Wumpus' lair and then shoot. I'm looking forward to that challenge. There won't be any ropes or extra arrows. I will probably add the bat, although I never liked him much. The bat provides a resolution to the fact that on rare occasions it is possible to generate a random map where portions of the map are isolated, and cannot be accessed without teleporting. Regarding the permutations of the original game, can anyone demonstrate the math for how many tunnels would be necessary to connect 20 rooms, given that there are 3 tunnels per room? I think the answer is 30, but I can't prove it.

I smell a Wumpus. Features: htw06.asm 07/29/06 - Switched to 4LK, freeing up even more cycles in the kernel. - Optimized ball display decoder. - Integrated maze buffer preloader to prevent black line artifacts. - Added clue display in GPR0, GPR1, M0, and M1. htw07.asm 08/03/06 - Improved player-to-playfield collision handling to act more like "Adventure". Rather than always moving you back to your original position, you can slide along a surface using diagonal movement, which makes traversing the maze much easier. - Added Wumpus and Pit placement routines. - Added clue placement routine for Wumpus and Pit clues. This routine automatically traverses through tunnels to find all connecting rooms. To Do: - Expand Wumpus clues so they appear in all rooms that are within 1 or 2 rooms of the Wumpus. - Add death detection (walking into room with Wumpus or Pit) - Add the ability to shoot your arrow at the Wumpus, so you can actually win the game. - Add death music and victory music. - Add cut scenes for Wumpus death, Pit death, arrow shooting, and victory. - Add title screen and music. - Add check to prevent player from starting in a hazard room. - Add clue display. Known Issues: - There is still one scanline of unwanted black lines at the top of the screen that I haven't cleared out yet, but the rest of the lines are gone. - I didn't test the scanline count before uploading this, so it's possible that it doesn't add up to 262. I'll check that tonight. Development Notes: The game is now minimally playable. On reset, a fresh maze is generated, populated with 1 Wumpus and 2 pits, and clues are assigned for the 3 hazards. You won't die if you walk into a room with a Wumpus or a pit (yet). They'll just show up as clue markers. But this is enough for you to get a feel for what the game play is like. Try to figure out which rooms contain the Wumpus and the 2 pits, without going into those rooms. For those of you who are not familiar with the original game, the green dots represent pools of slime, and are clues that one of the connecting rooms is a slime pit. The red dots represent pools of blood, and are clues that one of the connecting rooms contains the Wumpus' lair. The object of the game is to use the process of elimination and logical thinking to deduce which room contains the Wumpus, without going into said room. I'm surprised at how little code was necessary to make this game. It only used about 1.5 K, and could be optimized smaller. With some work, a 1K version of this game might be possible. But I'm more interested in producing a 4K or 8K version that will have nice cut scenes. I don't want to even think about what a Wumpus would smell like.

Congrats Flack. You're wise to be trimming down. You're literally adding years on to your life by knocking that much weight off. Good luck on the next round. Competitions like this really are the best way to break bad habits, especially when it involves weight loss or quitting smoking.

djmips, I've got the same problem when I'm play testing. I keep wanting to explore all the caverns. You'll be happy to know that as an employee of the Frobozz Dungeon Delving Corporation, you will be compensated for cavernous cartography (i.e., you'll get extra points for every cavern explored.) PacManPlus, did you see my first blog post about this game? I mentioned that Intellivision game. It wouldn't be too hard to do, as long as there isn't any horizontal scrolling. For the main screen, the mountains and forest could be done in background graphics (left side of screen gray, right side green), and the rivers could be drawn with a wide missile and a series of shifting HMOVEs. I'll add that as a possible game in the future. The original Intellivision AD&D game probably started as an attempt to port Hunt the Wumpus. This is evident in the "clues" that you see in the caverns adjacent to the dragons and zombies, and the fact that shooting at creatures in unexplored caverns is necessary to survive on the hardest level. I've always considered that AD&D game to be the grandfather of dungeon crawl games like Diablo. And that would make Hunt the Wumpus the great grandfather.

Excellent work SpiceWare! This game looks great. The only bug I found was if your player is in the diagonal position (between the vertical and horizontal axis) and the ball comes at you from a 90 degree angle, it can pass through your player.

Features: htw02.asm 07/22/06 - Added random number generator. - Mazes are randomly created. Hold down the reset switch to generate a new maze. - Unexplored caverns are concealed. htw03.asm 07/23/06 - Added screen wrapping so all 64 cells are displayed across 4 screens. htw04.asm 07/24/06 - Switched to 2LK, freeing up many cycles in the kernel. - Added delay to joystick read to slow down player. htw05.asm 07/27/06 - Added compensation for playfield mirroring so displayed tunnel graphics always match what's in the maze data (left turning tunnels vs. right). - Added partial display of tunnel graphics, so the upper and lower portions of a tunnel tile have to be discovered independently. To Do: - Add clue display. - Hide tiles that haven't been explored yet. Known Issues: - There are black lines on the screen at the top of unexplored tiles. This is coming from the kernel preloader for each row of tiles. I should be able to integrate the preloader into the guts of the kernel so it can be removed, and with it, the lines. Development Notes: My source code has become a convoluted maze of calculations. But it works. When I switched to a 2LK, I had to go from 5 scanlines per cell block to 4 scanlines per cell block. So the maze portion of the screen is noticeably smaller. This will leave me plenty of room for information displays, and I'll figure out a way to expand the maze if necessary.

Ohhhhh. Okay. You're talking about your bBasic implementation. I thought you were talking about my binary. I was scratching my head trying to figure out what would possibly cause rolling in my code... My game will definitely roll when the full map is built. It will take thousands of cycles to churn out 64 8-bit pseudorandom numbers and then post-process and validate the resulting maze. I'll probably just blank the screen while it's thinking.

Hmmm. That shouldn't be happening. I tested the binary on z26 with the -n option, and it reported 262 scanlines. What would cause it to roll if it's using 262 scanlines? Is there a mode in Stella 2.2 that will more closely emulate a real TV screen, and actually roll the display? It seems most Atari emulators go out of their way to compensate for coding errors and prevent screen roll, but I'd much rather see the screen roll in the emulator so I'll know there's a rolling problem.

Thanks for the heads up Chris. I did my original search back in 2003, and it hadn't occurred to me to do a more recent search. I tried vdub_bobby's game. It's a good effort, but the game play doesn't feel the same. The main thing that's missing is corridors. I particularly like the TI-99 implementation, because you can't tell where a tunnel leads until you either explore it, or explore everything around it and then deduce its path. Another nice element about the TI-99 version is the fact that a red dot indicated you were within two rooms of the Wumpus, rather than just one. This meant a lot more red dots, and it required you to do more sleuthing before you could take your shot.

Yep, you've found me out. The main inspiration for this game is Two Tigers. I put many hours (and quarters) into that game back in the arcade days. Unfortunately there won't be a two player version of this game, at least not with both players bombing the ship. 2 player sprites + 2 bombs + 4 shots + enemy sprites = bad flicker. I have been considering the posibility of a two player game where the second player controls the ememy planes or the AA fire. But I need to get the one player version done first. Using driving controllers sounds interesting, but it likely won't happen. Very few people own the original driving controllers, and neither do I. Anyone with MAME should try the arcade version. (Assuming that you own the original arcade game and have legal access to the ROMs. ) FYI, Twin Tigers was a top-down helicopter scroller, of a different vein.

This is the first Atari game I ever worked on. The project was started back in October of 2003. This was far too ambitious for a first project, but now that I've gotten more kernel coding experience, I revisited the idea, rewriting the entire program from scratch. Hunt the Wumpus is one of those games that absolutely belongs in the Atari 2600 catalog of games, and I'm amazed that it's never been implemented. The tough part is displaying the clues, which in this implementation will require 4 icons appearing on the same line. My plan is to use the 2 player graphics and 2 missles to display the 4 icons without having to fiddle with placement inside the kernel. There are dozens of ways to implement this game. The screenshot shows the implementation I've chosen. The game will have 64 tiles in an 8 x 8 array. This will be displayed on 4 screens, 4 x 4 per screen. A more advanced version may have vertical scrolling, which would only require 2 screens. A highly advanced version could have horizontal scrolling, but I'm fairly sure that would be impossible without using Supercharger RAM. A Supercharger version with larger rooms would look sweet, similar to Advanced Dungeons and Dragons for the Intellivision. My requirements for the current game are stringent. I don't want to have any flicker or skipped lines in the playfield graphics unless absolutely necessary. Anyhow, this is just another background project. My main focus is still on Stellar Fortress and The Battle of Midway. Features: htw01.asm 07/22/06 - Displays asymetric maze in playfield graphics. - Displays player in ball graphics. - Added joystick control. - Added collision detection with playfield. To Do: - Add clue display. - Hide tiles that haven't been explored yet. Known Issues: - None

100 degrees Fahrenheit? Brrrr! That's chilly. It was 117 here in Arizona yesterday.

Greetings Atari Junkies, I'm continuing work on Stellar Fortress, and have encountered an interesting programming challenge. I need to count bits. Lots of bits. I need to count all the individual 1's across 28 bytes. I've been trying to write an optimally efficient algorithm to do this. My target is to get a good mix of minimal ROM usage and minimal cycles. Here's what I've come up with so far. The first method is brute force: LDY #0 ;2,2 AddBit0 LSR ;2,1 BCC AddBit1 ;2,2 INY ;2,1 AddBit1 LSR ;2,1 BCC AddBit2 ;2,2 INY ;2,1 AddBit2 LSR ;2,1 BCC AddBit3 ;2,2 INY ;2,1 AddBit3 LSR ;2,1 BCC AddBit4 ;2,2 INY ;2,1 AddBit4 LSR ;2,1 BCC AddBit5 ;2,2 INY ;2,1 AddBit5 LSR ;2,1 BCC AddBit6 ;2,2 INY ;2,1 AddBit6 LSR ;2,1 BCC AddBit7 ;2,2 INY ;2,1 AddBit7 LSR ;2,1 BCC DoneAddBit ;2,2 INY ;2,1 DoneAddBit The code assumes that the target byte is already stored in A. The brute force method isn't that bad. The worst case path uses 6 x 8 + 2 = 50 cycles and 4 x 8 + 2 = 34 bytes. The resulting bit count is in Y. An alternative method is to use a lookup table. The fastest lookup table would be 256 bytes, which would only require 6 cycles. But I really don't want to burn 1 / 16 th of my ROM on a bit counter, so I went with a compromise. A two-pass nibble lookup: LDY #0 ;2,2 STY Temp1 ;3,2 STA Temp2 ;3,2 AND #%00001111 ;2,2 TAY ;2,1 LDA BitCounter,Y ;4,2 STA Temp3 ;3,2 LDA Temp2 ;3,2 LSR ;2,1 LSR ;2,1 LSR ;2,1 LSR ;2,1 TAY ;2,1 LDA BitCounter,Y ;4,2 CLC ;2,1 ADC Temp3 ;3,2 ADC Temp1 ;3,2 STA Temp1 ;3,2 BitCounter dc.b #0 ;0000 dc.b #1 ;0001 dc.b #1 ;0010 dc.b #2 ;0011 dc.b #1 ;0100 dc.b #2 ;0101 dc.b #2 ;0110 dc.b #3 ;0111 dc.b #1 ;1000 dc.b #2 ;1001 dc.b #2 ;1010 dc.b #3 ;1011 dc.b #2 ;1100 dc.b #3 ;1101 dc.b #3 ;1110 dc.b #4 ;1111 47 cycles and 45 bytes. A little bit faster, but 11 bytes larger. (The extra storage in Temp1 assumes that I'll be using this across multiple bytes, and that I'll want to keep a running total. The same is true for the brute force approach, but the total is automatically maintained in Y.) At this point, I'm going with the brute force approach. I'm curious if there's a way to make this any smaller or faster, so I'm interested in seeing other people's bit counting tricks. While I'm asking, can anyone recommend a website of 8-bit algorithm implementations? Does such a thing exist? I've found techniques here and there with Google searches, but I've never found a good centralized database of code snipets.

kart_fighter.zip Kenjutsu has mutated into the game Labyrinth. Labyrinth is a fantasy adventure where you become a valiant knight on a quest to rescue the fair princess from the clutches of an evil dragon. You control the actions of a daring adventurer finding his way through the castle of a dark wizard who has enchanted it with treacherous monsters and obstacles. In the mysterious caverns below the castle, your odyssey continues against the awesome forces that oppose your efforts to reach the dragon's lair. Lead on, adventurer. Your quest awaits! Yes, some concepts from Dragon's Lair will be integrated into this game. I liked the premise of Dragon's Lair, even if the gameplay was dry. The idea was you are presented with a series of rooms, and each room contains a challenge that must be overcome before you can move on. I've already come up with ways to implement the gas trap room, the whirling hall of knives, and the black knight encounter. But there will be a lot more to this game. Here is a planned list of features: - Randomly generated mazes of rooms. - There will be a challenge in each room. Complete the challenge to get a key and gain access to other rooms. - Find your way to the stairs to decend to the next level. - A variety of traps and puzzles. Pressure plates and trip wires that fire darts from the wall. These traps can be detected by observant players. And the 3 trap rooms from Dragon's Lair mentioned above. Also a multi-button puzzle at the end of each maze. - A wide variety of monsters. Goblins, Skeletons, DeathKnights, Berzerkers, Doppelgangers, Zombies, Wights, Blobs, and Bats, to name a few. Each creature will have its own fighting style. - Treasure chests, gold, and health packs to restore health. - Probably a hitpoint system for you and the monsters. - Progressive difficulty. As you go deeper into the maze, the speed and reaction times of your opponents will be faster. You will also encounter larger quantities of enemies. - The game will have an end goal, so you can "win" the game. This game is in no way associated with the 1986 Jim Henson / David Bowie movie of the same name. As for the storyline of the game, I may move away from the "kill the dragon and save the princess" plot, but so far that's undecided. Features: l05.asm 07/12/06 - Reworked kernel to use 2LK and half vertical resolution. This will free up many cycles for other effects. - Added animated warrior. l06.asm 07/12/06 - Added enemy goblin player. - Updated kernel to display both players and swords on same scanline. - Added preliminary dungeon wall. - Added goblin AI. l07.asm 07/13/06 - There are now 4 enemies. Select an enemy by holding down the select switch. The enemies are: - A green Goblin. - A grey DeathKnight. - An orange Berzerker. - A blue Doppelganger. - Each enemy has a different fighting style. l08.asm 07/14/06 - Added sword-to-player collision detection. - Added sound queue and rudimentary sounds for victory and defeat in a sword battle. To Do: - Make the sword rotation of the DeathKnight more fluid. - Add a vulnerability to the Doppelganger so he can actually be killed. - Implement the background graphics for the labyrinth. Known Issues: - None. Development Notes: There was no escaping the HMOVE bars. I need HMOVE motion in both directions for the sword effects, so I'll just have to live with it. I tried a brown background, but that provides much less contrast to the players, so they're harder to see. The black background seems to fit nicely with the Labyrinth theme, so I'll probably stick with it, and it allows me to ignore the HMOVE bars entirely. If anyone has ever played Swords and Serpents for the Intellivision, you'll notice some similarites. However, my game will have a lot more variety of fighting styles. I'm pretty sure it's impossible to kill the Doppelganger. Let me know if you figure out a way to kill him. I'll be adding a weakness to his attack method in a later revision. As is the case in real life, if you tie in a sword battle (you and your opponent simultaneously skewer each other), you still lose.

My parents were both engineers at Motorola, so I've been immersed in computers my whole life. I got my first computer in 1977 when I was 6. It was an MEK6800D2, more affectionately known as a D2 Kit. Check out this monstrosity: We don't need no stinkin' CRT terminal. Just 6 7-segment LEDs for the display. My dad hooked up a speaker to the RS232 port and found an assembly program that played a Beethoven song. 1977 was the year Star Wars came out, so I figured out how to hack the code for the Beethoven song and change it to the Star Wars theme. That's how I learned hexidecimal. All the machine code had to be typed in raw with the hex keypad. Edit - oops. Got my dates wrong. For a couple years after that, we used a TRS-80 on loan from work. I think it was a model II, because it had two integrated 8 inch floppy drives, and I'm pretty sure it had 32k RAM. When the TRS-80 was returned to work, I talked my parents into buying a VIC-20, which was a little more user-friendly than the D2 kit. They've still got that original D2 kit, stashed away in a closet.