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

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.