I’m just getting started with Unity, although I’ve been doing development for a long time.
I want to make an endless driving game, but I’m not sure what should move and what should be static. Is it better to fix a camera to the vehicle and have it move through an endlessly-generated world, or to hold the camera and vehicle in place and move stuff past them? The former seems more logical, but will the engine continue to behave well even as the position vectors for all of the objects grow in one direction? I know that some physics engines only like their inputs to fall within certain ranges and I was wondering whether the Unity engine cares. Would the loss of precision for the float value ever be an issue? Of course this might require the game to run for a few weeks, but still, I’m curious…
With endless/infinite environments, I would personally either use a closed-loop environment (sphere/cylinder, depending on dimensions) and move the player, or, if that is not an option, because there should be no repetition, I would keep the player stationary (roughly) and move the environment (generating and destroying sections/areas outside of the FoV).
Regarding physics, it shouldn’t matter too much if the car is moving or the street…maybe you have to play around with some values…
well if you are new to unity it’s better to first understand it completely before making any game… this game would be the next step … you can also search the internet “how to make driving game in unity tutorial” it will bring you more than 5 tutorials and they are well explained…
this is the best way to start … cause as i see your are a little confused and you didn’t know what is your question
take one of those tutorials and if there’s any other question come and ask … and you will be answered and helped…
As some said before you better be off starting small. Try to understand Unity3D by doing easy tutorials, once you understand the way of programming you can go a level higher.
You might want to take a look at this tutorial to give yourself a roughly view on what you need to keep in mind when making a game. (It’s not exactly what you want, but it’ll give you a rough view into it).
I can assure you I’m not really confused, at least not about this. All of the car tutorials I can find deal with a fixed, pre-defined track. I’m curious about a game where the road is straight and is dynamically generated. I have all of this working, but I always like to understand all of the different options available for making something work and I was wondering if there is a best practice for this particular scenario.
I can actually verify that moving the scenery works perfectly well and the physics engine is fine with it. As I’m sure we all remember from physics class (unless we skipped out to play video games :P), moving is only a relative property and there is no difference between a car moving through a forest and a forest moving past a car. Physics still works even if I’m running on a treadmill. The Unity engine seems to handle this properly.
I’d be very curious to know how all modern physics engines for the last 25 years solve the problem that float values only have 7.22 units of precision, as described by the IEEE spec:
So in the example of an endless driving game, you can travel roughly 10,000,000 units before the precision along the axis that you’re moving gets worse than 1 unit, meaning that I suspect the collision detection would start to get more coarse and blocky. Of course the player would have to play for a loooong time before reaching 10,000km, so it’s probably more of a theoretical problem, but I can imagine making a similar game with a space ship or something that could travel much faster and cover that distance in a playable amount of time.
My answer concerns your approach more than the various realities of the physics engine, a topic a noob like me is poorly-equipped to address. But many games make use of arbitrary pit stops to reset some variables, flush caches, and do basic housecleaning.
The arbitrary way is “zoning”, where your screen freezes, you see some sort of progress bar, etc. You could reset your vehicles position to zero and take a snapshot of your environment and translate that to zero. You’d be recalibrating both the car and the forest, to use an earlier example.
This is a heavy-handed approach and might adversely affect the players “suspension of disbelief”. Perhaps you could perform the same trick by introducing gimmicks such as tire-wear requiring a player pull over at a tire shop every so often. This recalibration would take place when they reach zero speed. Throw in a cut scene to distract, etc. Fuel is also an expendable. Maybe the driver has to see to a call of nature. Who knows?
Sometimes it seems when you’ve reached deadlock with the technical programming aspects of a project it may be best to take a step back and perform a Great Rethinking. Good luck.
Donerico: I would move the car, and then when it reaches a high enough number of units for precision to become a problem, teleport it back to 0ish and reset the landscape. That way you have proper physics with a moving car, but you also have the catch-reset for those crazy enough to drive long enough to break it.
Unity doesn’t really care about specific physics values it seems, but precision will become an issue at extremely high values.
I would recommend setting back the player’s position back to (0,0,0) once in a while, together with the environment of course (so you won’t notice it). Unity uses PhysX from NVIDIA as a physics engine, and I know by experience that using too big numbers (maybe starting from a few kilometers) can cause trouble.
All of the car tutorials I can find deal with a fixed, pre-defined track. I’m curious about a game where the road is straight and is dynamically generated. I have all of this working, but I always like to understand all of the different options available for making something work and I was wondering if there is a best practice for this particular scenario.