C++ simple game

[Bumpehh]

Hey guys, im new to C++. been learning for only about a week. The most complex program i can make is a calculator!
But, i was wondering, how hard would it be to make a text-based zork-like game?

Like i said before im new, so any tips and/or tricks to making the code more simple would be highly appreciated.
i know the more complex the more better the game will be, and the more easier it will be to modify it later on, but i dont understand much yet soo...yeah. :P

Depends what you mean by calculator. I'm assuming its just a simple switch statement style calculator. If it's an RPN type calculator you could easily create a text-based game.

If in doubt give it a go and see how far you get.

[WaltP]

It's difficult. You have to understand how to design, store, and retrieve data from a database you design.

I'd go with something like craps, tic-tac-toe, mastermind (also somewhat complex). A game that remembers a little bit of information but not too much.

[Bumpehh]

Depends what you mean by calculator. I'm assuming its just a simple switch statement style calculator. If it's an RPN type calculator you could easily create a text-based game. If in doubt give it a go and see how far you get.

A simple switch statement.

[Bumpehh]

It's difficult. You have to understand how to design, store, and retrieve data from a database you design.

I'd go with something like craps, tic-tac-toe, mastermind (also somewhat complex). A game that remembers a little bit of information but not too much.

I wouldnt know where to start with tic-tac-toe. and by "Design" do you mean graphics, or the design or the code? because im thinking of a game in the Command Prompt.

[WaltP]

No, design, as in plan.

If you are going to make a car, do you just throw metal together and hope it works? No, you design the car. When the design is finished, you then build the car based on the design. Same with a program.

[m4ster_r0shi]

im thinking of a game in the Command Prompt

Read this first.

IMO, the thing with the best result-to-effort ratio you can do right now is grabbing a graphics library (e.g. SFML) and writing a simple scrolling shooter. And if you 're worrying about your artistic skills, don't. Computer software nowadays allows you to create really cool stuff without a lot of effort. I'm working on a 2D puzzle game myself, and, recently, I remade the graphics using Blender. You can see the result here (I also put the previous version for comparison).

[WaltP]

Completely disagree. After only 1 week, you don't have the background in the language to even think about graphics yet. Learn the language first. Graphics can come later.

I'd also agree with waltp here. Introducing 3rd party libraries is probably a bit much for beginners.

In all honesty C++ isn't the greatest language to start writing games but, that being said if you just want to create a game in the console window, it is possible using non-standard functions to clear the screen etc without having to download and link to another library.

So the next question is let's assume you want to code noughts and crosses... What OS and compiler are you using?

[m4ster_r0shi]

After only 1 week, you don't have the background in the language to even think about graphics yet. Learn the language first. Graphics can come later.

This doesn't really make sense, because modern graphics libraries render language knowledge and graphics orthogonal concepts.

Suppose you want to write a Tic-Tac-Toe game. In console, you would do something like this:

#include <iostream>

void drawGrid()
{
    for (int i = 0; i < 3; ++i)
    {
        for (int j = 0; j < 3; ++j)
        {
            char ch;

            switch (grid[i][j])
            {
                case 0 : ch = ' '; break;
                case 1 : ch = 'X'; break;
                case 2 : ch = 'O';
            }

            std::cout << ch;
        }

        std::cout << endl;
    }
}

int main()
{
    int grid[3][3];

    while ( /* user doesn't want to quit */ )
    {
        // do some stuff...

        drawGrid();

        // do some more stuff...
    }
}

Using SFML, you would do something like this:

#include <SFML/Graphics.hpp>

void drawGrid(sf::RenderWindow & window, sf::Sprite & sptX, sf::Sprite & sptO)
{
    for (int i = 0; i < 3; ++i)
    {
        for (int j = 0; j < 3; ++j)
        {
            switch (grid[i][j])
            {
                case 1 : sptX.SetPosition(i * BLOCK_SIZE, j * BLOCK_SIZE);
                         window.Draw(sptX); break;
                case 1 : sptO.SetPosition(i * BLOCK_SIZE, j * BLOCK_SIZE);
                         window.Draw(sptO);
            }
        }
    }
}

int main()
{
    int grid[3][3];

    sf::Image imgX, imgO;

    imgX.LoadFromFile("X.png");
    imgO.LoadFromFile("X.png");

    sf::Sprite sptX(imgX), sptO(imgO);

    sf::RenderWindow window(/* window params (e.g. resolution) */);

    while ( /* user doesn't want to quit */ )
    {
        // do some stuff...

        drawGrid(window, sptX, sptY);

        // do some more stuff...
    }
}

