I played this but I haven't looked at the source code. Here's some things I noticed, and some suggestions on where to go next if you'd like to improve it/fix it:

* If you go into the space with a sword repeatedly, you will continue to pick up the sword. Since there's no indiciation of inventory, I can't tell if I'm getting multiple swords, or if it's just giving me the notification for walking on the space.

* When I fought the monster on the left, I got stuck. First I killed him, then he refought (like people have been saying) but no matter how many times I hit him, neither of us died. I pressed f like a million times.

* The map doesn't display again after a battle, so I have no idea where I am if I've forgotten my location. Since it updates every move phase, I think it should update here, too.

Here's some things you could try adding, that I think would be a good challenge based on what it seems you can do so far:

* Have the room be a random size and shape (even if it's just differenlty proportioned rectangles), instead of the same square every time.

* Have monsters and items appear at random locations. You don't have to have random amounts -- it could always be the same sword and two monsters, but in different places every time.

* Have a victory and loss condition (run out of HP and die, defeat all monsters and win, for example)

* Different weapons with different abilities, that they player can choose to replace with his current weapon.

Once you've done those, you can even try adding monsters that move and chase the player (or run, or do different things... they could have a simple AI). So you'll have to make an AI and turn-taking system.

Though to add these things, it might be good to look into object-oriented programming. I think that seems like a good next step after this. I haven't looked at the source code yet, but it doesn't seem like you're using classes based on the way it plays.

For example, if you wanted the monsters to be of random types and in random places, you could make a monster class, and when creating the initial map, create monster objects and assign them random coordinates (which are stored in the class in variables). Stuff like that. This will also make the program more expandable so you can add new things more easily.

OK, I decided to downlaod the source code. It's very difficult to read. Like said, use comments everywhere. Unless something would be glaringly obvious to someone looking at your code (imagine they've never even run the program and they're JUST looking at the code, figuring out what it does... they might not even know it's a game... pretend they'll never run the program and need to figure it out just from the code... comment all the time!)

Also, the formatting... like said, white space is important. You want to tab stuff. When your blocks are indented, they are a lot easier to read... especially when there are blocks within blocks. Just looking for braces nad trying to figure them in your head is a strain.

This will not only help others reading your code, but it will help you, too. If you leave to work on something else, then come back to this project later, you may find you have no idea what your code even does anymore... and without comments and nothing being indented or spaced well, you will have a lot of trouble trying to figure out how your program works anymore.

thanks for all the input

are there any general rules on commenting code?

[attachment=18002:adventure (3).zip] well I put in some comments and spacing

int x=0,y=0,w=4,attack=0,hp=6;//global variables

They are declared inside main(), how are they global? Maybe they "feel" global, because you dumped your whole program into a single function, but that's not the same thing.

cout << "***Welcome to Adventure***";//welcome text

This is a prime example for useless comments that only exist because someone said "you need to comment more".

for (int i=0; i<9; i++)//draw grid

I was wondering how many times you would copy/paste the same comment without eventually realizing that this code shouldn't be commented, but get its own function.

Comments should only be used where necessary. Prefer writing clean and readable code with decent names for variables and functions. Which means, don't be lazy and abbreviate the hell out of everything, keep functions short and have them do ONE thing, avoid confusion (don't use i and j as loop variables or any other combination of letters that look alike).

If you have a piece of code and feel the need to put a comment over it saying "this block does x", put it in a function and call it "x".

Comments are the last thing anyone ever updates, they are frequently copy/pasted along with the code and it's usually less than a month before they turn into a confusing mess of lies and deceit. Write code that speaks for itself and doesn't need comments in the first place.

Use comments where explanations are required or a chunk of code is impossible to quickly look at and understand what it's doing. "Find shortest path using A* (<link to more info about A*)" would be a helpful comment. "Assign sum of x and y to variable a" on the other hand is nothing but noise that actually makes it harder to read the code (seriously, if somebody needs you to explain what a=x+y does, they probably shouldn't be looking at any kind of source code in the first place).

Frankly, nothing I see in your code needs to be commented, because it's about as trivial and straight forward as it gets. Better names, clean formatting and at least an attempt at well structured code would make any kind of comment superfluous.

Get a book like "Clean Code", ignore the dogmatic parts and rather than taking everything as "how it always must be", read it as "what you should strive for within reasonable limits".

Frankly, nothing I see in your code needs to be commented, because it's about as trivial and straight forward as it gets. Better names, clean formatting and at least an attempt at well structured code would make any kind of comment superfluous.

There are some game design related changes i would like to see (Hope you want feedback on that too). They will also give you some more stuff to program :).

Randomness ; Give the hits some chance, and with it some more outcomes. Think of DnD's die rolls to determine damage. This will give more depth than just the simple "hit or miss".

Motivation ; What is the motivation behind hitting or running or doing anything in the game right now? Give the player a goal and with that possibly a winstate. A reason to run is also missing. Why would I run? I can't die anyways.

Feedback ; Give some more feedback to the player as to what happens or what his surroundings look like. With the earlier mentioned damage you can give a couple of different texts based on the severity of the hit. Also some feedback on how the enemy is doing after you hit him would be nice.

I can't think of anymore right now but this should keep you busy for a bit too. :)

Cheers,

IYIonster

Frankly, nothing I see in your code needs to be commented, because it's about as trivial and straight forward as it gets. Better names, clean formatting and at least an attempt at well structured code would make any kind of comment superfluous.

so I don't need any comments?

honestly, write all the comments you feel that you need, for yourself, 1 month from now

you are just starting out, and you will no doubt leave this project for another as you get better at programming and you realize that there are things that could be solved with easier and simpler code

so, this project could be like a reference for you, if you need to take alook at how you did a specific thing, when you need it

i frequently take a look at my previous code just because otherwise i would have to re-read documentation or "google it".. no one remembers every little thing

making your variable and function names "short sweet and to the point" is more important

so, for your ogres HP variable:

"hp" bad

"ogre.getHP()" good

me post now (PS. take a quick look at classes, they really do help compartmentalize both your code and your thoughts)

I am going to work on this project more.

"Writing the right comments" is an art an takes time to learn (heck, I need to constantly strive to improve myself). What you want your comments to do is to explain WHY the code does what it does, NOT what it does or how it does it. E.g. see the difference on the example that was posted above:

cout << "***Welcome to Adventure***";//welcome text

cout << "***Welcome to Adventure***";//need to display the welcome text already now or player won't know what game this is

Somewhat contrived example given how useless that text is anyway, but..

Not that comments for explaining why will always be longer, sometimes they are shorter. What you want to ensure is that your variable and function names are so clear that people can figure out what the code does for themselves, but you explain the motivations with your comments. To compare with a normal language sentence "I do X because Y", you want to include the Y as your comment, rather than X (most of the time, there are always exceptions) - since the code should already say what X is if it's clear enough.

Even though I said "people", it will benefit your future self as well if you have to revisit the code.