> the bug is that i want the damn thing to stop when your or the monster's health is less then or equal to 0

Have another look at the while and think about whether that expression will evaluate TRUE or FALSE in each of the four cases H>0 M>0, H<=0 M>0, H>0 M<=0, H<=0 M<=0, bearing carefully in mind the OR truth table.

> also i have one more question...

if you play a lot of these games you'll know that the simpler ones use randomisation to determine what happens where and when (e.g. wump, but even there the maze is setup at random at the start and you then find your way around it), but in the larger ones the whole thing is much more designed, so that you always know for example that you're going to hit a Balrog in the Mines Of Moria; you're never going to encounter him in Rivendell. There may be a degree of randomisation but that is more likely to be confined to the strengths of individual enemies, the effectiveness of each of your attacks, the amount of treasure each dead Orc drops, etc etc.

So what this means is that you'll need a database of what happens where, into which you'll code the overall design of the game. How you code the database is up to you; you could just use flat files or perhaps use one of the existing database products. Then as the user moves from point to point within the "maze" you lookup what's in the database at that point.

This of course means that you'll have to design the game itself and the starting point will need to be some sort of map. Dead simple one:
Code:
  1             5
  :             :
  :             :
START- - -3- - -4- - -END
  :
  :
  2
So we have 6 points. We start at START and the exits are N,S,E. Maybe there's some stuff to pickup here. You need some way to remember what you've picked up (inventory).
Let's say 1 is a trap and you drop dead - bottomless pit perhaps, and 2 contains a monster that you have to kill but nothing else Seasoned players will know there's no point heading south from START.
Maybe 3 contains some kind of puzzle you have to solve to open the way east from 4. So at 4 you'd check if the problem was solved and say "the exits are NORTH, WEST" if not, or "NORTH,WEST,EAST" if it was.
Let's say there's another monster at 5.
Maybe END is really the end or you have some supermonster/superpuzzle to dispatch before you win.

So the database/data structure will need lots of links; START needs 3 exits, to 1,2,3. 3 has 2 exits to START,4. You need to think about how to represent the two-way link between 3&4, and in the design if these really are two way links; maybe if 3->-4 is one way then if you don't solve the puzzle before moving east you're completely stuffed. And so on.
Each point will need a number of attributes. What is there and how it benefits (or otherwise) you.

Loads for you to think about there :-)