0
\$\begingroup\$

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?

\$\endgroup\$
2
  • 3
    \$\begingroup\$ Game code is no different from "real life" code, any OOA/OOD reference is good. \$\endgroup\$ Commented Dec 25, 2011 at 7:37
  • \$\begingroup\$ Entity is a slightly better name than Object as the latter is normally a reserved keyword or at least implies top level container for all objects in a codebase. \$\endgroup\$ Commented Jan 12, 2017 at 8:03

2 Answers 2

Reset to default
4
\$\begingroup\$

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.

\$\endgroup\$
0
\$\begingroup\$

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

\$\endgroup\$
8
  • \$\begingroup\$ My apologies. I did not mean that I asked it on an SE site. I asked in a chatroom full of programmers, informally, and got directed to a reference site. Also figaza's question was regarding the naming of classes and subclasses and subclasses of those subclasses, and I suggested that the asker instead use properties. Through personal experience, the first step to naming something is to figure out where in the hierarchy it should go. \$\endgroup\$ Commented Jan 12, 2017 at 1:56
  • \$\begingroup\$ The other downvote probably comes from the fact that what you're suggesting is not a good idea. A lot of people will suggest to get away from inheritance, they'll suggest composition over inheritance to avoid messy inheritance trees, which can become real hells to work with. \$\endgroup\$ Commented Jan 12, 2017 at 3:05
  • \$\begingroup\$ But that is literally what I was saying! Move away from inheritance (subclasses) and towards composition (properties that add behavior). Also, funny enough, that is the page I had looked at and couldn't remember where I had seen it. Should I edit my answer to say "For example (of what not to do):"? \$\endgroup\$ Commented Jan 12, 2017 at 3:14
  • \$\begingroup\$ The answer is better now. \$\endgroup\$ Commented Jan 12, 2017 at 3:28
  • \$\begingroup\$ IMO, the main issue I found with this answer still remains. Despite the impression that you are "answering the question, directly" there is far more explanation of structure than actual naming convention. I feel this would confuse or offput users. \$\endgroup\$ Commented Jan 12, 2017 at 3:37

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.