Naming Conventions ~ It doesn't matter what they are as long as you have them

[Oafkad]

I wish I could say that the title was my thought. It was actually something said to me at work by our Technical Artist. The more that I've applied this world view the happier I've been with my work. With that in mind I'm going to go over the naming conventions for the current Moosecats work. These are listed in no real particular order.

Handlers

Our different domains have shared handlers. At the base level our handler does two things. It listens for a client and the game state. The former of these processes needs to eventually be moved one layer higher to a "ChattyMoosecattyHandlerBase". This is because we don't actually care about the client in Fitty Moosekitty or Moosecat Manor. But we do explicitly care about it in Chatty Moosecatty. Overall though the benefit of handlers is that they give shared base logic for all the related objects.

For Chatty Moosecatty we use the handler for all of the message and commands. But soon we will also have one for the individual moosecats. Each Handler should be dedicated to one particular domain.

Listeners

These are components that listen for Events. They can listen for multiple events of the same type to do numerous different things in response to different events. They also automatically listen and cease listening when a gameobject is set active or inactive respectively.

Events

Our classes largely communicate through events and Data Containers. The event tells you "when" to do something and the data container tells you "what" you are working with. Generally, sometimes Events also send data like the state change event or the client event (which sends itself).

State

This is the name for all of our state machines. Currently the only state machine we actually use is a game state machine. But certain things like Moosecats will likely have their own state machines. Generally these are hybrids of visual and classic scripting.

Data

This is a collection of Datums. Data is what you'd expect. Collections of a bunch of like items. We generally want to separate Data containers by the shared stats of their constituents. If you imagine a city builder, you might have lots of different buildings, but you would have power plants as one Data collection, Healthcare as another, Transportation, and so on.

Collection

Purely a cosmetic concept. These are Data that are related to the player. Think inventory, Moosecats, things like that. Calling them collections allows us to more easily search for them and makes class names a little less confusing. A collection also contains Datum just like Data, as functionally it is largely the same with likely some small specific helper functions for me.

Datum

This is a single unit of information. Think individual cats or individual items in your inventory. Or even individual players in Chatty Moosecatty.

Artifact

These are scriptable objects that allow us to share data between objects without direct references. This makes adding and removing sections of our project easier. So if an idea doesn't pan out we can remove it without breaking references across the project.

I Prefix

This one is a bit weird. But the I Prefix tells us that something is an interface. There isn't a really hard and fast rule for these interfaces. Mostly that they are I and some kind of verb or descriptive title. Think IListener, or ILoadsFromJson.

 

[Joe Mama]

Ha, handlers.

[Oafkad]

15 minutes ago, Joe Mama said:

Ha, handlers.

Funnily enough, I've always tried to avoid the term "managers" because they become catchalls. But unfortunately Handlers ends up doing that. A devil by a different name. My goal at the moment is to keep handlers at one or two precise operations so that each thing is compartmentalized. Otherwise you end up with monolithic classes.