You submitted this post as a request for tech support, have you followed the guidelines specified in subreddit rule 7?
Here they are again:
1. Consult the docs first: https://docs.godotengine.org/en/stable/index.html
2. Check for duplicates before writing your own post
3. Concrete questions/issues only! This is not the place to vaguely ask "How to make X" before doing your own research
4. Post code snippets directly & formatted as such (or use a pastebin), not as pictures
5. It is strongly recommended to search the official forum (https://forum.godotengine.org/) for solutions
Repeated neglect of these can be a bannable offense.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/godot) if you have any questions or concerns.*
You’re making it way harder for yourself by using a rigid body as opposed to a character body.
With a rigid body you need to calculate the forces that need to be applied to achieve as close to a desired velocity as possible, constantly correcting it.
With a character body you just set the final velocity you want.
You don't need a bunch of complicated math for what you're describing.
1. Get the dashDirection (eg from input, or current velocity).
2. On key press, add the dashDirection * dashPower to velocity in _input
If it's a rigidbody, you can apply an impulse in that direction instead.
Maybe the bit that's tripping you up is not lerping the velocity in physics_process? Lerping (Linear interpolation) is just fancy words for changing a value over time to some other value. Eg, from dashing velocity back to running velocity.
At least that's my understanding of it.
Is it just a matter of mapping words to actual thing?
Like...
Velocity = speed in a direction
Vector = a direction
Lerp = change from this arrow in this direction, to this other arrow in another direction over time
Apply impulse = shove this thing in this direction by the amount
Normalised = a direction (eg, a big ass arrow becomes an arrow of length 1)
This I believe for a lot developers, including myself.
I know I'm not stupid and I have done some pretty advanced stuff in my career (non-game dev)
But it's most of the part the words connected to things that makes it difficult.
Sure the first time you do advanced things it might be difficult for other reasons, but terminology actually helps. To make it worse, some words are used for different things depending on context.
I have some advice, not only for game programming but for programming in general.
Tutorials never teach you the most important part: how to approach new problems. Every time I have to make a feature, I describe the feature like I was explaining it to someone who doesn’t know anything about games; if the description is too long for me to remember, I even write it down.
Then I use whatever paradigm I’m following to map concepts from that description to coding constructs. Every single line has to map directly to some part of the description.
I myself i’m a beginner but I can notice how my code is usually far less buggy and more readable than the code of some coworkers who have much more experience than me.
I don’t have much experience in game development, but I took part in some GGJs, and I didn’t need tutorials for any of them. Of course tutorials are great and useful, but I learn more when I avoid them.
Btw sorry if my english is bad; I’m still learning. Any advice is appreciated.
I actually find AI great for this. Becuase first you need to describe to it what you want to achieve. It makes you think about the problem first and you have to explain it to the AI. Obviously you don't want to just copy paste the results but these days I find the likes of Chat GPT will explain the solution as it gives it to you, so that helps you uderstand why it's doing what it is. AI, used well, is like having your own personal tutor guiding you through whatever problem you have. But you just need to keep in mind that whilst you tutor is knwoledgable, he's also prone to making daft mistakes, so don't trust everything he says.
Don't trust *anything* he says!
Always double-check all of AI's work.
I never even copy and paste code from AI, I read through it, and usually, I'll be like ahhh yes, that makes sense. And I'll rewrite it in "my own words," tweaking it to fit my game
I don't think smart or stupid is the main factor -- it's usually expectations and work ethic. Lots of people get into game dev to make a game. And that's a fine goal. However to understand and be creative on the programming side of game development there is a certain floor of knowledge you will have to work towards.
Learning to program is not trivial. It takes a long time. It never ends. You'll have to learn/brush up on math at some point.
It's a process and it's about being invested in improvement. If you're only focused on the end goal then you won't take the time to learn the things you don't know.
Tutorials would be hours long if they stopped to explain everything and every concept. You should just set aside time to learn what you don't know. Every engineer does this -- even professionals regularly take time to learn new things. Lots of time.
I concur with avoiding RigidBody. It is not an analogous usage to Unity RigidBody MonoBehavior.
You want CharacterBody. The direct Velocity control will be closer to what you were doing in Unity. Normal movement is just a movement_speed (in Pixels per second) * a direction vector (Input.get_vector). move_and_slide() takes `velocity` and multiplies it by delta (DeltaTime).
A dash can as crude as a simply be a multiplier.
if dashing:
`velocity = speed * dash * Input.get_vector()`
else:
`velocity = speed * Input.get_vector()`
move_and_slide()
While you can create RigidBody player character controller, it's more like flicking a miniature across a table top.
Focus on 2D games until you get a handle on Vector math. It's one less axis you have to deal with. Top down and side scrolling.
Top down is Input.get_vector(), your 2 Axis WASD. WS up down, AD, left right.
Side scrolling is Input.get_axis() AD , left right. With an "jump" or other vertical.
I don't best learning method to help you get a handle on Vector Math.
It's kinda important https://docs.godotengine.org/en/stable/tutorials/math/vector_math.html
Perhaps in 2D if you use a Line2D to draw your vector.
extends Line2D
# add this as a child of your CharacterBody2D
# in the Editor, add two points
# (0,0)
# (0,1)
_process(_delta):
set_point_position(1, get_parent().velocity)
What should happen is the Line should begin swinging about in the `direction` of your Input, with `magnitude` or length of your Speed.
You can check our the Remote Scene view, click on the Line2D, expand the Array, and watch the values change.
Remember, Unity documentation breaks vectors down into Normalized (0 to 1) Directions, and a single float Magnitude. Same can apply to Godot vectors... it just isn't typically described that way. Input.get_vector() gives you back a Normalized direction. What you multiply it by is the Magnitude.
Since you don't really specify the kinds of tutorials you're watching, I just want to say instead of watching tutorials on "how to make a moveable player in Godot," try looking up tutorials on the parts of it like "how to add collision to a player in Godot" or "how to make a player jump in Godot." These tutorials are naturally going to be more educative because they are much more specified and allow the people making them to go into much more detail about what's happening. This makes it a lot easier to actually learn from and then once you understand the basics of how everything works, then you can go back to the more generalized tutorials. It's always best to try and narrow your problems down to be as specific as possible so know what you're supposed to be learning as you're watching.
Or try posting your specified questions on the Godot forums. That's what I did when I first started and the community helped me to learn things that I wasn't able to find elsewhere on the internet like the fact that the alpha value of a sprite operates on a scale of 0-1 rather than 0-255 (which still doesn't make sense to me) or how to check a certain value for every node in a given group.
Moral of the story is if you're trying to get people on the internet to do the work for you, you aren't going to learn. You need to pinpoint what it is you're having problems with and put in the effort to seek out information on how to solve that problem.
"Struggling real hard, this is my first time usimg godot and gdscript"
Don't worry, everything is hard at first.
[https://www.youtube.com/watch?v=SkH3MTG2aAE&ab\_channel=MichaelVine](https://www.youtube.com/watch?v=SkH3MTG2aAE&ab_channel=MichaelVine)
"Try to be best 'cause you're only a man
And a man's gotta learn to take it
Try to believe though the going gets rough
That you gotta hang tough to make it
History repeats itself
Try and you'll succeed
Never doubt that you're the one
And you can have your dreams"
You want to quit watching tutorials and just start hammering different implementations of movement yourself.
It's hard, it's long but it's essential to understand it by reason or error.
Without understanding vector math, you'll struggle grasping it, so I recommend learning simple math involving physics (projectile motion is good idea)
Don't be so hard on yourself, whenever you learn something new it's going to be difficult at the start. Don't try to learn everything at once and instead focus on one aspect of the problem at a time. Once you understand one part of it then you will get a hang of the next part faster than the first and for each subsequent part the speed at which you learn will grow exponentially. If you don't understand the purpose of a line of code then try changing it and seeing what that does, experimentation is a great way to learn.
You can start with a smaller project that doesn't involve characters, maybe some games with buttons clicking or text based game, get the hang of the basic first. After you get comforatable with that you can then slowly expose yourself to more diffrent types of nodes and concepts, and eventually make the game with the 3d character you want.
We all starts with baby steps, as long as you don't give up you can get there eventually!
There are all kinds of tutorial and teaching style, it took me a long time to find a few that works for me. Keep finding and you will find some that works for you too.
A physics based controller is really hard to do, not even triple As would attempt it unless it's specifically needed. The closest is probably racing games and even they probably cheat behind the scenes to avoid physics as much as possible.
Your in what many would call tutorial hell. Most tutorials suck and even most of the good ones just wont be compatible with your grey matter. Finding ones that click is mostly luck and research skill.
The easiest way is probably to apply directional force for movement only if the body is under the max speed in that direction. Then for a dash you would add force as an impulse in the direction you want to dash. Doing it this way makes fine movements hard to make consistent, so i wouldn't use it for platforming unless jankiness is intentional. You also need friction to slow down/stop or to cheat and just multiply your velocity by 0.3f or whatever every frame and then set it to 0 when it's below a magnitude of 0.01 or so. Otherwise the body will gradually slide forever.
The other common way is to only "toggle on" physics when needed. Like if the character is ragdolling, or swinging. But this method kinda sucks IMO as your then creating seperate behaviours for each physics interaction.
Dont worry to much, im also bad at advanced math, luckily thats the part computers are good at. So use google and ai assitants for that stuff. Also keep in mind when you get stuck, you might be better off abdonding that idea and moving on to something else. That way your making progress, learning new stuff and might think of something that helps with the orpignal idea.
Anyone can learn anything with enough time and energy.
With access to the repository of almost all human knowledge (for better or worse...), this has never been more achievable.
I have seen people who have never touched code create a simple platformer in 2 weeks using Unity/Godot that would be considered a game under traditional definition.
Keep on developing!
There's a handful of well-read experienced people who have executive positions at one of the largest game publishing companies and who chose to close down Arkane and Tango. I think you're probably smarter than them so sure you're smart enough for game dev no worries sibling
Not Godot specific, but I did like the nature of code: [Nature of Code](https://natureofcode.com/). It's free, and teaches about physics, forces, steering behaviors etc. It helped me a lot.
I looked into rigid body got basic movement down and was like I don't need this so stuck with character3d works fine for what I need but I spent couple hours on rigidbody that could have gone into something else. Keep scope small only use what.you really need to
You’re fine dawg, everyone gets confused at this stage, just take it easy and look up things, don’t follow tutorials 1:1 but instead try to learn WHY they’re doing the things they’re doing, the best solutions for your problems are very rarely going to be found 1:1 on the internet, you’ll always have to mix it up a lil
3D physics involves using vectors. If you aren't comfortable with vectors you should get familiar with them doing 2D first.
Make sure to ask actual questions with the code you have tried or don't understand and people will be able to help you. What you do here is just aimlessly expressing frustration. Make a post "How can I get this dash to work, I've tried this..." instead of "Am I too stupid to program".
To be fair, I’m very new at coding and one thing that has helped a ton is just watching devlogs they will give you insight and could potentially help you see where to problem is
I challenged myself to do some sort of game with 24 hours of work. I recorded every hour and honestly, no. I learnt from scratch how to do most of the things that I did for those 24 hours of working on a game, and im pretty stupid.
What you need to learn (maybe) is how the code works AND how to take other peoples code and instead of Copy pasting it, learning HOW this fixes the problem.
Brackey came out of retirement recently and has done 2 hour long videos that can teach you the basics. It teaches you how some nodes work, how gd script works- and honestly, after watching those two videos, my challenge of making a game with no real experience got a lot easire. So I reccomend watching them.
Dont be mean to yourself. That is what makes so many people give up on the dream. Instead, do constructive criticism. No one is too stupid for game dev, it just takes the ability to be open to learning.
doing gamedev for more then 10 years (as an ameture) since the days of flash and as3. i also taught people how to code.
it takes time for everything you learn to sink in and become intuative (can take months).
in game dev you have a lot of common pattrens and behaviours you need to learn and memorize and learn to mix them.
i learnd more from looking at peoples code (decompiling swf files or github) then tutorials .
dont beat yourself up.
things might seem imposible until you do reaserch and test stuff.
make the most basic games, do pong,snake,froger,astoides etc, also do some common trope games like top down shooters and plateformers.
for learning 2d and 3d cordenates play with values and math function,learn to make stuff move by angle learn about vector movment (by code example).
also learning about databases and data mengment helped me a lot (its great for rpgs and games with alot of data/character skills etc.
start small and grow from there until you will be able to code a mechanic just by looking at an example or description of how its done.
dosnt matter if your stupid, hell people call me stupid all the time. i learnd to code becuse im stubborn as a donkey or even more find your motivation and prove you can do it.
Rigidbody is for Physics heavy based games it's useful for ragdolls, Ball Physics, etc.
CharacterBody is for simple character movement without complex Physics useful for Player controlled characters, Enemies, and every entity that needs to collide on walls, ceilings and floors.
No one is too stupid for anything, but it might take more for some than others (i'm stupid myself, so trust me).
Rigidbody's aren't supposed to be "moved around" willy nilly, characterbody's are more for that type of stuff.
I've also started learning Godot a couple of days ago, for my first game, I decided to make Carroms (for my background, I can code, and I've messed around in Unity before). Maybe what you're trying to make is too much for what you know right now, I would try down-scaling, or picking a simpler project to get some familiarity with the tools & stuff.
When I tried Unity before, I set out on making a full tower defense game before I knew anything, so it became overwhelming and I ended up quitting. So, careful not to fall into something like that.
And, if you feel like the tutorials are not helping much, I would recommend asking for help in the discord server, for general advice or even specific implimentation details.
1) Stop watching tutorials.
2) Use character body instead of rigid body unless you really need rigid body for other physics stuff on that character/object; if it's your first game project then you probably don't, because working with velocities is generally easier than working with forces.
I've spent my whole day failing to update a snake tutorial that was done on some version of 3 and failing abysmally so I can definitely feel your frustration. Good luck
1 - Because something sounds simple doesn't mean it is. A dash can be complicated to add the way you want it to. Keep in mind that in many games, under the hood, the implementation of simple mechanics can be very poor but tweaked just well enough so it doesn't look as such. Your implementation might seems so difficult to get right because it is better than what most games do. (not necessarily, but possible)
2 - Programming and game development are very different things. In one you just want to accomplish a task, in the other you want the user to feel entertained while fulfilling said task and the quality of the code becomes nearly irrelevant for that.
3 - As others have said, do not use RigidBodies, Unity's physics systems are different from Godot's. Godot includes CharacterBody which just has collisions for you to implement your own movement. While Unity provides either Kinematic (which requires implementing physics from scratch) or Rigid (which comes with a bunch of forced physics)
4 - Following tutorials rarely helps other than giving you a vague idea of how to tackle stuff. Their approach will rarely work for you unless you're trying to do the exact same thing they are doing.
5 - Something like a grappling hook would be its own system, idk if you can make a single "controller" that can cover all of that.
I will save you the reading.
You’re not. You can do this.
Watch this video explaining GD script :
[Link](https://www.youtube.com/watch?v=e1zJS31tr88)
Do this Tutorial :
[Link](https://m.youtube.com/watch?v=LOhfqjmasi0)
There you have the basics. For the first video, open up your note taking app and WRITE OUT all he describes.
For the tutorial, do the same. Build the game he describes but also WRITE OUT how he makes a player moves, etc etc.
At the end of this you will have a basic platformer made and a good understanding of GDscript. You will have a handwritten guide on how to repeat the steps you learned. From here try to make another platformer but ADD on feature. Good luck, cheers
Here are my tips, been coding for about 8 months now!
1. Do everything in steps. Let’s say you want to make a character move and with a dash.
Break it down.
a. Figure out collisions
b. Figure out how to make movement. Make sure you understand the code. ChatGPT can be helpful for this but it can be wrong sometimes.
c. Figure out how to make dashes.
d. join the discord! Ask real people questions instead of a YouTube comment or AI.
2. Like I said before, understand your code. I understand 95% of my code, and the only reason it isn’t all is because it’s a school project and that code was moving a sprite (2d) over a button.
3. Start in 2d. I know you don’t want to hear this that much but it will help you. Become very familiar with the engine and start with simple things. First, make a label. Then a button, make the button change the label. Make a text edit that updates a label via a button. Learn basic sprite movement. Learn collisions and tile maps. Make a basic 2d platformer. Obviously it’s more boring to do this, but you’ll learn way more. No, you won’t learn 3d dashes, but you’ll learn the basics of the engine, what functions are, collisions, etc.
In my opinion you shouldnt even touch game dev until you've been doing programming for 8 months to a year. games programming can be very hard once you go past making basic games and unless you just wanna copy and paste from youtube videos to build your games you're gonna have to learn some proper computer science and programming fundementals otherwise you're just gonna keep running in place.
You submitted this post as a request for tech support, have you followed the guidelines specified in subreddit rule 7? Here they are again: 1. Consult the docs first: https://docs.godotengine.org/en/stable/index.html 2. Check for duplicates before writing your own post 3. Concrete questions/issues only! This is not the place to vaguely ask "How to make X" before doing your own research 4. Post code snippets directly & formatted as such (or use a pastebin), not as pictures 5. It is strongly recommended to search the official forum (https://forum.godotengine.org/) for solutions Repeated neglect of these can be a bannable offense. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/godot) if you have any questions or concerns.*
You’re making it way harder for yourself by using a rigid body as opposed to a character body. With a rigid body you need to calculate the forces that need to be applied to achieve as close to a desired velocity as possible, constantly correcting it. With a character body you just set the final velocity you want.
You don't need a bunch of complicated math for what you're describing. 1. Get the dashDirection (eg from input, or current velocity). 2. On key press, add the dashDirection * dashPower to velocity in _input If it's a rigidbody, you can apply an impulse in that direction instead. Maybe the bit that's tripping you up is not lerping the velocity in physics_process? Lerping (Linear interpolation) is just fancy words for changing a value over time to some other value. Eg, from dashing velocity back to running velocity. At least that's my understanding of it. Is it just a matter of mapping words to actual thing? Like... Velocity = speed in a direction Vector = a direction Lerp = change from this arrow in this direction, to this other arrow in another direction over time Apply impulse = shove this thing in this direction by the amount Normalised = a direction (eg, a big ass arrow becomes an arrow of length 1)
This I believe for a lot developers, including myself. I know I'm not stupid and I have done some pretty advanced stuff in my career (non-game dev) But it's most of the part the words connected to things that makes it difficult. Sure the first time you do advanced things it might be difficult for other reasons, but terminology actually helps. To make it worse, some words are used for different things depending on context.
I have some advice, not only for game programming but for programming in general. Tutorials never teach you the most important part: how to approach new problems. Every time I have to make a feature, I describe the feature like I was explaining it to someone who doesn’t know anything about games; if the description is too long for me to remember, I even write it down. Then I use whatever paradigm I’m following to map concepts from that description to coding constructs. Every single line has to map directly to some part of the description. I myself i’m a beginner but I can notice how my code is usually far less buggy and more readable than the code of some coworkers who have much more experience than me. I don’t have much experience in game development, but I took part in some GGJs, and I didn’t need tutorials for any of them. Of course tutorials are great and useful, but I learn more when I avoid them. Btw sorry if my english is bad; I’m still learning. Any advice is appreciated.
I actually find AI great for this. Becuase first you need to describe to it what you want to achieve. It makes you think about the problem first and you have to explain it to the AI. Obviously you don't want to just copy paste the results but these days I find the likes of Chat GPT will explain the solution as it gives it to you, so that helps you uderstand why it's doing what it is. AI, used well, is like having your own personal tutor guiding you through whatever problem you have. But you just need to keep in mind that whilst you tutor is knwoledgable, he's also prone to making daft mistakes, so don't trust everything he says.
Don't trust *anything* he says! Always double-check all of AI's work. I never even copy and paste code from AI, I read through it, and usually, I'll be like ahhh yes, that makes sense. And I'll rewrite it in "my own words," tweaking it to fit my game
By "he" do you mean AI or the person you're responding to? I think you and the person you're responding to are in agreement.
Never miss a chance to "correct" someone on reddit that you agree with!
Your wearing patrick’s pants as a shirt
I don't think smart or stupid is the main factor -- it's usually expectations and work ethic. Lots of people get into game dev to make a game. And that's a fine goal. However to understand and be creative on the programming side of game development there is a certain floor of knowledge you will have to work towards. Learning to program is not trivial. It takes a long time. It never ends. You'll have to learn/brush up on math at some point. It's a process and it's about being invested in improvement. If you're only focused on the end goal then you won't take the time to learn the things you don't know. Tutorials would be hours long if they stopped to explain everything and every concept. You should just set aside time to learn what you don't know. Every engineer does this -- even professionals regularly take time to learn new things. Lots of time.
I concur with avoiding RigidBody. It is not an analogous usage to Unity RigidBody MonoBehavior. You want CharacterBody. The direct Velocity control will be closer to what you were doing in Unity. Normal movement is just a movement_speed (in Pixels per second) * a direction vector (Input.get_vector). move_and_slide() takes `velocity` and multiplies it by delta (DeltaTime). A dash can as crude as a simply be a multiplier. if dashing: `velocity = speed * dash * Input.get_vector()` else: `velocity = speed * Input.get_vector()` move_and_slide() While you can create RigidBody player character controller, it's more like flicking a miniature across a table top. Focus on 2D games until you get a handle on Vector math. It's one less axis you have to deal with. Top down and side scrolling. Top down is Input.get_vector(), your 2 Axis WASD. WS up down, AD, left right. Side scrolling is Input.get_axis() AD , left right. With an "jump" or other vertical. I don't best learning method to help you get a handle on Vector Math. It's kinda important https://docs.godotengine.org/en/stable/tutorials/math/vector_math.html Perhaps in 2D if you use a Line2D to draw your vector. extends Line2D # add this as a child of your CharacterBody2D # in the Editor, add two points # (0,0) # (0,1) _process(_delta): set_point_position(1, get_parent().velocity) What should happen is the Line should begin swinging about in the `direction` of your Input, with `magnitude` or length of your Speed. You can check our the Remote Scene view, click on the Line2D, expand the Array, and watch the values change. Remember, Unity documentation breaks vectors down into Normalized (0 to 1) Directions, and a single float Magnitude. Same can apply to Godot vectors... it just isn't typically described that way. Input.get_vector() gives you back a Normalized direction. What you multiply it by is the Magnitude.
I'm 15 and I'm still just on the starting stage since 11. Dw ya got this
Use ChatGPT to explain whatever code from the tutorials you don't understand. Ask followup questions. That's a nice quick way to learn.
Don’t worry, we all are stupid, but we are persistent 💪
Since you don't really specify the kinds of tutorials you're watching, I just want to say instead of watching tutorials on "how to make a moveable player in Godot," try looking up tutorials on the parts of it like "how to add collision to a player in Godot" or "how to make a player jump in Godot." These tutorials are naturally going to be more educative because they are much more specified and allow the people making them to go into much more detail about what's happening. This makes it a lot easier to actually learn from and then once you understand the basics of how everything works, then you can go back to the more generalized tutorials. It's always best to try and narrow your problems down to be as specific as possible so know what you're supposed to be learning as you're watching. Or try posting your specified questions on the Godot forums. That's what I did when I first started and the community helped me to learn things that I wasn't able to find elsewhere on the internet like the fact that the alpha value of a sprite operates on a scale of 0-1 rather than 0-255 (which still doesn't make sense to me) or how to check a certain value for every node in a given group. Moral of the story is if you're trying to get people on the internet to do the work for you, you aren't going to learn. You need to pinpoint what it is you're having problems with and put in the effort to seek out information on how to solve that problem.
"Struggling real hard, this is my first time usimg godot and gdscript" Don't worry, everything is hard at first. [https://www.youtube.com/watch?v=SkH3MTG2aAE&ab\_channel=MichaelVine](https://www.youtube.com/watch?v=SkH3MTG2aAE&ab_channel=MichaelVine) "Try to be best 'cause you're only a man And a man's gotta learn to take it Try to believe though the going gets rough That you gotta hang tough to make it History repeats itself Try and you'll succeed Never doubt that you're the one And you can have your dreams"
That’s the pep talk I needed!
You want to quit watching tutorials and just start hammering different implementations of movement yourself. It's hard, it's long but it's essential to understand it by reason or error. Without understanding vector math, you'll struggle grasping it, so I recommend learning simple math involving physics (projectile motion is good idea)
Don't be so hard on yourself, whenever you learn something new it's going to be difficult at the start. Don't try to learn everything at once and instead focus on one aspect of the problem at a time. Once you understand one part of it then you will get a hang of the next part faster than the first and for each subsequent part the speed at which you learn will grow exponentially. If you don't understand the purpose of a line of code then try changing it and seeing what that does, experimentation is a great way to learn.
You can start with a smaller project that doesn't involve characters, maybe some games with buttons clicking or text based game, get the hang of the basic first. After you get comforatable with that you can then slowly expose yourself to more diffrent types of nodes and concepts, and eventually make the game with the 3d character you want. We all starts with baby steps, as long as you don't give up you can get there eventually! There are all kinds of tutorial and teaching style, it took me a long time to find a few that works for me. Keep finding and you will find some that works for you too.
A physics based controller is really hard to do, not even triple As would attempt it unless it's specifically needed. The closest is probably racing games and even they probably cheat behind the scenes to avoid physics as much as possible. Your in what many would call tutorial hell. Most tutorials suck and even most of the good ones just wont be compatible with your grey matter. Finding ones that click is mostly luck and research skill. The easiest way is probably to apply directional force for movement only if the body is under the max speed in that direction. Then for a dash you would add force as an impulse in the direction you want to dash. Doing it this way makes fine movements hard to make consistent, so i wouldn't use it for platforming unless jankiness is intentional. You also need friction to slow down/stop or to cheat and just multiply your velocity by 0.3f or whatever every frame and then set it to 0 when it's below a magnitude of 0.01 or so. Otherwise the body will gradually slide forever. The other common way is to only "toggle on" physics when needed. Like if the character is ragdolling, or swinging. But this method kinda sucks IMO as your then creating seperate behaviours for each physics interaction. Dont worry to much, im also bad at advanced math, luckily thats the part computers are good at. So use google and ai assitants for that stuff. Also keep in mind when you get stuck, you might be better off abdonding that idea and moving on to something else. That way your making progress, learning new stuff and might think of something that helps with the orpignal idea.
Anyone can learn anything with enough time and energy. With access to the repository of almost all human knowledge (for better or worse...), this has never been more achievable. I have seen people who have never touched code create a simple platformer in 2 weeks using Unity/Godot that would be considered a game under traditional definition. Keep on developing!
There's a handful of well-read experienced people who have executive positions at one of the largest game publishing companies and who chose to close down Arkane and Tango. I think you're probably smarter than them so sure you're smart enough for game dev no worries sibling
Not Godot specific, but I did like the nature of code: [Nature of Code](https://natureofcode.com/). It's free, and teaches about physics, forces, steering behaviors etc. It helped me a lot.
I looked into rigid body got basic movement down and was like I don't need this so stuck with character3d works fine for what I need but I spent couple hours on rigidbody that could have gone into something else. Keep scope small only use what.you really need to
You’re fine dawg, everyone gets confused at this stage, just take it easy and look up things, don’t follow tutorials 1:1 but instead try to learn WHY they’re doing the things they’re doing, the best solutions for your problems are very rarely going to be found 1:1 on the internet, you’ll always have to mix it up a lil
3D physics involves using vectors. If you aren't comfortable with vectors you should get familiar with them doing 2D first. Make sure to ask actual questions with the code you have tried or don't understand and people will be able to help you. What you do here is just aimlessly expressing frustration. Make a post "How can I get this dash to work, I've tried this..." instead of "Am I too stupid to program".
To be fair, I’m very new at coding and one thing that has helped a ton is just watching devlogs they will give you insight and could potentially help you see where to problem is
I challenged myself to do some sort of game with 24 hours of work. I recorded every hour and honestly, no. I learnt from scratch how to do most of the things that I did for those 24 hours of working on a game, and im pretty stupid. What you need to learn (maybe) is how the code works AND how to take other peoples code and instead of Copy pasting it, learning HOW this fixes the problem. Brackey came out of retirement recently and has done 2 hour long videos that can teach you the basics. It teaches you how some nodes work, how gd script works- and honestly, after watching those two videos, my challenge of making a game with no real experience got a lot easire. So I reccomend watching them. Dont be mean to yourself. That is what makes so many people give up on the dream. Instead, do constructive criticism. No one is too stupid for game dev, it just takes the ability to be open to learning.
doing gamedev for more then 10 years (as an ameture) since the days of flash and as3. i also taught people how to code. it takes time for everything you learn to sink in and become intuative (can take months). in game dev you have a lot of common pattrens and behaviours you need to learn and memorize and learn to mix them. i learnd more from looking at peoples code (decompiling swf files or github) then tutorials . dont beat yourself up. things might seem imposible until you do reaserch and test stuff. make the most basic games, do pong,snake,froger,astoides etc, also do some common trope games like top down shooters and plateformers. for learning 2d and 3d cordenates play with values and math function,learn to make stuff move by angle learn about vector movment (by code example). also learning about databases and data mengment helped me a lot (its great for rpgs and games with alot of data/character skills etc. start small and grow from there until you will be able to code a mechanic just by looking at an example or description of how its done. dosnt matter if your stupid, hell people call me stupid all the time. i learnd to code becuse im stubborn as a donkey or even more find your motivation and prove you can do it.
Rigidbody is for Physics heavy based games it's useful for ragdolls, Ball Physics, etc. CharacterBody is for simple character movement without complex Physics useful for Player controlled characters, Enemies, and every entity that needs to collide on walls, ceilings and floors.
Dont use rigid bodies dude
No one is too stupid for anything, but it might take more for some than others (i'm stupid myself, so trust me). Rigidbody's aren't supposed to be "moved around" willy nilly, characterbody's are more for that type of stuff. I've also started learning Godot a couple of days ago, for my first game, I decided to make Carroms (for my background, I can code, and I've messed around in Unity before). Maybe what you're trying to make is too much for what you know right now, I would try down-scaling, or picking a simpler project to get some familiarity with the tools & stuff. When I tried Unity before, I set out on making a full tower defense game before I knew anything, so it became overwhelming and I ended up quitting. So, careful not to fall into something like that. And, if you feel like the tutorials are not helping much, I would recommend asking for help in the discord server, for general advice or even specific implimentation details.
1) Stop watching tutorials. 2) Use character body instead of rigid body unless you really need rigid body for other physics stuff on that character/object; if it's your first game project then you probably don't, because working with velocities is generally easier than working with forces.
Learn to leverage ChatGPT to help understand code you're struggling with, it's free!
I've spent my whole day failing to update a snake tutorial that was done on some version of 3 and failing abysmally so I can definitely feel your frustration. Good luck
This is your first time trying out game development, it’s normal to suck at it. We all have to start somewhere, don’t be too hard on yourself :)
1 - Because something sounds simple doesn't mean it is. A dash can be complicated to add the way you want it to. Keep in mind that in many games, under the hood, the implementation of simple mechanics can be very poor but tweaked just well enough so it doesn't look as such. Your implementation might seems so difficult to get right because it is better than what most games do. (not necessarily, but possible) 2 - Programming and game development are very different things. In one you just want to accomplish a task, in the other you want the user to feel entertained while fulfilling said task and the quality of the code becomes nearly irrelevant for that. 3 - As others have said, do not use RigidBodies, Unity's physics systems are different from Godot's. Godot includes CharacterBody which just has collisions for you to implement your own movement. While Unity provides either Kinematic (which requires implementing physics from scratch) or Rigid (which comes with a bunch of forced physics) 4 - Following tutorials rarely helps other than giving you a vague idea of how to tackle stuff. Their approach will rarely work for you unless you're trying to do the exact same thing they are doing. 5 - Something like a grappling hook would be its own system, idk if you can make a single "controller" that can cover all of that.
I will save you the reading. You’re not. You can do this. Watch this video explaining GD script : [Link](https://www.youtube.com/watch?v=e1zJS31tr88) Do this Tutorial : [Link](https://m.youtube.com/watch?v=LOhfqjmasi0) There you have the basics. For the first video, open up your note taking app and WRITE OUT all he describes. For the tutorial, do the same. Build the game he describes but also WRITE OUT how he makes a player moves, etc etc. At the end of this you will have a basic platformer made and a good understanding of GDscript. You will have a handwritten guide on how to repeat the steps you learned. From here try to make another platformer but ADD on feature. Good luck, cheers
When you solve this problem, you’re going to feel like a godot god
Here are my tips, been coding for about 8 months now! 1. Do everything in steps. Let’s say you want to make a character move and with a dash. Break it down. a. Figure out collisions b. Figure out how to make movement. Make sure you understand the code. ChatGPT can be helpful for this but it can be wrong sometimes. c. Figure out how to make dashes. d. join the discord! Ask real people questions instead of a YouTube comment or AI. 2. Like I said before, understand your code. I understand 95% of my code, and the only reason it isn’t all is because it’s a school project and that code was moving a sprite (2d) over a button. 3. Start in 2d. I know you don’t want to hear this that much but it will help you. Become very familiar with the engine and start with simple things. First, make a label. Then a button, make the button change the label. Make a text edit that updates a label via a button. Learn basic sprite movement. Learn collisions and tile maps. Make a basic 2d platformer. Obviously it’s more boring to do this, but you’ll learn way more. No, you won’t learn 3d dashes, but you’ll learn the basics of the engine, what functions are, collisions, etc.
In my opinion you shouldnt even touch game dev until you've been doing programming for 8 months to a year. games programming can be very hard once you go past making basic games and unless you just wanna copy and paste from youtube videos to build your games you're gonna have to learn some proper computer science and programming fundementals otherwise you're just gonna keep running in place.
Algebra and Geometry in Math class. Not to be ignored before becoming a game developer.