Notice that the language features you use in both cases are the same: arrays, loops, branching statements (switch) and functions. Ok, you could argue that in the second example we have objects and member functions, but this would be a very poor argument. There are no user defined types from the library's user's perspective. sf::RenderWindow, sf::Image and sf::Sprite are types defined in the library. Using them is as simple as using int and double. Also, member functions are just syntactic sugar. But if you want, you can switch to a C-like API (e.g. SDL) and get rid of them.

The bottom line is that if you lack the language knowledge to write a Tic-Tac-Toe game with graphics, then you also lack the language knowledge to write a console version of it.

Introducing 3rd party libraries is probably a bit much for beginners.

This doesn't make much sense either. Using a 3rd party library is extremely simple (as you can see above), especially if it is well documented (and SFML is). Also, installing a 3rd party library isn't that difficult. You just have to copy a couple of files, and click a few more buttons than usual when you create a project in your IDE.

As a side note, if the OP likes to do things the hard way and decides to go with a text-based adventure-rpg, (s)he could find this useful.

Well, in reply to the above post... Of course there is nothing inherently difficult about using a library, when you've been programming for a little while.

1. We don't know what OS the OP is using. Yes this matters, linux or Mac users will normally find using 3rd party libraries slightly more tricky.

2. We don't know what IDE the OP is using. Yes this matters, because where do you put the directory, do you have to add compiler/linking switches? All this makes it much more difficult.

3. Oject orientated paradigmns do matter when it comes to absolute beginners. How you can just brush it off 'as a very poor argument' without no reasons for justification? Now the OP not only has to learn the semantics of another library but also OOP idioms. Yes you can write a simple game like tic-tac-toe without OOP. Is it bad? Not necessarily for something so simple. Bigger/comples games? Yes OOP is better.

The bottom line is that if you lack the language knowledge to write a Tic-Tac-Toe game with graphics, then you also lack the language knowledge to write a console version of it.

Again, sorry but have to disagree here. You can adequately write a console version of tic-tac-toe without knowing how to use graphics.

Also, you may even be able to get around using non-portable functions such as clearing the screen by simply rendering the new board positions directly under the previous one. OK it might not look as pretty but then at least you can assume portability under windows, linux and *nix systems alike.

So in conclusion, given the OP's level the best possible step is to write a game like tic-tac-toe in the console window.

[m4ster_r0shi]

We don't know what OS the OP is using. Yes this matters, linux or Mac users will normally find using 3rd party libraries slightly more tricky.

Ok. But if you are a linux user you might actually find this fun :) Plus, it will only be difficult the first time you'll do it. Oh, and the key word here is 'slightly'.

We don't know what IDE the OP is using. Yes this matters, because where do you put the directory, do you have to add compiler/linking switches? All this makes it much more difficult.

No, it doesn't make it much more difficult. You are nitpicking now.

How you can just brush it off 'as a very poor argument' without no reasons for justification? Now the OP not only has to learn the semantics of another library but also OOP idioms.

Huh? I think you missed my point above. Read it again, more carefully. All I said was that introducing graphics doesn't have to introduce OOP. You can use CSFML or SDL and leave OOP out if you find it confusing.

Again, sorry but have to disagree here. You can adequately write a console version of tic-tac-toe without knowing how to use graphics.

Again, you missed the point. Let me restate it: The language features you need in order to write a console version of tic-tac-toe are the same language features you need in order to write a tic-tac-toe game with graphics. If you can do it in console, you can do it with graphics too. And if you can't do it with graphics, you can't do it in console either (remember, A => B is equivalent to !B => !A).

Also, you may even be able to get around using non-portable functions such as clearing the screen by simply rendering the new board positions directly under the previous one.

There, you noticed it too. With a graphics library you don't have to hack your way to portability. You 're already there.

So in conclusion, given the OP's level the best possible step is to write a game like tic-tac-toe in the console window.

No. In conclusion, given the OP's level, a good next step is to write a game like tic-tac-toe. Whether it will be a console or a graphics game doesn't make a difference. Except that a graphics game will be tons more fun.

[Bumpehh]

This should answer all questions. 1. im using Code::Blocks. 2. Im running Windows 7 Home Premium. 3. i dont want to jump into graphics yet.

[Bumpehh]

@WaltP when i said

and by "Design" do you mean graphics, or the design or the code?

i meant to say "Do you mean graphics or the design of the code?"
i understand what you need to know to build a program. and i understand the basics of building and retrieving memory stored in a database. not an expert though.

