C++ Text RPG - Commands and their output

Question

Synopsis

So far i tried to make games and most of the times i finished on having 'engines' ready. Not the games at all. I figured out that after having rendering, music, i/o handling, all that stuff ready i pretty found myself already burned out and having no idea what the game was about i wanted to write.

And in my at least 10 years of hobby gamedev i completed 10 engines but not a single game.

I got to know OpenGL, GLES, LibSDL and even low level frame buffer rendering - however that knowledge is nothing if you can't get your game out.

I wrote my own GL based UI systems, even coded my own scripting language, coded multiplayer tcp/udp client-server game system, coded level editors, model viewers, mesh exporters, ray tracers and tons of shaders. Meantime i worked on other things too - not related to gamedev (like Distributed Computing Libraries, Algotrading stuff, lot of IOT, exploits, machine learning algorithms..) and i finished them all, but still i come back to try to write a game and i fail.

Why?

After so many years i try to answer this question and i think the reason of me not being able to finish a simple game is because i always somehow focused on the engines, core but not the actual game itself.

It's like knowing all about how the game should be running so that you actually see it on your screen with top performance but when you ask me how does these two characters will fight - i would answer - you need to figure it out.

Today

This time is no different. I told myself i will write a game - 'simple' text RPG, no graphics at all - plain text, should be easy - no need to focus on anything but text - easy huh?

No

I just finished to build the scratch of the backend of the game, have the Rooms implemented, Entities, Parsing the input, Json loader, saveing, loading, inventory, commands interpreter and what? Well im stuck.

Problem

Imagine i have the following structure:

CEntity (base class for all entities)
CEntityItem
CEntityDoor
CEntityRoom
CEntityCreature
CEntityCreatureCow
CEntityCreaturePlayer
CEntityCreatureHorse

CCommand (base class for all commands)
CCommandLook
CCommandWalk
CCommandXXXX

The game 'engine' does nothing special, basically it goes endless loop asks for user input, passes the input into command and prints out the return

pseudocode

while(1) {
// Returns a vector of strings, users input split by ' ' space   

std::vector<std::string> vCommand = GetInput();

// Go through the available commands and see which fits

for(;;;)   
{           

         if(m_vCommands[a]->GetCall == vCommand[0])

         printf("%s\n", m_vCommands[a]->Handle(vCommand);   
}


}

And when a player types in (example)

Command: look

What i do is just go through the available commands, check which does it fit and pass it as

std::string strOutput = pCommand->Handle(std::vector<std::string>& rvstrCommandArguments);

A proper command object gets called out and performs action - in this example Look, returning a string that is then printed on players screen like:

Output: You look around and find nothing

Other examples of commands i am thinking on top of my head will look like:

fight <name>
craft <empty> - for a list of available options
craft <axe>
hide <where>

Just want to keep it simple to finish it this time.

But here comes the question,

Is it fair to keep the output of the command that should be displayed to the user within the command class itself (just as i do) ?

For now it's simple, but later i will add some text formatting (colors and stuff).

With my OOO approach 'everywhere' sometimes i feel i am overcomplicating things and trying to search for better solutions to problems that do not exist.

Answer 1

Is it fair to keep the output of the command that should be displayed to the user within the command class itself (just as i do) ?

Maybe. Yes in some cases, no in others. You've shared a lot about your architecture but nothing about the purpose so it's hard to answer with specificity. Code exists to accomplish a goal, not just to be good code, so the goal should be foremost in all your design decisions and is a critical component of asking good questions. :)

If you're concerned about hypothetical "code purity" or about "large scale maintenance" then, in one way, y is merging in two responsibilities to a single piece of code: a Command hypothetically should only be concerned with parsing input and dispatching an Action. Some other module should be responsible for consuming Actions, mutating game state, and dispatching Events. And finally, an output module should be responsible for consuming Events and producing the final output text. Note that I didn't call out specific classes or interfaces, just general concepts.

Now, here's the counter point to the above: that's all a crapload of heavily-abstracted OO code that is borderline "architecture astronauting." If you have a lot of complex interactions between different unrelated code modules, if your code is particularly large, and if you are working with a large team, then that kind of design can help. If you have a simple single-player text adventure game you're working on by yourself, that all would very probably be a mass of over-designed obfuscation of what should be fairly a simple input-update-output loop. One could argue in that case that what you have already even falls into that case, but it's hard to say without knowing all the details.

In terms of your question, what all that means is: use the simplest solution that will work. If outputting text in your Command object is simple and it works, just do it. Don't over-complicate. Don't design for problems you don't have and very possibly never will have.

TL;DR: make it as simple as possible but no simpler. :)

With my OOO approach 'everywhere' sometimes i feel i am overcomplicating things and trying to search for better solutions to problems that do not exist.

The most important thing to remember about OOP is that objects/classes exist to model isolated functional behavior, not to model real-world taxonomies. If something could be a function or a simple piece of data, just do that. OOP's power comes from modular composition of complex behavioral components. OOP's weakness comes from Java-style "everything's an object stuffed full of interfaces and getters/setters" (which a lot of folks these days confuse with OOP itself and think OOP as a whole is bad; that's just as wrong).

As a complete aside: that systems-Hungarian naming scheme in your sample code is killing me. There's literally zero good reason to prefix class names with C or to prefix variable types with type information. Unless you're working for 1990's Microsoft, nobody wants to work with code written like that. :)