on the right track?
Author
right now i am still new to the c++ scene.. im now into functions() and macros.. going to be getting into ::classes very soon. can you tell me if this text adventure code is going in the right direction? the function just outputs the two inputs (for debug reasons)
----------------------------------------------------------------->>
// Avalons Valor v.0.1 -- Justin Elkins
#include <iostream>
#include <string>
#define p cout <<
#define n << endl
#define i cin >>
using namespace std;
// Function Declarations
int main(void);
string creation(void);
//Global Variable Declarations
string race;
string Class;
string name;
string input;
int main(void)
{
p("")n n;
p("-------------------------------------------------------------------------")n;
p("DAVIONS VALOR - Into the Dragons Den V1.1")n;
p("-------------------------------------------------------------------------")n n;
p("welcome to davions valor, a text rpg about the days of old...")n;
p("when warriors fought wizards and beast against man!. This story")n;
p("starts with you the hero! you choose your own path in this game of")n;
p("cunning and smarts.. you start by choosing who you really are below!")n n;
creation();
return 0;
}
string creation(void)
{
p("please choose your race")n;
p("Races:")n;
p("Human Elf Dark-Elf")n;
p("Halfling Gnome Dwarf")n;
i(input);
race = input;
p("Please select a class");
p("Class:");
i(input);
Class = input;
p("Welcome to avalon young ");
p(race);
p(" ");
p(Class);
return race;
}
----------------------------------------------------------------->>
It's going in COMPLETELY the wrong direction.
The problem is the #define statement. In proper C++ code, you should never use preprocessor statements such as define except to affect the preprocessor. Doing otherwise leads to problems later on. For example, what if you wanted a for loop with a variable named i, so you type:
and get the errors:
Also, anything you #define is global no matter where you #define it.
The proper way would be to type out the 'long' version yourself each time. Yes, it can be tedious, but it is better in the long run because it will lead to fewer mistakes and the mistakes you do make will be easier to find and fix.
Other than that, the only real issue is that you probably want to use the 'string::getline' function to get strings (for example, "getline(cin, Class)", because it allows for spaces. If you just use "cin >> class", and the person types "Forest Ranger", it will only pick up the "Forest" part and the next input will get "Ranger".
The problem is the #define statement. In proper C++ code, you should never use preprocessor statements such as define except to affect the preprocessor. Doing otherwise leads to problems later on. For example, what if you wanted a for loop with a variable named i, so you type:
for(int i = 0; i < 10; ++i){ cout << "i is now" << i;}and get the errors:
error C2143: syntax error : missing ',' before '>>'error C2059: syntax error : '<'error C2059: syntax error : ')'error C2143: syntax error : missing ';' before '{'error C2059: syntax error : ';'Also, anything you #define is global no matter where you #define it.
The proper way would be to type out the 'long' version yourself each time. Yes, it can be tedious, but it is better in the long run because it will lead to fewer mistakes and the mistakes you do make will be easier to find and fix.
Other than that, the only real issue is that you probably want to use the 'string::getline' function to get strings (for example, "getline(cin, Class)", because it allows for spaces. If you just use "cin >> class", and the person types "Forest Ranger", it will only pick up the "Forest" part and the next input will get "Ranger".
Author
ok thx :) im getting into classes now so at the time i coded I knew nothing of classes really :) but im just now getting to that chapter.
[Edited by - shadowrage on August 25, 2005 11:21:23 AM]
[Edited by - shadowrage on August 25, 2005 11:21:23 AM]
Heh, the other big problem is that you're going to end up hard-coding everything. Ideally, you'd want to have all of the gameplay stuff (ie, text) stored in a file which is read and interpreted by the engine, which does all the fancy work with it.
I wrote a text-based engine a couple of days ago (linky) and the system I designed had 3 classes - Events, the Effects of Events, and the Conditions for an Effect to occur. All the data is packaged in XML files, which get read and sorted into Event class instances (which contain Effects, which contain Conditions) and it all works out pretty well.
But yeah. When designing, first think of what you want the program to do, then design it around that. You can keep doing it as you are now (by hardcoding everything and making endless functions with the same general structure) or you can package the function data into a uniform type:
header - contains the what-just-happened stuff, ie "You walk into a room. There is a bartender."
prompt - contains the question, ie "The bartender asks, \"Would you like a rootbeer?\""
response - gets the response, and deals with it, normally sending you to another event which then prints the header, its prompt, etc.
You can see that each event is pretty simple, and since we'll have multiple events of the same structure, we can create a class to encaptulate the functionality of the event:
Whatever works for ya [wink]
I wrote a text-based engine a couple of days ago (linky) and the system I designed had 3 classes - Events, the Effects of Events, and the Conditions for an Effect to occur. All the data is packaged in XML files, which get read and sorted into Event class instances (which contain Effects, which contain Conditions) and it all works out pretty well.
But yeah. When designing, first think of what you want the program to do, then design it around that. You can keep doing it as you are now (by hardcoding everything and making endless functions with the same general structure) or you can package the function data into a uniform type:
header - contains the what-just-happened stuff, ie "You walk into a room. There is a bartender."
prompt - contains the question, ie "The bartender asks, \"Would you like a rootbeer?\""
response - gets the response, and deals with it, normally sending you to another event which then prints the header, its prompt, etc.
You can see that each event is pretty simple, and since we'll have multiple events of the same structure, we can create a class to encaptulate the functionality of the event:
struct cEvent { std::string header; std::string prompt; std::map< std::string, cEvent* > responses; };// you can see the responses can get a little bit// messier, but that's because you can have multiple// types of input. You'd then write a function to// generically take any event instance, and pretty// much run it:void doEvent(cEvent* event) { // input-output is abstracted to whatever you want // it to be; whether its a MUD or a console app io->output(event->header); io->output(event->prompt); std::string in; io->input(in); doEvent(event->responses[in]);}Whatever works for ya [wink]
Quote:Original post by shadowrage
#define p cout <<
...
p("")n n;
p("-------------------------------------------------------------------------")n;
p("DAVIONS VALOR - Into the Dragons Den V1.1")n;
p("-------------------------------------------------------------------------")n n;
According to the way you defined p, you don't need (and perhaps shouldn't use) parentheses because p has no parameters. This would be better:
p "" n n; p "-------------------------------------------------------------------------" n; p "DAVIONS VALOR - Into the Dragons Den V1.1" n; p "-------------------------------------------------------------------------" n n; #define p(x) cout << x
Author
wow thx for all of your input! this will help me in the long run! :D. I just want to ask one thing.. In all of your opinions which is better to program for? Dx or OgL?
I like OGL, but both get the job done... if you only plan on doing windows development that is.
I think OpenGL is a lot easier to learn because it much less verbose. The functions are named well: glVertex3f is a vertex of 3 floats.
I can't speak much on DirectX because I haven't used it very much. The little bit I tried left a very bitter taste in my mouth.
Most will say that you should learn both, and they may be right. But to start I say pick one and go with it. If you don't like it, try the other.
There is one (serious?) drawback to OpenGL. It is exactly as the name describes, a graphics library. If you are looking for something that will handle input, sound, texture loading, etc. in one package - look elsewhere. With OpenGL you will most likely want/need to use additional libraries such as SDL.
Hope this helps,
Sam
I think OpenGL is a lot easier to learn because it much less verbose. The functions are named well: glVertex3f is a vertex of 3 floats.
I can't speak much on DirectX because I haven't used it very much. The little bit I tried left a very bitter taste in my mouth.
Most will say that you should learn both, and they may be right. But to start I say pick one and go with it. If you don't like it, try the other.
There is one (serious?) drawback to OpenGL. It is exactly as the name describes, a graphics library. If you are looking for something that will handle input, sound, texture loading, etc. in one package - look elsewhere. With OpenGL you will most likely want/need to use additional libraries such as SDL.
Hope this helps,
Sam
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
