When you first try to use Unity3D, it's a lot. You can't do anything are are blasted with new terms that make no sense. What is going on? The explanation is simple: Unity is made for professional game designers. They see how it takes 3 steps with crazy names just to turn something red and are like "good -- Unity does it the normal way".
What does that mean for us? Should we even be using Unity? Sure. It's good in a way. You'll be learning the real game designer way things work, not just some toy system. If you torture yourself figuring out Unity's 3D Scene window, you'll know how to use the one in AutoCad or 3DSMax. It's also good that it's easier to look things up. Most Unity terms are actually ripped-off real terms.
But, obviously, being made for pros has a big drawback -- you'll need a crash-course in game design to get started. Here's a very quick one:
You can grab any picture -- just JPG's or PNG's -- and use them in Unity. But games often prefer dimensions which are powers of two: 128, 256, 512 and so on. Width and height don't need to be the same -- 256x512 is fine. Other sizes will work but not as well (and Unity may complain).
Unity calls pictures textures. All games engines do. It's traditiional.
A picture trick for games is having transparant backgrounds. PNG's can do this. Suppose you need a red circle. Pictures are always rectangular, but you can draw a red circle and set the rest to be transparent. When you use it, you're placing a square [icture, but it looks like a circle. This same trick works for drawing arrows, or blades of grass.
A variant on that is partial transparency. It turns out that pictures have each pixel individually set from 0 to 100 percent see-through. We wouldn't need that for our circle, but for "ghostly fog" it's great. The edges are fully transparent, but the fog itself is partly see-through at different levels. Many special effects use this trick.
Game engines can also easily tint pictures. For real we'd make a white circle, then in the game "tint" it to whatever color we want (it works perfectly -- a white circle tinted red is prefectly that color red). We can tint real pictures, but not as nicely -- they mostly look darker and wierd.
We can also easily repeat pictures, called "tiling" (imagine the picture on a floor tile). You've probably seen this trick with game floors and walls. Without much trouble you could adjust a "wood" picture to repeat in both directions until it looks good on your wall or door.
For normal pictures people want the most pixels. Games are the opposite. Partly we don't want a huge download, but mostly it's that larger textures gum up the graphics card. So there's no point having a picture larger than 2048x2048 if that's the largest screen size. Likewise menu icons can be 512x512 or less, since that's as big as they'll ever be in the game.
3D shapes are called "models". That sounds right for cars or houses -- we're creating little models of them -- but even a simple square is called a model. People who make them are called 3D-modellers.
You can only put your pictures on very simple models, like Unity's cube or sphere. Other models need to come with pictures. A model of a cow might comes with white-cow and spotted-cow textures. Even if you have a great brown-cow texture, it won't look right on that cow model. You could use one of their pictures as a guide and attempt to draw your own, but that's as huge a pain as it sounds.
Animated models come with their own animations. You can't easily add more, or change them. A human often comes with walk, run and idle (standing around), then it depends -- maybe you get shoot, stab, throw grenade and die; or maybe 5 different dances.
To have any sort of picture, a model needs to be "unwrapped". Almost all models are, and usually say so. To have animations a model needs to be "boned" or "rigged", which means it has bendable parts.
Non-unwrapped models can still get any solid color. But they're rare. You might find a collection of non-unwrapped geomtric shapes. Any rigged model can also be posed by you -- bending the legs and things. And, of course, there are levels of rigging. A rigged cow's ears and tail may or may not be bendable.
Models are made either for games or movies. Movie "high-poly" models have as many triangles as possible to make them look realistic. Games "low-poly" models are the opposite -- as few as possible as long as they look decent. Most modles will say, or else check whether the wire-frame is thick with tiny lines.
Models not made for Unity are perfectly usable in Unity, but you may need to make adjustments. Unity thinks cows should be about 2 units long. Most other systems think 2000 is the correct size. That can be a big surprise, but setting a scale factor of 0.001 in the import settings completely solves it. Regular models also think +y is forwards, whereas Unity thinks it's +z. A non-Unity cow probably faces the wrong way. But we can also easily fix that.
If you want to try making models, it will take a while. Learning how to select verts, edges and faces is tricky. Extruding and subdividing take practice. You'll have to understand normals and edge support or else the lighting will look weird. Then you need to learn how to unwrap -- the theory behind it and how to make seams. It's fun, and not too bad for simple things, but it's a ton of work.
Moving around in a 3D editting window is a bit of an art. One trick is that, as everyone knows, RGB matches with xyz: the x-axis is always the red line, with green for y, and blue for z. Unity thinks y (green) goes up, while x is sideways (or east/west) and z is forward/backward (or north/south). But everyone also knows you can ignore that. 2D games often use x & y for the ground, despite what Unity thinks.
Every 3D program has a Local/Global toggle button. Global is obvious -- slide, spin or stretch on the real xyz axis. Local switches to the object's personal arrows. That seems weird, but if a car is aimed in some funny way, switching to local allows you to perfectly slide it "ahead" and back.
Objects in 3D worlds grow and shrink independantly in x, y and z -- wider, taller, deeper. For examples, you can make a barrel a little shorter, keeping the same thickness. Or one copy of a rock can be a little wider. If want a simple 2X-sized cow you'll have to stretch it by 2 in all three directions.
The main trick to navigating around is knowing the edit camera is always focused on something, and deciding what to focus it on. It's often staring into blank space. Spinning or moving just gives more blank space. The best way to find your game area is to select something (by name, from the side panel) and recenter your camera there. Then it's usually easy to slide in that general area. But if you want to get a good look at a nearby rock, recenter the camera on that. The spin and zoom will work a lot better that way.
The little 3-way arrow image is good for re-orienting yourself. Clicking the green y spans to a perfect top-down view, and so on. But it definitely takes practice.
Scripts are the most depressing (or exciting, depending) part . The "scripts" that make the game run are really just typed-out computer programs. Unity even uses C#, which is a standard business programming language. Writing game scripts is about 70% general computer programming, 20% "game programming" and 10% specific Unity add-ons. If you think you might want to be a computer programmer in a bank, this is great news -- Unity scripting will teach you that. But if you were hoping to pick up enough scripting in a few days to do simple stuff, it's terrible news. It seems like programming only for games should be simpler, but game inventory isn't that much different from real inventory; and knowing when someone passed a level is about the same as knowing when they passed their ethics training.
Unity divides the game into "scenes". They could be your game levels; or rooms (that thing when you walk into a door, the screen blanks for a second, and you're in the next room). You don't have to use them. In that case Unity says your game is in one big one (which it auto-creates). Putting the stuff you made into groups like this is common.
Things are editted one scene at a time. Loading a scene unloads the old one. Often when you can't find something you know you made, it's because you're in the wrong scene (sometimes you'll be in a new empty scene since Unity got confused).
Unity says the things in the game are called gameObjects, and what they do is in sub-parts called components. For example, when you click to create a camera you're really getting a generic gameObject with a Camera component. That seems silly, but it allows you to customize. Say you want a camera which also hears sounds -- add the AudioListener component. Want the player to hear sounds instead? Add the AudioListener to the player.
At first you don't need to worry about this -- Create Cube makes everything you need for a cube. But for later changes you may need to go to its components and add or remove some.
Assets are everything you can use to make things. GameObject vs. Asset can be confusing. Importing a car model creates it as an Asset, where it will stay. Dragging it into a scene creates a new gameObject using it. When you bring in a picture it's an Asset. GameObjects with components that want pictures can select it.
Scripts are nice excamples of this. They're just assets, sitting and doing nothing. If you drag a "wander around" script onto a few gameObjects, you get real copies of it, making those things wander around.
Particle systems are a standard game trick. They can fake fire, smoke, a stream of water, a puff of dirt, or the trail of a rocket. They create lots of moving small pictures, over time, always angled towards the camera. Adjusting how they move, spin, shrink and grow, and fade in-and-out is the trick to making them look good. Unity's particle systems work the usual way.
One of the main tricks with particle systems is using textures with transparent backgrounds. A fire texture might be a blobby circle with more and less transparent insides. Overlapping a dozen of those looks like a fire.
Games use a very strange word for semi-realistic rolling, falling and bouncing. They call it "physics". They have a built-in Physics Engine to handle it. It's pretty amazing. You can make some cubes, enable physics on them, and they magically roll around like real cubes. If you've seen Angry Birds, that's all physics engine. It's one of the easiest things to make in Unity.
The physics system ignores the visible shape of your object. You may have seen this in a game if you walked around an oddly-shaped bush and noticed it takes up a perfect circle. That invisible ball is the Collider. Every object that might ram something or be rammed needs a collider to tell the physics ssytem what shape it counts as.
Ball and box colliders are common since many objects are mostly round or mostly rectangular. More complex objects can use a combination: two boxes can make an L-shaped collider; a ball with a small box can make an apple with a stem.
The official name of the physics system is Rigidbody Physics. Rigidbody means the computer isn't able to bend or smush objects -- they're rigid. To partly make up for this the system allows us to connect objects using various joints -- springs and hinges and such.
Many game engines use invisible areas called Trigger Zones. These don't block morement. Instead they tell you when something enters, leaves, or stays inside. A typical trigger zone can be set to do damage, like for an area of fire (you provide something that looks like fire, but the box-shaped trigger zone does the real damage). Unity has these, but they're a type of collider. Also, since it's Unity, they have no built-in damage or anything else. You need to code their effects by hand.
This is a mix of terms from before, but written out as definitions, plus some new technical terms you might run into:
Don't use the pre-made shapes
You're allowed to use Unity's cube and sphere, and they're fine as stand-ins, but they aren't good enough. Consider the cylinder. It has 20 sides, which looks pretty round, but you may want 32 sides to make it look even nicer. For far-away columns you may want 6-sided ones to save the CPU. Unity's cube has sharp edges. You may want them beveled with slightly rounded edges. You may also want a different unwrap, letting you put different pictures on some sides.
Don't use the built-in Ariel font
You can, but people will notice and it will look lazy. Loading another font is a pain, but not too bad. It requires True Type fonts, which your computer has. They end in dot-TTF
Don't use the built-in textures
Unity provides generic textures for buttons. They work, you can use them, but for a real game you can do better. That "fuzzy circle" for particle effects isn't all that bad, but your custom-made textures will be better (for example, a wavy outline, and more swooshiness inside).
It only has to look right
Most things in games use cheats. For example, a life bar should be split green/black. But actually making a single 2-color bar is a pain. It's easier to make a full-sized black bar with a shrinking green barover it. That looks like a single 2-color bar, so it's fine.
For a flame zone we'd use a big particle system to show the flames and an invisible trigger zone to do the damage. The fire isn't really doing the damage, but it's fine.
Particle systems are great
The starting particle system looks like garbage -- a bunch of white blobs blasting out. But you can use your own textures, change how many and the size and speed, add gravity; tweak colors; have them grow and fade; spin. They can make all sorts of things: fireflies, rocket exhaust, ground mist, a leaf pile being jumped into.
Multiple particle systems can do more. A waterfall can use one for the main part, another for the big splashes at the bottom, and a third for the big water mist.
Physics engines are finicky
The physics system works so well it's easy to forget it's just a program. It tends to freak out in some situations:
Billboards and partial transparency
Many things which are mostly flat can be just a picture drawn on a flat square: hanging moss on the sides of a cave or spiderwebs or sun-shafts (set to be very transparent). Anchor chains can use this trick (if you only see them from a distance).
Unity's line-renderer draws ugly long thin squares with bends. But if you give them a texture with the sides fading in, you get a cool-looking beam.
Tiling is tough but worth it
To make a brick wall we only need a smallish picture of bricks with the sides matching. We can repeat it in both directions to get bricks over the whole wall. That works for grass on the ground, or a wooden plank.
But making a good-looking "tilable" picture is a lot of work. First you have to match the edges by shifting the image as you make it. But the main problem is that bad patterns just appear. When you see your picture tiled 10x10 often one little part sticks out and ruins it
The ground can't have caves
Unity uses standard no-frills terrain, common in many game engines. It's a big grid of points which can only be raised or lowered. There's no way to make a cave or an overhang. But it's great for making a large area with hills and slopes and nicely mixed grass/dirt/rock textures.
I made a red box, but it looks really dark now
That's due to lighting. A scene has at least one light which acts like the sun. If it's at a steep angle then flat parts of the scene will be darker. Or the light's intensity could be too low. Or the background light, called Ambient, could be too low.
There's no perfect starting values for these since game designers often put several lights in the scene, carefully adjusted.
How do I put a 100% pure red dot on the ground?
Tell the system it's not a real thing in the world by turning off lighting. Do this by switching to a "unlit" shader.
It actually makes a lot of sense. The system assumes things are in the world. Your dot is a red dot painted on the ground. It uses lighting and shadows and diffuse and specular to make it look real. It has no way of knowing you want a pure red "marker dot" unless you tell it by switchng to that shader.
What's with powers of two for pictures?
Pictures in games are drawn at all different sizes, often smaller. To help with that, game texture systems pre-make pictures at half-size, quarter-size, all the way down. 256 is good for that since it divides evenly down to 1. The trick is called Mip-Maps.
Do we need the physics engine to make things move?
Most movement is done by scripts, especially regular smooth movement. For example, platforms in a platformer which need to have an exact pattern are moved using code.
"Physics" movement is only good when you want realistic complicated movement and don't care too much where it goes. Many games will never use it.
transform.position.x += 1 should add one to x, but it's an error
Yes, it should. Unity does a few tricky things behind the scenes. 99% of the time Unity scripts work exactly like real programs. This is the 1%. You can only set x, y and z all together (the manual shows how). But it's not so weird -- it's a get-reach-through bug, which is a real thing in C#.
JPEG's can have transparency, why can't they in Unity?
The "good" transparency is set for each pixel, and only PNG's have that. The graphics card is wired-up to read from it. JPEG's fake transparency by agreeing that one exact color is fully transparent. No one making a game would want to use that when PNG's are so much better, so it's not even in Unity.
Exactly how do I paint a red dot on the ground?
First realize you can't just put pictures in the scene. You have to put them on models. So first add a "quad" model (a simple flat-square 3D shape, just 4 corners).
Next realize that you don't put pictures directly on models. Models only have Materials. So create a new material, select your dot texture in the slot for textures, and put that material on the quad you just made. Easy, right?
Can I use a shader to mix two pictures?
Yes. Shaders can do fancy stuff like that, and more. It turns out Unity's standard shader has slots for 2 textures. If you use the second one, it blends them 50/50. You can even give them different sizes.
Can I use a shader to mix pictures with a slider for the percent of each?
Sure, but you'll have to write it. You can find the code for a 50/50 mix, find the line that mixes them ... a lot of little details. Or you may be able to find a visual shader editor. Or find someone who knows how to write shaders. It's one of the easier things to make a shader do.