What are you working on currently? (2020)

How would that be related to Fortnite?

Some people, (ahem fortnite addicts ahem,) associate the word “rift” with Fortnite for some reason that’s beyond me.

How is that even possible? :joy:

1 Like

No clue, that’s the first thing someone said to me when I sent it to them, “Is that fortnite?”


Yes, it is. Good job making the audio!

Good luck making more future audios!

Currently, I’m working on frequent updates for my current game Explore And Craft, as well as working on a second (unreleased) game.


DevForum post:


Update on my work, I pretty much completed it! Really proud of myself, though feedback is appreciated. (especially that color palette, makes me think of chocolate :upside_down_face:)

More screenshots here

Ignore the avatar on the sidewalk, I forgot to remove it while doing photos. B’)

If possible, you can check out the work here: Homestore Cafe thing i guess (sold) - Roblox


Wow this took me absurdly long to do. Oh well, here’s the transition for create-a-class. UI still needs to be made, but I had a lot of fun overdoing the transition :smiley:


Love the map. The animations in the video seem smooth and clean as well, however, is the little grid crosshair going to be like a mouse so you’ll be able to click on spawn points because I feel like that’d be a nice little feature. To add on I feel like you could do way better with the UI and potentially make it more modern and aesthetic kind of like Bad Business but add your own unique style onto it (I know you mentioned it's not done but it's feedback) either way good progress since I can see you’re quite dedicated and seem to be working on it constantly which most projects on Roblox fail to do due to lack of motivation or resources.

Ahh I see you. That’s pretty sick.

Clever, I assumed you used “Verlet integration”? You used some fancy formulas, played around with a bit of physics and applied vector math :wink:

Pretty smooth :sunglasses:

Nope! I just generated a grid of parts, and connected SpringConstraints between eachother.


Ohh shoot I had a feeling it was wrong. Never thought of that :joy:
Whelp, this is embarrassing :sweat_smile:

Anyways, the above thing is pretty cool, hehe. (Only if your a math geek)

Preparing to get in the spirit of Halloween.


I am working on a rpg game where you have to find these crystals and level up to as high as you can

Something about the spring on the gun feels off to me. Not sure what, perhaps it feels too rigid? Looking good though otherwise


Just successfully got a custom rigged body using the new mesh-skin deformation technology to use inverse kinematics with joint constraints. As a way to demo this, each body part is trying to get as close to the yellow dot as possible without violating joint constraints. Now that I have this working I can use it to hopefully do some cool environment interaction stuff like open doors with the doorknob, adjust walking animations to have the feet never clip through the ground, and a ton of other fun stuff!



What method are you using for the inverse kinematics especially for the constraints? It looks real smooth and bugfree for the unsolvable cases compared to mine :sob:.

1 Like

New Update in ‘‘The Terrain’’!
There is a little secret what you can find :cowboy_hat_face:,
anyways this is not biggest Update , I want do some BIG Update what will be awsome :smile:

Oh Boi


Heya! Thanks! Lemme do a quick post-mortem. To anyone more knowledgeable in CFrames, I’m not saying this is the best way to do this (I know defining with quaternions is likely more elegant), however, it worked for the task and was within my ability.

Why Euler Angles Aren’t Great for Constraints
Euler angles are an easy to use way to track most rotations, however, it has a small problem when it comes to constraints (and gimbal lock but we don’t need to talk about that right now).


This Vector3 of Euler Angles above, will automatically be translated to:


Now this makes sense when you think about it, however, it can make defining constraints a real headache. So I needed a way to define the rotation that predictibly used numbers within a certain range without too much of a headache.

3D Mapping a Rotation Matrix
This was a bad idea, and isn’t worth discussing in much detail. I hoped to get around the euler angle issue by taking various vector3 directions and plotting them, then defining coordinates within certain zones as safe. This was filled with headaches and scaled horribly and was soon dropped in favor of -

CFrame Axes
I settled on using two axes similiar to a 2 ring gimbal.

Above is a 3 ring gimbal, just ignore the blue ring.

So this is actually what happens behind the scenes with Euler Angles, and is still susceptible to gimbal lock, which is what happens when two axes line up and can’t be rotated further - however, gimbal lock only happens when you use 3 axes.

If I use only two, not only does my job become easier, but I realized most joint movement is definable using only two. There are of course some instances where it isn’t perfect in this, but they’re not super noticeable, such as rotating an arm rather than twisting a wrist. It also defeats gimbal lock as I mentioned earlier.

What really makes this appealing for constraints though is that rotation ends up being defined by only 1 number per ring, and that number is consistently between -180 and 180 (or at least can be easily converted to that without having to reference any other axes).

Using CFrame.fromAxisAngle you can easily simulate a gimbal!

