Unity Glossary in Layman's Terms

I’m having a really difficult time learning the language of Unity and IT jargon in general.

In order for me to learn, I need to be able to clearly translate each term into a definition I’d be able to understand plainly and at its simplest, most concise form.

For example:
Collider: something that determines how objects interact with the world.

I don’t need anything specifying that the objects or the world relate to gaming and/or Unity because the context is already there and those things come implied with that context.

I’m creating my own personal glossary to reference back to whenever I come across anything confusing while playing around with Unity.

Would any of you be willing to contribute to this thread with at least one layman’s term definition for something commonly found and used in Unity?

Any and all help would be greatly appreciated!

… are you sure about that? “most concise form” may result in lost information.

You can look up every things you do not know, that will lead you to its documentation and the documentation will explain what that thing is.

https://docs.unity3d.com/Manual/CollidersOverview.html

1 Like

I’m sure about it, yes. That’s how I learn new words, even in other languages. That link you’ve sent me is one I’ve seen a hundred times and I always feel my brain turn to mush afterwards ahaha

… My point was that meaning of words is not precise to begin with, so trying to reduce things to one concise definition might not be a good idea. As you might end up missing details.

For example, in english “cat” refers to a certain cernivorous mammal, to an animal from certain family of mammals, but can also refer to a a unix-like command-line tool, act of using that tool, to a brand of heavy machinery, to a person, and also to certain type of fish… depending on context.

Now, of course, software frameworks usually have fairly strict definitions, but still, it is possible to omit a detail.

Also, it would be a better idea for you to ask questions about specific definitions rather than asking people to define everything in the engine.

1 Like

On one side I see point of OP.
Sometimes we need very childish and basics explanation, what thing does. But that is to understand very basics concept and get hook point, to expand upon.

This is very bad description of collider however, as it tells us nothing, what it is. Or how it interacts. Also, colliders don’t necessary have to interact with a game world. They can be used for UI, or just player’s raycast.

On other hand thing is, same as in any type of profession, we learn terms and definitions, as are used in given environment. Being to vague, leads often to ambiguity in meanings. But giving descriptive explanations and examples, brings better picture of the subject.

Then another thing is, for many things, once read once, we probably get idea how thing should work. From that point, we need look for details and possibly syntax / API, in case of programming.

Lets look into Lerp as an example.
https://docs.unity3d.com/ScriptReference/Vector3.Lerp.html

In layman terms (it is there already):

Expanding upon:

And then there are code examples.

So in this case work is already done, for what OP requires.

Consider the fact, that there are tons of terms, that can be put into “layman” way. Question is, does anyone want to go that route? For most, you probably read once, while writing about it, catch what is about and never need to look again into it. Rather willing to look into docs for more details.

Also, searching for “Unity what is xyz” give alternative explanation of things. Which also helps to understand subject better from different angle.

2 Likes

I think it will end up being frustrating and wasted time.

What is important is how things interact with each other. What depends on another thing. This gets too complicated.Human brain can’t hold that much info. So we put it into manuals. As long as you can search you dont need to worry about knowing everything.

What can be reduced and explained simply is the end user experience. FOr me it helps to describe that completely because it is simple and I can visualize it. Then figuring out what nuts and bolts are necessary to make it happen it more manageable.

1 Like

On paper this might sound like a good idea but it’s a very bad one. For starters, human language is not the same as working with a computer. With human language you can largely get away with just the words and the brain will be able to interpret your meaning but a computer needs the grammar to be precise or it won’t be able to understand anything you’ve given it and you can’t learn grammar by reading the dictionary.

4 Likes

And it’s not just important “for the computer,” but also for the designer.

Let’s say I have a square block and I want it to constantly rotate to face the player. How do I do that? If I were using the definition in the OP, I’d say “I use a collider, because a collider is something that determines how objects interact with the world.”

But of course the definition is too open-ended to actually be useful, and thus that wouldn’t solve my problem (it doesn’t even make any sense).

I need to know specifically what each thing, be it components in Unity, API commands in programming, or grammar in regular language, whatever, means so that I can express myself properly.

4 Likes

In human languages it is recommended to learn phrases, due to differences in grammar rules and the like.

Nope.
“Collider is an invisible shape attached to an object which determines that object’s boundary for the purposes of collision detection and/or physics.”.

Frankly, you should start asking questions about specific terms.

2 Likes

Did you already see the official glossary?

8 Likes

That’s kind of fun:

o Mesh: a 3D object (made of connected squares and triangles, often rotated and bent)
o Model: same as a mesh, but sometimes “a mesh with all the extra stuff”
o Texture: a picture. Any jpeg, png … is a Texture

  • Alpha / Alpha channel: the transparency of each part of a texture
  • Shader: a special graphics card program to manipulate textures “live”: It can animate, combine or add to
    o Material: added to a mesh to give it a color. Often includes Textures and a shader
  • Specular lighting: advanced Material feature to make something look shiny
  • Diffuse lighting: basic Material feature “parts are darker if facing away from the light”
  • Bump map / Normal Map: an often blue-ish texture telling a shader how to make a flat area look bumpy
    o Unwrap / unwrapped: optional part of a model allowing a texture to be drawn on it
    o Bone/Rig: added to a model to allow parts to bend / move. Required for most animation.
  • skin / skinned: another word for the mesh of a boned/rigged model
    o render: draw on the screen (using the mesh, bones, material, lights … )
    o LOD: Level of Detail: an advanced trick for drawing far-away models with less detail to speed up rendering
    o Billboard: drawing a picture on a flat square, for speed. A low LOD billboards trees

o Particle System: special effects created by spraying small textured billboards

