Hello, I've started creating a text based ASCII art driven RPG as an extension of the C++ programming I've received at uni. Generally I would avoid using a forum on how to decipher what I've done wrong but I'm somewhat new to OO style programming and I would love some help.
I've created a list of variables in a base class (Player/Hero class) where all of them are being recognised in the associated .cpp file except a string array. A similar set of variables is in another base class (Enemy class) where it has no issues except for when I declare it above other elements where it seems to corrupt them. I'm unsure on how to allocate sufficient memory to allow for larger sprites.
// This is excluding functions/constructors
class HERO
{
protected:
std::string heroClass = "No_Class";
std::string heroName = "No_Name";
int heroExperience = 0;
int heroLevelUpExperience[10] = {0,10,25,40,60,80,110,140,175,210};
int heroGold = 0;
int heroLevel = 1;
int heroTotalHealth = -1;
int heroCurrentHealth = -1;
int heroTotalMana = -1;
int heroCurrentMana = -1;
int heroTotalEnergy = -1;
int heroCurrentEnergy = -1;
int heroDamage = -1;
int heroSpeed = -1;
std::string heroSprite[19];
};
Thanks if anyone is able to help, sorry I'm still kinda new to this
there are a few places your code could go 'wrong'. (the corruption you mention).
-- your heroLevelUpExperience array could be accessed out of bounds, corrupting subsequent variables.
-- your strings can go out of bounds, if you misused the [] operator, going out of bounds.
-- your array of strings could go out of bounds itself or in the strings via either of the previous 2 mistake types.
you should probably use vector instead of arrays. But even those fail if you abuse the [] operator...
I'm unsure on how to allocate sufficient memory to allow for larger sprites.
So you've made an array of 19 strings on the stack (unless you have further code in constructor that uses the keyword new?)
Each string can hold quite a lot of characters, so I'm not sure how you're running out of room, especially if you have nineteen of them...
I have these libraries in the .h file
#ifndef HERO_H
#define HERO_H
#include "Globals.h"
#include <string> and these in the .cpp file
#include "Hero.h"
#include "Globals.h"
#include <sstream>
#include <string>
The only time the above function is called is when I am drawing the combat interface here;
1 2 3 4 5 6
for (int i = 0; i < 18; i++)
{
combatHero.getHeroSprite(i);
printBufferSprite();
combatEnemy.getEnemySprite(i);
}
The strange this is that no other variable is having scope issues other than this one
heroClass
Is prompted to be entered by the user before object creation and defines which daughter class will be called heroName
Is also prompted by the user and is a parameter of the base class constructor
This is the declaration of the getHeroSprite function;void getHeroSprite(int spriteLine);
I printed the string in that way as my sprite wouldn't always be the same size so I had a loop in there to keep the sprite being less than 30 characters or so. I think that I must have overwritten the function with the ENEMY variant which doesn't need that.
After commenting out the little bit of Windows stuff (I'm on linux), it compiled and ran just fine for me.
I notice some strange things in the directory structure. There's an extra Hero.o file (in obj/Debug/Users/Jallan/Desktop/ActionRPG).
Try deleting all of the .gch files, .o files (including the extra Hero.o and Goblin.o) and the .exe and totally rebuilding it.
If that doesn't work, try moving all the .cpp and .h files into a totally new project. It might be better to do this anyway since something seems to have gotten screwed up in the directory structure.
Okay, I tried moving it previously but I must've stuffed that up, I'll try cleaning it up again. I was banging my head against the wall looking for issues in the code itself
So I cleaned up the files and moved it all into a new project. Seemed to find everything OK now and is running 100%. Should be good to go from here. Thank you for your help, glad to know that it wasn't me directly causing issues and is more so relieving to know what it was all along.