[m4ster_r0shi]

i dont want to jump into graphics yet

Why is that?

So, what kind of game do you want to make?

PS: Something I found regarding your original question
("how hard would it be to make a text-based zork-like game?")

Hi Bumpehh,

Thanks for answering those questions. So your next step is to consider what Waltp meant by design.

By design it is best to draw a flow chart. If you've never used one before you will do because a flow chart is essentially how all programs work.

So get some paper and write out what happens when you start the game of tic-tac-toe.
Then what must come first? For example, is it a two player game? Or do you play against the computer? If you play against the computer do you choose to go first or second?

Once you've understood flow charts. I think your next step will be to understand arrays, if you haven't already.

[Bumpehh]

Why is that

Because i personally think my first real game should be in the CP because thats what most programmers do. And for obvious reasons, like, it being more simple and Programmer-Friendly. :)

[Bumpehh]

@iamthwee

i understand Arrays, and multidimenstional arrays.
ive never thought of writing a flowchart. i think i might do that.

[m4ster_r0shi]

Because i personally think my first real game should be in the CP because thats what most programmers do.

One problematic thing with this line of reasoning is that 'real games' and 'CP' have nothing to do with each other. Another is that what most beginner (<- you forgot that adjective above) programmers do is not what is right.

And for obvious reasons, like, it being more simple and Programmer-Friendly. :)

This statement is just plain wrong. The console is actually a very hostile environment for game development. I think you didn't check the first link I posted, so, you'd better do it now.

ive never thought of writing a flowchart. i think i might do that.

Don't do it. A flowchart is not the best technique to use when designing a game. It may be enough for something simple as tic-tac-toe, but it scales very poorly as you move to bigger and more complex games. When designing a game, it's better to think in terms of state and events that affect that state. For example, ask yourself questions like:

1. "What are the different game states I'll have to deal with?"

2. "In what way exactly can the user interact with the game in each state?"

3. "What are the events (either user or game generated) that trigger state transitions?"

And then answer these questions:

1. "There will be an initialization state, where the user chooses whether (s)he will play against the computer or another human. There will be a main state, where the gameplay takes place. There will also be an end state, where the winner is anounced and the user is asked if (s)he wants to play again."

2. This is the same as 1, but in more detail, enough to allow you to translate it to C++ code.

3. "When the game starts, we begin with the initialization state. Then, we move to the main state (the transition here is linear). In the main state, three Xs or Os in a row (or column or diagonal) trigger a transition to the end state. Then, you can choose to either end the game or move back to the initialization state."

And if you like flowcharts, you can model the above technique using one, like this:

set the current state to the initialization state

  ||
  \/

repeat until the game ends:

  allow the user to interact with the game, based on the current state

    ||
    \/

  check if state transitions must be made, and if yes, make them

i understand Arrays, and multidimenstional arrays.
ive never thought of writing a flowchart. i think i might do that.

That's great. If you understand arrays then you should be able to move on quickly.

For flow charts it is really simple. There are just a few rules to follow which are fairly simple. You'll find yourself using these a lot when attacking more complex problems.

http://www.mindtools.com/pages/article/newTMC_97.htm

That's the first site I googled there may be others which are better.

Once you have your flowchart finished you can start to code.

Now masterroshi kindly posted a starter template for tic-tac-toe. Run with this and let's see where you get. Think about what other functions you might need... Such as checkwin(), enterPosition().

#include <iostream>
void drawGrid()
{
    for (int i = 0; i < 3; ++i)
    {
        for (int j = 0; j < 3; ++j)
        {
            char ch;
            switch (grid[i][j])
            {
                case 0 : ch = ' '; break;
                case 1 : ch = 'X'; break;
                case 2 : ch = 'O';
            }
            std::cout << ch;
        }
        std::cout << endl;
    }
}
int main()
{
    int grid[3][3];
    while ( /* user doesn't want to quit */ )
    {
        // do some stuff...
        drawGrid();
        // do some more stuff...
    }
}

[m4ster_r0shi]

Now masterroshi kindly posted a starter template for tic-tac-toe.

That code is completely broken though :S I was in a hurry when I wrote it and when I realized there were problems it was too late to edit my post. So, here's a fixed version, in case the OP decides to use it:

#include <iostream>

