Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm looking for a common dictionary of terms (much like design patterns have a common language for how things interact) that are specific to games.

For instance, if I'm making a game of pong with a high level of complexity, I want to name things accordingly.

I've seen some visual objects that a user can interact with called a widget, some non-interactive ones called a doodad (back when I played with starcraft map editor anyway). Is there a proper name for the frame rate clock? Is there a proper name for the game clock (the clock that is about the movement of objects in the world but not the visual drawing)?

I just want a dictionary so I can speak the same language and not make up things as I go. I'm concerned I'm going to create things named doodads, whosits, whatsists, and flim-flams... and I don't want to do that.

share|improve this question

closed as not constructive by Nicol Bolas, Sean Middleditch, Tetrad Jun 14 '13 at 22:42

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

These names vary by region, company and developer. Most of them are made up and are often just synonyms for "thing".

Create names that describe the purpose of the code. A frame rate clock is called a frame rate clock. There's no dictionary for these things. You can't have a dictionary if the objects you're describing don't have a firm definition. The objects used in game development change from game to game. It depends on the game being developed for what functionality needs to be implemented. The objects being created are frequently specific to that game. Just call them what makes sense.

share|improve this answer
A frame rate clock could also be called a draw frequency display. We often don't realize for how many things we use domain specific phrases. – Philipp Jan 20 '13 at 17:14
Sure, I've never heard it called that and using display in the name, to me, means it will be shown on screen, but if that makes sense to the developer, then use it. We can make up dozens of names for the same thing. It's just important to be consistent and use names that convey the purpose of the object. – Byte56 Jan 20 '13 at 17:20
I upvoted this and now you have 25k rep! Congratulations! :D – Doorknob Jan 21 '13 at 0:11

I guess what you're asking about is a glossary for the programming side of game development. I don't think one exists, which is certainly a shame.

Incidentally, a widget is a term that has come over from GUI development. I've never heard the term doodad before in a technical context.

share|improve this answer
Blizzard used to (and may still) use the term doodad to refer to certain types of elements in level builders – Brian Webster Jan 21 '13 at 6:00
Yes, the OP said he encountered it in a Starcraft context. I've never heard of it anywhere else though. – Kylotan Jan 21 '13 at 13:22

Literature might be your best source of info if you want to find the usually-accepted terms for the things of game development. A good reference for that might be, this isn't a dictionary but it should give you a starting point.

share|improve this answer

For strictly UI purposes (interactive items), both Control and Widget are very common. Component is also getting popular, though that by itself is confusing for today's frequently component-based game object systems. Using classes like UIControl, or using namespaces, is a good idea to clearly identify what you mean.

For items in the game, the most general term is Game Object. These are often all Entity in code, but GameObject or even GO aren't uncommon. Game engines that are strictly 2D sometimes just call all game objects Sprite, which is a little inaccurate, but works.

Where possible, name objects based on what they are or do, not some clever short synonym. In the worst case, if you pick a bad name and are using a large-project-friendly language, it's trivial to just rename your classes and instances if you decide a name is too confusing.

Really, internal consistency in your own project is more important. So long as you use naming styles and conventions consistently, and document what the purpose of everything is, you'll be fine. It doesn't matter if you call every game object a PeaPod (obviously a dumb name) so long as you clearly document in your Getting Started manual and supporting references what a PeaPod is. So long as the name isn't outright misleading (don't call your renderable mesh object a PhysicalBody for instance as that implies physics rather than graphics).

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.