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

[iamthwee]

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.

[iamthwee]

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.

[iamthwee]

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?")

[iamthwee]

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

[iamthwee]

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...
    }
}