I am making a racing game and I want to create a vehicle selection “menu”. I want to have multiple cars lined up in a garage and be able to sort through each of them, with the camera following. I have only found information about how to make a vehicle selection screen focused on one car at a time, so any help is appreciated.
To be clear, I already figured out how to load and position the cars the way I want, I just want to know how to make the camera cycle through each car.
Camera stuff is pretty tricky… I hear all the Kool Kids are using Cinemachine from the Unity Package Manager.
There’s even a dedicated Camera / Cinemachine area: see left panel.
If you insist on making your own camera controller, do not fiddle with camera rotation.
The simplest way to do it is to think in terms of two Vector3 points in space:
- where the camera is LOCATED
- what the camera is LOOKING at
private Vector3 WhereMyCameraIsLocated;
private Vector3 WhatMyCameraIsLookingAt;
void LateUpdate()
{
cam.transform.position = WhereMyCameraIsLocated;
cam.transform.LookAt( WhatMyCameraIsLookingAt);
}
Then you just need to update the above two points based on your GameObjects (in your case moving the look-at to the car, or near the car, and moving the look-from wherever you want it to be), no need to fiddle with rotations. As long as you move those positions smoothly, the camera will be nice and smooth as well, both positionally and rotationally.
How would I handle switching between cars in the menu? Basically I want to make it so that whenever you press ex. the right arrow key, the camera goes to the next car and the other way around.
This is all just basic character customization or selection screen tutorial stuff. It’s WAY more than will fit in this tiny text box!!
These things (inventory, shop systems, character customization, dialog tree systems, crafting, ability unlock systems, tech trees, etc) are fairly tricky hairy beasts, definitely deep in advanced coding territory.
The following applies to ALL types of code listed above, but for simplicity I will call it “inventory.”
Inventory code never lives “all by itself.” All inventory code is EXTREMELY tightly bound to prefabs and/or assets used to display and present and control the inventory. Problems and solutions must consider both code and assets as well as scene / prefab setup and connectivity.
If you contemplate late-delivery of content (product expansion packs, DLC, etc.), all of that has to be folded into the data source architecture from the beginning.
Inventories / shop systems / character selectors all contain elements of:
- a database of items that you may possibly possess / equip
- a database of the items that you actually possess / equip currently
- perhaps another database of your “storage” area at home base?
- persistence of this information to storage between game runs
- presentation of the inventory to the user (may have to scale and grow, overlay parts, clothing, etc)
- interaction with items in the inventory or on the character or in the home base storage area
- interaction with the world to get items in and out
- dependence on asset definition (images, etc.) for presentation
→ what it looks like lying around in the world? In a chest? On a shelf?
→ what it looks like in the inventory window itself?
→ what it looks like when worn by the player? Does it affect vision (binoculars, etc.)
→ what it looks like when used, destroyed, consumed?
Just the design choices of such a system can have a lot of complicating confounding issues, such as:
- can you have multiple items? Is there a limit?
- if there is an item limit, what is it? Total count? Weight? Size? Something else?
- are those items shown individually or do they stack?
- are coins / gems stacked but other stuff isn’t stacked?
- do items have detailed data shown (durability, rarity, damage, etc.)?
- can users combine items to make new items? How? Limits? Results? Messages of success/failure?
- can users substantially modify items with other things like spells, gems, sockets, etc.?
- does a worn-out item (shovel) become something else (like a stick) when the item wears out fully?
- etc.
Your best bet is probably to write down exactly what you want feature-wise. It may be useful to get very familiar with an existing game so you have an actual example of each feature in action.
Once you have decided a baseline design, fully work through two or three different inventory tutorials on Youtube, perhaps even for the game example you have chosen above.
Breaking down a large problem such as inventory:
If you want to see most of the steps involved, make a “micro inventory” in your game, something whereby the player can have (or not have) a single item, and display that item in the UI, and let the user select that item and do things with it (take, drop, use, wear, eat, sell, buy, etc.).
Everything you learn doing that “micro inventory” of one item will apply when you have any larger more complex inventory, and it will give you a feel for what you are dealing with.
Breaking down large problems in general:
The moment you put an inventory system into place is also a fantastic time to consider your data lifetime and persistence. Create a load/save game and put the inventory data store into that load/save data area and begin loading/saving the game state every time you run / stop the game. Doing this early in the development cycle will make things much easier later on.
Various possible inventory data structures in Unity3D:
I already have figured out 100% what I want to do; basically the player just picks their own car and an opponent and then the race loads. The race/spawning in player and rival car part is already done, the thing I need the most help with would be the visuals/camera.
This is more or less what I want the end product to look like:
For cycling through the cars I would probably just lerp the position and direction where the camera is facing to the next car, but I have no clue how I would handle the rest (car driving out animation, smooth camera turn around after it’s finished, etc)
I find this approach works great for these kinds of tasks: ask yourself “Can I … ?” and work from there.
Imphenzia: How Did I Learn To Make Games:
Two steps to tutorials and / or example code:
- do them perfectly, to the letter (zero typos, including punctuation and capitalization)
- stop and understand each step to understand what is going on.
If you go past anything that you don’t understand, then you’re just mimicking what you saw without actually learning, essentially wasting your own time. It’s only two steps. Don’t skip either step.
If you run into issues, here is…
How to report your problem productively in the Unity3D forums:
This is the bare minimum of information to report:
- what you want
- what you tried
- what you expected to happen
- what actually happened, log output, variable values, and especially any errors you see
- links to actual Unity3D documentation you used to cross-check your work (CRITICAL!!!)
The purpose of YOU providing links is to make our job easier, while simultaneously showing us that you actually put effort into the process. If you haven’t put effort into finding the documentation, why should we bother putting effort into replying?
I’m not a complete beginner to gamedev, just Unity and C#. Thank you for the information, next time I will try to report better.