Best way to instantiate a game object as a child of an existing gameobject in a scene mid-run, but then also have that game object's transform be set in relation to its parent and MOVE with its parent?
(I need a popup over someone's head when X happens that lasts until the person disappears off screen. Every way I've tried either doesn't properly child the co-ordinates of the popup, so it ends up being placed weird, or throws me a null exception for various reasons)
http://docs.unity3d.com/ScriptReference/Transform.SetParent.html
child_transform.SetParent(parent_transform). Once it's set as the child, moving the parent should automatically move the child. If not, write a move method that first updates the parent's transform, then set up a foreach loop that goes through each attached transform and modifies them.
Anyway once an object is a child, it will always move, scale, and rotate the exact same way as its parent, and it's coordinates will be redefined so that whatever the parent's location is is (0,0,0)
So if you're doing a 2d game, what you're looking for would look something like
GameObject child = (GameObejct)Instantiate(child); //Instantiate the child
child.transform.SetParent(parent.transform, true); //make it the child of the parent
child.transform.localPosition = Vector3.zero; //move it to the parent
child.transform.translate(new Vector3 (0, parent.renderer.bounds.size.y, 0)) //this will move it up by an amount equal to the height of the parent
There's probably better ways to do that last line depending on what exactly you need
i programmed staircases.... aka portals to other maps over the weekend
and... it worked the first time! no crazy bugs. I was expecting my assumptions about object deallocation to be false and I would get stuff like enemies from the previous map still hanging around and attacking me or stuff like that but nope.. completely clean transitions
Anyway once an object is a child, it will always move, scale, and rotate the exact same way as its parent, and it's coordinates will be redefined so that whatever the parent's location is is (0,0,0)
So if you're doing a 2d game, what you're looking for would look something like
GameObject child = (GameObejct)Instantiate(child); //Instantiate the child
child.transform.SetParent(parent.transform, true); //make it the child of the parent
child.transform.localPosition = Vector3.zero; //move it to the parent
child.transform.translate(new Vector3 (0, parent.renderer.bounds.size.y, 0)) //this will move it up by an amount equal to the height of the parent
There's probably better ways to do that last line depending on what exactly you need
at least with programming you're working toward a very specific target
and okay sometimes it's a moving target but at least you have a clear idea in mind for what your shit should do
designin' though is just
"come up with some ideas and hope they're good because you won't know for sure one way or the other until you put a ton of work in to put them into a testable state"
"The only listed requirement I don't meet to be a hearthstone designer is having legendary rank, why don't I just get ass deep into hearthstone and hit legendary and apply..."
at least with programming you're working toward a very specific target
and okay sometimes it's a moving target but at least you have a clear idea in mind for what your shit should do
designin' though is just
"come up with some ideas and hope they're good because you won't know for sure one way or the other until you put a ton of work in to put them into a testable state"
I am basically the opposite of this. Programming and development stuff is pretty tough for me and I've never really been able to get a solid grasp on code.
But designing stuff? Testing ideas, developing ways to mesh systems and themes? I'm all over that stuff.
i'm trying to figure out how make a sword swing work in a top down zelda clone
so far, i know that as you swing the sword, you want to have a hitbox that more or less occupies the same space as the sword on each frame (possibly adjusted slightly for gamefeel purposes)
and if the sword's hitbox contacts an enemy, you want to do some damage function with that enemy
but where I'm getting tripped up is, what's the best way to determine whether there is an enemy in the path of the sword
the most obvious solution would be to raycast from the hitbox in the direction of the sword's arc, but it seems like you'd have to do a lot of ray casting each frame to ensure that you're not missing anything. False negatives seem like they need to be the number one thing to avoid at all costs for this sort of thing, and raycasts in this sort of environment seem prone to lead to false negatives
the only other solution I can think of though, is to maintain some sort of array or linked list or some other data structure, containing references to every enemy currently spawned, and on every frame of the sword swing, a script iterates through that list and checks each enemy's hurtbox to see if it overlaps with the sword's hitbox. That's guaranteed to always produce the correct answer, but it seems like a very slow and inefficient approach, especially in potential situations where there could be a large number of enemies.
I suppose another option would be to have that sort of data structure, and as enemies move, they check the player character's position to see whether or not they're within attack distance, and if they are they add themselves to the list and if they're not they remove themselves from it. That's better in the sense that it would keep the number of checks performed low, but it still seems like there's gotta be a smarter, simpler solution that I'm just not thinking of.
Basically I assume that if they could pull it off on a snes then there must be a very simple, very elegant solution to the problem
Another idea would be to work it into the tile system used for collision detection
Have each tile have a "hasEnemy" Boolean, along with a Boolean to reference enemies. When an enemy moves into a tile it sets the tile's Boolean to true and assigns itself to the variable, and when it exits the tile it sets the Boolean to false and sets the variable to null
If the sword passes through a tile where "hasEnemy" is true then it performs the sword hit function on the referenced object
MachwingIt looks like a harmless old computer, doesn't it?Left in this cave to rot ... or to flower!Registered Userregular
Collision detection between primitives is actually surprisingly cheap, thanks to Minkowski addition! Unless you're doing per-poly collision, you don't really need to worry about the cost of checking against a bunch of enemies. I don't know if Unity uses anything like octrees to optimize these kinds of checks by default, but if not then that'd save some computational time as well.
For large numebrs of enemies you'd use a quadtree(or octree for 3D). Quadtree divides up space into 4 sectors, and those each have 4 sectors, and those etc.. to some depth. Whenever an enemy moves you'd find which sector it best fits. If it overlaps a border it will be listed in the parent node, otherwise it's placed in the child node. This can be made more efficient by dynamically splitting sectors where enemies are focusing and removing nodes where there are few.
So now you take your hurtbox and find the node it fits into and check for collision for anything listed on that whole branch. http://www.mikechambers.com/blog/2011/03/21/javascript-quadtree-implementation/
But if this is in unity, just use their collision system.
I don't think the sword in top-down zeldas does per-pixel collision sampling. At least not on the SNES. It's relatively expensive to do that, and the difference between that and just some abstract collision maps is going to be almost imperceptible. There's fairly good evidence that LTTP relied on low-resolution collision maps that were just Done Really Well to give the perception of high resolution collision.
first and foremost you'll want to cull down your potential target list to just the enemies that are within the hypothetical reach of Link, facing in any direction, which is simple
then define a rectangle that specifies the hit box for the sword at a given point in the swing... if the swing is a 6 frame animation, then it can have 3 stages each occupying two frames... one with the sword extending from his body, one straight forward, and then one out to the side and returning
But if this is in unity, just use their collision system.
i remember being incredibly frustrated by unity's stuff early on and that's why i decided to just go it on my own, and now i'm going back and trying to use their stuff and i'm still finding it to be nothing but a headache machine
for instance: based on the evidence I've gathered first hand I think the idea that the OnCollisionEnter() function is called when a collider collides with another is in fact a myth
Unity is insidious in that you end up learning how to use Unity but not learning how to program, because just operating within Unity's environment is a language unto itself. That headache is your brain telling you there are so many better ways to do such simple tasks
most 3D engines are like this
i've been programming professionally at a high level for almost ten years. i open up unreal editor and its all like nope.avi
if i know how a thing works i know how to tweak it
unity keeps so much stuff under the hood so that non-programmers can figure it out that it just becomes a chore when something doesn't work how i expect or want it to
doing more research LTTP apparently does occasionally produce false negatives with the collision on link's sword swings, so determining how it does it and copying it seems like a bad idea
right now i'm thinking the solution is
when the player does the sword input, generate a list of every enemy that might be hit by the sword:
-Take a list of all enemies on screen
-Add all enemies within the range of the sword to the list of potential targets
-for the remaining enemies, check their movement speed, and see if it's possible for them to move into the path of the sword in the time the sword swing animation takes to complete. if it does, add them to the list of potential targets
once that's done, on each frame of the sword swing, determine whether the sword's hitbox is overlapping each potential target's hurtbox, and if in any case it is, call that enemy's damage function and remove that enemy from the list of potential targets, to ensure that it's impossible to hit the same enemy twice in one swing
well anything done on a 16-bit system with mere kilobytes of RAM will produce "false negatives" to the human eye, no doubt. but sometimes its about effort level too. pixel-testing can be rough
one function that seems like it'd be super useful to have in unity is something where like, you pass it a rectangular prism as an argument, it looks at the space defined by that rectange in the coordinate plane, and it returns a data structure, probably a list?, of every object contained within that space
which
i guess what i'm really asking for is a 3 dimensional equivalent to raycasting
and i can see why that would get costly, enough that even though it's the intuitive way to solve a lot of problems it's not the optimal way
the way some developers solve that is by constantly keeping up list of objects in given quadrants, so that when you go to sample an intersect on a prism, you're only iterating through objects likely to be a match, instead of every object in the game
you can also categorize your collide-able objects, so like "this object can collide with players" vs "this object can collide with walls but will pass through players"
its all about culling your data down to a point where you can cheaply iterate through it
conversely, in an engine as refined as Unity, it probably wont matter if you cull or not until you get to thousands of objects in a scene, maybe even tens of thousands
Jasconius on
0
Options
MachwingIt looks like a harmless old computer, doesn't it?Left in this cave to rot ... or to flower!Registered Userregular
-for the remaining enemies, check their movement speed, and see if it's possible for them to move into the path of the sword in the time the sword swing animation takes to complete. if it does, add them to the list of potential targets
This'll probably be more expensive than just checking a wider area to begin with. If you know the fastest an enemy is ever gonna move, you can fudge that first area check outward to compensate.
i guess what i'm really asking for is a 3 dimensional equivalent to raycasting
and i can see why that would get costly, enough that even though it's the intuitive way to solve a lot of problems it's not the optimal way
Unity has a form of "thick" raycasting (spherecasting). Alternatively, you could do a few raycasts at the extemes of your sword.
I spent a bit of time last year prototyping a game where the character's gravity oriented itself to whatever surface he was touching. One problem I ran into was how to handle "curved" surfaces and stepping across angled polygons- I ended up doing 5 raycasts (one at each corner of the player's bounding box downward, one at the center), looked at the normals of each surface hit, and averaged the hits to get the final orientation.
Is anyone in here doing stuff in c++? I want to start messing with GUIs, but I haven't ever setup an external library, or built a GUI anything
Yes. I think the most hobo-efficient way right now is to use Awesomium, which runs a chrome window html gui and will feed you textures to send to the frame buffer.
alright this is an issue i've been struggling with forever now
the art assets i'm using are pixely lookin
and no matter what i do
i can't make them appear correctly when i build and run the game
as a random example my player character sprite is 18x25
when i import it to unity, i have it treat 1 pixel as 1 world unit, meaning its 18 units by 25 units tall
and i use point filtering so there's no bluriness
and i've gone to great lengths to always ensure that everything's coordinates are integer values (for instance i spent most of today reworking my movement system so that you could use decimal speed values and still get integer movement, for example a character with .5 speed will just move one whole unit every 2 frames)
I'm using an orthographic camera, with a size of 112.5, for a camera view that encompasses 400 x 225 world units, which is exactly 1/4 of 1600x900
and yet when I build the game and run it at a 16:9 aspect ratio at 1600 by 900 resolution
I get weird little goofs
things like some columns of "pixels" on a sprite being wider or narrower than other columns
or i think i've mentioned this here before, if I crank the graphics quality up all the way some of the sprites get red or grey boxes around them that denote the borders of the sprite, which I'm given to understand represent some sort of rounding error when calculating the position of an object, but there shouldn't BE any rounding error because everythings coordinates should be integer values!
This is a cropped screenshot I took of my game while it was running at full screen at 1600x900, with my monitor set to the same resolution:
You can see what I'm talking about by looking at the area around her left eye and above.Most of the sprite scaled perfectly by a factor of 4, but a little piece of it there didn't, and in other places it' been more noticeable
The weird thing is that the errors are consistent. Like every single time I build and run the game that sprite will look exactly like that, but only that instance of that sprite. I have another object in the scene with the same exact sprite, but it has a different set of graphical errors. If I edit that sprite and reimport it, there's a reasonable chance that the specific error it has will go away but a new one will appear (the last draft of this sprite had a misshapen pupil in one of her eyes)
I also tried just scaling up the sprites by four and expanding the camera, so that ostensibly there wouldn't be any need for scaling and no chance of things being messed up by scaling
Posts
http://docs.unity3d.com/ScriptReference/Transform.SetParent.html
child_transform.SetParent(parent_transform). Once it's set as the child, moving the parent should automatically move the child. If not, write a move method that first updates the parent's transform, then set up a foreach loop that goes through each attached transform and modifies them.
My Steam
Here ive just been doing
child.transform.parent = parent.transform;
Anyway once an object is a child, it will always move, scale, and rotate the exact same way as its parent, and it's coordinates will be redefined so that whatever the parent's location is is (0,0,0)
So if you're doing a 2d game, what you're looking for would look something like
GameObject child = (GameObejct)Instantiate(child); //Instantiate the child
child.transform.SetParent(parent.transform, true); //make it the child of the parent
child.transform.localPosition = Vector3.zero; //move it to the parent
child.transform.translate(new Vector3 (0, parent.renderer.bounds.size.y, 0)) //this will move it up by an amount equal to the height of the parent
There's probably better ways to do that last line depending on what exactly you need
http://www.audioentropy.com/
and... it worked the first time! no crazy bugs. I was expecting my assumptions about object deallocation to be false and I would get stuff like enemies from the previous map still hanging around and attacking me or stuff like that but nope.. completely clean transitions
i am the C++ lord
yesssssss
designing stuff is hard
http://www.audioentropy.com/
and okay sometimes it's a moving target but at least you have a clear idea in mind for what your shit should do
designin' though is just
"come up with some ideas and hope they're good because you won't know for sure one way or the other until you put a ton of work in to put them into a testable state"
http://www.audioentropy.com/
a snowy company, that knows something about the craft of war
and star
and...watching....over????
THE INTERVIEW WENT PRETTY WELL I THINK
"The only listed requirement I don't meet to be a hearthstone designer is having legendary rank, why don't I just get ass deep into hearthstone and hit legendary and apply..."
http://www.audioentropy.com/
I am basically the opposite of this. Programming and development stuff is pretty tough for me and I've never really been able to get a solid grasp on code.
But designing stuff? Testing ideas, developing ways to mesh systems and themes? I'm all over that stuff.
i'm trying to figure out how make a sword swing work in a top down zelda clone
so far, i know that as you swing the sword, you want to have a hitbox that more or less occupies the same space as the sword on each frame (possibly adjusted slightly for gamefeel purposes)
and if the sword's hitbox contacts an enemy, you want to do some damage function with that enemy
but where I'm getting tripped up is, what's the best way to determine whether there is an enemy in the path of the sword
the most obvious solution would be to raycast from the hitbox in the direction of the sword's arc, but it seems like you'd have to do a lot of ray casting each frame to ensure that you're not missing anything. False negatives seem like they need to be the number one thing to avoid at all costs for this sort of thing, and raycasts in this sort of environment seem prone to lead to false negatives
the only other solution I can think of though, is to maintain some sort of array or linked list or some other data structure, containing references to every enemy currently spawned, and on every frame of the sword swing, a script iterates through that list and checks each enemy's hurtbox to see if it overlaps with the sword's hitbox. That's guaranteed to always produce the correct answer, but it seems like a very slow and inefficient approach, especially in potential situations where there could be a large number of enemies.
I suppose another option would be to have that sort of data structure, and as enemies move, they check the player character's position to see whether or not they're within attack distance, and if they are they add themselves to the list and if they're not they remove themselves from it. That's better in the sense that it would keep the number of checks performed low, but it still seems like there's gotta be a smarter, simpler solution that I'm just not thinking of.
http://www.audioentropy.com/
Another idea would be to work it into the tile system used for collision detection
Have each tile have a "hasEnemy" Boolean, along with a Boolean to reference enemies. When an enemy moves into a tile it sets the tile's Boolean to true and assigns itself to the variable, and when it exits the tile it sets the Boolean to false and sets the variable to null
If the sword passes through a tile where "hasEnemy" is true then it performs the sword hit function on the referenced object
that seems like a solid way of doing things
http://www.audioentropy.com/
Unless I did a tile system where the tiles were 1 pixel in size, it's possible to straddle tiles and not fully occupy them
Which would make that system produce false positives
Which are better than false negatives but still bad!
http://www.audioentropy.com/
So now you take your hurtbox and find the node it fits into and check for collision for anything listed on that whole branch.
http://www.mikechambers.com/blog/2011/03/21/javascript-quadtree-implementation/
But if this is in unity, just use their collision system.
I don't think the sword in top-down zeldas does per-pixel collision sampling. At least not on the SNES. It's relatively expensive to do that, and the difference between that and just some abstract collision maps is going to be almost imperceptible. There's fairly good evidence that LTTP relied on low-resolution collision maps that were just Done Really Well to give the perception of high resolution collision.
first and foremost you'll want to cull down your potential target list to just the enemies that are within the hypothetical reach of Link, facing in any direction, which is simple
then define a rectangle that specifies the hit box for the sword at a given point in the swing... if the swing is a 6 frame animation, then it can have 3 stages each occupying two frames... one with the sword extending from his body, one straight forward, and then one out to the side and returning
then do your hit testing, done
http://www.audioentropy.com/
i remember being incredibly frustrated by unity's stuff early on and that's why i decided to just go it on my own, and now i'm going back and trying to use their stuff and i'm still finding it to be nothing but a headache machine
for instance: based on the evidence I've gathered first hand I think the idea that the OnCollisionEnter() function is called when a collider collides with another is in fact a myth
http://www.audioentropy.com/
most 3D engines are like this
i've been programming professionally at a high level for almost ten years. i open up unreal editor and its all like nope.avi
if i know how a thing works i know how to tweak it
unity keeps so much stuff under the hood so that non-programmers can figure it out that it just becomes a chore when something doesn't work how i expect or want it to
although with that said
the animation stuff is really great and i love it
http://www.audioentropy.com/
right now i'm thinking the solution is
when the player does the sword input, generate a list of every enemy that might be hit by the sword:
-Take a list of all enemies on screen
-Add all enemies within the range of the sword to the list of potential targets
-for the remaining enemies, check their movement speed, and see if it's possible for them to move into the path of the sword in the time the sword swing animation takes to complete. if it does, add them to the list of potential targets
once that's done, on each frame of the sword swing, determine whether the sword's hitbox is overlapping each potential target's hurtbox, and if in any case it is, call that enemy's damage function and remove that enemy from the list of potential targets, to ensure that it's impossible to hit the same enemy twice in one swing
http://www.audioentropy.com/
which
i guess what i'm really asking for is a 3 dimensional equivalent to raycasting
and i can see why that would get costly, enough that even though it's the intuitive way to solve a lot of problems it's not the optimal way
http://www.audioentropy.com/
the way some developers solve that is by constantly keeping up list of objects in given quadrants, so that when you go to sample an intersect on a prism, you're only iterating through objects likely to be a match, instead of every object in the game
you can also categorize your collide-able objects, so like "this object can collide with players" vs "this object can collide with walls but will pass through players"
its all about culling your data down to a point where you can cheaply iterate through it
conversely, in an engine as refined as Unity, it probably wont matter if you cull or not until you get to thousands of objects in a scene, maybe even tens of thousands
This'll probably be more expensive than just checking a wider area to begin with. If you know the fastest an enemy is ever gonna move, you can fudge that first area check outward to compensate.
Unity has a form of "thick" raycasting (spherecasting). Alternatively, you could do a few raycasts at the extemes of your sword.
I spent a bit of time last year prototyping a game where the character's gravity oriented itself to whatever surface he was touching. One problem I ran into was how to handle "curved" surfaces and stepping across angled polygons- I ended up doing 5 raycasts (one at each corner of the player's bounding box downward, one at the center), looked at the normals of each surface hit, and averaged the hits to get the final orientation.
http://www.audioentropy.com/
Yes. I think the most hobo-efficient way right now is to use Awesomium, which runs a chrome window html gui and will feed you textures to send to the frame buffer.
the art assets i'm using are pixely lookin
and no matter what i do
i can't make them appear correctly when i build and run the game
as a random example my player character sprite is 18x25
when i import it to unity, i have it treat 1 pixel as 1 world unit, meaning its 18 units by 25 units tall
and i use point filtering so there's no bluriness
and i've gone to great lengths to always ensure that everything's coordinates are integer values (for instance i spent most of today reworking my movement system so that you could use decimal speed values and still get integer movement, for example a character with .5 speed will just move one whole unit every 2 frames)
I'm using an orthographic camera, with a size of 112.5, for a camera view that encompasses 400 x 225 world units, which is exactly 1/4 of 1600x900
and yet when I build the game and run it at a 16:9 aspect ratio at 1600 by 900 resolution
I get weird little goofs
things like some columns of "pixels" on a sprite being wider or narrower than other columns
or i think i've mentioned this here before, if I crank the graphics quality up all the way some of the sprites get red or grey boxes around them that denote the borders of the sprite, which I'm given to understand represent some sort of rounding error when calculating the position of an object, but there shouldn't BE any rounding error because everythings coordinates should be integer values!
This is a cropped screenshot I took of my game while it was running at full screen at 1600x900, with my monitor set to the same resolution:
You can see what I'm talking about by looking at the area around her left eye and above.Most of the sprite scaled perfectly by a factor of 4, but a little piece of it there didn't, and in other places it' been more noticeable
The weird thing is that the errors are consistent. Like every single time I build and run the game that sprite will look exactly like that, but only that instance of that sprite. I have another object in the scene with the same exact sprite, but it has a different set of graphical errors. If I edit that sprite and reimport it, there's a reasonable chance that the specific error it has will go away but a new one will appear (the last draft of this sprite had a misshapen pupil in one of her eyes)
what the hell is going on and how can I stop it
http://www.audioentropy.com/
But if anything that made it worse
http://www.audioentropy.com/
http://www.audioentropy.com/
void Update () { if (transform.localPosition.x % 1 != 0){ transform.localPosition = new Vector3(Mathf.Round(transform.localPosition.x), transform.localPosition.y, transform.localPosition.z); } if (transform.localPosition.y % 1 != 0){ transform.localPosition = new Vector3 (transform.localPosition.x, Mathf.Round(transform.localPosition.y), transform.localPosition.z); } }Didn't do anything.
http://www.audioentropy.com/
Did...did you lock your computer chair to whole numbers
Everything is whole numbers
Except for the way the sprite is drawn in the screen
i guess no one has any ideas on why this thing is shitting itself then?
http://www.audioentropy.com/
http://www.gdcvault.com/play/1021921/Designing-with-Physics-Bend-the
the only help I can offer is that I had a similar problem in Unity, and upon compiling and running outside of the editor NONE of that stuff happened
I guess i'll go ask the question on Unity Answers, see if they have any ideas
http://www.audioentropy.com/
the camera ISN'T at a whole number coordinate, it's the only thing that isn't
I wanted its lower left corner to be at (0,0)
and since its orthographic size is 112.5, that puts its coordinate position at (200,112.5)
could this be the answer to my problems?!?!?!?!?!!? let's find out
http://www.audioentropy.com/