Three structure types

It looks like the way I'm programming is reaching some kind of goal with how I'm now using three types of "structures" to manage a large scale project. First is type-style class, a small class with often only one variable, or something like Point or Rectangle classes. Creating your own types should be a priority in object-oriented programming anyway so I'm creating them when it makes sense. Which is almost always over using regular types. A great example is Point class, it's way better to create a class that holds x and y variables rather than use them as integers.

Second type is a regular class, not a type class but larger with more data and components. These are things like monster, item and level classes.

Third type is a procedure, which in C++ is just a function outside any class. Somehow I find these really useful in parts where you need some kind of action with object instances.

With these it feels like nothing is missing and I'm able to manage the source code better than ever before. Also, I've largely began to disconnect classes from "modular" files. I find that modules are useful, but only when you have a small class hierarchy (inheritance) or similar types of classes. For example I have Point, Coords, Rectangle and some other similar classes in one file, because they inherit from each other. You need to include the base classes anyway if you want to use any of them.

The RPG system

Most of the problems in this project seems to be in developing the role-playing system. It's a "simple" concept, most RPGs have some variables like health that is determined by monster type or internal stat like strength. But it's still complex enough to actually implement a new system without just copying an existing one. Even when you don't use an existing system it's still probably going to have health, stamina and the usual suspects.

Maybe that's the issue I have with it, I'm trying to think about how not to create just another RPG system. One way to try is more "realistic" system which is always going to fail, because realistic games just don't work, the player character has no chance to survive for long in that type of game world. Yet, I think some developers are annoyed by the fact that RPG systems are simple in the outside and they make the gameplay feel too much like you are working with numbers, and tactics revolve around trying to figure out how much HP the enemy is going to take in one turn etc.

However if I want to finish this project it's largely depending on RPG system which I now know is the core of a roguelike game, while many developers like myself focus too much on game world development (random generation routines) and leave RPG system as an afterthought. In a way this has been even more difficult to me, because I never really was that highly tactical player that can squeeze everything out from the resources you have in the game. Maybe the gameplay could reflect that philosophy by reducing the amount of close combat or even creating alternative ways to handle combat situations. In most radical solutions you could remove "mandatory" combat and create safe areas in the dungeon you could travel, leaving combat as an optional feature.

Whatever the solution will be, I doubt it's going to be a basic RPG system with a basic roguelike game. I would hate to create a game like that while other developers are just fine with it.