koobas.hobune.stream
Creating a draggable object - and defining areas.
Hi. Im new to unity, so far I created "flappy bird" like game, and I want to make something more advanced. Im trying to create "stay in the line" 2d game, but with a draggble ball, which you need to drag in the "route" without hitting the walls.
Im not sure how to approch the two main parts in the game.
1.Creating a draggble (by touch) object.
2.Creating the route - creating the outer walls and then use "onCollsion" - is that the correct way?
and more genreal question, if im just planning on creating 2d-games, do you think that I should stick with unity?
Thanks!
I think there is a drag object script that can help you start in the right direction here http://wiki.unity3d.com/index.php?title=DragObject
That's the way I would do it
There are a variety of drag and drop scripts posted on UA. But for what you are doing here, some have issues. Given the game mechanic, something simple might work better for you:
#pragma strict
var follow : boolean = true;
function OnMouseDown() {
follow = true;
}
function Update() {
if (Input.GetMouseButtonUp(0)) {
follow = false;
}
if (follow) {
var v : Vector3 = Camera.main.ScreenToWorldPoint(Input.mousePosition);
v.z = 0.0;
transform.position = v;
//rigidbody2D.MovePosition(v);
}
}
Basically if you touch the ball anywhere, it snaps to the mouse position and follows until the mouse button is lifted. If you are going to be using Physics for your app, then you what the commented out line instead of the one above it. For touch, if you restrict the player to one finger, then there are just a few lines changed/added to the script.
Which brings me to your second part of your question. You could put colliders on the background and use OnCollisionEnter() or OnTriggerEnter(). This is a typical Unity way of dealing with collisions. But assuming touching the edges means death, I'd likely not do colliders and instead read the pixels of the texture(s) directly to determine if the ball is still on the path. Reading pixels directly is not a simple process, and the particulars will depend a bit on how you build and animate your paths: single texture on a moving plane, multiple random moving tiles swapped in, single using mainTextureOffset to animate, etc. But I think it would greatly simplify the path creation process.
Thanks alot!
about that one finger restriction, lets say I want to put 2 balls on the route, and they can only move together, ie you must press both balls, and move them at same time. How would that change the code ,other then adding another ball-object?
And about creating the route, if I just want to make Levels and not endless route, which why should I go?
Thanks again!
Little of this code applies to multiple fingers. First, this code uses On$$anonymous$$ouseDown() to detect a click on the ball. For multiple balls, you would need to go to a Raycasting solution so that you can map a particular finger to a particular ball. In addition, you'll likely have to identify your finger by Touch.fingerId and search out the id in the Input.touches array (not just use the index of the touch).
As for the path on a single Quad (assumes the whole path is on a single texture), there is a fairly simple way to construct things. First create your path. Then create a mask of your path. The mask would have the path narrowed by the radius of the ball. For example in this picture the top half is a slice of the path, the bottom half is a slide of the mask, the grey lines are there for refrence and would not be in the final image.
The mask need not be of the same resolution as the path, but it needs to be the same aspect ratio. In addition, the mask should be marked as read/write enabled in the Inspector.
So to tell if the user went out of bounds you would do:
Collider.Raycast(transform.position, Vector3.forward, hit) from the center of the ball against the mesh collider on the Quad you are using to display the path.
On the mask use Texture2D.GetPixelBilinear() with the x and y RaycastHit.textureCoord as the parameters. This will give you the color. If the color is nearly black, then the user dies.
Note you don't want to do a direct comparison to black. If you you are using black and white like I've done in the image, just test if the color.r < 0.1.
WoW! Thanks a bunch! (:
Although im still a bit confused about the finger\multiple fingers.
Isnt there an event to fire in case an object being touched and moved?.
That way I can just check that both objected are "pressed" and are "moving". $$anonymous$$aybe the movig part is abit more problametic.
And about "mouseclick", If I export my game to android\ios, does mouse events being fired when using the finger "as if it was a mouse"?
Thanks again!
There are a number of different kinds of mouse things in Unity. Not all of them are mapped to touch. But On$$anonymous$$ouseDown() is mapped to touch, so the code I gave you for a single object will work for touch. As for multi touch, let me give you one scenario:
touch down on one object it gets touches[0] to follow
touch down on second object, it gets touches[1] to follow
During frantic play, my first finger lifts briefly from the glass
For a moment there is no longer two touches, so the second object either has to do nothing or will generate an error when accessing touches[1]. Worse, the finger that was touches[1] before, becomes touches[0], so the ball that was being manipulated by finger 1 immediately snaps across the screen to the touch 2 position.
There are other issues. Educate yourself on touch and fingerid. Take a look at any answers you find in Unity Answers with 'fingerid' in them. The code is not that hard to write, but you cannot approach it in the simplistic way I gave you for a single finger.
Thanks for clarifying,and for your time and answers!
going to do some reading (;
