The Console is a Terrible Medium for Games

[drecklia]

Sorry, but what is console programming? I might be doing it now, but never have realized.

[Disch]

The console is a terminal window that normally uses only text for i/o. On windows it defaults to a black window with white text.

Basically if you're displaying things with cout or printf, you're using the console.

[bidnajunkeol]

Well... then I would feel sorry for the developers of graphic programming intrinsics library -- they would have to cram and jam themselves to implement such high-level intrinsics for super-simple coding! I believe that no person -- not even Bill Gates, Steve Jobs, or Albert Einstein -- can memorize tons of code used to implement simplest graphic functions like imagefile.LoadFromFile().

[blackcoder41]

You don't need to memorize it anyway. You can just look it up in it's documentation, also that 's why IDEs with intellisense is invented.

[appnerd]

I write text adventure games, and have completed the alpha release of my C++ Text Adventure Library (which is simple but mighty). In other words, the thought I am attempting to convey is that...

YOU
ARE
WRONG!!!!!!!

[appnerd]

I'm serious.

[firedraco]

text adventure

Isn't that using the console for i/o only though?

[appnerd]

Yeah!

Usually text adventures convey messages using text.

Just saying. Didn't you read anything on the last two pages?

Anyway, I love Text Adventure games because of the uniquely cool medium (text).

[Disch]

appnerd wrote:

I write text adventure games, and have completed the alpha release of my C++ Text Adventure Library (which is simple but mighty). In other words, the thought I am attempting to convey is that...
YOU
ARE
WRONG!!!!!!!

Did you read anything beyond the topic? I addressed this is the first post:

I wrote:

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?

[snip]

But for that... yes. The console would probably be easier.

Whether or not a console approach is "better" depends on some factors. Windows offer advantages the console doesn't offer -- specifically relating to you having full control over the display. Adding a picture or two, creating a border, etc, etc is a trivial task in a window, but is unnatural and weird in the console.

But if looks aren't important and you just want simple text i/o, then yeah, the console will be a lot less work and will be fine for your needs.

[rocketboy9000]

write text adventure games, and have completed the alpha release of my C++ Text Adventure Library (which is simple but mighty). In other words, the thought I am attempting to convey is that... you are wrong

It may seem that way to you right now, but soon you'll try to show the game off to a friend and he'll say: "Can't you just put a picture of the zombie on the screen? Like, get it off of Google." And then you'll realize that you've been working under artificial constraints. If you go and get a good graphics library, you can do amazing things, like 3 dimensional tetris, molecular modeling, water ripple refraction simulation, etc. If you make sprites for game objects, you can make Pac-man or Space Invaders. Interactive text (even with ncurses or similar) is simply the lowest form of programming. If you like it, it's because you've never done anything else.

[Disch]

Interactive text (even with ncurses or similar) is simply the lowest form of programming.

While I whole-heartedly agree with the overall message you're trying to illustrate, I must point out that the above statement can only really apply when you're speaking in terms of I/O.

I wouldn't even say that console IO is the "lowest" form -- I'd just say it's the most minimalistic.

Many extremely sophisticated programs have a minimalistic interface (any compiler, for example). Of course they're also a major pain to use directly and you often have to use another program to aid in interaction with them.

[appnerd]

I/O isn't minimalistic in any sense:

In many cases, the amount of code needed for i/o is much greater; just because a medium has limitations doesn't mean it's minimalist. In many cases, i/o gives you a chance to break out of the hypothetical gaming box in that you can add (without much difficulty) commands to not just "pick up the shovel" and "examine the tree" but "eat the shovel" and "shake the tree" (from Dunnet). i/o is NOT!!!!! minimalist.



ps. In dunnet, both commands kill you: you choke on the shovel, and a coconut falls down and crushes in your head

[rocketboy9000]

@Duoas: That's why I specified "interactive." Of course a non-interactive program like a compiler can just use a bunch of text as an interface. But when interacting with ordinary humans the requirements are different.
@dunnet: There's no reason you can't use a partial text interface for a graphical game. If The most common commands are "hit person in front of me with my sword" and "move around" those should use arrow keys, a joystick, the left mouse button, etc. For less common commands you can use a little txt box similar to the chat in WoW, although an inventory menu would be easier to use. However your users will appreciate seeing an actual shovel rather than reading "there's a shovel here."

[simeonz]

Everyone links to this thread :) Soon it will be the first hit on google when you type "software".

Ok. I am not game developer, and I don't understand the first thing about it. Don't be pissed, but I have to ask. Why are most opinions so concerned with graphics? I mean, I agree that graphics are necessary for playability in contemporary terms, but why is that topic perceived so central to the training process?

Even I would like to learn how to generate random mazes and maps, or find the shortest root in the presence of obstacles, or make decisions in complex environment, or learn from the opponent, or support scripting languages. And as I said, I am not into game development at present, but this stuff is interesting.

Now, if I wanted to train collision detection/hit detection, animated graphics, GUI, obviously using the console would be ridiculous. And apparently, generating free-form 3d with different elevations is different from random mazes, but I (as a noob) could live with that.

Those algorithms are probably implemented somewhere. Probably. Most fundamental things I can think of are already implemented somewhere. But, I would rather train with exotic problems then mainstream ones. Despite the circumstances.

Regards

[rocketboy9000]

Well, one reason is with real graphics it is actually easier to understand the OOP paradigm. In Pac-Man you can see objects moving around and doing their thing. In addition, the way graphics are done is more OOP-like:

al_clear_to_color(black);
maze.display();
pacman.display();
for(int i=0;i<4;i++)ghost[i].display();
al_flip_display()

Than in console graphics, which is like programming the scanlines on a CRT directly.

[Disch]

rocketboy wrote:

@Duoas: That's why I specified "interactive.

I think you're replying to me, not Duoas. And yeah point taken.

appnerd wrote:

I/O isn't minimalistic in any sense:

Yes, console I/O is extremely minimalist in every sense. It's minimalistic in that the API doesn't do much for you. All it does is input and output text. And if we're talking about standard lib API, it doesn't even give you any placement/formatting options. Very, very minimalist.

"Minimalist" doesn't mean "easier to use", in fact it's usually the opposite. Building a house with just a hammer and saw is minimalist, but is much more difficult than using power tools.

In fact that's kind of my whole point. Because the console does so little for you, you end up having to do more work -- which makes using it harder than some alternatives in many cases.

appnerd wrote:

In many cases, i/o gives you a chance to break out of the hypothetical gaming box in that you can add (without much difficulty) commands to not just "pick up the shovel" and "examine the tree" but "eat the shovel" and "shake the tree" (from Dunnet).

Having a console interface does not give you any more options than you would have in any other interface. What you're describing could easily be accomplished with Verb buttons a la Maniac Mansion. Rather than the user typing one of several available verbs, they would click on it.

Now, I'm not saying the verb button approach is better -- I'm just saying that using the console doesn't open any additional doors for you, whereas using a window-based game lib opens several. The console just holds you back and limits what your program is capable of. Even if you want the text I/O interface, that can be accomplished with a gaming lib.