o Physics / Physics Engine: an automatic system which can move, spin, slide, bounce objects (like Angry birds)

  • rigidbody physics: same a Physics. The simplified physics used in all games where we assume things can’t flatten, bend or crush – everything is a “rigid body”
    o Joint: a physics connection between objects. Allows them to drag each other
    o ragdoll: something made of several objects connected by joints, made to be shoved so it flops like a ragdoll
    -kenematic: frozen. A physics object with the physics temporarlity frozen
    -asleep a physics object which hasn’t moved in so long the system has stopped checking to see how it moves

o GameObject: a “thing” in a Unity game
o Component: anything which can be added to a GameObject. Unity doesn’t have different types of gmeObjects. Instead gameObjects have different components saying what they do
o Script: a component, which is a program written by you

  • Monobehaviour: another word for a script
  • Mananger / Controller: an infomal term for a script which tells several gameObjects what to do
  • Singleton: an informal term for setting up a script with data every gameObject or scene can share
    o Rigidbody: the component turning it into a Physics Object
    o Collider: a component giving the size it counts as for physics. Often about the same size as the mesh, but simpler
  • Basic collider: a geometric shape described with math and settings
  • Mesh collider: a hand-made collider
  • Compound collider: a collider created by combining several basic colliders
    o Trigger / trigger zone: a type of collider that does not block movement, but which wills tell you about overlaps
    o Raycast: a script can look in a direction (cast a ray) and find which colliders or triggers are there

o Scene: like a game level. A “folder” of created gameObjects
o Asset: anything which isn’t a gameObject: textures, meshes, audio files… . Things in the Asset panel
o Prefab: a complex gameObject converted into a ready-to-copy Asset. The primary way Unity games make things

  • Instantiate: general term for creating a gameObject. Also the name of the command to spawn a prefab
  • Spawn: informal word for Instantiate

o Quaterion: a 3D rotation
o Local: coordinates xyz relative to something else: either a parent, or your personal spin
o Orthographic: a “flat” camera setting with no 3D perspective
o Canvas: a required holder for 2D gameObjects, A component

3 Likes

I understand why people would want this, but I don’t think it will be as helpful as they initially think. The issue is that technical terms and “jargon” exist because they are useful and often necessary. They refer to other knowledge that you still need to have.

The given definition of Collider is indeed easy to understand, but it also doesn’t tell you much. What kind of interaction does it relate to? The same words would also be true if applied to other, completely different things. For example:

Material: something that determines how objects interact with the world.

So I’d at the very least suggest a new definition of Collider:

Collider: Data which describes the shape of a GameObject when checking to see if something collides with it.

If you really want this in layman’s terms then you can swap “GameObject” for “object”, but that’s losing some important context. Those words mean different things, and if you’re working in Unity then the meaning of “GameObject” is one of the first things you need to learn.

3 Likes

The real thing would be an Intro to Game Design. But Unity has no reason to write that. They’d have done it years ago if they wanted to.

Their paying customers have always been people who already knew game design, switching to Unity. And education on “Basics of Game Design” isn’t something Unity Co. is good at. They tried a little with Unity Learn – ugg. Microsoft is a good comparison – “How to use Excel” and “Using Windows like a Pro” books are written by 3rd parties. Unity teaching game design is like an auto-dealer starting a Driver’s Ed school to help it sell more cars.

Six years ago, to be precise.

6 Likes

I don’t see the stuff raised in this thread as being about “game design” anyway.

Game design is about what the game should do. Everything I see here is about how to make it do it. Which is its own design discipline, it just isn’t game design.

A game designer must somewhat understand the underlaying tech his design will require.

I notice this alot at my day job, a UX designer that understand underlying tech is alot easier to work with than one that do not understand/care about the underlying tech

1 Like

For sure, understanding your medium in technical detail will help significantly. Note that game design could just as well apply to board games, role playing, escape rooms, etc. where the medium is completely different.

Game design is about figuring out what your game must do to have the desired impact on players. If you’re making a digital game then software engineering is where you figure out (most of) the technical implementation.

I say “most” because art and other areas will have their own “engineering” aspects, too.

All of which is super useful for newbies to have explained. Hmm. Definition?

Game design: The art of deciding what a game must do to achieve the desired impact on players. This includes things such as the game’s rules, level designs, and controls. It often also works along with visual and audio design, writing, and (for video games) software engineering, among other skills.
Level design: An aspect of game design where the individual levels or areas of a game are designed.

(There are a bunch of other areas, too.)

Software engineering: Designing the technical details of how something should be programmed, including how related resources or systems are integrated and managed.

2 Likes

To me it’s about what completely new users ask here: how to change color or add a jpeg, why they fall through the floor, how to get info on script commands such as Unity’s special if-else. Call it “Into to Computer Game Making” or whatever. An outline of the technical parts.to make reading the manual easier.

Those Extra-Credit videos are a good example of the problems. A 3rd party, making what they want, on their site. It’s a fun video, but it’s just “start small, read tutorials, here are the basics of Agile”. It answers maybe 0.5% of common questions from new users.

A bump-map is typically grayscale, and the value determines how high the bump is. The “blue-ish” texture you are thinking of a normal map, which details the normal of that point of the UV map that correlates to the model. They both serve the same purpose generally, but work very differently.

3 Likes

That leads into a slippery problem with “intro” stuff. It’s so easy to add more and more detail to where it’s no good as an intro. Like where Wikipedia pages have one weird super-technical section, or sometimes immediately list every type of something before explaining what it is.

Hmmm…I want to get across the idea that some jpegs are just a way to store 2D data, and give 1 idea of how shaders and materials can do relly fancy stuff. “Normal map” and “bump map” each end in :map" (which may later help when they see shadow maps). Both terms seem equally common. I think I’ll change it to: “bump map / normal map:” Thanks.