Some Game Programming Questions

Hey all,

I'm going to start out by saying that I know I'm just a very beginner at this. I'm trying to develop my skills by working on a console-based text game. For our purposes today, think NetHack.

Basically, I'm trying to get it so I can have a character (represented by the '@' symbol) move around the screen, using the arrow keys. I have it working, kind of. Here's my program:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
#include<iostream>
#include<conio.h>

using namespace std;

#define CONSOLE_MAX_WIDTH 80
#define CONSOLE_MAX_HEIGHT 12

void PrintMap(int PlayerXLoc, int PlayerYLoc);

int main()
{
	unsigned char com;     // User-input command
	int cx = 40, cy = 10;  // Current character's x-y location

	do { 
	system("cls");

	PrintMap(cx, cy);

	//Get Command
	com = _getch();

	switch(com)
	{
	case 224:
		com = _getch();
		if(com == 72)
			cy--;
		else if(com == 75)
			cx--;
		else if(com == 80)
			cy++;
		else if(com == 77)
			cx++;
	}

	if(cx < 0)
		cx = 0;
	else if(cx > CONSOLE_MAX_WIDTH - 1)
		cx = CONSOLE_MAX_WIDTH - 1;
	else if(cy < 0)
		cy = 0;
	else if(cy > CONSOLE_MAX_HEIGHT - 1)
		cy = CONSOLE_MAX_HEIGHT - 1;

	} while(com != 'q');

	return 0;
}

void PrintMap(int PlayerXLoc, int PlayerYLoc)
{
	// py: current 'y' output location, px: current 'x' output location
	for(int py = 0; py < CONSOLE_MAX_HEIGHT;  py++)
	{
		for(int px = 0; px < CONSOLE_MAX_WIDTH; px++)
		{
			if( px == PlayerXLoc && py == PlayerYLoc)
				cout << "@";
			else
				cout << " ";
		}
		cout << endl;
	}
}


Basically, it was just thrown together in a couple minutes. I know there are many bad programming practices being put to use there. I have a few specific questions though: Firstly, should I be using _getch() to get the character's movement input, or is there a better way? That's the only way I know of the capture an arrow key's input.

Secondly, is there a better way to refresh the screen? I know that right now, it kind of works, but as I add more to the program (such as walls the character can not pass), the whole screen will flash whenever I move. I would rather avoid this if I could. I also feel bad as someone in the beginner stages of programming getting in the habit of using a system() call. Maybe I'm wrong, but it just feels like a bad practice.

Thirdly, is there a function to call which will return the console's width and height values in terms of the number of characters? Right now, as you can see, I just have them hardcoded for a standard 80x14 character screen. It says 12 because in my print map function, there's an endl after every line, including the last one, bringing it to 13. Then when I call getch it seems to add another newline with a blinking cursor at the bottom (Something I'd also like to get rid of).

Lastly, is all of this going to be worth the effort without any win32, DirectX or OpenGL programming? The point of this game was to make something somewhat interesting using just the console, so I could get practice before delving into more complex topics.

Some things I want to implement in the future which may affect the answer to the last question:
- Real-time changes to the playing field (NPC's moving around the screen, maybe having the chance to move every second or two)
- User-defined key bindings


Thanks a bunch for any input! I'd rather know the answers ahead of time so I don't need to redo the entire program later, when I actually get into developing it.
Tyyrus wrote:
Lastly, is all of this going to be worth the effort without any win32, DirectX or OpenGL programming? The point of this game was to make something somewhat interesting using just the console, so I could get practice before delving into more complex topics.


No it will not be worth the effort. I think your time would be better spent in 2d where you can practice the same skills. Learn SFML or SDL and practice your skills there without the restrictions of the console... also see: http://www.cplusplus.com/forum/articles/28558/
That's quite interesting. Approximately at what point would it be a good idea to start working with graphics?
IMO once you have a firm grasp on how to handle Loops, File I\O, Classes & Structures, pointers, how to link libraries and additional cpp files as well as headers and you've established your preference for error handling while writing code (if you don't know what I mean about the last one then please ask because none of the first ten tutorials that come up on google for either library even touch on this). All of these skills are needed to understand SDL, SFML or any expansion library really. Now granted there is more that you probably should know in order to effectivly work with these libraries but actually UNDERSTANDING them is not as important if you really can't wait to start.
Thanks a bunch Return 0 for the link! It's actually really interesting, and I'll be looking more into SFML. Computergeek01, I have a working understanding of almost all the topics you mentioned above. I haven't really been programming for a year or so, so I'm finding myself a little bit rusty, but I'm remembering things quickly. Linker errors still give me a headache, but I think they always have haha.. But thanks I'll keep all that in mind when I'm reading up on the libraries.
Haha, I wouldn't say I have a "firm grasp" on any of those topics Computergeek01 mentioned. I don't know. I've been programming for almost five weeks now (this week and the 2 weeks before were very intense, approximately 12 hours each day). I was hoping be done with Pong by the time I finish my eighth week, but we'll see about that...
By the way the style of game you're trying to make is usually written with the help of libraries like these, another one is 'Allegro' although the other two are more popular. They aren't only for graphics, they also help with "clearing the screen", using keyboard commands like the arrow keys and sound. So even if you don't jump right into graphics, there is still plenty for these libraries to offer you.
Congratulation on 500th post, you're halfway to a grand! ;D

I can't wait till I'm done with this course of mine (after January 23rd). By then I should have a good enough grasp on pointers, classes, loops, file I/O, exception handling and touched a little about queues, trees, stacks, lists, linked lists and templates. Then it's off to a long road to do all these small little 2D games I've always wanted to make...
I have an unpopular opinion regarding this topic.

The way I see it, you have to learn a medium alongside learning the basics of the language anyway. The medium you learn might as well be the one you want to use. What’s the point of learning C++ while using cout if you’re never going to use cout in any programs you want to make? IMO, you might as well learn C++ while using whatever lib you’re going to be using. If you want to use SFML to make games, then get SFML and start learning how to write C++ w/ SFML to make games.

I personally started with MFC many, many years ago and didn’t find it very difficult. And SFML is tons easier than MFC (and more fun). Starting with the console just seems like a fat waste of time to me – unless you’re ultimate goal is to make console programs, in which case it’s a good move.

But like I said it’s an unpopular opinion. A lot of people disagree with me. So I might be wrong.
Disch: I partly agree with you - but only partly. I think there's some merit in doing some standard programming, as you'll learn from there, but most newbies aren't aware of what counts as learning the right mindset and syntax, and what counts as console programming and learning the console program think. So they might end up spending too much time learning console-related programming.

As for me, I'm just trying to get myself comfortable with classes, loops, pointers, and I still have to learn about exceptions, streams and file I/O.

Then it's gonna be a period of googling to decide on what to use for starting up with the graphics and whatnot...
Topic archived. No new replies allowed.