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.


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.


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?


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.


Imagine i have the following structure:

CEntity (base class for all entities)

CCommand (base class for all commands)

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


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


         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.

  • 2
    \$\begingroup\$ I just want to point out when you say you will make your first game and have it be a simple text rpg, then you start talking about json parser, saving loading and inventory. I mean, if you have no experience in them, each one will require some efford to accomplice. I'd suggest making a very simple game, using only technologies you are 100% familiar with, so when you finish it you will have a finished game. On your next game, use technologies you are familiar with, but add one new one that you have no idea how to implement, and make that the focus of your new game. \$\endgroup\$
    – TomTsagk
    May 19, 2018 at 20:55
  • \$\begingroup\$ I feel like this is an XY problem. If your goal is to make a text RPG, you should make a text RPG, not an engine in which you could later create a text RPG. I would strongly recommend you pick up an existing tool for creating text games, either something simple like Twine, or something more robust like Inform (depending upon what type of text game you had in mind). Look at existing engines which do all the heavy lifting for you, so you can focus on making the game, which seems to be your actual goal, here? \$\endgroup\$ May 20, 2018 at 6:01

1 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. :)

  • \$\begingroup\$ amazing answer, thank you - especialy liked that about java :) for the prefixes, i just like them, always used them :) thanks again, i will keep on with the approach for this simple game. \$\endgroup\$
    – PeeS
    May 19, 2018 at 20:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .