Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Dismiss Notice

When does it finally click?

Discussion in 'General Discussion' started by Not_Sure, Mar 7, 2013.

  1. Not_Sure

    Not_Sure

    Joined:
    Dec 13, 2011
    Posts:
    3,541
    Okay, full disclaimer, this will be a wail fest with a complete focus on getting some sort of vigor back.

    I've tried, damn have I tried, to get from the point where all this stops being static noise and actually start to make sense. But for every bit of datem I think I digest there's always an ocean of things to learn. And somewhere in the process of getting the next thing down I realize that I've forgotten just as much.

    I lose heart. Go back to the roots of my desire to develop and reset. Over a decade later I actually feel further than when I started. I just want to get to that point where I have an idea and be able to go "Yeah, I know how to do that." And I see people like hippo that seem to have that and I want so bad to be like that.

    When will this ever happen?
     
  2. khanstruct

    khanstruct

    Joined:
    Feb 11, 2011
    Posts:
    2,870
    If I had to guess, I'd say you're going about learning in the wrong way.

    You're trying to memorize specific functions, scripts, etc. It's unrealistic to think that you'll actually achieve that, so don't be too hard on yourself.

    Instead, try learning HOW code works. Try to understand the patterns of how things seem to fit together, and even try to get in the heads of the people that put the language together. Once you can do that, you'll be able to assume, if not predict, how code should work.

    There will always be things you didn't know, or methods you hand't thought of, but if you can figure this out, it'll be much easier for you to work through problems and feel more confident in your abilities.
     
  3. wccrawford

    wccrawford

    Joined:
    Sep 30, 2011
    Posts:
    2,039
    First off, it *is* an ocean. you will never learn it all. People like Hippo know all the basics and then generally specialize in more advanced stuff. It can come off that he knows *everything* because he doesn't spout off when he doesn't know the answer. He's as human as you or I.

    Don't let the fact that you'll never know everything slow you down, though. There's a lot about the English language that you don't know, and that doesn't stop you from using it well.

    When will this happen? Quicker if you keep practicing. Baby steps. Do easy stuff until it becomes easy, then work on harder things. If you keep jumping in over your head, you'll keep drowning in that ocean.

    Do not underestimate the feeling of accomplishment you'll get from a small project. I entered Ludum Dare last time with a very short 2.5D platformer using nothing but colored blocks. It was a horrible game and there was a ton that could be improved. But the feeling of accomplishment was amazing. In 48 hours, I had produced a playable game. Next time I'll up the ante and insist it's a *fun* playable game.

    BTW, I'm a professional non-game programmer and the head of the team, and most of the code at work does not fall into "Yeah, I know how to do that" territory. You'll constantly be the same, unless you pick a niche and stick to it. (Trust me, that's boring.) It's fine to want to feel like that about the basics, but for the core of your game, you'll always been wondering how to do it.

    Make games. Don't worry about where you are in relation to others, or when things change. The best thing to do is just keep putting out code.

    If you insist on a number, 10,000 hours. That's what they say it takes to master a new skill. In other words, practice practice practice. Fake it 'til you make it. Keep on keepin' on. Just do it.
     
  4. khanstruct

    khanstruct

    Joined:
    Feb 11, 2011
    Posts:
    2,870
    Get in the Game. Have it Your Way. It takes a strong man to make a tender chicken....
     
  5. Amon

    Amon

    Joined:
    Oct 18, 2009
    Posts:
    1,366
    Not_Sure!
     
  6. khanstruct

    khanstruct

    Joined:
    Feb 11, 2011
    Posts:
    2,870
    $I-See-What-You-Did-There..png

    ...good lord, I've had too much coffee this morning
     
  7. drewradley

    drewradley

    Joined:
    Sep 22, 2010
    Posts:
    3,063
    Tomorrow. Always tomorrow.
    It never really just clicks. But there will be a day when you realize you can do something without needing to look at the script reference. But there is no click.
     
  8. Not_Sure

    Not_Sure

    Joined:
    Dec 13, 2011
    Posts:
    3,541
    LOL, the irony of my name is it used to be "pat.mathis" but I had "not_sure" as my answers name to hide my stupidity. The name comes from Idiocracy in which the protagonist got the name from computer error. When the forums changed format it gave me this name instead, so I kept it.

    Anyway, thank you every one for your "buck up" comments. I really do need them.
     
  9. lmbarns

    lmbarns

    Joined:
    Jul 14, 2011
    Posts:
    1,628
    Over time you find you know a lot more than you did a year before. Just gotta stay in it. I remember how frustrated/time consuming debugging errors was when I started, now it's like second nature to troubleshoot/fix them.
     
  10. Jaimi

    Jaimi

    Joined:
    Jan 10, 2009
    Posts:
    6,171
    Either you get it, or you don't. Either way is fine. Concentrate on what you can do, and work with others on the rest. Most people need a designer, but don't realize it.
     
  11. Gigiwoo

    Gigiwoo

    Joined:
    Mar 16, 2011
    Posts:
    2,981
    I never had a 'click'. But, I am successful. And, here's what I do. I practice things almost beyond my ability. I FAIL quite a lot, but I also have some small successes. And either way, I study what happens and then, I IMPROVE! And, then I REPEAT. Fail; Improve; Repeat. This is called, Deliberate Practice.

    Suggestion 2: I don't lose heart because I build SMALL PROJECTS! One time, my wife challenged me! "Build something in 6 weeks! It can be as simple as your name flashing, but you need this!' I countered, 'Can I have 8 weeks?' ... and it took me 9. But, that victory set me up for success for the past 18 months! So, build the smallest possible thing you can in 8-12 weeks! Finish it, ship it! It'll be bad, but you'll have accomplished something that 99.9% of people haven't. And, then repeat.

    Suggestion 3: I read lots of books - about NON-programming subjects. Psychology books, like 'Mindset'. And business books like 'Speed of Trust', or 'Great By Choice'. And leadership books like 'Power of Habit' or 'Switch'. And self-help books like, 'Lead with a Story' or 'Born Standing Up' by Steve Martin. I expand my mind, improve my ability to think sideways. Of course, I read game books too, like The Art of Game Design.

    Suggestion 4: When I feel overwhelmed, I take a deep breath, then a bigger one, and then an even bigger one, and I hold it! Until my lungs feel like bursting, and then let it out. That's when I can appreciate that I really have a lot to be grateful for, right now. And, that it's a journey, not a destination.

    Good luck,
    Gigi.
     
  12. imaginaryhuman

    imaginaryhuman

    Joined:
    Mar 21, 2010
    Posts:
    5,834
    I second the notion to work on really, really small projects. Try to make something you can finish in a few weeks. It makes it much more achieveable and less daunting and you don't lose interest so easily plus you can see progress toward a single goal. You then don't need tons of milestones, just one go - finish it, and a reasonable timeframe to do it in. I made an asset store asset in about 1-2 weeks part time and it's making money.
     
  13. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,509
    People have already said this stuff, but I'm going to say it again because my own experience backs it up so much:

    1: Start with small projects. Tiny projects. You'll learn more from finishing 5 small projects than from a single bigger one that's 5 times their size. I say start with things that you can finish in days rather than weeks, because it means you can restart (and try different approaches) much faster, and that's where the learning is - trying more things, or different ways of doing the same things. Also, small projects mean that you'll be more ok with stuffing things up, because there's less at risk when you do and you'll know you can apply what you learn from it in the next game you make - which won't be far away.

    Make a Space Invaders clone - menus, game, score screen, local high score, polished graphics, call it a day. Rinse and repeat with simple games. Learn. Enjoy.

    2: Learn to program on its own. "Game programming" is not a subset of "programming", it's a specialisation. In other words, you need first to know how to program, and then you learn how to apply it to the specific scenarios of programming for games. It's possible to learn by jumping straight to the specialisation, but it will take much longer and potentially result in a less complete understanding.

    Get yourself a programming book for C# (purely because that's got better available written reference) and work through it outside of the context of Unity to build up foundation knowledge.

    3: Yes, it is an ocean of information. That is not a bad thing. I've been doing this successfully for years, as both a professional and a hobbyist. There are people who could bury me without blinking if it came to a contest of game development knowledge, and they don't know it all either. So don't worry about knowing it all, nobody does. Worry only about knowing enough to get done what you need to do (which you do by... starting with small games, and working your way up one step at a time). Once you're there, the things that you don't know become positives instead of negatives, because they represent opportunities for you to improve your skill at your craft. Also, once you have the fundamental knowledge down, you can more effectively direct your learning into areas that suit your needs.

    Start learning things one thing at a time, starting with the foundation of programming knowledge, then letting your games direct you.

    Hope that helps!
     
    Last edited: Mar 8, 2013
  14. UnknownProfile

    UnknownProfile

    Joined:
    Jan 17, 2009
    Posts:
    2,311
    There is not just one moment with one big click. It is more like a watch, where you wind and wind and wind until you finally hear the first little click, and from then on the clicks will happen regularly until it is time to learn something new and wind the watch again.
     
  15. JohnnyA

    JohnnyA

    Joined:
    Apr 9, 2010
    Posts:
    5,039
    If you have been at it for a decade maybe your are just not cut out to be a programmer ... and I don't really think that's a big deal. Programming is just a means to an end, an important part of the process no doubt, but one that can be outsourced pretty cheaply these days.
     
  16. Eyeshock

    Eyeshock

    Joined:
    Sep 7, 2012
    Posts:
    60
    Just pick something to do and then do it; one of my biggest gripes with computer science classes is the 'written final'. I have never once sat down to code anything without a variety of references, and even then the internet is usually sufficient.

    My point is: there are too many variables to ever 'click', and in the time it takes you to potentially learn 'enough', new libraries and engines are released. Just pick a project and go with it; this rule is universal in exhibition.

    Memorize nothing; google everything.
     
  17. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,614
    There are some skills that can help you cover ground orders of magnitude more quickly.

    The first is: learn how to parse and glean knowledge from text even when you don't understand all the terms. For example, if I tell you that "Xing the Y can increase Zability, but will increase the number of Qs per A," then even if you don't presently understand what X, Y, Z, Q or A actually are, you can still deduce that:

    * Zability is a variable quality that can be increased or decreased
    * a Y is something that can be Xed
    * every A has some number of Qs (maybe zero)
    * Zability and Qs-per-A are (probably) opposed things, I.e. one is good and the other is bad

    You can deduce these things, but then carry on reading without actually stopping to understand exactly what they are /right now/; you can put off understanding them until you think you actually need to. I've always referred to this practice as "black-boxing unknown concepts" - you're taking these unfamiliar words and treating them as black boxes (opaque, mysterious, but logically distinct things) and building up structures around them until such a time as you need to actually open the box and look inside.

    I learned DirectX this way, at age 13 and DirectX version 7 - not from tutorials or books, but just from reading the SDK reference documentation. I latched onto words I recognised (like "draw" and "clear" and "color" and so on), black-boxed everything else, and began assembling a high-level picture of everything. Once things are in context they become much, much easier to process.

    The second skill is: learn how to look for errors in your understanding quickly and effectively. This is both a matter of spending time thinking about what you're learning, reconciling and correlating it with other things you know, looking for commonality and inconsistencies and so on - and also, on a more tangible level, learning to use your tools to get good, rapid feedback. Learn how to use step-and-trace debugging, for example; my article on the topic may help. Don't spend hours writing stuff before checking that it compiles and runs correctly; build test scenes and isolate the code you're working on to check it quickly with every change you make.

    The third is: seek ways to allow yourself to forget about things. For example, design-by-contract; instead of having to remember how all your functions are implemented, figure out what invariants they obey and what their overall effect is, and remember /that/ instead.