House Escape -- an old-style Adventure Game

[Dilbert]

Hello,

one of my big projects while trying to learn C++ is to create a command-line driven game. It didn't have to be huge; it just had to encompass a good deal of what I know about C++ as an OOP language. This project is nearing completion, and when it does, since I feel I must share something of the scale it's become, I'll release it for play. It probably won't get much attention, but I really don't care.

The main reason I'm going to do this is to get advice on how to improve. I know that online tutorials and instruction books are no match for formal training and, of course, experience. I can't do the first until college, but the second I can get now.

So, the first order of business is to head off this kind of comment: "Why did you use ABC to accomplish this? XYZ would be much more efficient."

Chances are, I haven't seen it before. So if there's an easier way to do something, let me know, but don't ask why I didn't use the most efficient method. My blanket answer is that "I didn't know you could do that..."

*ahem* That aside, next thing is to say what the program basically is and how far I am in completion. The basic premise is that the player is in my house, and for reasons that are disclosed in-game, has to escape it. The geography of my house perfectly matches the one in the game, but in order to make the game challenging, I've had to delve into complete and utter fantasy to keep this from being a 5-move game. It's just one abnormal... entity... of sorts, but it dramatically alters the game. (In retrospect, I wish it was that easy now... this is getting big...)

The game is command-line driven because I don't know how to GUI program yet, and because I can't think of a use for a GUI in this game.

As for writing the game, I am about 80% complete. The commands, their consequences and how they interlink is set up. The big portion of the remainder is writing the command parser. There are only 11 items, but writing every way the player interacts with them and the environment is a pain in the *censored*.

Another hurdle is writing a tutorial. I'm not about to allow my command parser to grow to the point that I have 10 different commands that boil down to the same thing, so I'm having specific commands -- and ONLY these specific commands -- work. To compensate, I'm going to write a tutorial that should make it easy to know how to do something in this game.

In summary: I'm writing a game, it's not done, watch this thread so you can play(test for bugs) and give me coding advice when it is done.

Est. Completion time: 1 week
Accuracy of completion time estimate: Microsoft
Size of project: 48 KB (source code)

[fffreak]

I hope all goes well, as I look forward to seeing this. By the way, are you teaching your self C++, or are you taking a class?

8-)fffreak

[Dilbert]

I plan on going to a class in college, but for now all I've got is a C++ for beginners book and whatever I can find on the Internet (which is a lot!).

Hopefully, the source code will not look like I'm such a beginner (I plan to release it). As it is, the project is getting big.

I'm writing the parser right now, which is adding several hundred lines to the code. I'm up to 1656 in escape.cpp and 371 in escape.hpp. The parser isn't even half done. And I still haven't written int main() yet. Though quite frankly, that won't have much purpose other than to get the player started.

More fun facts:
Classes: 12
Functions: 119

UPDATE 7:00 PM GMT-8: The parser is done, using 592 lines of code to parse 72 commands, not counting the fact that I have several different ways programmed to do the same command (I shouldn't, for example, penalize someone for trying "turn on light" rather than "turn light on").

UPDATE 7:52 PM: int main() has been written. The length of escape.cpp is now 2110 lines, with more to come as I add more functions, fix problems I know exist, and do a final code check before I let the compiler spew errors at me. (Come on, how can a project this big not have code errors?)

Items left on to-do list: 11
Expected time to do next item: 2 hours
Sanity: 0%

[Sidewinder]

with more to come as I add more functions, fix problems I know exist, and do a final code check before I let the compiler spew errors at me.

Waiting until the end for a compile can be overwhelming and very disheartening. If you write your program modularly, I suggest you compile after each function is complete and fix the errors as you go. One advantage is you can concentrate on the logic more and not the syntax so much.

Just a thought.  8-)

[Dilbert]

Trouble is, the only code I'm actually concerned about is the code that links up with other classes and their member functions. I'd have to make a mock class system just like the one I'm making, and that would be equally time-consuming.

In a normal program I couldn't agree more. But a game, the way I have it, won't work with that very well. I wish it did. Oh well, good to know for next time.

[Neil]

OK the impression I get is that you're writing code but have yet to test if it works? Please tell me that is not true...

Also that seems like a very large amount of functions. I don't want to rain on your parade (I've never used that phrase before) but I have a feeling your code is too specific and not very modular Ask yourself this question: after completion, how easy would it be to add a new possible command, or a new room? If it would take hours of function writing and modification..... well at least you have learnt for next time

I look forward to seeing your code!

[Dilbert]

It is true, I'm afraid.

As for adding new commands, or a new room, that would be easy enough. In fact, that's next on the agenda; a couple of new commands that hopefully add a little to the game.