In order to determine the angle of rotation, first define the global cframe with the axis at a degree rotation of 0. You can then multiply the inverse of that cframe upon a global cframe of your target’s position. Using this you can easily get a Vector3 of coordinates. Take the axes of the Vector3 that aren’t parallel with your axis, then use them and math.atan2() to create a rotation angle, which you can use to create a new cframe with the axis rotated by the angle.

Repeat that process with the second ring, basing it off the cframe of the first one when defining the axis direction. Once this is completed you should be pointing directly at your target, and be able to define that angle using two numbers ranging from 180 to -180! (Kind of, sometimes you need to clean up the numbers a bit as described in further detail later)

So for the constraints, all you have to do is set an allowable range of numbers between 180 and -180. If the number falls outside of that range have it round to the nearest cap. Once you have the final constrainted axes, you can easily insert it into a bone as a WorldAxis and a rotated one as a WorldSecondaryAxis, and the bone will auto-line up!

Making it Modular
Now what I described earlier is functional, and will allow you to accomplish your goal. If you want to avoid a lot of duplicate code though you’ll need to take these extra steps.

Start by making a dictionary of each joint type, you can try to make them non-side specific, but you’ll certainly need to flip some constraints when adjusting, so I usually just define the right side first, then directly clone that constraint when the script starts, hard coding in some edits to apply on this clone. For each joint type dictionary entry, have another dictionary of variables.

Here’s what my dictionary looks like:
The axis refer to directions, primary refers to the outside ring, secondary refers to the inside ring locked to the primary ring. The variables like the vector3 directions, and the min/max angles are fairly straightforward and serve to fit the method we discussed earlier. There are some new variables though which are important.

Due to the way that atan2 handles negative numbers, as well as when the opposite and adjacent sides change size as you move, some angles are above 180, and some are negative. In a normal one-off use of this, you can just put in some hard-coded if statements to get everything in the right place. However when using a bunch of different joints all facing different directions we need a shorthand for it.

That shorthand I ended up using was a set of variables such as:

  • Direction: determines what direction the final axis faces
  • TwistDirection: As we lack a 3rd axis, sometimes limbs come out consistently flipped in the wrong direction, TwistDirection allows you to flip it back when you need to.
  • Prim/Sec Offset: Sometimes the calculations come off staggered by sets of 90 degrees, this allows you to offset that 90 degree rotation at the end of each calculation.
  • Prim/Sec Direction: Sometimes the limb is twisting in the opposite direction you want it to go, so this applies a negative sign to the final angle.

Now as these variables are quite interconnected, some may be redundant, however when debugging you will want as many tools as you can possibly get.

This system was a pain to debug.

Unless you’re naturally gifted in visualizing 3D trigonometry (I once thought I was, I’ve changed my mind after this project lol), I highly advise taking the time to make some good debugging tools. I made four which are invaluable.

The first one is setting your entire joint adjust process in a render loop, sending whichever joint you’re working on the goal of trying to reach a specific visualized target V3 in the place. This allows you to instantly see how how the constraints work by moving the character around. In the end I also made the target move to increase this.

The second one is a real-time constraint adjustment UI which allowed me to instantly change certain constraints and watch in real time how it effected how the character tried to reach a goal. This meant that when making a constraint work I didn’t have to constantly try to visualize all the angles and comprehend the movements between tests, I could just randomly try out numbers until I had a working combination.

The third one is an offset line tracker, which created 3 parts aligned with the offset as to trace along each vector the path taken to from your joint to the target. This allowed me to see visually the vector3, which is great for allowing easy comprehension of what distances your joint is being fed to produce the angles. Color coding helps a ton as well.

The final tool, and in my opinion the most important, is a gimble visualization. With this you’ll be able to instantly know that the axes are in the correct direction, as well as less abstractly determine what rotations are being used to get to a certain final direction.

Performance is an area it is limited in. Currently adjusting an entire body’s worth of important joints (around 12) takes about 0.002 seconds. As the amount of time available per frame at 60 fps is 0.016, this takes up around 10-15% of that time. It can certainly be optimized, however if your game is already struggling with performance issues a full IK rig with procedural animations might not be for you. One way I plan on optimizing mine is to only use IK when necessary, relying on normal animations otherwise.

Another limitation mentioned earlier was that certain movements are not perfect analogs for an IRL body due to removing that third axis. You could certainly integrate it into the design, however that does open you up to problems with gimbal lock. To my knowledge the best ways to overcome gimbal lock are rotation matrices and quaternions. However I tried using rotation matrices and it was quite difficult, and I still only barely comprehend quaternions, so for the average dev I would advise against trying these approaches unless you really know what you’re doing.

Good luck!


Here is a quick song I made, I mean it ain’t the best, but, it’s ok I guess. The genre is midtempo for those who don’t know. Enjoy!!