- Forum
- General C++ Programming
- What do you think of this simple Rock, P
What do you think of this simple Rock, Paper, Scissor game?
I'm still not exactly an expert, but I made this simple rock, paper, scissors game. It runs fine and everything, but is there anything that you would change, in terms of programming style, or maybe making it simpler? Also, I didn't use srand() to seed the random number, but it seems to be different every time so I guess I don't need it?
Anyways, here's the code: http://pastebin.com/f2531e2d1
Anyways, here's the code: http://pastebin.com/f2531e2d1
I don't know how you get that mysterious no srand behavior but I'd advise calling it at the start anyway, calling it once is generally worth the code overhead.
The loop where you get user input seems a bit odd to me. I personally dislike the idea of while (true) break loops. Better to check the condition where it belongs rather than use a break to escape, when break is often unnecessary, but hey.
In the line where you randomize the CPU's choice what's the point of the +0 at the end, and the 3-0+1?
For your winner function, I'm sure there's a way to streamline that but I can't think of one.
Anyway looks fine to me.
The loop where you get user input seems a bit odd to me. I personally dislike the idea of while (true) break loops. Better to check the condition where it belongs rather than use a break to escape, when break is often unnecessary, but hey.
In the line where you randomize the CPU's choice what's the point of the +0 at the end, and the 3-0+1?
For your winner function, I'm sure there's a way to streamline that but I can't think of one.
Anyway looks fine to me.
Looks very nice. I have a few suggestions of other ways to implement the game, but I don't know how much it would simplify things.
It is very "procedural". I would make the game itself a class and the functions members. Main() would create a game object and call play() on it.
You could use a function to assign a score to each: -1 lose, 0 tie, +1 win. The nice thing about that is you just need to assert that computer.score + user.score == 0 to know it scored correctly.
Rather then an long if/else section for scoring, you could look up the result using a static 2D table.
It is very "procedural". I would make the game itself a class and the functions members. Main() would create a game object and call play() on it.
You could use a function to assign a score to each: -1 lose, 0 tie, +1 win. The nice thing about that is you just need to assert that computer.score + user.score == 0 to know it scored correctly.
Rather then an long if/else section for scoring, you could look up the result using a static 2D table.
Oh wow, PanGalactic you are very much an OO programmer hm? I personally dislike the idea of class-ifying (the verb class-ify in contrast to the verb classify) things that execute more as tasks or series of events; I personally prefer to use a class as a tool for the implementation of functional programming. But to each his/her/their own.
It is simple now, but with a well thought-out class structure you could have, for instance, ComputerPlayer, ConsolePlayer, RemotePlayer, WebPlayer, SmsPlayer, SmartComputerPlayer, AlwaysRockComputerPlayer, etc. The game wouldn't care which two were playing. The way it is built now you cannot easily have ComputerPlayer vs. ComputerPlayer. A good OO design makes that sort of thing easy(er).
For the most part, prefer OOP over all paradigms until there is a specific, justifiable reason to use a different one. OOP is nothing short of brilliant; most of its criticisms relate to a poor modeling structure not the paradigm itself.
Topic archived. No new replies allowed.