#Need your ideas

72 messages · Page 1 of 1 (latest)

sudden wave
#

so im creating a console based game and i want it to be fast. i want to make the option of changing the stats, how can i do it without a lot of IF statements

balmy valeBOT
#

When your question is answered use !solved to mark the question as resolved.

Remember to ask specific questions, provide necessary details, and reduce your question to its simplest form. For tips on how to ask a good question run !howto ask.

sudden wave
#

Stats.h :

# 
#include<iostream>
#include<fstream>

#include"jsonExtractor/nlohmann/json.hpp"


using json = nlohmann::json;


struct Vigor
{
    double Health;
    int Stamina;
    double StaminaRegen;
};

struct Intellegnce
{
    int AbiliyPower;
    int AbilityPenetration;
};

struct Dexterity
{
    int Evasion;
    int Accuracy;

    int AttackDamage;
    int AttackPenetration;

    int CritChance;
    int CritRate;
};

struct Endurance
{
    double Armor;
    double MagicResist;

    int IceResistance;
    int WaterResistance;
    int LightningResistance;
    int FireResistance;

    double WeightCapacity;
};

struct Luck
{
    int Luck;
};


class StatsManger
{
private:

    

public:

    Endurance* _Endurance;
    Dexterity* _Dexterity;
    Luck* _Luck;
    Intellegnce* _Intelligence;
    Vigor* _Vigor;

    StatsManger(const char* ImportPath = "nopath")
    {
        _Vigor = new Vigor;
        _Endurance = new Endurance;
        _Dexterity = new Dexterity;
        _Intelligence = new Intellegnce;
        _Luck = new Luck;

        if (!ImportStats(ImportPath))
        {
            return;
        }

    }

    ~StatsManger()
    {
        delete _Vigor;
        delete _Endurance;
        delete _Dexterity;
        delete _Luck;
        delete _Intelligence;
    }

    //json
    bool ImportStats(const char* Path);
    bool ExportStats(const char* Path);
};```
#

Stats.cpp :

#

Entities.h :

# 
#include<iostream>

#include"Stats.h"

class Entity
{
private:

    StatsManger* EntityStats;
    const char* StatsPath = "Stats.json";


public:

    Entity()
    {
        EntityStats = new StatsManger{StatsPath};
    }

    ~Entity()
    {
        EntityStats->ExportStats(StatsPath);
        delete EntityStats;
    }

};

class Player : public Entity
{
private:

public:

};```
#

so i need your ideas for the stat changing

vast pond
#

if you want things to be fast stop allocating them with new

#

you're 1. adding extra indirection 2. doing unnecessary memory allocations

#
  1. you're adding in extra need for destructor calls to clean up the memory
sudden wave
#

where should i not use it

vast pond
#

every use you have for new is incorrect

#

they should all just be regular values

#

not pointers

sudden wave
#

why

vast pond
#

for the reasons I gave earlier

#

basically not doing it is just better

sudden wave
#

when should i use new

vast pond
#

ideally never

#

since any use-case for new that has special lifetime requirements can be fullfilled by the smart-pointers or containers

#

let me demonstrate with your entity class

sudden wave
vast pond
# 
class Entity
{
private:
  StatsManeger EntityState;//not a pointer
  const char* StatsPath = "Stats.json";

public:
  Entity() : EntityState(StatisPath) {}//no longer need a `new`, can just construct in the initializer list

  ~Entity() {
    EntityState.ExportStats(StatsPath);
    //no longer need to delete, which you might forget
  }
}
sudden wave
#

how did you make it with colors ?

balmy valeBOT
#
How to Format Code on Discord
Markup

```cpp
int main() {}
```

Result
int main() {}
Note: Back-tick (`) not quotes (')
sudden wave
vast pond
#

you should always prefer values first

sudden wave
#

why there is the new keyword if its not good

vast pond
#

and then if you need to you can allocate stuff

vast pond
#

its just not for this

#

it allows you to manually manage the lifetime of an object, instead of it being scoped. Which is useful. Its just not what you were doing

#

If you find yourself writing a class which just allocates in the constructor and then free's in the destructor ... you probably didn't want to use new

sudden wave
#

in C it has a lot of benefits over none dynamiclly allocated variables

vast pond
#

I mean its the same benefits in c++ ...

#

You shouldn't malloc most things in c either

sudden wave
#

yeah

vast pond
#

its just inefficeint

#

and confusing

sudden wave
vast pond
#

which if statements are you worried about?

#

honestly nothing here is slow

#

except the file IO

#

which you can't do anything about

sudden wave
#

no like if a user wanna change a stat

#

i will need to do like if(userinput == stat) { change stat }

#

for almost every stat

vast pond
#

mhm

#

so

#

there are lots of "solutions" to this

#

but

#

you're best option is probably just to have an array storing all the possible names of stats, and then check against those in a loop

#

itll be the same as if you just wrote out all the if statements by hand

#

But its more extensible

#

You could use some form of hashmap. The problem is the theoretical speed you gain from that is offset by the real world slowness of random jumps and hashing

sudden wave
#

i saw that you can put functions as values in maps

#

is it a good thing to use

vast pond
#

probably not

#

people will give you different opinions

sudden wave
#

in general

vast pond
#

I would start of getting it working firstly with just the ifs

#

and then maybe turn it into an array if it gets unwieldy

#

but thats pretty much as far as I would go

#

you could use a tree or a hashmap (std::map or std::unordered_map) but realistically you're not actually gaining very much from that. it might look nicer but its often not actually better

sudden wave
#

basically the ifs are the best way for things like this

#

even if its a 200 lines of ifs

vast pond
#

okay no that counts as unwieldy

#

pretty much anything over 6 I would say "Yep now is time for an array"

#

But thats just my personal preference

#

If you know its going to be 200 and currently you only have 2 then you still might make it an array, since writing it twice is longer than just writing it correctly the first time