#include <iostream>
using namespace std;
class person {
private:
int lvl, sta, str, wis, agi, dex, mana;
}
class race : public person {
public:
char[] name;
char[] description;
void setlvl(int rlvl) {
rlvl = lvl;
}
void setsta(int rsta) {
rsta = sta;
}
void setstr(int rstr) {
rstr = str;
}
void setwis(int rwis) {
rwis = wis;
}
void setagi(int ragi) {
ragi = agi;
}
void setdex(int rdex) {
rdex = dex;
}
void setmana(int rmana) {
rmana = mana;
}
int getlvl() {
return rlvl;
}
int getsta() {
return rsta;
}
int getstr() {
return rstr;
}
int getwis() {
return rwis;
}
int getagi() {
return ragi;
}
int getdex() {
return rdex;
int getmana() {
return rmana;
}
}
Is this the right way to do this?
Author
Im making a text RPG, because I decided that was the next thing I should do. It's going to have 5 races, all better at something. There will be 5 different levels, along with mana. I'm in the beginning stages, and have planned a little bit, programmed a bit too. I just want to ask if this is the right way to go about making the person and race.
Adam
Inheritance normally models an is-a relationship; containment models a has-a relationship.
Is a race a person? No.
Does a person have a race? Yes.
Then person should have a race member variable.
The accessors / mutators should be in the person scope, for similar reasons to above.
Other than that : if you're C++ing, please (for the love of God) use std::string instead of char arrays.
HTH,
Jim.
Is a race a person? No.
Does a person have a race? Yes.
Then person should have a race member variable.
The accessors / mutators should be in the person scope, for similar reasons to above.
Other than that : if you're C++ing, please (for the love of God) use std::string instead of char arrays.
HTH,
Jim.
Author
Can i have a function like:
//code//inside classstring getname() { return wname;}//more code
Yup (so long as you're 'using std').
Another example would be (not that I'm advocating this, as there are several flaws in this code, but for illustrative purposes):
Jim.
Another example would be (not that I'm advocating this, as there are several flaws in this code, but for illustrative purposes):
class Race{};class Person{private: race myRace_;public: race GetRace{return myRace_;}};Jim.
Author
Hmm,
Also what about for an inventory, how can I make a limited array of "Items"?
Make like a int[49] array, and then make it null, until i point an 'item' to it?
like..
Also what about for an inventory, how can I make a limited array of "Items"?
Make like a int[49] array, and then make it null, until i point an 'item' to it?
like..
//code//My inventoryint[49] inventory;int item;inventory[0] = item;return inventory[0];
you should look into std::vectors. they are not very complicated and its best to start learning the good stuff as soon as possible. a vector is basically an array that can shrink and grow as you need it. its actually easier to use then an array IMO..
second, all those get/set's scare me. do you really need to expose all that data to the outside world? Gets() aren't too bad, but all those sets look bad. why do you need to be able to set those values from outside the class? for example, when a player creates a character, why not have the constructor for the class set all the initial data?
second, all those get/set's scare me. do you really need to expose all that data to the outside world? Gets() aren't too bad, but all those sets look bad. why do you need to be able to set those values from outside the class? for example, when a player creates a character, why not have the constructor for the class set all the initial data?
one of the most important factors of OOP is encapsulation. encapsulation means that objects only care about themselves, and not the outside world. "private" helps with this, in that it almost forces us to encapsulate our data.
think about a car. a car is made up of hundreds of different pieces that are all connected to each other. if one of these parts break, you only have to buy / fix that single part.
now, if the car was one big hunk of metal all welded togeather and connected, what happends when that one "part" breaks? your whole car is screwed, and you have to buy a new one.
the same thing goes for upgrades. if you want to change or upgrade one of the parts to your car, you only have to change that single part; if your car is one big mess all woven togeather, you have to replace the entire car just to change / upgrade a single part.
your game should be this car. each piece to your code should have a specific purpose, and not worry much about the other parts. if you ever have to change a part of your engine, you dont want to have to change your entire code base, you only want to change that single part that needs changing.
to be honest, if you are very new to C++, you dont have to worry about this too much. for now, just worry about getting things to work. you will learn more about how to write good code later.
think about a car. a car is made up of hundreds of different pieces that are all connected to each other. if one of these parts break, you only have to buy / fix that single part.
now, if the car was one big hunk of metal all welded togeather and connected, what happends when that one "part" breaks? your whole car is screwed, and you have to buy a new one.
the same thing goes for upgrades. if you want to change or upgrade one of the parts to your car, you only have to change that single part; if your car is one big mess all woven togeather, you have to replace the entire car just to change / upgrade a single part.
your game should be this car. each piece to your code should have a specific purpose, and not worry much about the other parts. if you ever have to change a part of your engine, you dont want to have to change your entire code base, you only want to change that single part that needs changing.
to be honest, if you are very new to C++, you dont have to worry about this too much. for now, just worry about getting things to work. you will learn more about how to write good code later.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement