How do modern 2D games take care of multijointed bosses?
Moderator: Moderators
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
How do modern 2D games take care of multijointed bosses?
Do they have so much RAM that object memories can have huge tables of where every child object is in memory?, or do they allocate as much memory as they need total, and move stuff around in memory to fit?
Re: How do modern 2D games take care of multijointed bosses?
The amount of memory this requires is a minuscule fraction of the amount of total memory available. I don't think modern 2d game programmers worry about such things much. At least, the ones being productive don't.
There are probably dozens of ways to implement multijoint bosses, but the least surprising for me would be a scene graph for each limb and keyframe animation to move everything around. The hitboxes would be rotated with the limbs.
I don't know if that answers your questions though.
There are probably dozens of ways to implement multijoint bosses, but the least surprising for me would be a scene graph for each limb and keyframe animation to move everything around. The hitboxes would be rotated with the limbs.
I don't know if that answers your questions though.
Re: How do modern 2D games take care of multijointed bosses?
I'm assuming that even most 2D games now use common game engines that incorporate physics, so this talk is relevant (and interesting!!)
https://www.youtube.com/watch?v=NwPIoVW65pE
It even goes into multi-jointed territory.
https://www.youtube.com/watch?v=NwPIoVW65pE
It even goes into multi-jointed territory.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: How do modern 2D games take care of multijointed bosses?
That was really interesting. It's interesting how I ran into the same glitches while programming an SNES game.
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: How do modern 2D games take care of multijointed bosses?
I really can't even think of a single modern 2D game with multijointed bosses. I thought that multijointed bosses were only ever a thing due to memory/VRAM bandwidth constraints. Admittedly, it often doesn't make a difference visually, particularly if the object is inorganic.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: How do modern 2D games take care of multijointed bosses?
GBA and DS games were full of them
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: How do modern 2D games take care of multijointed bosses?
I think the most common thing I've seen is "skinning" of a "skeleton".
Wikipedia: Skeletal animation
The skeleton being a tree of "bones", each bone a transformation matrix that's a point and space as well as an orientation and scale. When you move/animate a bone, it moves all of its attached children bones along with it, it makes a tree hierarchy. Ultimately the animation is played back as interpolations between keyframes of various poses of the skeleton.
On top of the bones, you have the "skin". This is a 2D or 3D mesh, wherever every vertex is attached to one or more bones (e.g. a vertex in the forearm might be 90% elbow bone, 10% wrist) and will move along with those bones as they do. Physics systems often let you attach various physics shapes to bones, etc.
If you want to have rigid parts (e.g. metal pieces of a machine), just attach the vertices to a single bone. If you want to work with "sprites", you can use a lot of 4-vertex rectangles. If you want to do it without rotation, just don't rotate the bones, etc. If you don't have/want a modern GPU, meshes, etc. you can even just do sprite tiles attached to bones too. Whatever constraints you want to use to get the look/behaviour you like.
All of this applies equally to 3D and 2D work. I've seen it in both all over the place. I could probably easily come up with 100 2D examples if I looked, but I'm not going to spend time on that. Instead I'll just link a video of one of my favourites: Odin Sphere. All of its characters, bosses and otherwise, are animated this way:
https://www.youtube.com/watch?v=-nj6H5TBmcI
This video seems to have a good explanation of the whole concept:
https://www.youtube.com/watch?v=f3Cr8Yx3GGA
Why is this "modern"? Well, you could have a hierarchy of bones in the past, but the main thing that's tricky on old hardware is just the rotation and scaling of bones. You need a good floating point unit to make that turnkey, though it's certainly possible to implement on old hardware too (especially if you can live without rotation/scaling).
As an alternative to pre-made animation, you can use physics to animate bones as well. E.g. if you had something with a long tail, you could make a physical model of a bunch of connected pieces, and attach the bones to those physics objects rather than the other way around. Either way works, actually sometimes the two approaches are blended, e.g. the "inverse kinematics" technique of using a physics system to determine how a player's legs should be placed to stand on an uneven floor, blended with the animated upper body.
Wikipedia: Skeletal animation
The skeleton being a tree of "bones", each bone a transformation matrix that's a point and space as well as an orientation and scale. When you move/animate a bone, it moves all of its attached children bones along with it, it makes a tree hierarchy. Ultimately the animation is played back as interpolations between keyframes of various poses of the skeleton.
On top of the bones, you have the "skin". This is a 2D or 3D mesh, wherever every vertex is attached to one or more bones (e.g. a vertex in the forearm might be 90% elbow bone, 10% wrist) and will move along with those bones as they do. Physics systems often let you attach various physics shapes to bones, etc.
If you want to have rigid parts (e.g. metal pieces of a machine), just attach the vertices to a single bone. If you want to work with "sprites", you can use a lot of 4-vertex rectangles. If you want to do it without rotation, just don't rotate the bones, etc. If you don't have/want a modern GPU, meshes, etc. you can even just do sprite tiles attached to bones too. Whatever constraints you want to use to get the look/behaviour you like.
All of this applies equally to 3D and 2D work. I've seen it in both all over the place. I could probably easily come up with 100 2D examples if I looked, but I'm not going to spend time on that. Instead I'll just link a video of one of my favourites: Odin Sphere. All of its characters, bosses and otherwise, are animated this way:
https://www.youtube.com/watch?v=-nj6H5TBmcI
This video seems to have a good explanation of the whole concept:
https://www.youtube.com/watch?v=f3Cr8Yx3GGA
Why is this "modern"? Well, you could have a hierarchy of bones in the past, but the main thing that's tricky on old hardware is just the rotation and scaling of bones. You need a good floating point unit to make that turnkey, though it's certainly possible to implement on old hardware too (especially if you can live without rotation/scaling).
As an alternative to pre-made animation, you can use physics to animate bones as well. E.g. if you had something with a long tail, you could make a physical model of a bunch of connected pieces, and attach the bones to those physics objects rather than the other way around. Either way works, actually sometimes the two approaches are blended, e.g. the "inverse kinematics" technique of using a physics system to determine how a player's legs should be placed to stand on an uneven floor, blended with the animated upper body.
Re: How do modern 2D games take care of multijointed bosses?
See Spine and Spriter for examples of software designed specifically for this. It's also sometimes called "puppet animation".
Fun image from this blog post:
puppet vs not.
Fun image from this blog post:
puppet vs not.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: How do modern 2D games take care of multijointed bosses?
I'm guessing Unity probably uses dynamic memory allocated object memory, because it would need to have trees of objects which can be any size at all.