All too often on these forums I see people asking how to either make a game in the console, or asking how to do a specific task related to game making in the console. Things like clearing the screen, repositioning the cursor, changing the font color, having the program run "in the background" so it doesn't wait for user input, etc.
The bottom line is the console is not designed for this kind of thing, and you shouldn't use it for these types of programs.
You
can make it work, but the end result will be bad on many levels:
- you'll have hackish code that twists console I/O away from what it does normally to what you want it to do.
- you'll have to comprimise your goals to accomidate the console's limitations
- your program won't be as polished as it could otherwise be
- it will be much more difficult than the alternatives.
I'm writing this article in an effort to persuade people to
move away from the console when they start making simple games.
In this article I use SFML in the example (get it at
http://www.sfml-dev.org ). I like SFML because I find it to be particularly beginner friendly, but also very fast, well documented, cross platform, has an active userbase, and is actively being developed. However it is not your only option. Other libs are available, such as Allegro or SDL.
If you're interested in game dev, I recommend you get SFML and start playing around with it. You might have to wrestle with the install and getting it set up, but it's a one time process. Once you figure it out, you don't have to do it again, and you'll be able to make future games easily. A small price to pay.
And because it's more fun for me... I'm writing the article in Q&A fashion!
Q) But graphics are complicated. Isn't the console easier for beginners?
That first statement is a falacy. And no. You'd be surprised how easy simple graphical libs can be. With the right lib, drawing an image is as simple as this:
1 2 3 4 5 6 7 8 9
|
// load the image
sf::Image imagefile;
imagefile.LoadFromFile("myimage.png");
// put the image in a "sprite" (basically a rectangle of something we want drawn)
sf::Sprite mysprite(imagefile);
// draw that sprite to the screen
mywindow.Draw(mysprite);
|
The difficulties of graphics are grossly overestimated.
Q) But wouldn't it be better to start with the console, then take what I learned and move on to graphics later?
No.
Console development and game development are completely different worlds, with completely different styles.
About the only thing you'll learn by doing console dev first is language basics (what is a variable, what is a class, rules of C++, etc). But those basics are just as easy to learn with
ANY target medium. The console is just the one people are introduced to most often because it's the only one the standard library supports.
Other things you learn from the console (how to structure the program's flow, how to poll and get user input, how to display things to the user) have little to no application in the game world. Games have to do it completely differently. You'll ultimately have to "unlearn" a lot of things the console taught you and relearn an entirely new way to do things. So you're better off just not wasting the step.
Q) But I don't want graphics. I just want ASCII symbols and a simple grid style map (for a rogue-like or something similar). Wouldn't the console be better?
Probably not. If you're using text for something graphics could represent, it's probably better (and just as easy) to use graphics.
If you really don't want to use graphics... like if you like the ASCII style... you can use the graphic lib and just draw ASCII symbols as graphics so it looks like you're printing text when you're really not.
That might sound stupid, but it offers many benefits:
- game libs have a more suitable approach to getting user input
- game libs have other features you might want, like background music or sound effects
- game libs don't have the same restrictions consoles do, like which colors can be displayed, and the resolution at which the game runs.
Q) But all I want is a simple text based adventure game where you type things like "move east" and it prints a description. Wouldn't the console be better for that?
Well you probably shouldn't be making that kind of game (see next Q). But for that... yes. The console would probably be easier. As long as:
- you are
sure you don't want any accompanying graphics. Keep in mind you might change your mind later and want a simple picture of the current location to be shown above the description text.
- you don't want any BGM
- the game will be waiting for user input (it won't be "running in the background")
Q) Why did you say I shouldn't make a text based adventure game? What's wrong with them?
They're not easy to make. In fact they're one of the harder games you can make.
Parsing text input and making sense of it
alone is difficult. Add onto that the heavy events and complexities involved in text based adventure games an you have a project that a beginner probably isn't equipped to handle.
Believe it or not, simple realtime action games with animation and graphics (like a simple galaga or space invaders clone) are
tons easier to make.
Beginners want to try out the text based games because they
think it will be easier because they
think graphics are difficult. But they're mistaken!
Q) But I've tried and I don't understand animation, and I know how to do console stuff. Wouldn't it be better to just stick with what I know?
That's because you learned console programming and not game programming. Remember they're different worlds, and having some experience in one doesn't necessariliy prepare you for the other.
If you're already stuck in your ways and really don't want to learn something new, then fine. Do whatever is the most fun for you.
But if you find yourself asking questions about how to do things the console isn't designed to do... stop. Instead of learning how to do things the wrong way, why not learn how to do them the right way? I mean as long as you're learning new things....
Anyway that's about all I have to say. Hopefully I can just link to this post in threads which this comes up.