   Game making tutorial for beginners
  I have been writing tutorials on various subjects for over 7 years.Here is a page I added to Authentic Society encyclopedia explaining how to build a first game in the C++ language, for beginners.By beginners, I mean absolute beginners.http://www.authenticsociety.com/about/WriteOwnGamesCCan anyone tell me how much does the average Gamedev person knows about making games, compilers, programming languages, etc. ?What type of tutorials would you guys like to see the most? Please leave your answer.[Edited by - gregsometimes on November 19, 2010 3:10:13 AM]
  This is a good start for most beginners but you should also include some for of primer for c++ after this, and explain how if, else, return, all workand then go into making a an interactive game.   ;Quote:Original post by FritzMarThis is a good start for most beginners but you should also include some for of primer for c++ after this, and explain how if, else, return, all workand then go into making a an interactive game.Fritz, that's a very good point. The page clearly needs an explanation of how the programming language works, at least the parts that are used in the source code.Thank you for your feedback.   ;  If you're going for absolute beginners to coding, maybe you want to give a detailed primer of C++ first and give some exercises in their relative sections so that the beginner may get used to the concepts they were just explain.In the Game Paradigm section, I see you're using #define statements to define some constant strings. I thought that maybe since you're teaching C++, it would make sense to start people off with the higher level concepts of the language and it's more natural (and superior) features. C++ offers a high level string concept and introduces the const keyword, so combining the two, instead of:/* Define constant values */#define NUMBER_OF_TRIES 5 // Guess the number 5 times until game over#define TRIESLEFT  "You have %i tries left: "#define TOOLOW"Computer: The number you entered is too low\n"#define TOOHIGH    "Computer: The number you entererd is too high\n"#define WINNER"CONGRATULATIONS, You won, the number %i is correct!\n"#define LOSER "SORRY YOU LOST, The number I thought of was %d\n"you would have a much nice and easier to work with:include <string>/* Define constant values */const int NUMBER_OF_TRIES = 5;const std::string TOOLOW = "Computer: The number you entered is too low\n"const std::string TOOHIGH = "Computer: The number you entered is too high\n"Clearly some of the macros can't be defined as constants. That's usually where functions come in, but the examples above could've been just written out in the code; however, you can write some inline functions which I believe have a similar effect as macros.   ;  boogyman19946,That's an incredibly good point - what you say is true, and I will keep that in mind. I am trying to think of different ways of writing the tutorial so that the person who has no absolute knowledge will understand, and... more importantly:a) Find the tutorial interesting to learn from, and:b) Will not get confusedHaving said that, I want to keep things simple. #define may not be the most ideal way of doing things, but it is easier to read, and makes the newbie think "Ah-ha, we are defining something", instead of thinking "what is this std::xxx" crap for? So now I have to explain standard library to a newbie, and I think that should be reserved for later.But what do you (or everyone else) thinks of having a second and third part of the tutorial that explains how to make the same exact game using two different approaches:Part #2:The one that boogyman19946 is explaining (the proper, modern way of using the language) - and THEN show the contrast and provide explanations of why it should be done that way - this way the tutorial will not overwhelm the reader. I'd imagine that these newbies, are eager to learn a new thing... they don't want to be concerned with the details, at least not right away.Part #3:Where the reader learns how to create the same game using Object Oriented programming.Thanks everyone, I'm glad to have received 2 helpful responses so far :) It is really helping to improve the tutorial!   ;  Along with the other people who commented before me, you definitely need to include some C++ comments or explanation along side what you're teaching. When I saw this, I didn't have the image of making a text based game in mind: I thought you had written something more along the lines of how to make a graphical game.This seems aimed at people who basically never touched programming in their life, or may be new at it so they don't know how to apply the concepts towards game logic. I've done this as a project for almost every C++ class I've taken, usually to learn how to make if, then, else statements and random numbers. Ergo, you should definitely spend a little more time explaining some of the basic syntax of C++ and stuff like that so that people unfamiliar to the language can follow along.I can't tell you what the general consensus is for skill level among Game Dev people. Sorry.   ;Quote:Having said that, I want to keep things simple. #define may not be the most ideal way of doing things, but it is easier to read, and makes the newbie think "Ah-ha, we are defining something", instead of thinking "what is this std::xxx" crap for? So now I have to explain standard library to a newbie, and I think that should be reserved for later.I totally disagree. Show them the correct way to do things. Too many people jump into programming and learn bad practices first. It makes it hard for them to unlearn them, because what they are doing still works. It just makes many other aspects of coding harder than they need to be.Avoid #defines in C++.Avoid global variables.Use std::cout not printfSince you want to avoid confusing people, use if()else() instead of the ?: operator.This is c++ remember? You wrote the game in C. That's ok too, but C and C++ are two totally different things.Maybe something more like this?// guess.cpp : Defines the entry point for the console application.//// Guess is a simple game where the player has 5 tries to guess a random number the computer chose.#include <iostream> /* Include std::cout and std::cin */#include <cstdio>  /* Include rand/srand */#include <ctime>   /* Include time() */// Foreword.// Some of the functions you are going to encounter.// std::cout <<, this is output to the screen. Things to print are chained with <<.// std::endl. Used to "flush" your std::cout to the screen. Adds a newline character aswell.// std::cin >>, this is input from the keyboard. Things are chained with >>.// rand() get a random number between 0 and RAND_MAX// srand() call ONCE to init the random number generator.// time() get the current time. This provides an effectively random number to seed srand() with, so all the random numbers after it are also effectively random.// Using a non-random number in srand() will actually cause your calls to rand() return the exact same stream of 'random numbers' every times.// Here we make our game classclass Game{// Keep all our variables private, so you can't access them from the outsideprivate:unsigned triesLeft;unsigned number;// but make all our functions public, so you can call them in main()public:// Constructor. Setup everything in our class.Game(){number = rand( )%100; // make a random numbertriesLeft = 7; // init the number of tries leftstd::cout << "Computer: I have thought of a number between 0 and 100. Can you guess it?" << std::endl;}// Destructor. Clean up everything in our class.// This usually involves releasing resources~Game(){std::cout << "Application Terminated" << std::endl;}// Play the game!void Play(){std::cout << "Welcome to the game!" << std::endl;// Loop till the player runs out of guesseswhile( triesLeft ){// Report the remaining tries leftstd::cout << "You have " << triesLeft << " tries remaining" << std::endl;// Get the player's guessunsigned result;std::cout << "Your guess? " << std::endl;std::cin >> result;// Check that against the number the computer came up with.if(  result == number ){std::cout << "You WIN!" << std::endl;return;// this breaks out of the function, so the LOSE message doesn't show up}else if( result < number ){std::cout << "Too low!" << std::endl;}else{std::cout << "Too high!" << std::endl;}// Decrement the number of tries the user has lefttriesLeft--;}// If we get here, the while( ) loop exited. This means the player is out of tries.// Poor fellow.std::cout << "Sorry, you lose!" << std::endl;}};/* int main()   Program entry point */int main(int argc, char* argv[]){// Init the random number generatorsrand( (unsigned int)time( NULL ) );// Make the gameGame myGameInstance;// Run the gamemyGameInstance.Play( );//if you aren't running this from the actual command prompt or debugger,//your application will "just exit" at the end. Uncomment these lines to force//the person to press enter to continue.// std::cout << "Press 'enter' to quit." << std::endl;// std::cin.get(); return 0;}Also consider adding some error checking to the user input. In C++, you can get some nasty problems from not checking if std::in failed or not. (ie typeing "a" as a guess in the above code causes it to loop till you lose the game).You could also avoid making a class entierly, and do everything in main. That way you don't have to explain classes or functions.  Part of the beauty of some games like the guess the number one is that you can start out VERY simple with it, and then refactor the code over several tutorials to show off different language features without changing how the program works.edit:Refactored it without the class or the functions.// guess.cpp : Defines the entry point for the console application.//// Guess is a simple game where the player has 5 tries to guess a random number the computer chose.#include <iostream> /* Include std::cout and std::cin */#include <cstdio>  /* Include rand/srand */#include <ctime>   /* Include time() */// Foreword.// Some of the functions you are going to encounter.// std::cout <<, this is output to the screen. Things to print are chained with <<.// std::endl. Used to "flush" your std::cout to the screen. Adds a newline character aswell.// std::cin >>, this is input from the keyboard. Things are chained with >>.// rand() get a random number between 0 and RAND_MAX// srand() call ONCE to init the random number generator.// time() get the current time. This provides an effectively random number to seed srand() with, so all the random numbers after it are also effectively random.// Using a non-random number in srand() will actually cause your calls to rand() return the exact same stream of 'random numbers' every times./* int main()   Program entry point */int main(int argc, char* argv[]){// Init the random number generatorsrand( (unsigned int)time( NULL ) );unsigned number = rand( )%100; // make a random numberunsigned triesLeft = 7; // init the number of tries leftstd::cout << "Welcome to the game!" << std::endl;std::cout << "Computer: I have thought of a number between 0 and 100. Can you guess it?" << std::endl;// Loop till the player runs out of guesseswhile( triesLeft ){// Report the remaining tries leftstd::cout << "You have " << triesLeft << " tries remaining" << std::endl;// Get the player's guessstd::cout << "Your guess? " << std::endl;unsigned result;std::cin >> result;// Check that against the number the computer came up with.if(  result == number ){std::cout << "You WIN!" << std::endl;break;// this breaks out of the loop so we can quit}else if( result < number ){std::cout << "Too low!" << std::endl;}else{std::cout << "Too high!" << std::endl;}// Decrement the number of tries the user has lefttriesLeft--;}// Poor fellow.   if( triesLeft == 0 ) std::cout << "Sorry, out of turns, you lose!" << std::endl;//if you aren't running this from the actual command prompt or debugger,//your application will "just exit" at the end. Uncomment these lines to force//the person to press enter to continue.// std::cout << "Press 'enter' to quit." << std::endl;// std::cin.get();return 0;}edit again: changed the number of tries to 7. Can you guess why?Quote:. I am trying to think of different ways of writing the tutorial so that the person who has no absolute knowledge will understand, and... more importantly:a) Find the tutorial interesting to learn from, and:b) Will not get confusedThen add Pseudocode, or a Flow Chart. 90% of the problem that most people have with programming is understanding what to do. You can read code all day but never make the leap to understand why the author wrote it that way.  You have to see the process, break it into steps, beak those steps into atomic parts then build back up the whole.You didn't even explain WHAT game you were coding! There is a lot of leadup you need before you even get to the code. That way a real beginner can get a feel for what they are looking at before they get bogged down trying to memorize words like std::string.What IS the guess the number game? (i pick a number, you guess it.)How do you translate that to steps? (pick a number. take a turn guessing. loop for another turn.)How do you break each of those steps up? (ie. a guess is either correct, too high, or too low. A correct guess finishes the turns.)How do you code each of those atomic parts? ( unsigned int, rand, while, if, else, std::cout, std::cin )How do you start to put it together? Remember, not everyone intuitively gets that order matters. ( "put on your shoes and socks", most people intuitively know what it means, but a computer would get it backwards. )There was a great thread a few days back about someone who just didn't "get" functions. Maybe that could point you in a better direction. People stumble on strange things because programming is new to them. It is an abstract, yet exact mathmatical science. It's hard to get people thinking that way initially.[Edited by - KulSeran on October 24, 2010 3:15:46 PM];  I agree, on the webpage it says learn C++, but the game is written in 100% C as far as I can see. This would confuse newcomers to know end, they are seperate languages.i'm a beginner in C and if I wanted to learn C++ then your tutorials wouldn't be any good.Other than that it's great, although as others have said, if it's for people who have never touch programming, they need to know what an int is etc before even doing guess number.   ;Quote:Original post by gregsometimesboogyman19946,That's an incredibly good point - what you say is true, and I will keep that in mind. I am trying to think of different ways of writing the tutorial so that the person who has no absolute knowledge will understand, and... more importantly:a) Find the tutorial interesting to learn from, and:b) Will not get confusedAs said by others, when you introduce them to actual C++, they will get confused either way. What is worse is that then, instead of using the better aspects of C++, they will revert to the old stuff from C, which isn't desired in this case. If you're planning on using #define, don't do it in a C++ tutorial.Quote:Original post by gregsometimesHaving said that, I want to keep things simple. #define may not be the most ideal way of doing things, but it is easier to read, and makes the newbie think "Ah-ha, we are defining something", instead of thinking "what is this std::xxx" crap for? So now I have to explain standard library to a newbie, and I think that should be reserved for later.If it looks dirty, use an "using namespace std;" statement. Then you can say "const string Something = "w.e";", and now the user says to himself "Oh ok, we have a constant string named Something that is equal to "w.e". The better part of this is that the compiler can do type checking and catch mistakes during compile time. It'll bark a little at the newbies, but they won't get nasty bugs.Quote:Original post by gregsometimesBut what do you (or everyone else) thinks of having a second and third part of the tutorial that explains how to make the same exact game using two different approaches:Part #2:The one that boogyman19946 is explaining (the proper, modern way of using the language) - and THEN show the contrast and provide explanations of why it should be done that way - this way the tutorial will not overwhelm the reader. I'd imagine that these newbies, are eager to learn a new thing... they don't want to be concerned with the details, at least not right away.If they don't want to be concerned with the details, use the proper concepts right off the bat and don't bother them with the old stuff at all.Quote:Original post by gregsometimesPart #3:Where the reader learns how to create the same game using Object Oriented programming.Thanks everyone, I'm glad to have received 2 helpful responses so far :) It is really helping to improve the tutorial!Instead of the same game, do something different. It'll keep the newbies interested and they won't have to grind the same concept over and over in countless different ways.Quote:Original post by KulSeranIt is an abstract, yet exact mathmatical science. It's hard to get people thinking that way initially.Sounds a lot like Algebra and Calculus ;] Abstract and strict logical science.   ;Quote:Having said that, I want to keep things simple. #define may not be the most ideal way of doing things, but it is easier to read, and makes the newbie think "Ah-ha, we are defining something", instead of thinking "what is this std::xxx" crap for? So now I have to explain standard library to a newbie, and I think that should be reserved for later.Another vote here for using proper C++ idioms from the outset.First of all, using constants rather than #define's doesn't involve the standard library or the std namespace in any way, so that particular argument doesn't make a great deal of sense.The 'Aha, we're defining something!' argument is specious as well, IMO; there's enough that's unintuitive about macros that any intuitive advantage of using the word 'define' is likely to be negated.People have different opinions about how to teach and learn C, C++, etc. Some say learn C, then C++. Some say if you're going to learn C++, just learn C++. I won't offer an opinion here, other than to say that if you're going to present your tutorial as a C++ tutorial, use C++, not C. Otherwise, you're just going to confuse your audience and instill habits that will most likely have to be unlearned later.   