Naming convention problem

Hi. I have several mini games in a game. I am gonna implement Daemon class but the problem is that the daemon class is completely different from each other.
So I should use namespaces to prevent conflict or use different class names like
DaemonInFireGame
DaemonInBubbleGame
DaemonInFPSGame
...

 

And what's the question or concern?

 

how should I call classes
your approach when you face in this situation

 

I always use namespace.

 

Either I didn't understand the question, or namespaces are not necessarily what you're looking for in this particular case.

What's the defintion of a "Daemon" in your context? What's its purpose? Which logic is driven by the daemon?

 

Yes you are right. I do not need to call it specially maybe
One Daemon in one special game has to move and comes out from a grid.
Another one executes one special animation and the other one moves into the player (path finding and tracing) and etc
I can call more generally like Mover and Animator and Tracer
but suppose I have different reward panels with different rewards and items that player can get them.. but can handle with breaking to smaller and more general codes?

 

So it's some sort of controller that drives/controls/coordinates different components/subroutines that can be overriden (inheritance) or composed (composition, component based) ?

What does one have to do with the other? I'm not sure how you associate the class types or their implementation with reward panels.

For a mini game, the daemon could just act as the controller and coordinator. Kinda-like the "engine" that issues calls to referenced components, like updates, transitions etc. You could implement this a some sort of state machine.

I'd probably build this by referencing small mini-game components rather than subclassing the daemon. This allows to combine various of these small components, link them to an instance of the mini-game-driver (daemon) which in turns handles the general updates.

Look at it as if the daemon was an interface to a self-contained mini-game subsystem. For instance, the daemon could have events like "MiniGameCompleted", "MiniGameCanceled", "RewardReceived"...
This does clearly seperate concerns, i.e. it does allow the components that speak to the daemon to define, react and process the results rather than having intrusive logic within the daemon and/or within the mini game components.

Having intrusive logic within the daemon - by intrusive i'm referring to application logic that is not an actual concern of the subsystem itself - you'll find yourself defining a lot of stuff redundantly, you couple these components to systems they wouldn't need to care about at all and you will also recognize soooner or later, that you need to change or subclass these components just for slight differences in behaviour... That's usually not desired and a very dirty way.

 

Thank you. So you say that we should not put a special name for classes?

For example in clash of clans or RTS games, we do not have names like BarbarianAttacker or BarbarianMover etc?
Instead we have OnGroundAttacker,InAirAttacker: To attack enemies
Walker,SnakeMover, Flyer, WaveUpDownFlyer , etc? : To move entities
ClosestEnemyFinder,MaxHitPointEnemyFinder,MinHitPointEnemyFinder,etc : To Find the enemy(target)
or for stateController we must not have DaemonStateController or BarbarianStateController etc?

So when we face to select special name, we should care that we are wrong?

 

No, that's not what I said.
If you work alot with inheritance, you can do that. However, you always have to check if it makes sense to do that.
I would always try to save inheritance for situations in which it does actually make sense.

You certainly don't need to specialize types at all. A Unit can always just be a Unit, differences in behaviour can be modelled as pluggable components. E.g. you don't need a GroundUnit, AirUnit, HybridUnit and all sorts of combinations. Instead, you can simply go with a Unit and reference a MovementController, an AttackStrategy and such. This greatly reduces specialized type defintions and helps to seperate concerns as you can build all combinations by throwing components together. Hence it's also very flexible and it scales extremely well.

As for a the RTS example though, I'd go with a subsystem that updates components of the units, the typical ECS approach. It's more efficient and you'll have some centralized control over everything.

 

Yes but my question was about naming convention.
When I want to implement a class that it implements special movement, I need to create a class right? I do not want to discuss about interface. Therefore I need to put a name for it. Should I call it based on the behaviour even if it is completely special and complex movement?

 

As I said, it's up to you. You can do that, there are no common conventions other than choosing a self-descriptive name within the context of your domain, which is the best you could do with this approach, of course.

My point was, that - in general - this leads to the question whether it is a good way to deal with it. I wouldn't try this approach and look for more flexible and extensible way, that I mentioned above, i.e. that special movement could just be moved to another component, because that's a clear seperation once your system grows larger and needs more variations.

In the end it's up to you.