Unity: understand components with a falling cube
Build one small physics experiment and see the different jobs performed by a GameObject, renderer, collider, and Rigidbody.
First Play Studios · Edition 1 · Updated November 14, 2026
A cube falls onto a floor, and you can explain why it is visible, why it moves, and why it stops.
Before you start- An existing Unity 6 3D project
- A new scene you can change without affecting your real game
In this guide
An object is a container for capabilities
A Unity GameObject holds components. Its Transform records placement; other components contribute functions such as drawing or physics. Looking at the component list is often more useful than guessing what an object does from its name.
Think of this lesson as a controlled experiment. You will build a floor and a cube, then change one property at a time. There is no character controller, inventory, or score to distract from the relationship between appearance and behavior.
Assemble the experiment
Create a Plane named TestFloor at position (0, 0, 0). Create a Cube named FallingCube at (0, 3, 0), with scale (1, 1, 1). Confirm the cube has its Box Collider and the plane has a collider. Add a Rigidbody to the cube, keep Use Gravity enabled, and leave Is Kinematic disabled.
Position the camera so the floor and cube are visible in the Game view. A scene can contain the correct objects while its camera points somewhere else. Save the scene before entering Play mode. In a fresh run the cube should fall and settle on the floor.
Predict, change, observe
The Rigidbody lets the physics system move the cube; the colliders describe the shapes involved in contact. A mesh alone does not make a solid barrier. Gravity also needs a body that is allowed to respond to it.
Stop the run before changing your saved setup. Turn gravity off for the cube, run again, and compare with your prediction. Then restore gravity and repeat. Treat a test as evidence about one configuration: a successful cube drop does not prove a character controller, moving platform, or networked game will behave correctly.
Explain three different failures
- Build the scene and record the cube’s starting height before Play mode.
- Run once with the listed configuration and note where the cube comes to rest.
- Stop, disable gravity on the cube, and run again. Predict the result first.
- Restore gravity. In a separate saved copy, disable the floor collider and compare the result.
- Restore the working setup and write one sentence each for renderer, collider, and Rigidbody.
Check your result.
- The working cube drops and is supported by the floor.
- Turning gravity off changes the result without making the cube invisible.
- Restoring the saved working setup reproduces the original result.
Common mistakes to watch for.
- Do not mix 2D physics components with this 3D exercise.
- A camera problem and a physics problem require different checks.
- Do not assume temporary Play mode edits became saved scene edits.
Keep the conversation useful.
I’m using Unity 6 and testing a cube above a plane. Here are the exact components, Rigidbody settings, positions, and observed result. Help me distinguish a rendering issue from a physics issue. Suggest one reversible change at a time and explain what each test can prove.
Sources & version notes.
Unity 6, checked against the 6000.0 manual. Documentation-based exercise; not run in the Unity editor.
Further reading from the original documentation:
Practice times are estimates. Software-specific exercises are documentation-based unless their version note says otherwise.A question or a small win?
Tell the workshop what happened when you tried this guide. Ask for a useful next step, or share something you got working.
See discussions about this guide We’ll include the guide link in your draft. Sign in to post, then add your own question or progress before sharing.