Thread: Tried to create a basic RPG-Need help with Class/Subclass System

Hey I'm learning C++ by teaching myself. I purchased a book and it was pretty helpful but it doesn't go too in depth into subjects. I previously have experience with C and a little Objective-C experience.

I tried to create a basic RPG text game using classes in order to understand the concepts better. I created a class for the player and a class for monster, and I created a battle system for them to fight, die, etc. However, they only interacted when I entered a code for them to both fight.

How do you create a map? Is that a class of its own with monster and player being a subclass? Or is it completely different?

Do you need a separate class for movement?

Please let me know whatever tips and knowledge you have related to concept. I don't want any code or anything, just explanations so that I can do this right. I learn by example.

Thank you for your time and help.

I think the only way to help you is to ask and have you answer more specific questions.

Hey I'm learning C++ by teaching myself. I purchased a book and it was pretty helpful but it doesn't go too in depth into subjects.

Which subjects?

How do you create a map? Is that a class of its own with monster and player being a subclass? Or is it completely different?

If you're creating a text based RPG, why do you need to represent a map? You won't display the map, so as long as you can describe where the player, things, and monsters are, you might be fine. You should organize how you want that to happen. You could have a narrative class that receives input from the other program objects that triggers the display of prepared flavor text, et cetera....

Do you need a separate class for movement?

What does movement mean in a text based RPG?

Thank you for replying!

Originally Posted by whiteflags

I think the only way to help you is to ask and have you answer more specific questions.



Which subjects?

It goes in depth about the basics of C++ like variables and arrays and such, but I'm already pretty familiar with that from C so it wasn't too difficult to grasp the concepts. However, it was too brief for my liking in the Class and Abstraction chapters. It discussed basics like class syntax and class friends etc, but it didn't really go in depth with examples that will help to solidly illustrate teh subject.

If you're creating a text based RPG, why do you need to represent a map? You won't display the map, so as long as you can describe where the player, things, and monsters are, you might be fine. You should organize how you want that to happen. You could have a narrative class that receives input from the other program objects that triggers the display of prepared flavor text, et cetera....

Well map wise what I mean is if you tell the character to move to certain rooms, certain rooms will have treasure, whereas others will have monsters, etc. I have no idea how to design it so that it knows where the current player is in relation to the monsters and all. So a narrative class would just be another class that isn't a subclass of anything? And it would receive positional inputs from the player class? So what you're saying is that I should add to the player class so that it has a position attribute? Or is position a subclass or another class entirely? See where I get confused!

What does movement mean in a text based RPG?

By movement I just meant like, going into another room, into a dungeon, towards treasure, and so on.

It's ultimately up to you how you abstract away concepts into classes and how these classes interact with each other. There exist good design principles to be followed, but not one correct way to do things. It is, of course, good to look at the work of others (if possible) to see what has come before and its advantages/disadvantages, etc.

Originally Posted by Time Traveler

It's ultimately up to you how you abstract away concepts into classes and how these classes interact with each other. There exist good design principles to be followed, but not one correct way to do things. It is, of course, good to look at the work of others (if possible) to see what has come before and its advantages/disadvantages, etc.

Do you know of any good examples? I'm trying to follow proper design principles so that I will have a good foundation to work with later on. This is only a personal project that I'm doing so that I can learn and reference from.

It goes in depth about the basics of C++ like variables and arrays and such, but I'm already pretty familiar with that from C so it wasn't too difficult to grasp the concepts. However, it was too brief for my liking in the Class and Abstraction chapters. It discussed basics like class syntax and class friends etc, but it didn't really go in depth with examples that will help to solidly illustrate teh subject.

I see. See if you can find any material in the recommendation thread to pick up. The thing is, your book discusses what keywords and syntax mean, and you need to understand more object oriented design.

Well map wise what I mean is if you tell the character to move to certain rooms, certain rooms will have treasure, whereas others will have monsters, etc. I have no idea how to design it so that it knows where the current player is in relation to the monsters and all. So a narrative class would just be another class that isn't a subclass of anything? And it would receive positional inputs from the player class? So what you're saying is that I should add to the player class so that it has a position attribute? Or is position a subclass or another class entirely? See where I get confused!

Welcome to programming! Addressing these types of problems before writing any code is normal. You have to understand before you can do it. So you're on the right track, and like Tclausx says, there is no one way and it's really up to you.
There's a lot of thought put into good design before you even type a keyword and it can be quite formal (with charts) before you understand enough to do anything. This is normal.

I would start by just doing what you understand. You said that the narrative class would be a class by itself, and you would keep track of where the player is with position data. Let's tackle each thing in turn. The narrative class is just a class that prepares output for the human player and displays it on the screen. I gave the earlier example of reading flavor text from a file (room descriptions....) That's a class because it has a clear job to do and it encapsulates part of our program data.

But there's more to a game then stuff a DM would say. So now you ask yourself, well how do I want to record position data? I'll give you a possible answer. Maybe each room is a grid and you have names for all the cells in the room, like a really big chess board. You can scatter riches wherever you like on the board. And if the player heads through a doorway then you have to, maybe, read a file and make a new room before the player enters. This should make it clear at least what interacting with the surroundings entails.

By movement I just meant like, going into another room, into a dungeon, towards treasure, and so on.

Well movement sounds like something the player object would do instead of movement being data that you need to store. This is pathetically brief but if we go back to the grid map I talked about earlier, a lot of object oriented design is deciding what objects to make out of program data, and what each object can do with its data. For example, the player object "moves" in our RPG by updating his position data. That could be a member function for the player class. Our grid map is the state of the game. You could dump the object in a file to make save states.

Once you have that all planned out you get to think about things that act against the human player....

As a piece of advice, if you aren't clear how a feature helps you, such as friend attributes, don't force them to be a part of your class design. You can do a lot with few features in C++.

If you are thinking about using inheritance to represent all of your RPG classes or types you might want to think again. If you are thinking about embedding objects in your map as your map data you also might want to think again.

In my opinion there is not enough difference between classes of characters to warrant a huge hierarchy of classes. Remember that classes should be about behaviors, not about roles. Fundamentally the behavior of a wizard or a warrior is no different. They both plod through the world and kill other characters. They may have different abilities but at their core they do the same exact thing. You could easily represent their different abilities via a small compact data structure like a struct and use values to represent the various traits and abilities. In most RPGs all characters have the same traits and ability set just in varying quantities. A wizard can cast spells better b/c his/her mana value is high and their spell modifier values are high as well. A warrior still has mana but it may be at zero and his/her spell ability may also be at zero. The UI could filter this information and choose not to display mana if it was at zero, etc. The options here are endless.

A 2D game map at its simplest is an array of numeric values. It is up to you to determine what those values mean. They could index into an array, vector, or list of rooms. They could serve as the key to a std::map which then exposes more data. I would only use the latter if you had a system where all rooms were unique b/c otherwise the key,<value> concept does not make any sense. You could also represent a map as a linked list of pointers, a tree of pointers, etc., etc. There are a million representations and all will work just fine but they all have their advantages and disadvantages. What ultimately decides your approach is your design and the requirements of your game.

So in the end both answers come down to the design of your game and the requirements therein. Take a step back and do some design on the game and how you want it to function and play out and you will gain a much better understanding of what objects you need, what their responsibilities will be, and how they will relate to other objects.