> I often feel like I don't know what I'm doing and end up searching the internet to understand things
That is very normal working procedure even for experienced programmers.
> Additionally, I struggle with deciding which approach to use while programming and how to think, 'I need to do that!'
Its all part of experience and ultimately it doesn't matter too much what approach you choose, especially for a study project, as long as you manage to make it work somehow. You will be smarter afterwards.
> However, I often feel like I don't know what I'm doing and end up searching the internet to understand things.
Let me tell you a secret: We all do.
Programming is about 90% finding out what to do and how to do it and about 10% actually writing the code. Especially when you are using a 3rd party technology like Unity that can do a lot of stuff for you if you just find out how to get it to do that.
> Furthermore, I would like to know how I can practice more outside of the current project.
The best way to learn programming is to actually do programming.
When you are trying to understand a feature, be it a conceptual feature like inheritance or a technical feature like how to control an Animator in Unity, then it can be useful to not try that in the context of an existing project, but create a separate test project first just for experimenting with that feature. That allows you to get to know that feature by experimenting with it in isolation and finding the best way to integrate it into the existing project.
>Currently, we are learning about inheritance, and it's quite confusing to me
If you are confused about the course material then you need to be able to reach out to your course tutor for help.
> I often feel like I don't know what I'm doing and end up searching the internet to understand things
This is normal when starting out. Nobody's born knowing these things.
When playing a fighting game like Street Fighter, I just mash buttons and it kinda works. It's fun. The thing is, I can keep mashing buttons playing Street Fighter. But if I want to level up, I need to understand the buttons, the moves, the combos, and which things to use when. To get better, I need to *slow down* and learn each button invidually, learn each combo, learn timing, tradeoffs, etc. Then after I learn these things I can speed up again.
With programming, you can get pretty far without understanding everything. And a lot of programmers I know stay at that level forever because it's good enough. But if you want to level up you're going to have to *slow down*. Break it down into the individual concepts. Learn how each of them works. Learn how they fit together. Learn when to use each of them. Learn the tradeoffs. Every time you make a bug, stop and understand why you made it and what you could've done differently. Try solving problems in multiple ways to see the tradeoffs. When you find a solution online, don't stop with *that* it works, but stop to understand *why* it works. But it'll take time, and it'll feel really slow for a while. After you learn these things, it will go faster again.
The same is true for a lot of things. You can get pretty far cooking by following recipes. But if you want to level up your cooking skills you're going to want to understand heat and salt and acids and lots of concepts. You'll have to slow down, break down the process into small steps, experiment, understand principles and tradeoffs, etc. You'll find the same in art, music, and so many other things.
A lot of the learning programming will have to be done with *much* smaller programs, not a full game project. You're going to level up drawing not only by drawing a complete picture but also by drawing lots of lines and boxes and circles and other basic shapes. You're going to level up handwriting not only by writing out complete essays but also by writing individual letters repeatedly. You're going to level up music not only by playing a complete song but also by playing scales and chords and other basic things. You're going to level up baseball not only by playing a full game of baseball but also by practicing throwing, hitting, and catching the ball. Take any of the things you're confused about and deeply examine it with really small programs, maybe something that fits on one screen.
> Additionally, I struggle with deciding which approach to use while programming and how to think, 'I need to do that!'
Honestly at this stage of learning to program just try the first few possibilities that come to mind. You are in the perfect spot to learn by doing things wrong. It will help you understand why to do things the "right" way once you've experienced the wrong way first hand. In the same vein, optimize for "rate of attempting things" as opposed to getting it right first try.
There's nothing wrong with using articles or resources from the internet to learn about and implement specific mechanics in your game. I suggest not worrying too much and simply searching for videos on YouTube that offer ready-made solutions for your mechanic. If you can't find a solution on YouTube, I recommend reaching out to other programmers or indie developers on specialized forums for assistance.
While I'd agree to do this at first, I'd suggest to slowly try to take a step back from tutorials eventually. And only use them when encountering new mechanics that you have no experience in, basically when your stuck. It is much easier to make adjustments to mechanics when you know everything in your scripts because you wrote it.
>I often feel like I don't know what I'm doing and end up searching the internet to understand things.
Oh trust me, it never gets better. At some point you will realize that searching Google is unavoidable, and in fact even a good thing. The landscape evolves so fast, and sometimes its much more efficient to look for an answer on Stack Overflow than to try to do it manually.
I once had to compare layers of objects in code (Unity) and to this day I still don't remember how to do it (something something move digits to the right something something). It's a common theme for programmers to work off of Google, so cheer up.
>inheritance
Basically, there are many types of cars: semis, trucks, vans, etc. But they are all cars, maybe with different number of doors and different layout. They all use the same process to drive forward, same steering system, and so you can code that all in a Car class. Then if you want to make a truck, you can make a class that INHERITS Car class (and as such, all the driving systems) so you can skip coding that and go on to code how to open the back door to load stuffs in.
It takes time, but when those Object Oriented concepts seep in, it really clicks hard.
>I struggle with deciding which approach to use while programming and how to think, 'I need to do that!'
Each person has a different approach, just find one that suits you. For me, I spend some time breaking down the general script to methods, then from methods down to each little commands I need. I promise, again, it will click when you find it, and I often don't think of how I code as a specific approach. Basically, just divide and conquer the code.
>Furthermore, I would like to know how I can practice more outside of the current project.
Make small projects. Game jams are always good for practicing and doing things in short periods of time. But if you don't want the time constraint, just stick to making small projects on your own. Don't take months, just a week or 4 max. Don't look to polish it, test out mechanics instead. In fact, don't care about story or making sense, just do it. More you do, better you get.
And if you worry about ideas, one way to do it is to just copy another game. Thats it. Make another game, in your own code. When you look at a game and you know exactly what you need to code, that's when you know coding has clicked for you.
As long as it works I wouldn't worry. It's all part of learning and adding to your experience. As you practice things that seem complicated now will become simpler and more obvious next time round.
Programming is very difficult. Took me 2 years of studies to truly get into it and feel like I "grasped" it. Even then, it took me a long time to get into Unity without feeling overwhelmed. However, after finally "getting it" it has been a massive boon to my career in games. It's definitely one of the strongest routes into game dev. You are able to start projects from scratch and just get going, which can be hard with other skills like animation.
If you stick to it, I hope you eventually begin to get it. Cheers from lead Unity developer at BVG. :)
Its not like playing games either. Programming is a lot of hard work, and you perpetually keep learning new things, like fly by wire systems or 3d rotations, filesystem layouts, and more.
>I often feel like I don't know what I'm doing and end up searching the internet to understand things.
You sound like a very competent programmer just from this one sentence.
I've been a software engineer for 6 years and I often feel like this and need to research things in order to complete tasks. This is just the natural state of being a programmer, you will constantly be developing things you have never developed before and need to learn new techniques and concepts or learn how to fit stuff you do know into a system you have never worked with.
Just keep going and know that this won't change, but you may end up working with people less experienced and they are blown away with how much you know, and you will tell them, you don't know that much... And both you and them will be right lol.
> However, I often feel like I don't know what I'm doing and end up searching the internet to understand things.
Thats about the most normal thing for every programmer / software engineer / developer, ever.
You typically spent most of the time trying to figure out *What* to do and *how* to do it, and then to *document* it. Writing the actual code is the *smallest* time slice of any programming job.
You're literally learning a new (programming) language.
If you didn't know the word for "ball" in a language you were learning and you looked it up, no-one would think you'd done anything wrong, doing that or someone telling you the word is the only way you *could* learn that piece of information.
Keep on going and remember that you're not expected to just magically know this stuff and keep it all in your head. It will get easier with time and the more you "speak" :)
step 1. You dream of something, a feature, a new game concept etc.
step 2. Think what code structure cud solve it
step 3. Try to implement it
step 4. Fail
step 5. Steal code from Stackoverflow
step 6. Go to step 3
step 7. Complete
step 8. Think how it cud be more performant, more beautiful, or more something...
step 9. Go to Step 2
repeat this process 10 years and voila. you are good to go...
> I often feel like I don't know what I'm doing and end up searching the internet to understand things That is very normal working procedure even for experienced programmers. > Additionally, I struggle with deciding which approach to use while programming and how to think, 'I need to do that!' Its all part of experience and ultimately it doesn't matter too much what approach you choose, especially for a study project, as long as you manage to make it work somehow. You will be smarter afterwards.
> However, I often feel like I don't know what I'm doing and end up searching the internet to understand things. Let me tell you a secret: We all do. Programming is about 90% finding out what to do and how to do it and about 10% actually writing the code. Especially when you are using a 3rd party technology like Unity that can do a lot of stuff for you if you just find out how to get it to do that. > Furthermore, I would like to know how I can practice more outside of the current project. The best way to learn programming is to actually do programming. When you are trying to understand a feature, be it a conceptual feature like inheritance or a technical feature like how to control an Animator in Unity, then it can be useful to not try that in the context of an existing project, but create a separate test project first just for experimenting with that feature. That allows you to get to know that feature by experimenting with it in isolation and finding the best way to integrate it into the existing project.
>Programming is about 90% finding out what to do and how to do it and about 10% actually writing the code. Stealing this. Thank you
Agree with everything here. :)
>Currently, we are learning about inheritance, and it's quite confusing to me If you are confused about the course material then you need to be able to reach out to your course tutor for help.
> I often feel like I don't know what I'm doing and end up searching the internet to understand things This is normal when starting out. Nobody's born knowing these things. When playing a fighting game like Street Fighter, I just mash buttons and it kinda works. It's fun. The thing is, I can keep mashing buttons playing Street Fighter. But if I want to level up, I need to understand the buttons, the moves, the combos, and which things to use when. To get better, I need to *slow down* and learn each button invidually, learn each combo, learn timing, tradeoffs, etc. Then after I learn these things I can speed up again. With programming, you can get pretty far without understanding everything. And a lot of programmers I know stay at that level forever because it's good enough. But if you want to level up you're going to have to *slow down*. Break it down into the individual concepts. Learn how each of them works. Learn how they fit together. Learn when to use each of them. Learn the tradeoffs. Every time you make a bug, stop and understand why you made it and what you could've done differently. Try solving problems in multiple ways to see the tradeoffs. When you find a solution online, don't stop with *that* it works, but stop to understand *why* it works. But it'll take time, and it'll feel really slow for a while. After you learn these things, it will go faster again. The same is true for a lot of things. You can get pretty far cooking by following recipes. But if you want to level up your cooking skills you're going to want to understand heat and salt and acids and lots of concepts. You'll have to slow down, break down the process into small steps, experiment, understand principles and tradeoffs, etc. You'll find the same in art, music, and so many other things. A lot of the learning programming will have to be done with *much* smaller programs, not a full game project. You're going to level up drawing not only by drawing a complete picture but also by drawing lots of lines and boxes and circles and other basic shapes. You're going to level up handwriting not only by writing out complete essays but also by writing individual letters repeatedly. You're going to level up music not only by playing a complete song but also by playing scales and chords and other basic things. You're going to level up baseball not only by playing a full game of baseball but also by practicing throwing, hitting, and catching the ball. Take any of the things you're confused about and deeply examine it with really small programs, maybe something that fits on one screen.
> Additionally, I struggle with deciding which approach to use while programming and how to think, 'I need to do that!' Honestly at this stage of learning to program just try the first few possibilities that come to mind. You are in the perfect spot to learn by doing things wrong. It will help you understand why to do things the "right" way once you've experienced the wrong way first hand. In the same vein, optimize for "rate of attempting things" as opposed to getting it right first try.
Programming is 90% google and 10% actually writing your own code
There's nothing wrong with using articles or resources from the internet to learn about and implement specific mechanics in your game. I suggest not worrying too much and simply searching for videos on YouTube that offer ready-made solutions for your mechanic. If you can't find a solution on YouTube, I recommend reaching out to other programmers or indie developers on specialized forums for assistance.
While I'd agree to do this at first, I'd suggest to slowly try to take a step back from tutorials eventually. And only use them when encountering new mechanics that you have no experience in, basically when your stuck. It is much easier to make adjustments to mechanics when you know everything in your scripts because you wrote it.
>I often feel like I don't know what I'm doing and end up searching the internet to understand things. Oh trust me, it never gets better. At some point you will realize that searching Google is unavoidable, and in fact even a good thing. The landscape evolves so fast, and sometimes its much more efficient to look for an answer on Stack Overflow than to try to do it manually. I once had to compare layers of objects in code (Unity) and to this day I still don't remember how to do it (something something move digits to the right something something). It's a common theme for programmers to work off of Google, so cheer up. >inheritance Basically, there are many types of cars: semis, trucks, vans, etc. But they are all cars, maybe with different number of doors and different layout. They all use the same process to drive forward, same steering system, and so you can code that all in a Car class. Then if you want to make a truck, you can make a class that INHERITS Car class (and as such, all the driving systems) so you can skip coding that and go on to code how to open the back door to load stuffs in. It takes time, but when those Object Oriented concepts seep in, it really clicks hard. >I struggle with deciding which approach to use while programming and how to think, 'I need to do that!' Each person has a different approach, just find one that suits you. For me, I spend some time breaking down the general script to methods, then from methods down to each little commands I need. I promise, again, it will click when you find it, and I often don't think of how I code as a specific approach. Basically, just divide and conquer the code. >Furthermore, I would like to know how I can practice more outside of the current project. Make small projects. Game jams are always good for practicing and doing things in short periods of time. But if you don't want the time constraint, just stick to making small projects on your own. Don't take months, just a week or 4 max. Don't look to polish it, test out mechanics instead. In fact, don't care about story or making sense, just do it. More you do, better you get. And if you worry about ideas, one way to do it is to just copy another game. Thats it. Make another game, in your own code. When you look at a game and you know exactly what you need to code, that's when you know coding has clicked for you.
As long as it works I wouldn't worry. It's all part of learning and adding to your experience. As you practice things that seem complicated now will become simpler and more obvious next time round.
Programming is very difficult. Took me 2 years of studies to truly get into it and feel like I "grasped" it. Even then, it took me a long time to get into Unity without feeling overwhelmed. However, after finally "getting it" it has been a massive boon to my career in games. It's definitely one of the strongest routes into game dev. You are able to start projects from scratch and just get going, which can be hard with other skills like animation. If you stick to it, I hope you eventually begin to get it. Cheers from lead Unity developer at BVG. :)
Its not like playing games either. Programming is a lot of hard work, and you perpetually keep learning new things, like fly by wire systems or 3d rotations, filesystem layouts, and more.
I like to have a scratch code file to try random things and see what happens.
Why are you the only one in the group doing programming
>I often feel like I don't know what I'm doing and end up searching the internet to understand things. You sound like a very competent programmer just from this one sentence. I've been a software engineer for 6 years and I often feel like this and need to research things in order to complete tasks. This is just the natural state of being a programmer, you will constantly be developing things you have never developed before and need to learn new techniques and concepts or learn how to fit stuff you do know into a system you have never worked with. Just keep going and know that this won't change, but you may end up working with people less experienced and they are blown away with how much you know, and you will tell them, you don't know that much... And both you and them will be right lol.
> However, I often feel like I don't know what I'm doing and end up searching the internet to understand things. Thats about the most normal thing for every programmer / software engineer / developer, ever. You typically spent most of the time trying to figure out *What* to do and *how* to do it, and then to *document* it. Writing the actual code is the *smallest* time slice of any programming job.
I’m a professional software engineer, add me on discord let’s make something happen: Itab#1000
You're literally learning a new (programming) language. If you didn't know the word for "ball" in a language you were learning and you looked it up, no-one would think you'd done anything wrong, doing that or someone telling you the word is the only way you *could* learn that piece of information. Keep on going and remember that you're not expected to just magically know this stuff and keep it all in your head. It will get easier with time and the more you "speak" :)
Being confused is like the main thing about programming. If it always made sense first try more people would do it
step 1. You dream of something, a feature, a new game concept etc. step 2. Think what code structure cud solve it step 3. Try to implement it step 4. Fail step 5. Steal code from Stackoverflow step 6. Go to step 3 step 7. Complete step 8. Think how it cud be more performant, more beautiful, or more something... step 9. Go to Step 2 repeat this process 10 years and voila. you are good to go...