Why, what's wrong with them? It's what got me started. And no-one's died yet

Ok, so my games never work, the PC resets with every recompile, and every time I get to the point where I can execute my program I need to re-install the windows. But otherwise it's fine.

This is a joke right? This is not even closely valid C++- - code! Did you ever try to compile it? Even if it would, by skimming through it, I can say it would crash like hell... Listen to people's advises or at least post the freaking compiler-errors!!

But what is wrong in this code:
(IN attachment you have all my program)

This programm guns very good so what is wrong
imaxcs you said:
"I can say it would crash like hell"
but it doesn't crah

X-G I am not troll
I use your advices and thanks some of you my programm gun but what is in this programm wrong (without "goto") ??

X-G if you don't want help me you didn't write.

X-G my programm is almost good and you can only criticize me - you do not want even to say what is bad despite that my programme great run.

And "goto" must be because if somebody will press other button than: "->; <-" then program go to "direction" - and player will have press "->; <-" - the number of eyes will not change, if I use "continue" then player also will have press "->; <-; Esc" but the number of eyes will change - and I don't want that the number of eyes change until player press "->" or "<-".

This site should be enough.

kosmitek,

Let's say that that little "pink pawn" that you had in your code was going to become a nice little animated sprite (like a swirling "rock" or a "chess piece" that occasionally moves or whatever).

   +---+---+---+---+---+---+
   | X |   | X |   |   |   |
   +---+---+---+---+---+---+
   |   |   |   | X |   |   |
   +---+---+---+---+---+---+

Say you had three pawns on the screen at once. Declaring the pawn as a class would allow each of the three pawns to have a different look, have different x/y coordinates, be facing different directions, etc. For those, it would be fine to use a class, since each pawn would need to keep track of similar data (direction facing, coordinates, etc) but all the data itself would be different (the top two are facing down, the bottom is facing up, so each would have a different "direction").

As an example of a usage of classes, my games have several bad guys/monsters. Each bad guy/monster keeps track of its current location, the direction is is trying to go, and its health. If I attack one of those monsters, its HP goes down slightly. When the monster dies, I don't need to keep track of that monster anymore and "delete" it. When it gets "deleted", the class destructor frees up all the data it was storing (like the BITMAP it was using, its location, etc.). In that case, it would be useful to have a class.

So kosmitek, if you could describe for us, what do you want to use a "class" for in your game? If you have only 1 pawn and 1 "game board", I don't think you would need to use a class.

TeamTerradactyl you are very very very helpful - thank you a lot.

So I want do this game:
Player throws bone and pawn moves about some number of fields on left or right ( player decides), every time when pawn stands up on field will be drawn event, for example: "you get 100 dollars" or "you lose 50% of your weapons", player can stand up on some field which is shop - there he can buy weapons but if he stand up on field which is shop and then he throw 2 eyes then he lose all his weapons. After 20 movements he will fight with monster so he must have many weapons, if he has too little weapons he will die.

So it is my plan of game - where I can apply here OOP ?

kosmitek:

This sounds slightly similar to Monopoly, where each "field" has a different attribute (like "collect 200 dollars" or "You owe [some person] $50", etc.). If this is the case, then I would suggest making the "field" a class:

Then, each "field" you land on can have its own attributes and pictures. This would make sense, since you would use several "field" objects where you would really only use a handful of "pawn" objects.

You would need to define several different "Attributes" that this class would be able to use: one would be a "shop" where you buy stuff, another would be a "thief" where you lose 50% of your weapons, etc. How you implement your "Attributes" would be up to you. But I hope this helps answer your question.

Steve:
Bones are dice
Eyes (snake eyes): double 1's

kosmitek: Yes, the "monster" would be an excellent place to use a class. Another would be the "player" because you need to keep track of the player's position, health, strength, etc.

(note: It's Christmas)
To kosmitek:
'heirdom'? you probably mean inheritance...
It has nothing to do with "the player inherits the monster's money"

In the case of your game, one possible use of inheritance could be if monsters stay on the board:
"The player and the (visible) monsters ARE pawns on the board: They are represented by a BITMAP, and they are positioned on one of the cells. If these two informations (image and position) are "stored" in the parent class (ex: Pawn), you can code a function Pawn::draw() to draw them on the screen, this single function will work well for a Player or a Monster - anything that inherits Pawn.

This is only an example, certainly not THE solution for what you want to do. People here have much experience coding 2D objects moving on a background (I've just described 40% of the games on a.cc), but board games are much, much more difficult to design and code, and frankly there's no evident OO design there. If you've never DESIGNED something in object-oriented design, a board game is the worst choice to start...You will never complete the game, and you will not even learn why your design does not make your game go in the right direction.

If you want to progress in your game, structured programming is the way to go...until at least you completely understand how to use Allegro for a game, with some code for all initializations, a game loop, some code for logic, some other code for display, etc... and no memory messup.

Only if he starts taking the only good advice in this thread and reads a damn book and starts from the beginning, and drops the notions he has ingrained in his head right now. He needs to start over, not be further confused and fed misinformation.

Thank you for you advices, especially thank TeamTerradactyl. I do not thank "X-G", he only discouraged me and he write nothing helpful.

I have fast change my code as you say. Now I have simply class, late I will add here that if player stand on some field then something will done, I will also add class monster etc.

But can you say me that my fragments of code touch OOP are okey ? And why my destructor isn't okey ?