void drawGrid(int grid[3][3])
{
    std::cout << std::endl;

    for (int i = 0; i < 3; ++i)
    {
        if (i != 0) std::cout << "------" << std::endl;

        for (int j = 0; j < 3; ++j)
        {
            char ch;

            switch (grid[i][j])
            {
                case 0 : ch = ' '; break;
                case 1 : ch = 'X'; break;
                case 2 : ch = 'O';
            }

            if (j != 0) std::cout << '|';

            std::cout << ch;
        }

        std::cout << std::endl;
    }

    std::cout << std::endl;
}

int main()
{
    int grid[3][3] =
    {
        {0, 0, 1},
        {0, 1, 0},
        {2, 0, 0}
    };

    while (true)
    {
        // add more stuff here...

        drawGrid(grid);

        // add more stuff here...

        std::cout << "quit? (y/n) ";

        char ch;

        std::cin >> ch;

        if (ch == 'y' || ch == 'Y') break;
    }

    return 0;
}

I still insist on using a finite state machine instead of a flowchart to model the game logic though.

I quote from here:

...some people do not see the true difference between the two. The confusion starts with the missing understanding of a state which is not known in a flowcharts. [...]
...there are groups that exploit the concept over any imaginable extend. The procedure is always the same: one intends to use flowchart for some relatively simple tasks and after a while we have a uncontrollable monster and nobody knows how get out of it.

The author also uses a simple example to demonstrate the problem with flowcharts. Notice how the problem of switching a lamp on and off depending on some conditions (which can be modeled very easily using a state machine) becomes overly complex (like a Goldberg machine) when modeled with a flowchart.

^^ Dude this isn't your thread. Understand the obvious purpose the OP had when starting the thread - 'to learn how to code a simple game.'

We don't care if your template was broken, it was simply a point of reference on which the OP can start coding via a process of trial and error.

Also, stop trying to justify yourself by pulling as many random topics out of your a** you can remember as a freshman. Do you do this is everyday life?

We get it. You're obviously right and we're wrong. You can't see me now but I'm bowing down to your obvious superior knowledge.

Just let the OP do what he feels he wants to next.

[m4ster_r0shi]

Just let the OP do what he feels he wants to next.

I have no intention of doing otherwise. Actually, even if I had the intention, I wouldn't be able to do it. The OP can do whatever (s)he wants regardless of what I say. However, doing something because you want to do it is not the same as doing something because you think is right or / and easy while in fact is not.

If the OP had said that (s)he wants to remain in the console because (s)he really likes its vertical scrolling bar and the grey characters on the black background, I wouldn't have a reason to continue. It's his / her personal preference and I respect that. But (s)he didn't say that. (s)he said that (paraphrased) most programmers use the console to write real games because it's easy.

As someone who has more (not much more though) experience than the OP in the topic, I feel obliged to present the alternatives and make sure (s)he understands which one is better in what way and why. But after that, of course, the OP can do anything (s)he desires.

I didn't have any intention to upset you (or anyone else), and I apologize if I did.

[Bumpehh]

STOP Arguing about whos a better programmer! Gosh, this thread is about my question not your fued.

and i think im gonna go with game design. MasterRoshi is very convincing :)

[Bumpehh]

i couldnt even get SFML to install right or work with code blocks....i think im gonna pass. i want to become a programmer to have fun, not get frustrated.

[sfuo]

I would like to say that I agree with WaltP and that you should start off with learning the language before trying to hop into making a game with graphics. The first game I ever made was black jack in a console window (looking back on it, it was a POS) and I learned loads.

However, another option is to use SDL. I learned from it but quickly switched off to OpenGL to attempt some 3D "games".

Here is the tutorial website I used. This shows you how to setup SDL for Code::Blocks and a few other IDEs.

[m4ster_r0shi]

i couldnt even get SFML to install right or work with code blocks....i think im gonna pass.

Don't give up so easily. Since you're using Code::Blocks, my guess is that you don't have the correct version of MinGW.

Here's what you'll do:

1. Get the latest MinGW from here (use the GUI installer), and install the C and C++ compilers in C:\MinGW.

2. Open Code::Blocks and from the menu bar go Settings -> Compiler and debugger...

3. Go to the Toolchain executables tab and change the compiler directory from
   C:\Program Files\CodeBlocks\MinGW (or whatever it currently is) to C:\MinGW.

Now, you should be able to make SFML 1.6 work by following these instructions.

If you face any problems don't hesitate to post.

[Bumpehh]

my guess is that you don't have the correct version of MinGW.

I already got the newest version of MinGW.
And i wanna get into OpenGL not a Graphics Library.
I'll wait a bit before i get into that though.

Anyway, this question is closed now.
Thanks for all the advice guys! :)