I am kind of new to unity,to any kind of engine,actually.
I am trying to find a way to have a controllable mass of fluid,i mean to be able to go forward,back and so on using the arrow keys.
At first i thought about having some kind of mesh filled with simulated liquid but it doesn't really fit for my project....
Long story short, i need to be able to move a droplet of water.
I think you should start with instantiating just a lot of balls (2d or 3d) - as a representation for droplets. You can give them all physics colliders and rigidbody mass and you will be able to control them all, by proximity or individually.
In the future you can replace spheres with some kind of surface-generating algorithm like metaballs or raymarching
Related
So I want to have air time in my game, but I can't figure out how to check the collisions of all my wheels. I can only check whether a single wheel is colliding with the floor, not if all of my wheels are colliding with the floor.
Sorry for the poor wording, but the goal is to check to see if any of the four wheels are touching the floor.
There are several ways to achieve this, but one would be to create multiple Colliders for each wheel. Then you check whether each of these wheels is currently touching the ground. So you would have an extra Collider Object per wheel to check this.
Another way would be that if you have like one Object as car you could check the positions your object is having collisions with and calculate them but that would be way to complicated because I dont think performance will be that important for you.
I'm fairly new to game development and I'm trying to develop a 2D game in unity where the main character has a jetpack with two thrusters and I want him to control each one individually. So if he only turns on one thruster he goes 5 meters above ground and hovers there while using both would make him hover at a height of 10 meters. How would i go about doing this?
I tried just simply adding forces as if the character was jumping and freezing the y-axis to 0 until he let go of the jetpack button but that did not give me the feel i was looking for. I also tried raycasting a line out of the jetpacks to the closest surface and adding a force to the jetpack to allow the player to float at that height but that I couldn't figure out a proper way to implement it.
The Raycast sounds like a great idea. Do the raycast to the next available platform and do as #Ahndwoo said in a comment, `
What you would need to do is divide the force of your thrusters by the
magnitude of the Ray. Thus, as the Ray gets longer, the force
decreases.
By doing this you'll get the natural movement from a force and you'll control how high can you get.
I would Make your thrusters holder as an object and as more turbines it has, the more powerful i'll get.
I am thinking of building a game like the sims and was thinking of how I could make the characters interact with any object without having to systematically change the character's code and prefab whenever I decide to add new furniture and props to the library. I have had an idea that consists of having my animations attached to the furniture itself rather than having it attached to the character (which would require a lot of memory and extra code if we had a lot of furniture in the game library!). I was thinking about it and had in mind that I could add a rig skeleton in Blender that has the desired animation(s) but not rig any specific object - so that I only have the animation, the location, rotation and scale of the bones! and since the characters' rigs are the same as the skeleton's rig in the furniture's animation, they could be compatible!
I hope this makes sense...
The thing is that I realise at this stage that I do not know the Animation class very well, and I am not sure if / how I can use the animation attached to the furniture to make my character interact with it...
Can Animation.Play() take multiple arguments apart from the animation to play and the play mode? Is it possible to specify which object has to play the animation? I am talking about doing all of this from the script - I write in C# by the way... and I might attach the script to the camera so I hope the script does not have to be necessarily attached to the character prefab in order to play the animation... Though I don't mind creating a function in the character's script if necessary!
I am not new to Unity but I have mostly been using cars and character controllers, so I haven't dealt with much animation coding yet...
I thank you in advance for your help and apologise for my weird english - I live in France! ^^
Mecanim performs retargeting of humanoid animations, so for what concern that specific case, you should be able to use the same rig and set of animation clip on different models.
For what concern grabbing furniture, you don't need the object to be rigged. You can use IK to precise move your character's hand toward the target object and then parent it to the relative joint in the hierarchy.
I want to create a 2d game in C# using XNA. There should be stickmen who can wear different weapons like a pistol, a grenade or a rocket launcher. And those stickman also should be able to do other things, like drink a bottle of beer and stuff.. So how do you create and store these animations (drink a bottle of beer, walk, throw a grenade) and how can you tell them how to hold a weapon (pistol: in the hand, grenade: in the hand, but holding the arm behind them, rocket launcher: on the shoulder)? What's the best (simple and extensible) approach to this?
For stickmen, comes to my mind, skeletal animations with directly rendered bones. Such vector graphics would scale very well compared to sprites. Skeletal animation stores a tree of bones with lengths and angles, and interpolates between predefined keyframes. The advantage of this is that you can easily incorporate some simple physics and inverse kinematics that blend with the animations (take a look at Jakobsen excellent Verlet dynamics paper) for holding weapons, beer cans and mantling ledges, etc. This is fairly advanced stuff, much easier than 3D graphics, but it will still take you a long time to design and implement.
One thing that can help when compositing sprites (giving a hero a sword, etc) using SpriteBatch is the Origin argument on some of the Draw method overloads. It allows you to rotate around something other than the top left corner and can also help when positioning sprites that are of differing sizes. Since the Origin is specified in source texture scale, any calculations will be valid event if the sprites are drawn at a different scale.
What you're asking is a fairly broad question. You might want to have a look at the 2D Platformer sample that comes with XNA Game Studio. That can get you started.
I'm designing a 3D game with a camera not entirely unlike that in The Sims and I want to prevent the player character from being hidden behind objects, including walls, pillars and other objects.
One easy way to handle the walls case is to have them face inwards and not have an other side, but that won't cover the other cases at all.
What I had planned is to somehow check for objects that are "in front" of the player, relative to the camera, and hide them - be it by alpha blending or not rendering at all.
One probably not so good idea I had in mind is to scan from the camera to the player in a straight line and see if you hit a non-hidden object, continuing until you reach the player. Unfortunately, I am an almost complete newbie on 3D programming.
Demonstration SVG illustration < that wall panel obscures the player, so it must be hidden. Another unrelated and pretty much already solved problem is removing all three wall panels on that side, which is irrelevant to this question and only caused by the mapping system I came up with.
What I had planned is to somehow check for objects that are "in front" of the player, relative to the camera, and hide them - be it by alpha blending or not rendering at all.
This is a good plan. You'll want to incorporate some kind of bounding volume onto the player, so the entire player (plus a little extra) is visible at all times. Then, simply run the intersection algorithm for each corner of the bounding volume.
Finding which object is at a given point on screen is called picking. Here's an XNA link for you which should direct you to an example. The idea is that you retrieve the 3D point in the game from the 2D point, and then can use standard collision detection methods to work out which object is occupying that space. Then you can elect to render that object differently.
One hack which might suffice if you have trouble with the picking approach is to render the character once as part of the scene, and then render it again at the end at half-alpha on top of everything. That way you can see the whole character and the wall, though you won't see through the wall as such.
One easy way, at least for prototyping, would be to always draw the player after you draw the rest of the scene. This would ensure that the player is rendered on top of anything else in the scene. Crude but effective.
Create a bounding volume from the camera to the extents of the player, determine what objects intersect that volume, and then render them in whatever alternate style you want?
There might be some ultra-clever way to do this, but this seems like the pretty straightforward version, and shouldn't be too much of a perf hit (you're probably doing collision every frame anyway....)
The simplest thing I can think of that should work relatively well is to model all obstacles by a plane perpendicular to your ground (assuming you have a ground.) Roughly assuming everything that is an obstacle is a wall with some height.
Model your player as a point somewhere, and model your camera as another point. The line in 3d that connects these two points lies in a plane that is particularly interesting to you, because if this plane intersects an "obstacle plane" below the height of the obstacle, that means that that obstacle is blocking your view of the player point.
I hope thats somewhat clear. To make this into an algorithm you'd have to implement a general method for determining where two planes intersect (to determine if the obstacle is tall enough to block view.)