my first attempt at a c++ program
Author
First off I should thank the community here for all the help they have provided via the search function. I was able to solve pretty much everything that had me stumped by doing a search in the forums.
I just recently finished reading a beginners book on c++ programming and this is my program to try out some of the things Ive learned. I didnt mean for this to be a "good" program really, but rather just figuring out the correct way to get some basics working correctly. I understand that I probably did many things that shouldnt have been done, or should have been done differently, Im looking forward to corrections and suggestions that would make my programming better in the future. I was a little lazy in the naming and theres a lot that was just copy and pasted from tutorials and other resources. My goal next is to read up on putting things in seperate files and getting a grasp on more advanced function as well as the STL. If someone has a better direction I should be heading, Id be glad to hear it.
Ive done a little bit of microcontroller programming in assembly, and at first, and even a little still, my programming thinking was from an assembly point of view. For example, my program has one class where Im sure other things should have been made into a class also. Ive been used to setting bits and using them for my flags, I felt guilty making all these named varials and constants.
The program is in a "barely functioning" state, theres definately things that could be improved, but I think I got everything working well enough.
The game is a tick tac toe variant named "trick tac toe". Ive actually made a simple thing into a confusing one. The object is the same- get three in a row. Only now in addition to your placing your X or O, you also place a fake X or O. The fake piece is worthless besides the confusion imposed on your opponent(and yourself). Trying to keep track of things is quite a chore and probably takes away from any fun when the board starts to get full(which happens pretty fast). The AI is a little on the unintelligent side. It was a little too hard the way I originally did it, but I think I went to far the other direction. The stupid setting just does random moves.
Heres the instructions(I know the actual game desperatly need them)- left click to set your real piece, and right click to set your fake one. You can do either on the opponents squares, if the square had a real piece, your move is removed and lost for that turn. If it was a fake piece, it is replaced by your move. You can put your own real piece on your fake piece, but a fake piece must go on an empty square or one occupied by the opponent.
Anyways, heres the program and the source file. I believe its complete and should run as its uploaded. I was doing a inno setup, but I couldnt get the "start in" working so the shortcuts were of no use.
game development showcase page
Heres one thing that I never figured out-
this code will work fine as it is in the program-
{
Mix_PlayChannel( -1, valid, 0 ) ;
computerFake(board, cPiece, fakeOnPiece, fakeSquare, compMove);
}
but reversing the two lines would create an access violation-
{
computerFake(board, cPiece, fakeOnPiece, fakeSquare, compMove);
Mix_PlayChannel( -1, valid, 0 ) ;}
}
As far as I know they dont use anything in common. My guess is something that they are using some function that Im not calling directly or seeing. I really have no idea though.
[Edited by - jasong on September 21, 2007 10:09:31 PM]
Hey, I downloaded your code and i'm definately impressed given that it's your first game. I like that you had some sound effects, own textures, font, and a decent menu system, which shows your thinking about a game as a whole rather than just the core content programming (which alot of people do). Some ingame instructions would top it off nicely as you've already pointed out.
I only looked quickly at your source and it looks pretty solid. Afew things to suggest for future;
- i saw all the const int's at the top of your file used for text colour, AI level etc.. look at using enumerated values for these instead of defining them as actual variables.
- There's quite afew if, else if, else if, else if, etc. blocks for some of your logic, in which your checking the condition of only one particular variable (and keeping the rest constant). The 'switch' keyword was born for this :)
- And as I think you've already mentioned, moving things into different classes, and organising the structure of the code a little better based on that. The code will work fine as you can see with only one big class, but as you start to develop larger and more complex games you'll quickly see the need to have everything split into smaller classes and be more object oriented. Afew concepts you might want to look into are 'coupling' and 'cohesion', which deal with the way classes are designed, and really helps in the long run.
Besides nitpicking like above, i'm overall impressed with your program, keep reading and practicing, and keep posting your stuff on the forums.
I only looked quickly at your source and it looks pretty solid. Afew things to suggest for future;
- i saw all the const int's at the top of your file used for text colour, AI level etc.. look at using enumerated values for these instead of defining them as actual variables.
- There's quite afew if, else if, else if, else if, etc. blocks for some of your logic, in which your checking the condition of only one particular variable (and keeping the rest constant). The 'switch' keyword was born for this :)
- And as I think you've already mentioned, moving things into different classes, and organising the structure of the code a little better based on that. The code will work fine as you can see with only one big class, but as you start to develop larger and more complex games you'll quickly see the need to have everything split into smaller classes and be more object oriented. Afew concepts you might want to look into are 'coupling' and 'cohesion', which deal with the way classes are designed, and really helps in the long run.
Besides nitpicking like above, i'm overall impressed with your program, keep reading and practicing, and keep posting your stuff on the forums.
Quote:Original post by supamike
- i saw all the const int's at the top of your file used for text colour, AI level etc.. look at using enumerated values for these instead of defining them as actual variables.
Defining constants using enum is an old hack and is no longer necessary. It is better to define constants using static int const.
Author
Thanks for the pointers supamike.
I realized the if else blocks I used would have been better suited with the switch statements after I had done it. My lack of experience kept me from forseeing that. Towards the end I used the switch when I was organizing the game states based on one of lazyfoo's articles.
The program took me a while for what it is, so I dont think it should be impressive, really . It just happens to be the way I learn best. Ive learned that, after studying many different things and wasting a lot of time. I will get more from a simple reference stating what an instuction does, what it needs and what it spits out along with the syntax than from reading a bunch of books trying to teach with tutorials and stuff. When I was learning to do the microcontroller stuff, I read a lot of material that didnt really help me that much. My brain started taking it all in when I sat down and read the companies instruction reference pamphlet, and thats when I realized that other stuff didnt do much for me, and thats probably why I dont do too well in a typical classroom setup. I read that 90% of game programmers have the same personality type as me, so a lot of people here are probably be the same.
I just ordered The C++ Standard Library: A Tutorial and Reference(for the reference portion:)) and I will be going over that as well as reviewing some things Ive learned and looking deeper into others, before I go on to my next project. I should be able to plan things out a little better and write some psuedocode thats a little more accurate. In my next project I want to implement some collision detection, anitmations and scrolling.
I realized the if else blocks I used would have been better suited with the switch statements after I had done it. My lack of experience kept me from forseeing that. Towards the end I used the switch when I was organizing the game states based on one of lazyfoo's articles.
The program took me a while for what it is, so I dont think it should be impressive, really . It just happens to be the way I learn best. Ive learned that, after studying many different things and wasting a lot of time. I will get more from a simple reference stating what an instuction does, what it needs and what it spits out along with the syntax than from reading a bunch of books trying to teach with tutorials and stuff. When I was learning to do the microcontroller stuff, I read a lot of material that didnt really help me that much. My brain started taking it all in when I sat down and read the companies instruction reference pamphlet, and thats when I realized that other stuff didnt do much for me, and thats probably why I dont do too well in a typical classroom setup. I read that 90% of game programmers have the same personality type as me, so a lot of people here are probably be the same.
I just ordered The C++ Standard Library: A Tutorial and Reference(for the reference portion:)) and I will be going over that as well as reviewing some things Ive learned and looking deeper into others, before I go on to my next project. I should be able to plan things out a little better and write some psuedocode thats a little more accurate. In my next project I want to implement some collision detection, anitmations and scrolling.
Quote:Original post by jasong
My goal next is to read up on putting things in seperate files and getting a grasp on more advanced function as well as the STL. If someone has a better direction I should be heading, Id be glad to hear it.
Sounds like a good goal to me.
A couple of things I noticed when skimming over the code:
- Formating. The formatting seems to be a bit inconsistent in some places, you should try to keep things consistent so it's easier for people to read.
- Function Size. This is really related to the copy and pasting that you mentioned but just to reinforce the notion, functions should be relatively small things which perform a logical action, as a general rule of thumb if a function is more then a screen long or has more then three nested control structures (if, while, for, ...) then you should split it into multiple smaller functions.
- Variable Declarations. In general you should declare variables as close to the first point that you use them as possible. If you see lots of tutorials declaring them all at the start of the function then this is probably because they either where written by C programmers or are written in C which requires you to do this. (Technical Note: IIRC only C89 requires this not C99)
- Repetition. There are a number of things where you have written things out multiple times (copy and pasting) which would be better suited to loops (or SC++L algorithms).
There where some other things but most of those are covered by what you said. Most of what I said is directly related to things which you already noticed as well which is good since it means you're paying attention to the quality of the code you write.
Edit:
One last thing (which is partly opinion), I just noticed you use pVar for pointers etc... so Hungarian notation is generally considered bad style in C++.
Author
So when naming the variables I should just you a descriptive name for them? In one of the books I read, it said that the p or r is a good idea to remind you of what the name is for. I used the same names in different functions that were all reffering to the same thing. Is this OK, or should I have unique names in each function?
Hello,
Well I look through your program and I got some things to talk about.
Naming Convention: Your naming convention was inconsistent. For example, you started off naming your const with all caps and then switch to not doing that. If you was to use your own style please make sure it is consistent throughout the program, but generally people use all caps to note it is a constant.
Length of Program: I think for it to be in one long file is really bad. I think the class should have been broken into another file. Maybe you could of put the functions to in another file since most of them were long.
Length of Functions: The functions are very long, and you could have broken it up into way smaller pieces.
Et cetera: I did not see that much comments. I will advise you to use comments for your own sake, too. What happen if you went and look at this program a year later. You would probably not remember what everything meant. For example, you don't remember a certain function use. Also, I like to see comments because then I know you are trying to make it easier for the people who look through your code. Last thing, if you like to keep all the functions with the main function I would advise you to protype them in the beginning and write all the actually function code after main. Here is an example:
Last of all, I seen that one person complained about Hungarian notation, but I only see that you used it in function declaration part. I think that is ok, because the actually variable name is not that.
~Carl J. Loucius
Well I look through your program and I got some things to talk about.
Naming Convention: Your naming convention was inconsistent. For example, you started off naming your const with all caps and then switch to not doing that. If you was to use your own style please make sure it is consistent throughout the program, but generally people use all caps to note it is a constant.
Length of Program: I think for it to be in one long file is really bad. I think the class should have been broken into another file. Maybe you could of put the functions to in another file since most of them were long.
Length of Functions: The functions are very long, and you could have broken it up into way smaller pieces.
Et cetera: I did not see that much comments. I will advise you to use comments for your own sake, too. What happen if you went and look at this program a year later. You would probably not remember what everything meant. For example, you don't remember a certain function use. Also, I like to see comments because then I know you are trying to make it easier for the people who look through your code. Last thing, if you like to keep all the functions with the main function I would advise you to protype them in the beginning and write all the actually function code after main. Here is an example:
void SetNumber(int num);int GetNumber();int main(){ return 0;}void SetNumber(int num){ //blah blah blah}int GetNumber(){ //blah blah blah}Last of all, I seen that one person complained about Hungarian notation, but I only see that you used it in function declaration part. I think that is ok, because the actually variable name is not that.
~Carl J. Loucius
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
