naming conventions in game code / vocabulary

Question

I'm just starting out as a game developer, and I'm finding some difficulty when naming classes.

I usually call the class that handles everything World, Map, or Grid. Then there's the names, inside.

---

For example, I'm making a Frogger clone, and I have a class for everything that moves on screen (I try to use MVC and I'm talking about the model here - I have Sprite classes in the view), and I named it Object for lack of a better name. Then there's a subclass from Object which I named Frog (though I could name it Player) and another one for the things controlled by the computer, which I don't know what to call (it could be Enemy or Obstacle or something appropriate for cars and trucks). This class also includes the turtles, which are more like helpful objects, yet are not powerups.

---

How should I manage my naming conventions?

Answer 1

If you're having trouble naming things it's probably because your class design itself is messy. Just hearing you talk about your code it seems like you're overusing inheritance.

Also, there are a ton of questions on here about MVC and generally speaking it isn't a good pattern to try to force into things. Gaming is more like Model view viewmodel than mvc anyway.

I don't think there's a specific reference for what you're looking for. Also, in general SE sites are better if you ask specifically what you're looking for instead of a reference for what you're looking for. For example, draw out your specific class hierarchy and ask what might be the best way to name your obstacles-that-also-can-be-useful, or whatever.

Answer 2

Tetrad is correct that your ideas seem a bit messy at the moment. But to answer the question more directly (small picture rather than big picture) for those who come hereafter:

Typically you want a few classes with a lot of properties, rather than subclasses. Here's a wikipedia reference someone gave me when I asked this exact same question like 4 days ago in a chatroom. (Thanks Alex, for helping me find it again).

For example (of what not to do): Among the entities we've got Frog, Truck, Land, Water. Land and Water are stationary, or static. Frog and Truck are moving, or dynamic. So we could make Static and Dynamic subclasses and put each one into those classes. On the other hand, both a Truck and the Water will kill you. Maybe Water is Dynamic, instead? Water and Truck are both in the Enemy class? Well... no.

It's better to use properties on the various entities. Frog and Truck have the canMove property. Truck and Water have the killOnContact property.

To Clarify and make Direct You'll find that it's easier to come up with names for the behaviors and features and what not, than it is to come up with a single category in which something should go. (The same reason each SE site has tags rather than categories).