Jump to content

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


Recommended Posts

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.

DataContainer

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.

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 Artifacts. 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.

Artifact

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

Stats

Stats classes are containers for variable information. Think players, Moosecats, Items, etc. A big benefit to having this information contained within a "Stats" class rather than as part of the base class is that we can save it to json easier. Similarly we can update from json easier.

I

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.

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...