However, adding a new room is just a tad more time-consuming. Erring on the side of allotting too much time per task, setting up the class in the header with all the needed function prototypes would take about 15-30 minutes, depending on the number of objects. Implementing the room would take about 5 minutes per function. Getting other rooms to "hook up" to the room would take about 30 seconds per room that needs connection (copy-paste, change the target room).

Assuming an average of two objects in a room, and one way to implement each, creating a new room should take, at most, an hour.

Addressing the large number of functions: It's not as much as it seems. I can break it down:

The first obstacle is leaving my room. The player needs to collect two items, after doing one thing, and use them, in order to leave it. There's also a function designated to an action that seems reasonable, but won't, in this game, work. That's two items to put in inventory (one func each), one func for the first action needed, one for the action that doesn't work, and two each to implement the items. That's 6 functions right there. Then, there's the one to leave my room, making 7. Finally, there's a "description" function for a "look around" command, private variable accessors, and the constructor and destructor. That makes 14 in the first room.

However, not all the rooms are this intensive. The Guest Bathroom, for example, has only 7, including constructor, destructor, and all item or room-related functions. I think that one's got the fewest functions.

Actually, I think [game detail hidden] is the room with the fewest functions; it's actually got 12 total, but 4 or 5 are, like any command-line game, red herrings.

On average, I have about 9 functions per room, including every way to use an item, the constructors, etc.. However, I've got 11 rooms going, here. That makes appx. 99 functions, and let's not forget the parser which is the backbone of the whole thing. In the interest of making the code easier to read, it's one parser/room. No big deal, it just takes more space that way. (And also solves the problem of a command doing one thing in one room, and a totally different one in another room.)

Sorry to rant, I got carried away. Anyway, I'm getting to it again.

[Neil]

Oh dear.... I hate to break it to you, but your design sucks You have basically hard-coded all your rooms and actions and now you face the consquences. Never mind a function for each item, you should have one function for all items....

[Dilbert]

I'm not quite following you, here. :-?

[Neil]

I'll wait til I see your code, then see what I can suggest

[Dilbert]

Sounds good. I am looking for help, here, so as soon as it's done I'll take all the help I can get. It probably does suck, though.

[Dilbert]

Oookay, I knew that my code sucked, but this is ridiculous. I got a thousand errors, and I'm rewriting.

EDIT: Before I go on, I should ask: If I have a member function of class X, how can I access the member variables of class Y? That seems to be a place it was hanging up the compiler.

[fffreak]

Neil is right Dilbert, when writing a program, you should perodically compile it, to make sure there are no errors, then fix any errors as you go along. Sorry I am a noob at C++ so I couldn't really help you with that, now Java on the other hand I could help you with.

[Dilbert]

I found out one of the big problems. A little late, but I did.

As it happens, I needed to access an accessor in another function in an if statement. Trouble is, I was doing this:

Code: [Select]

class X
{
public:
   //Other member functions
   bool getVar() const { return theVar; }
   //More stuff
private:
   bool theVar;
};

class Y
{
   //Stuff
   void myFunc(); //Obviously, I wouldn't ever use these classes and function names.
};

...

void Y::myFunc()
{
   if(Ben.getVar())
   {
      //Stuff
   }
}

...

int main()
{
   X Ben;
   Y George;
   George.myFunc();
   ...
}
Imagine my frustration when I found out that I only needed to do this:

Code: [Select]

class X
{
public:
   //Other member functions
   bool getVar() const { return theVar; }
   //More stuff
private:
   bool theVar;
};

class Y
{
   //Stuff
   void myFunc(); //Obviously, I wouldn't ever use these classes and function names.
};

...

void Y::myFunc(X Ben)
{
   if(Ben.getVar())
   {
      //Stuff
   }
}

...

int main()
{
   X Ben;
   Y George;
   George.myFunc(Ben);
   ...
}
I was doing that originally, but I forgot why after a week-long break, so I removed them as I couldn't find a reference on it.

However, I discovered this a little late: I'm sick and I was upset, so I ended up using Shift-Delete on the hpp and cpp. Smooth move, Dil-man.

I have a backup from my flash drive (yay!) and I will have about 70% of what I wrote back. But I'm isolating and testing the tBedroom sequence now in a separate hpp/cpp combo. I think this one will compile. As it were, I lost a good chunk of my parser and int main().

This supports Scott Adams' theory:

"People are idiots. That's everyone, not just the people with low SAT scores . . . idiocy is a condition that people slip into and out of every day.

--Scott Adams, The Dilbert Principle

As it were, I've got the cold and the flu, so debugging my bedroom will wait for a while. I've got all day tomorrow... I'm staying home sick.

[Neil]

You need this: http://en.wikipedia.org/wiki/Test-driven_development