I'm working on a VR project in Unreal and I'd like my player hands to form to certain objects whenever the user grabs them. (I.e. the way our hands work) Unfortunately, I haven't really found any examples online of others doing this.
For example, I'd like when the user picks up say a hand held tool like a hammer that the hand would wrap around the handle. When the user grabs a basketball the hand shouldn't be closed but, expanded like a you would if you were to palm a basketball in real life.
I haven't done a lot of testing with this but, I'm pretty sure since the hands are based off of a Animation Blueprint that they simply ignore collisions and follow the animation.
I guess the simplest solution would probably be based off of collision where the hand plays an animation and as the fingers of the hand wrap around the object they stop at that position where they collide with the object in question. If it is even possible that is.
Related
I am trying to make a 3D jumping game where my character is standing still and the objects and background are moving towards him to make it seem like he is running. I have a bunch of models for buildings that I am instantiating using an empty game object that I use as a spawner. I want the buildings to spawn one after each other, so whenever one building has moved far enough and left enough space the next one should spawn. I first tried to do this with InvokeRepeating, but the buildings are different widths so it does not work well with a constant repeat rate. I then tried to put a collider on my spawner and spawn a building whenever the spawner collider is not colliding with anything, but it seems to just spawn buildings infinitely. Is there a way to fix this or a better way to do this?
There are many different ways of doing this.
The most straightforward is possibly to let each building spawn the next one, as I assume they each know how wide they are and thus when it's time for the next.
Well , first things first your problem is looking more like a design problem. I would recommend searching things like "procedural world building" , also object pooling. There is lots of examples of runner games that do what you describe.
You can check the palyer position to instantiate , you can create parts of the road as prefabs , make lots and lots of prefabs and instantiate them as you go etc. The question you asked is simply too wide to give an actual answer. So if you have any more spesific questions , it'll be nice to answer !
so I've been trying to see if I can make use of Wheel Colliders for the past several months now. As much as I've managed to figure out more and more things about how to set them up properly, there's some things I've been noticing that seem impossible to avoid:
Even if your friction sideways stiffness is lower, there's a chance that your car will continue to "spin" or "rotate" in the direction you were steering if you JUST hold down your input long enough to get the car beyond just rotating. I've noticed this will happen, whether for example the "SteerHelper" or "TractionControl" functions are doing their work or not. This will put a dent in ensuring smooth turn movement. Now, I don't know if maybe this is just due to realistic car physics (I mean, I can picture the car skidding in scenarios where they lost grip of the road for sure), but it just feels kinda glitchy. Sometimes, even when I'm not turning, the car will start to turn a little to the left or right and then gradually seem to "lean" that way in terms of applied torque to the rigidbody. I've seen many suggestions for trying to stop the rigidbody from doing this. Here is one way I'm trying to work against this:
rb.AddTorque(-rb.angularVelocity * 2);
However, it seems that the car will still "spin" more than intended. What would be ideal is to be able to MAYBE allow the car to turn a little extra after the left or right steer buttons were released (maybe more or less depending on the vehicle), and no more than that to ensure there is maximum control to give the engaged and maybe arcadey game play I've been going for for a long while.
It's been difficult to adapt an ideal friction curve value that would give the most ideal feel of a drift turn, especially a more arcadey one. I'm not trying to go for wide turns that slow you down, I'm trying to go for tight (yet controllable) turns that allow you to preserve most of your speed. I find that especially at higher values of stiffness, as I know many people have observed in other posts, that again, the car will turn back an extremely high amount sometimes (you drift left enough, a force is turning your vehicle way to the right). It's sad, because I've wanted to be able to say I've "mastered this beast" and used it for my purposes, but I don't know if that's really a good practical expectation for anyone. I even worked my own alternate friction curve values that would be used in the controller:
But I guess as some people say, you can't polish something that's broken? Moving to the third point...
I've read so many posts that show how to adjust a vehicle's center of mass, or to add more colliders in different spots to correct it, using scripting to add an offset to the center of mass, etc. So many tips that say, "lower the center of mass, you'll find it" and I give that a try. When the center of mass is too low, my car can get pretty shaky on the terrain (not that it hasn't in the past, but it's often been things I could correct, like the weird initialization of the attachedRigidBody of the wheel colliders themselves in the beginning, etc). High enough, and of course, (even when it's lower sometimes???) the car will just start spinning in the air on either multiple axes or specifically the forward z, when you drive off a ledge or bump into something with a high enough speed. It just seems inevitable.
I've been trying to give my benefits of a doubt. I like to think there's a correct way to use this thing, and that I'm just not familiar enough with Unity3D physics concepts. However, it just seems more and more that I'm investing too much time in a broken component - or, maybe I just never got the best grip of physics.
I was about ready to try just convex mesh colliders around my tires, and just abandon the idea of gripping physics altogether, but I'd love to hear suggestions to either address anything I've mentioned above, or just a more ideal package to move onto. I've glanced at packages like Vehicle Physics Pro, but I do want to be sure I'm getting something that makes sense.
Full disclosure: I'm in the middle of trying to make a game that feels incredibly similar to F-Zero, but with wheels.
Thanks in advance for any thoughts or suggestions you can provide.
(Maybe not an answer per se, but hopefully helpful.)
Note Unity also suggests to possibly give the car a constant downward force via script. It might be telling that such workarounds are officially given, one would think proper physics would, well, properly work without them.
There's some assets you might want to give a try generally:
One is the Unity Asset Store asset called Arcade Car Physics, and it's free. I've tried it and it works (but not sure if it works for your needs). It's using Unity's native Wheel Collider plus extra scripts.
Another is the Arcade Car Physics github project. It has nice plane stabilization and more, and works well. It's not using the native Wheel Collider.
Then there's this asset called Vehicle Physics. Instead of native Wheel Colliders, they've create a fully custom wheel system so that it would be more physically workable. The asset is not free, but they offer a free demo executable where you can drive around different vehicles, and that works quite well. (I haven't yet bought this asset myself.) As a downside, some reviews mention there's some complexity in setting this up (and I suppose future support for this custom Wheel Collider hinges on the company continuing to exist).
Good luck!
I'm trying to figure out a good way to script the NPCs in my RPG. A sample NPC interaction could go something like this:
NPC starts dialog #1 with player.
When the dialog is finished, the NPC moves to a waypoint on the map.
Once the NPC arrives at the waypoint and the player talks to him again, he starts dialog #2.
At the end of the dialog, the NPC asks a question.
If the player gives response A, the dialog ends. In this case, talking to the NPC again starts dialog #2 again.
If the player gives response B, the NPC gives an item to the player, and disappears. From now on, that same NPC will be present in a different Unity scene.
I've found plenty of examples of making a dialog tree, but I can't find a good way to handle complex situations like that. One of the most challenging problems is to determine which scene -- and where in the scene -- that NPC is. Depending on how far along the player is in the game, that NPC could be in any one of many different scenes, and will have different dialog and behavior.
Since Unity makes it easy to attach a script to my NPC's game object, I could of course do this all through a C# script. However, that script will get pretty big and messy for important NPCs.
The path that I've gone down so far is to create an XML file. Something like this:
<AgentAi>
<ActionGroup>
<Dialog>
<Statement>Hi!</Statement>
<Statement>Follow me.</Statement>
</Dialog>
<MoveTo>Waypoint_1</MoveTo>
<SetNpcState>NpcGreetedPlayer</SetNpcState>
</ActionGroup>
<ActionGroup>
<Conditions>
<State>NpcGreetedPlayer</State>
</Conditions>
<Dialog>
<Statement>Here, take this.</Statement>
</Dialog>
<AddItem>Dagger</AddItem>
<MoveTo>Waypoint_2</MoveTo>
</ActionGroup>
</AgentAi>
That sample would cause the NPC to greet the player and move to another spot. Then when the player talks to him again, the NPC will give the player a dagger and move to another waypoint.
The problem with the XML is that I'm worried about it growing very large for important NPC that can be in a lot of different places depending on where the player is in the game. I'd have to keep dynamically determining which NPCs are in a scene each time I load a new scene. I'm not totally against doing it with XML like this, but I don't want to waste a bunch of time heading down this road if there's a better way of doing it.
Since this type of behavior is common in a lot of games, is there a good way of doing it in Unity without having to homebrew my own complex system?
Normal software systems would use a database, once the level of complexity gets too high.
I'd setup the storyline with a numeric reference, like the pages of a book.
If they go to a higher number without interacting then the interaction is still available.
Then you can setup each interaction as a separate thing, with a start and finish number (not available before and not available after).
maybe you could do this by making the xml files separate, but I'd think you still need to tie them into the storyline.
I am wondering how developers are able to create games where the player can actually see the characters hands as they are casting spells, shooting, etc. A good example of this would be Overwatch. How is this done? Is there two separate views? One that the enemy sees, and then another that the player sees where its just arms and one is hidden to the other player? Or is the camera positioned in such a way where it is actually just the character model. Thanks!
"depends", basically. But the most common way (e.g. what most FPS games do) is having a detailed model for the player (your local avatar) with properly placed camera(s - see later) so you can see your hands/feet/etc and everyone remote to you is rendered "as is" (the model and it's locomotion / animations for jumping, etc - including how the model holds e.g. a rifle while jumping, etc).
The tricky part comes when
a) your game wants to be unique/complex on this e.g. like in your example: you want to see hands while you 'cast a spell' (or blood spilling in the eyes or anything)
and/or
b) you realize it's annoying to see particular body parts (e.g. your feet, as it might block view and/or makes jumping look silly), or gun sinks into walls/doors or such
In both cases, using multiple cameras for so called "layering" is the solution. Long story short: there's a camera that see the rifle in (kinda) topmost Z-Order, or a camera that cannot see the character model or a camera that can see "floating hands" casting spells.The trick with these, nothing else but that particular camera can see the effects, i.e. only the player (everyone else, as I mentioned above, see the model doing the "standard something" associated with that particular action. E.g. casting any spell ==> waving hands above the head or such).I hope this helps to give you an idea how it works. Cheers!
first time posting on stack and everything looks promising so far! I had a bit of a complicated question here so I'll do my best to provide exact details of what I'd like to get accomplished. I'm working with a third person controller in unity, so far everything is going great. I've dabbled with basic up and down platforms, a little glitchy but things work. Anytime my player runs through a mesh I make sure the mesh collider is working and a 'rigid-body' is attached set to Kinematic. Here's the kicker, in my game I have turning gears which the player can jump on. This is great except for the player doesn't turn with my gear, which would make sense according to my game-play. What would be the process for getting my character to interact with this animated mesh? I imagine some sort of script which my nooby mind cannot fathom at this point in my unity career. If anyone out there knows the solution to this, I would love to have any assistance, either way I'll plugging away at a solution. Thanks again!!
This is assuming that you're using the packages that ship with Unity3D, which it sounds like you are. After importing the Character Controllers package, you'll have a bunch of scripts in the Standard Assets\Character Controllers\Sources\Scripts folder, in the project hierarchy view. There's a script in there called CharacterMotor.js, attach that to the same GameObject you're running ThirdPersonController on.
Essentially this script adds more interactivity between the character and the scene. There's several methods inside this script that automatically move the character when in contact with a moving object (as long as it has a collision mesh) basically by inheriting the object's velocity.
If your gear/cog wheel has a proper collision mesh set up, adding this script to your character should be all that you require.