I have greatly underestimated how much work it is to make a content-dense video. From here on, I may continue to make these videos as I come across sufficiently interesting problems, at a reduced upload rate, for this channel. Smaller dev updates will move over to my twitter account. Let me know if this makes sense.
I would prefer to have more smaller videos. Even if it would mean they're going to be on the same subject. This game is a journey and we are in it together!
This video must have taken so much work to create. It really shows. I'm still eager to learn more about your pixel art game engine. How long did it take you to make? What inspired you to start work on your current game? What were some big hurdles, etc. When I try to make videos I fall into the trap of everything being very formal, well edited and with good visuals, but I would really appreciate a short video of you sitting down with little to no script and just talking about your project as if it were show and tell.
It makes sense to have the content more organized and spread on/exclusive to other platforms but i feel it'd be good to have the shorter videos on youtube as well since that makes it easier for your main audience to keep up with the project. Also yt likes consistency so maybe that'll also help reach more people?
The production value on those input curves is through the roof just to illustrate the mapping. Such a captivating delivery. You've really made me interested in looking for more mathematical interpretations of game concepts.
This is actually a very interesting problem, because in top-down games, the player's angular input is expected to map directly to a world angle, as opposed to say FPS aim assist, were you're only manipulating the 1st derivative of your aim position. I was surprised when I realized the math is going to be totally different. I took a similar approach to you, however ran into a problem further down the road: When the entity I'm currently aim-assisted towards dies (eg something else kills it) or blinks away, the mapping function suddenly changes. The region around the player's current input sudden snaps back to the identity function, causing the player to perceive a jump in the output position despite holding their input angle steady. This temporal discontinuity was very jarring and violated the player expectation that "if I hold my finger still, so should my aiming line". I ended up implementing essentially the same function, but on the first derivative. That way, if the curve "changes behind the scenes" you wouldn't notice any discontinuity, only that passing back to the area now feels "faster" than before. This creates a new problem, which is that you will accumulate angular error, where after all targets are eliminated, a player input of "due north" may no longer map to due north in the game world! I ended up solving this by tracking how much error there is between player input and game world output, keeping that as a "debt to be repaid". Whenever the player input angle changes, I "pay back small amounts of debt", hiding the error inside of motion. If the player input changes dramatically enough (e.g., a 90 degree sudden change) I just pay back the debt all at once, and it is not noticeable to the player.
great comment! I had the exact same thoughts and came to a very similar solution. accumulate "debt" as you put it to avoid time discontinuities, and pay it back at a rate proportional to the input speed.
Late reply, but it sounds like you've independently arrived at many of the principles of what's known as "Proportional Integral Derivative" Control, or "PID". I'd highly recommend looking more into the topic! PID can apply to LOADS of concepts (motors, capacitors, human senses, etc)
I was not expecting this much value and professionality for a small channel, you really deserve a lot more! Just that math animation you made god knows how long it took
Very nice vizualisations for the aim assist properties in terms of "real vs felt" angles, love these focus videos. They always make me think of shorter, focused GDC conferences
I can't even imagine how long this took to make, but I think it was worth the effort. Making content like this helps to push us as an indie dev community forward. I'm really excited to see what other cool solutions you come up with!
Amazing job showing the math behind aim assist. This made me think of bullet magnetism from games like Halo, where the vector of the bullet is adjusted instead of the rotation of the player. Magnetism is the same thing as aim assist, just less obtrusive because it doesn't rotate the player, and I believe it's better because it doesn't effect the sensitivity of your rotation input like aim assist does, which could harm the consistency of movement or platforming mechanics.
in 2D I guess this is equivalent to having a separate vector for projectile aiming (which gets assist) and player movement (which stays raw). This is sort of how death's door works (it aims the projectile vector secretly in the background) like you say, fundamentally it's the same thing, but I agree that the nuance of separating the two vectors is meaningful thing to do. thanks for the comment.
I always love it everytime you flex your brain muscles and share what's inside it. The production quality this time is magnitudes higher than the usual, too. Man, I can just imagine how much that taxed you. Thank you for your hard work! Looking forward to more of your brain flexes!
first of all, thank you for your hard work, all those motion graphics and editing must have taken a lot of time and effort, it was very good and helped visualize things better. while I didn't understand the math you were showing, your explanation was enough to give ideas and maybe even sell me to learn it lol. Also, I have been following your stuff for what feels like years I think and you are making good progress, it's very nice to see. hope the full game or project comes out as you want. I am doing gamedev too but I am a beginner at best I guess so you motivate me a lot. please keep going and have a good time.
I was thinking about how to handle objects that occlude eachother, that's probably the thing that most aim assists handle badly. But to solve this I would like to abstract this further and think of enemies as simple arc segments, and that those arc segments just overlay ontop of eachother. Then you make the aim assist only consider those arc segments when attempting to aid the player, or more likely the ends of those arc segments. That makes it easier to finetune a function for aim assist as you cut away a lot of nuances and automatically solve the issues of enemies obscuring other enemies and enemies being that are obscured by objects, at least so long as your aim assist doesn't lock on to your target. But I could also see issues cutting away that much nuance, as you could lose information that you find actually quite important, like distance, speed, size, what type of target it is etc.
I really appreciate that you talk about the subject at a higher level mathematically than most game developers do. Really goes to show that this is a channel aimed at professionals
These videos are 1. Very well explained and exceedingly helpful 2. Incredibly pleasing to watch the animations of 3. Make me want to play the game you made very very much.
I'm not a game dev so I didn't think I'd watch all 11 minutes but yeah, I'm glad I did. This was well made video and everything was explained super well. Great work.
Dude... I *LOVE* your video style. Explaining technical problems with an aesthetic/intuitive focus on the artistic understanding of the problem really helps me grasp how to start thinking about solving the proble instead of not fully understanding what the problem is (just knowing that it "doesn't feel right.")
These are the kinds of videos I love sharing with my math and CS friends as educational and motivational displays of what uses their university maths can be applied to!
incredible video. there’s a deep discontinuity between tutorials that teach you how to quickly scaffold a mechanic and videos that change your entire thought process and frameworks. well done
You could also make a narrow range within each target that deals more damage or modifies projectile or enemy function in some form, to still reward precision. Like a critical hit sort of thing.
Currently studying computer science to find applications on game dev I always want to find a gamedev channel that use more complex math to solve problems, so I already love this channel
This is so good! And I'm getting more and more excited to see where your game ends up, anyhow I'm sure it'll be satisfying! Learning Manim, creating fitting visuals and setting such high standards for video quality, no wonder it takes time! These kinds of videos makes my math heart so happy! I would've loved to join SOME myself, but had trouble prioritizing it - But I'm curious - do you think it'll take significantly less time to make a second similar-type video, now that you've gone through the process of making one, learning Manim etc.?
I still haven't figured out a good workflow for synchronizing the manim animations to audio track while still managing to iterate on the visuals/script. I think the cost of iterating on small details was probably the biggest time sink for this particular video.
I love the way these videos seem to take things intuitive to game design and put a new perspective on it to ask critical questions. I don’t create games but the struggle of bad aim assist is very relatable, and the idea of graphing inputs and outputs on an x-y graph was insanely novel, I love it!
I wrote an Aim Assist system for a First/Third Person shooter, primarily using the Resistance 3 GDC talk as a template. I broke it into two components, what I called "Aim Magnetism" and "Aim Forgiveness." Magnetism was an additive/subtractive layer blended into the user's inputs, essentially letting the game nudge and pull the user towards targets they were aiming close to. Forgiveness was a system that worked out the correct direction from the player's weapon to hit the nearest target, which we could blend into the actual fire direction, improving the player's chance to hit without obvious snapping of their camera, something which is far more jarring in a 1st/3rd person perspective.
Holy shit man, you're a genius. You explain things well and make me interested in mathematics I never thought useful to me. And you're very wellspoken and humble. Good luck on your game!
I notice this problem most in Hades when playing the Aspect of Lucifer on the gun-good luck trying to target your hellfire ball if there’s an enemy near it (which is the only time you’d want to target it)
Excellent video! Thank you so much for taking the time to make this. These problems are part why I love programming so much; taking on an issue that from the outside you can hardly see is there, and thereby discovering and exploring all the intricate ways one can solve them.
Not an experienced game designer here, but an interesting game to look at is CrossCode. It has amazing combat and also dedicated buttons for melee and ranged projectile attacks. That game actually has zero aim assist for projectiles, but it still feels good, even though it is harder to hit small targets. I think that game balances it by giving you large projectiles to shoot ( instead of arrows or bullets ) and having large enemies. Smaller enemies are intended to be hard to hit and the game wants you to use melee for large amounts of small enemies. Isn't having large projectiles basically a form of aim assist? An idea for aim assist for small hit-scan projectiles (like bullets) would be them actually having a large hitbox, and whenever they detect a hit the visual projectile gets corrected to hit the target. That way you could work around having a snapping system like this at all and avoid some of the additional problems you've shown towards the end. Amazing video by the way, always a great source of inspiration.
Good comment. One slight difference I see with large hitboxes is that they can't thread needles. Otherwise I agree that large projectiles (or equivalently, large enemy hitboxes) are a good way to solve the problem. The projectiles in CrossCode were very functional, and their tactical use was very satisfying, but they were mostly used on very slow moving or stationary targets. It's pretty much impossible to aim and hit Apollo with balls. At least for me.
I also think that the "small bullet big hitbox" solution would be potentially more visually jarring, seeing a shot that is clearly going to the miss wide but suddenly hits.
@@ninjahappysquid That's why I said they would be hitscan, with the visual representation being corrected on attack. Like you said, it would look bad on small projectiles that actually move through the world. :^)
Thoroughly enjoyed. The visualizations are really nice. As mentioned at 10:18, that the production budget is exceeded, just know that it is perfectly fine to skip doing things like: at 8:04, satisfying to watch, but the only person who is gonna see that more than once is you cause you edit the video.
it's actually pretty easy to do that stuff with the right tools! I think that fade out animation probably only took a minute or two to write. It's the script revisions and math visualizations that end up taking the most time for me, since those are the important things to get right or viewers will get lost
Wow man, another great content video, really appreciate visual explanation and effort you have put in to explain this in consumable manner instead of pure abstraction. Bravo sir.
This is an amazing video and totally not what i expected from subscribing to an interesting journey about developing your game But im very glad you created this, its amazing!
I just want to say, I've learned so much and have gained so much inspiration from your videos. This technical approach to game design problems is truly something novel. Thank you for doing what you do.
Amazing video! Great quality and detail! We are exactly the same in the sense that you put too much time into your side projects. I call them rabbit holes. They always lead me much further from my game than I plan. I completely agree that the aim assist system should prioritize vectors or angles, rather than redirecting them entirely. But your video brought several things to my attention that I had not considered before.
Wowie! That was extremely engaging. Great job! The amount of work you put into it really shows (using manim for the interim math explanations was a great idea)!
The only issue I can see is that the slope between targets must remain linear i.e., f(x) = x, or input mapping between targets will result in varying sensitivity. One way to solve this would be to refer to the target lock method, and retain the snapping functionality, but smoothing the sudden discontinuities. Therefore, each target would have a sharp 'entry' and 'exit', while remaining flattest, and equal to x, at the centre of the target. Other than that, this was an extremely intriguing video, referencing a problem I've encountered but never approached directly.
I did something like this (but not as good, derived with much less math know-how) years ago but this looks even better! I'm glad the idea is seeing the light of day since I failed to ever share it or release something using it.
Awesome work... I really never thought of any aim assistant beyond the plain snapping solution... I hope to reach that level of professionalism once in my future devlogs! :)
These videos are so informative and interesting, thank you for putting in the effort. You’ve inspired me to look deeper at the mathematical opportunities in my game.
I've only watched two of your videos so far, but your approach to things seems to be to generalise a problem to a mathematical form and rearrange it until your inputs are intuitively describable such that you as a game designer can tailor an experience. Seems pretty cool.
For a mouse you could just get the regular pointer location, calculate the rotation and use that as on the graph. Visualize the cursor with the curve would make it feel inconsistent but showing a secondary aim cursor would solve that. Or maybe the assist is subtle enough not to affect the experience of mouse movement. It could certainly be lower than on a controller. But still be nice for someone who needs it. Accessibility in games is very important.
It's important to consider that the aim assist should not disengage if an enemy is outside of the weapon's range, it should disengage only when the anticipated collision between the enemy's predicted movement and the projectile occurs outside of the wapon's range
This is outstanding and awe-inspiring. I love what you've done. I'm hoping to make a game with this level of quality and beauty. This is a wonderful inspiration for me. Thank you
So far, I have seen two pf your videos and they were both stellar in both technical content and presentation. Formme, you are on par of the best UA-camrs in this field and I am fhankful for yoursuperb work. Thank you a lot and all the best wishes =)
I also just noticed that both my views were your last two videos. As these represent the stellar quality I was talking about, your question in your own comment should be answered with "well yes the videos are rarer, but they are worth it!"
A big thing that could solve this is giving player the ability to set their own priority. It is similar to how Fast Travel is an option in games and in turn doesn't need fancy mechanics for an open world. It works for those who want it and those who don't want it will ignore it. If there is 20 enemies being able to give an enemy a score from 1-20 (If you met them) lets you decide what is most important for you. Or better yet games can design enemies to "taunt" the player letting them be one of the few that can force targeting and create unique situations. Use the downsides to become a strength.
This is exactly the type of problem I love solving yet would never be able to solve in a big studio because of time constraints and perceived roi of the endeavor. Those details are what make a game feel great though imo.
Coming at this from the perspective of a player with no game design experience, I'd like to see something like a smoothed version of the graph at 7:13. Graphs like the one at 6:18 seem to have the problem that if there are many targets grouped up on one side, the slope would get really steep on the other side. That would have a significant effect on the player's aim when they are not aiming near the targets, and I would get really annoyed if I had to aim 30° off of where I want to aim for me to hit. Great video though, very entertaining and informative.
This is a really good comment. I'd seen that something didn't feel right with the standard smoothing described in the video, but couldn't put my finger on it. This is absolutely what was bugging me
This framing of aim assist is fantastic, well done. IMO, one constraint missing from your model is that the function should be smooth with respect to its first derivative. In particular when "wrapping" round "past" 360°, the first derivative should be continuous unlike what is shown at 7:50.
I think the best way of aim assist is activating the system whenever the player shoots! So it will feel like player can aim smoothly (without any snapping) but at the firing state it will be much more easy to shoot at the target!
This man: I will use maths to solve the problem! My lazy ass: Make it aoe! But seriously, I never really liked aim assist on top-down games since it always feel like it's either between janky or irrelevant, so having another new idea presented in a really clear way is really great.
You mentioned balancing for mouse control vs stick control. For mouse control, it would be natural to interpret the exact position of the cursor as more likely being on target than anything else in the same general direction. Or putting it another way, since the cursor allows the player to express both an intended direction and distance of aiming, whatever portion of the aim assist logic uses distance information should probably prioritize distances closer to the cursor distance rather than prioritizing smaller distances. Translating that to stick controls is an interesting question. Maybe the best choice is to just revert to prioritizing smaller distances. But the control stick does still convey both direction and distance that the player pushes the stick, so it seems wasteful to ignore the distance information. It gets tricky though. Using more distance of the stick to mean more distance on the aiming priority seems intuitive, but a player suddenly reacting to a nearby threat is probably going to slam the stick in that direction and not bother with being nuanced about the distance. It might make sense then to also use information about the recent rate of change of stick direction to interpret the intention. A large sudden change of direction likely indicates reaction to an imminent threat, so prioritize distance from the player rather than interpreting stick distance. A fast back-and-forth wiggle of the stick within a small angle likely indicates frustration with the aim assist and trying to make it lock onto something else within that angle window, so then switch to a new target in the direction of the initial wiggle away from the old target, and maybe start using stick distance as an indication of intended target distance. Maybe that can be simplified somewhat. First, decide some thresholds of what 'rapid' means. A rapid change of both direction and distance likely means the player is slamming the stick radically in the direction of a nearby threat, so prioritize smaller distances from the player. A rapid change of direction but not distance likely means the player is jiggling the stick to try to switch targets, so prioritize the next target over according to that change in direction. A change of distance without rapid change of direction likely means the player is trying to express an intended distance of the target, so map the distance of the stick to an intended aiming distance between 0 and the maximum range of the weapon.
A game I’ve played that really strikes this home is the lego batman series. Lego batman one had an aim assist that was brutal for the batarang, but by 3 they had tuned it just beautifully
awesome video on a subject that has bugged me greatly before. The approach that I've wanted to play with is weighting all potential targets within the zone then selecting the highest overall value. The directionality system you've described could play a significant role in that weighting, allowing for a more nuanced understanding of "which is the player actually pointing" than raw stick inputs. You could potentially even have an output be less "aim at this target" and more "aim in this direction". That may sound sorta weird, but it would allow you to do things like check if objects overlap from the pov of the avatar, and aim for that intersection. That would help with your "what if a target is hiding behind another target?" condition. Weighting could be arbitrary values paired with conditionality like AoE, in combat, nearness, etc.
I am so happy to have found your channel. This is pure beauty! Thank you for providing a mathematical definition to game design problems. Your visualizations are incredibly helpful and clean. They remind me of 3Blue1Brown channel. Can you share what tool you use to make your graphs and real-time modification of x and how it shows in f(x) in the graph? I'm definitely subscribing and turning notifications on. Keep on the great work!
The way you describe the aim assist curve instantly makes me think of Destiny 1 and 2 by Bungie who are known for their excellent shooting controls using a controller.
Holy shit. You have basically done 50% of the work of writing a scientific paper on this, this is something at the level of 3blue1brown This video made me realize we need more research into videogame design, and I'm happy to be here waiting for this channel to explode even more.
I have greatly underestimated how much work it is to make a content-dense video. From here on, I may continue to make these videos as I come across sufficiently interesting problems, at a reduced upload rate, for this channel. Smaller dev updates will move over to my twitter account. Let me know if this makes sense.
I would prefer to have more smaller videos. Even if it would mean they're going to be on the same subject. This game is a journey and we are in it together!
This video must have taken so much work to create. It really shows.
I'm still eager to learn more about your pixel art game engine. How long did it take you to make? What inspired you to start work on your current game? What were some big hurdles, etc. When I try to make videos I fall into the trap of everything being very formal, well edited and with good visuals, but I would really appreciate a short video of you sitting down with little to no script and just talking about your project as if it were show and tell.
Anything from you will be great anyway ^_^ ! Do what you feel is best for you
I love your videos very much. Have you thought about opening a Patreon?
It makes sense to have the content more organized and spread on/exclusive to other platforms but i feel it'd be good to have the shorter videos on youtube as well since that makes it easier for your main audience to keep up with the project. Also yt likes consistency so maybe that'll also help reach more people?
The production value on those input curves is through the roof just to illustrate the mapping. Such a captivating delivery. You've really made me interested in looking for more mathematical interpretations of game concepts.
thanks! means a lot.
@@t3ssel8r Did you create them using Manim?
@@ThisIsTheInternet yeah
Kämpfer ?!
@@Bloody_River Yup, my pfp is from Kämpfer.
The video turned out amazing!
It was absolutely worth the wait
thanks!
Well, hello there
I love how at 10:18, the abstract representation transitions perfectly into the game. Amazing attention to detail.
While complaining about how much work making the video was! 😄😄😄
🤯🤯🤯
This is actually a very interesting problem, because in top-down games, the player's angular input is expected to map directly to a world angle, as opposed to say FPS aim assist, were you're only manipulating the 1st derivative of your aim position. I was surprised when I realized the math is going to be totally different.
I took a similar approach to you, however ran into a problem further down the road: When the entity I'm currently aim-assisted towards dies (eg something else kills it) or blinks away, the mapping function suddenly changes. The region around the player's current input sudden snaps back to the identity function, causing the player to perceive a jump in the output position despite holding their input angle steady. This temporal discontinuity was very jarring and violated the player expectation that "if I hold my finger still, so should my aiming line".
I ended up implementing essentially the same function, but on the first derivative. That way, if the curve "changes behind the scenes" you wouldn't notice any discontinuity, only that passing back to the area now feels "faster" than before.
This creates a new problem, which is that you will accumulate angular error, where after all targets are eliminated, a player input of "due north" may no longer map to due north in the game world! I ended up solving this by tracking how much error there is between player input and game world output, keeping that as a "debt to be repaid". Whenever the player input angle changes, I "pay back small amounts of debt", hiding the error inside of motion. If the player input changes dramatically enough (e.g., a 90 degree sudden change) I just pay back the debt all at once, and it is not noticeable to the player.
great comment! I had the exact same thoughts and came to a very similar solution. accumulate "debt" as you put it to avoid time discontinuities, and pay it back at a rate proportional to the input speed.
I love how intuitively you explained your solution, thanks for the comment!
Late reply, but it sounds like you've independently arrived at many of the principles of what's known as "Proportional Integral Derivative" Control, or "PID". I'd highly recommend looking more into the topic! PID can apply to LOADS of concepts (motors, capacitors, human senses, etc)
@@zappergames4785 ooo that seems interesting
@@zappergames4785 That's awesome! I will check this out.
I was not expecting this much value and professionality for a small channel, you really deserve a lot more! Just that math animation you made god knows how long it took
if he deserves more, you can help by sharing this video on your social media ☺
Very nice vizualisations for the aim assist properties in terms of "real vs felt" angles, love these focus videos. They always make me think of shorter, focused GDC conferences
I too am a big fan of the GDC deep dives
@@t3ssel8r there's no such thing as too big
I can't even imagine how long this took to make, but I think it was worth the effort. Making content like this helps to push us as an indie dev community forward.
I'm really excited to see what other cool solutions you come up with!
Amazing job showing the math behind aim assist. This made me think of bullet magnetism from games like Halo, where the vector of the bullet is adjusted instead of the rotation of the player. Magnetism is the same thing as aim assist, just less obtrusive because it doesn't rotate the player, and I believe it's better because it doesn't effect the sensitivity of your rotation input like aim assist does, which could harm the consistency of movement or platforming mechanics.
in 2D I guess this is equivalent to having a separate vector for projectile aiming (which gets assist) and player movement (which stays raw). This is sort of how death's door works (it aims the projectile vector secretly in the background)
like you say, fundamentally it's the same thing, but I agree that the nuance of separating the two vectors is meaningful thing to do. thanks for the comment.
I always love it everytime you flex your brain muscles and share what's inside it.
The production quality this time is magnitudes higher than the usual, too. Man, I can just imagine how much that taxed you.
Thank you for your hard work! Looking forward to more of your brain flexes!
first of all, thank you for your hard work, all those motion graphics and editing must have taken a lot of time and effort, it was very good and helped visualize things better. while I didn't understand the math you were showing, your explanation was enough to give ideas and maybe even sell me to learn it lol.
Also, I have been following your stuff for what feels like years I think and you are making good progress, it's very nice to see. hope the full game or project comes out as you want. I am doing gamedev too but I am a beginner at best I guess so you motivate me a lot. please keep going and have a good time.
I like that you’re making tutorials now, your game inspires me and its awesome to see an interesting 3blue1brown-esk video on the topic
I was thinking about how to handle objects that occlude eachother, that's probably the thing that most aim assists handle badly. But to solve this I would like to abstract this further and think of enemies as simple arc segments, and that those arc segments just overlay ontop of eachother. Then you make the aim assist only consider those arc segments when attempting to aid the player, or more likely the ends of those arc segments. That makes it easier to finetune a function for aim assist as you cut away a lot of nuances and automatically solve the issues of enemies obscuring other enemies and enemies being that are obscured by objects, at least so long as your aim assist doesn't lock on to your target. But I could also see issues cutting away that much nuance, as you could lose information that you find actually quite important, like distance, speed, size, what type of target it is etc.
Despite finding it difficult to understand, you explain it in such a way that makes sense without knowing how to code
I really appreciate that you talk about the subject at a higher level mathematically than most game developers do. Really goes to show that this is a channel aimed at professionals
makes us mathematcally minded people whoe are not into game dev more invested and the video easier to understand as well
The 3blue1brown of game dev. Insane channel.
I doubt most game studios have such a math centric approach to gameplay.
This is something I noticed a lot while playing EtG, good video.
These videos are
1. Very well explained and exceedingly helpful
2. Incredibly pleasing to watch the animations of
3. Make me want to play the game you made very very much.
the only time i actually open a youtube notification
I'm not a game dev so I didn't think I'd watch all 11 minutes but yeah, I'm glad I did. This was well made video and everything was explained super well. Great work.
Dude... I *LOVE* your video style.
Explaining technical problems with an aesthetic/intuitive focus on the artistic understanding of the problem really helps me grasp how to start thinking about solving the proble instead of not fully understanding what the problem is (just knowing that it "doesn't feel right.")
These are the kinds of videos I love sharing with my math and CS friends as educational and motivational displays of what uses their university maths can be applied to!
this is pragmatic heaven born from math instead of simple logic. beautiful
The visuals in this video were really helpful for understanding the concept, good video!
incredible video. there’s a deep discontinuity between tutorials that teach you how to quickly scaffold a mechanic and videos that change your entire thought process and frameworks. well done
It's always a good day when t3ssel8r uploads
You could also make a narrow range within each target that deals more damage or modifies projectile or enemy function in some form, to still reward precision. Like a critical hit sort of thing.
I don't think I have anything to contribute here besides saying this looks amazing and I always look forward to your videos! Keep up the great work!
Currently studying computer science to find applications on game dev I always want to find a gamedev channel that use more complex math to solve problems, so I already love this channel
This is so good! And I'm getting more and more excited to see where your game ends up, anyhow I'm sure it'll be satisfying!
Learning Manim, creating fitting visuals and setting such high standards for video quality, no wonder it takes time! These kinds of videos makes my math heart so happy! I would've loved to join SOME myself, but had trouble prioritizing it -
But I'm curious - do you think it'll take significantly less time to make a second similar-type video, now that you've gone through the process of making one, learning Manim etc.?
I still haven't figured out a good workflow for synchronizing the manim animations to audio track while still managing to iterate on the visuals/script. I think the cost of iterating on small details was probably the biggest time sink for this particular video.
I love the way these videos seem to take things intuitive to game design and put a new perspective on it to ask critical questions. I don’t create games but the struggle of bad aim assist is very relatable, and the idea of graphing inputs and outputs on an x-y graph was insanely novel, I love it!
I wrote an Aim Assist system for a First/Third Person shooter, primarily using the Resistance 3 GDC talk as a template. I broke it into two components, what I called "Aim Magnetism" and "Aim Forgiveness." Magnetism was an additive/subtractive layer blended into the user's inputs, essentially letting the game nudge and pull the user towards targets they were aiming close to. Forgiveness was a system that worked out the correct direction from the player's weapon to hit the nearest target, which we could blend into the actual fire direction, improving the player's chance to hit without obvious snapping of their camera, something which is far more jarring in a 1st/3rd person perspective.
this channel is pure condensed game design progress and thought, it’s amazing
i love that grapple mechanic you showed near the end
Wow, the quality of this channel is just beautiful
Holy shit man, you're a genius. You explain things well and make me interested in mathematics I never thought useful to me. And you're very wellspoken and humble. Good luck on your game!
That was a clear explanation of unclear math, loving everything you’re doing
I'm not a game developer, but this video and your approach of using math are both fascinating. And your teaching skills are great, congratulations!
I really love how you dig into details with the mathematics rather than only the coding, makes it more interesting. Maybe that's just me.
I notice this problem most in Hades when playing the Aspect of Lucifer on the gun-good luck trying to target your hellfire ball if there’s an enemy near it (which is the only time you’d want to target it)
I've been waiting for soo looong. It's still the best
your videos are so captivating. I clicked on this video out of accident and spent one of the best 10 minutes of my life.
Excellent video! Thank you so much for taking the time to make this.
These problems are part why I love programming so much; taking on an issue that from the outside you can hardly see is there, and thereby discovering and exploring all the intricate ways one can solve them.
Not an experienced game designer here, but an interesting game to look at is CrossCode. It has amazing combat and also dedicated buttons for melee and ranged projectile attacks. That game actually has zero aim assist for projectiles, but it still feels good, even though it is harder to hit small targets. I think that game balances it by giving you large projectiles to shoot ( instead of arrows or bullets ) and having large enemies. Smaller enemies are intended to be hard to hit and the game wants you to use melee for large amounts of small enemies.
Isn't having large projectiles basically a form of aim assist? An idea for aim assist for small hit-scan projectiles (like bullets) would be them actually having a large hitbox, and whenever they detect a hit the visual projectile gets corrected to hit the target. That way you could work around having a snapping system like this at all and avoid some of the additional problems you've shown towards the end.
Amazing video by the way, always a great source of inspiration.
Good comment. One slight difference I see with large hitboxes is that they can't thread needles. Otherwise I agree that large projectiles (or equivalently, large enemy hitboxes) are a good way to solve the problem.
The projectiles in CrossCode were very functional, and their tactical use was very satisfying, but they were mostly used on very slow moving or stationary targets. It's pretty much impossible to aim and hit Apollo with balls. At least for me.
I also think that the "small bullet big hitbox" solution would be potentially more visually jarring, seeing a shot that is clearly going to the miss wide but suddenly hits.
@@ninjahappysquid That's why I said they would be hitscan, with the visual representation being corrected on attack. Like you said, it would look bad on small projectiles that actually move through the world. :^)
Thoroughly enjoyed.
The visualizations are really nice.
As mentioned at 10:18, that the production budget is exceeded, just know that it is perfectly fine to skip doing things like: at 8:04, satisfying to watch, but the only person who is gonna see that more than once is you cause you edit the video.
it's actually pretty easy to do that stuff with the right tools! I think that fade out animation probably only took a minute or two to write. It's the script revisions and math visualizations that end up taking the most time for me, since those are the important things to get right or viewers will get lost
Wow man, another great content video, really appreciate visual explanation and effort you have put in to explain this in consumable manner instead of pure abstraction. Bravo sir.
you are very talented in many fields
- programming
- math
- art
- ux
that's impressive
This is an amazing video and totally not what i expected from subscribing to an interesting journey about developing your game
But im very glad you created this, its amazing!
Jesus Christ! Math? Being useful in a real problem? With proper visualization and explanation? I've never seen that before, you're a god!
I just want to say, I've learned so much and have gained so much inspiration from your videos. This technical approach to game design problems is truly something novel. Thank you for doing what you do.
Super interesting! i 100% deaths door and never noticed the aim assist, maybe im just That Bad at aiming
I am Software engineer, but after watching your videos the respect highly increase and I am nothing in compare with you guys
Amazing video! Great quality and detail! We are exactly the same in the sense that you put too much time into your side projects. I call them rabbit holes. They always lead me much further from my game than I plan. I completely agree that the aim assist system should prioritize vectors or angles, rather than redirecting them entirely. But your video brought several things to my attention that I had not considered before.
Wowie! That was extremely engaging. Great job! The amount of work you put into it really shows (using manim for the interim math explanations was a great idea)!
Indiscovered this channel on a rabbit hole session. And im here to STAY
so useful not only in the realm of gamedev but also for any human/machine interaction
The only issue I can see is that the slope between targets must remain linear i.e., f(x) = x, or input mapping between targets will result in varying sensitivity. One way to solve this would be to refer to the target lock method, and retain the snapping functionality, but smoothing the sudden discontinuities. Therefore, each target would have a sharp 'entry' and 'exit', while remaining flattest, and equal to x, at the centre of the target.
Other than that, this was an extremely intriguing video, referencing a problem I've encountered but never approached directly.
I did something like this (but not as good, derived with much less math know-how) years ago but this looks even better! I'm glad the idea is seeing the light of day since I failed to ever share it or release something using it.
I am amazed at how good your game looks and the amount of detail you consider in every step of the process. Wish nothing but success onto you🙏🏻
Cool work!
I am just starting my own implementation of aim assist and this video provides a great starting for me to build upon. Thanks t3ssel8r
Awesome work... I really never thought of any aim assistant beyond the plain snapping solution... I hope to reach that level of professionalism once in my future devlogs! :)
These videos are so informative and interesting, thank you for putting in the effort. You’ve inspired me to look deeper at the mathematical opportunities in my game.
I've only watched two of your videos so far, but your approach to things seems to be to generalise a problem to a mathematical form and rearrange it until your inputs are intuitively describable such that you as a game designer can tailor an experience.
Seems pretty cool.
The production value of this video is impressive. Great job!
This is amazing. As a mathematician I'd love to explore this concept. Very interesting!
For a mouse you could just get the regular pointer location, calculate the rotation and use that as on the graph.
Visualize the cursor with the curve would make it feel inconsistent but showing a secondary aim cursor would solve that. Or maybe the assist is subtle enough not to affect the experience of mouse movement. It could certainly be lower than on a controller. But still be nice for someone who needs it. Accessibility in games is very important.
It's important to consider that the aim assist should not disengage if an enemy is outside of the weapon's range, it should disengage only when the anticipated collision between the enemy's predicted movement and the projectile occurs outside of the wapon's range
your videos never dissapoint and are always a source of inspiration. Congratulations on an amazing channel!
This is outstanding and awe-inspiring. I love what you've done. I'm hoping to make a game with this level of quality and beauty. This is a wonderful inspiration for me. Thank you
So far, I have seen two pf your videos and they were both stellar in both technical content and presentation. Formme, you are on par of the best UA-camrs in this field and I am fhankful for yoursuperb work. Thank you a lot and all the best wishes =)
I also just noticed that both my views were your last two videos. As these represent the stellar quality I was talking about, your question in your own comment should be answered with "well yes the videos are rarer, but they are worth it!"
A big thing that could solve this is giving player the ability to set their own priority.
It is similar to how Fast Travel is an option in games and in turn doesn't need fancy mechanics for an open world. It works for those who want it and those who don't want it will ignore it.
If there is 20 enemies being able to give an enemy a score from 1-20 (If you met them) lets you decide what is most important for you. Or better yet games can design enemies to "taunt" the player letting them be one of the few that can force targeting and create unique situations. Use the downsides to become a strength.
I'm so glad i found your channel, bell icon activated, can't wait for the next one, thank you so much!
your videos make me wanna learn game design
Damn what a wonderful video!! Awesome job on the explanations wonderful job on the animations -- low key had some 3B1B vibes with the graphs
This is incredible! Great job, man. Subbed
excellent visualizations!
Another good question is lock on for pricing with lined up enemies, since that is a common machanic for a lot of games
such a cool way of visualizing this
This is exactly the type of problem I love solving yet would never be able to solve in a big studio because of time constraints and perceived roi of the endeavor.
Those details are what make a game feel great though imo.
neat. Simple, good solution, and easy to understand
Late and other have mentioned this here, but the principles of feedback control systems analysis (such ad PID controllers) can be super useful here.
that's what this video already sort of is isn't it? or is there something else you have in mind?
Thank you for showing people how amazing math is
Such a simple idea, just brilliant! Thanks!
Solid understanding of your algorithms
Coming at this from the perspective of a player with no game design experience, I'd like to see something like a smoothed version of the graph at 7:13. Graphs like the one at 6:18 seem to have the problem that if there are many targets grouped up on one side, the slope would get really steep on the other side. That would have a significant effect on the player's aim when they are not aiming near the targets, and I would get really annoyed if I had to aim 30° off of where I want to aim for me to hit. Great video though, very entertaining and informative.
This is a really good comment. I'd seen that something didn't feel right with the standard smoothing described in the video, but couldn't put my finger on it. This is absolutely what was bugging me
I think the mathematical restriction he imposed on maximum correction amount would catch that (this was one of his theoretical constraint points)
this is great, can tell you put your whole self into this, thanks for your work
I cannot believe what I am seeing it with my eyes! LOOL TY SO MUCH!
This framing of aim assist is fantastic, well done. IMO, one constraint missing from your model is that the function should be smooth with respect to its first derivative. In particular when "wrapping" round "past" 360°, the first derivative should be continuous unlike what is shown at 7:50.
I think the best way of aim assist is activating the system whenever the player shoots! So it will feel like player can aim smoothly (without any snapping) but at the firing state it will be much more easy to shoot at the target!
You are an excellent instructor. I will stick with you.
This man: I will use maths to solve the problem!
My lazy ass: Make it aoe!
But seriously, I never really liked aim assist on top-down games since it always feel like it's either between janky or irrelevant, so having another new idea presented in a really clear way is really great.
You mentioned balancing for mouse control vs stick control. For mouse control, it would be natural to interpret the exact position of the cursor as more likely being on target than anything else in the same general direction. Or putting it another way, since the cursor allows the player to express both an intended direction and distance of aiming, whatever portion of the aim assist logic uses distance information should probably prioritize distances closer to the cursor distance rather than prioritizing smaller distances.
Translating that to stick controls is an interesting question. Maybe the best choice is to just revert to prioritizing smaller distances. But the control stick does still convey both direction and distance that the player pushes the stick, so it seems wasteful to ignore the distance information. It gets tricky though. Using more distance of the stick to mean more distance on the aiming priority seems intuitive, but a player suddenly reacting to a nearby threat is probably going to slam the stick in that direction and not bother with being nuanced about the distance. It might make sense then to also use information about the recent rate of change of stick direction to interpret the intention. A large sudden change of direction likely indicates reaction to an imminent threat, so prioritize distance from the player rather than interpreting stick distance. A fast back-and-forth wiggle of the stick within a small angle likely indicates frustration with the aim assist and trying to make it lock onto something else within that angle window, so then switch to a new target in the direction of the initial wiggle away from the old target, and maybe start using stick distance as an indication of intended target distance.
Maybe that can be simplified somewhat. First, decide some thresholds of what 'rapid' means. A rapid change of both direction and distance likely means the player is slamming the stick radically in the direction of a nearby threat, so prioritize smaller distances from the player. A rapid change of direction but not distance likely means the player is jiggling the stick to try to switch targets, so prioritize the next target over according to that change in direction. A change of distance without rapid change of direction likely means the player is trying to express an intended distance of the target, so map the distance of the stick to an intended aiming distance between 0 and the maximum range of the weapon.
A game I’ve played that really strikes this home is the lego batman series. Lego batman one had an aim assist that was brutal for the batarang, but by 3 they had tuned it just beautifully
awesome video on a subject that has bugged me greatly before.
The approach that I've wanted to play with is weighting all potential targets within the zone then selecting the highest overall value. The directionality system you've described could play a significant role in that weighting, allowing for a more nuanced understanding of "which is the player actually pointing" than raw stick inputs.
You could potentially even have an output be less "aim at this target" and more "aim in this direction". That may sound sorta weird, but it would allow you to do things like check if objects overlap from the pov of the avatar, and aim for that intersection. That would help with your "what if a target is hiding behind another target?" condition.
Weighting could be arbitrary values paired with conditionality like AoE, in combat, nearness, etc.
I am so happy to have found your channel. This is pure beauty! Thank you for providing a mathematical definition to game design problems. Your visualizations are incredibly helpful and clean. They remind me of 3Blue1Brown channel. Can you share what tool you use to make your graphs and real-time modification of x and how it shows in f(x) in the graph? I'm definitely subscribing and turning notifications on. Keep on the great work!
the animations are made in manim. thanks for the support :)
The way you describe the aim assist curve instantly makes me think of Destiny 1 and 2 by Bungie who are known for their excellent shooting controls using a controller.
Great video! The animations worked very well, made it really clear. :)
Incredible presentation of a deceptively complex topic!
Holy shit.
You have basically done 50% of the work of writing a scientific paper on this, this is something at the level of 3blue1brown
This video made me realize we need more research into videogame design, and I'm happy to be here waiting for this channel to explode even more.
This is phenomenal. Great work.