RPG Skeleton, Part 2 - The Entity, and a SpecType

This question is a followup to Simple RPG skeleton, Part 1 - The Character.

This is the second "part" of my development of this skeleton, and it now includes two new classes, Entity, and SpecType. The Entity class essentially serves as a base class for any character-like object, and has the following attributes and methods:

• name - The name of the entity.

• health - How much health the entity has.

• toString() - Return a string representation of the entity.

The SpecType class serves as a small utility class for creating number-related specs that apply to character-like object, and has the following attributes and methods:

• specValue - The value of the spec itself.

• changeValue() - Change the value of the spec, and make sure it stays in the range \$0\rightarrow\infty\$.

I'm wondering the following things:

• Should SpecType be an immutable class? Right now, it's just modifying itself when changeValue is called.

• Is the Entity class designed in an appropriate way?

• Am I following standard C++ practices?

entity.h

#ifndef RPGGAME_ENTITY_H_
#define RPGGAME_ENTITY_H_

#include 
#include "spectype.h"

/// 
/// A base class that represents an entity, and implements
/// some base attributes, like health or name, and a few helper
/// methods for apply damage.
/// 
class Entity
{
public:
    std::string name;
    SpecType    health;

    Entity(const std::string& name, SpecType health);
    std::string toString();
};

#endif

entity.cpp

```
#include
#include
#include "entity.h"

///
/// Constructor for the Entity class.
///
/// The name of the entity.
/// The health of the entity.
Entity::Entity(const std::string& name, SpecType health):
name(name),
health(health)
{}

///
/// Return a string value representing the entity.
///
///
/// This is mostly not used unless a raw Entity is being
/// used by itself, which should be very uncommon, or not
/// happen at all.
///
std::string Entity::toString()
{
return "Na

It's not much code, so there's little else to change or fix here. The only tiny mistake you made was forgetting to mark toString with const, so that it can be called on a const object, very tiny and easy fix:

std::string toString() const;
                       ^^^^^

And the same on the definition. I'm assuming you're already familiar with the meaning of const in a method, but if not, here's an explanation. In summary, a const method is not allowed to mutate the object, only to inspect its member data, thus callable if the object itself is const.

Right now, there's not much reason for the existence of SpecType. In my opinion, it does too little to be a separate class. Assuming you are already extending that class, then it makes sense, but otherwise, it is better to avoid predicting the future and don't bother adding boilerplate classes that end up unused.

The suggestion made by a previous answer to the other question of creating a template class was interesting because each template instantiation has a unique type, so that would prevent, for instance, mixing health with mana because those would be unrelated types. Going that way, then I'd say the template Spec type would be a nice addition, even if just as a tiny wrapper, since it adds type-safety to the code.

Commenting for auto-generated documentation

I get it that some companies really value generating documentation from comments in the code, but take a piece like this one for example:

/// 
/// Constructor for the SpecType class.
/// 
/// The value that the SpecType contains.
SpecType::SpecType(int specValue):
    specValue(specValue)
{}

What is that comment adding to the understanding of the code, that couldn't be inferred just by reading the code? Nothing whatsoever. And those XML tags are simply atrocious! They completely distract me from the actual comment text and code.

If you really must comment mechanically to generate documentation, then I'd suggesting using a better tool: doxygen.

Doxygen uses a less invasive markup than those XML tags (actually, you can choose from a few different styles), and more, it doesn't force you to exhaustively comment every method. Methods you don't comment are copied verbatim to the output doc, so obvious things like a constructor don't have to be commented with "this is the constructor for class XYZ".

StackExchange Code Review Q#102639, answer score: 3