Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Feeling Retarded about scripting

Discussion in 'Scripting' started by goodfoot, Jul 11, 2007.

  1. goodfoot

    goodfoot

    Joined:
    Jun 20, 2007
    Posts:
    21
    I'd like a little informed advice on an issue I'm having with scripting.

    I'm taking Unity's tutorials. I've taken tutorials and online lessons about Javascript as well. I can "mostly" understand the concepts of classes, declarations, etc. I can copy the code that the tutorials tell me to "mostly" without problems.

    Here's the problem I have. I've thought up several games, and one in particular that I want to build. I have detailed ideas about how I want the game to look and play. However, I can't translate "what" I want to be in the game into "how" I would write the script to make it happen.
    I'm sure everyone here at one point or another (probably in your bedroom when you were 10 LAST YEAR!!LOL) has been learning programming and had trouble "conceptualizing" the language. That is, to not only learn the words and symbols but also to synthesize how they would work when you started typing. Maybe there's some tricks and shortcuts that might help me conceptualize better.
    I see books that say "this book makes Javascript VERY easy to learn and use" then another book says "Python is the easiest language to learn and use, buy us!!). Which book is right? Or is another book right??lol I've read enough around these boards to value many opinions here. I am NOT trying to find a quick fix that will allow me to avoid scripting because I know it is important. But maybe knew of a better way to go about it or some shortcuts or mental tools that might make it easier and more efficient.

    Anyway, thanks for the help. I'm enjoying Unity's tutorials as my trial subscription's running down. However, I still don't feel like I could recreate a script just from my own mind. thanks a bunch for your help.

    'foot
     
  2. DaveyJJ

    DaveyJJ

    Joined:
    Mar 24, 2005
    Posts:
    1,558
    It's taken me about two years to start to feel comfortable tackling some basic-intermediate scripting tasks on my own, so I feel your pain. I still don't get how some of the specific syntax relates (i.e. and to paraphrase, OnCollisionEnter (other:eek:ther) ... why not simply OnCollisionEnter (objectA:eek:bjectB) etc) and that confuses me.

    And then to try to locate how to write a specific thing in the docs when you don't know the term to look for (i.e., why are cars listed under automobiles in the yellow pages syndrome) can be frustrating.

    But there are enough tutorials, a great Wiki of scripting stuff, and a wealth of knowledgeable people are willing to share there info here. Just ask and most things get answered.

    Enjoy!
     
  3. zumwalt

    zumwalt

    Joined:
    Apr 18, 2007
    Posts:
    2,287
    Since you are new to coding, start with javascript, mainly because all of the tutorials are written for javascript and you won't have to worry about translating to either BOO or C#.

    For your game, first start out by conceptualizing what you want to do and how you want to get there. This is easiest when you grab some blank paper from Wal-Mart and some pencils. Then you draw a box and put in this box the word "begin", now what you want to do from there is draw another box and put into it something like "spawn character" then draw a line between the two. Follow this up by more and more boxes showing what you want to happen for each step.

    You will find that when you finally get to your final "End Game" box, you have tons of boxes with lines like a spiderweb.

    This will help you visualize how the game will flow.
    Now, the harder part is visualizing what each part in the game will do. You will probably have a box that say something like "player fights enemy", now from that box you have to identify what happens during the fight. Both the player and enemy can take damage and both or either can die.

    All of these boxes are a high level view of what happens during the life of your character or even the life of the game.

    To learn how this initial step works, start out with a piece of paper and stand outside your house. Work on the steps it takes to go from your front door to your kitchen. Then identify things that can happen between the front door and kitchen. Then drill down into what you can do in the kitchen.

    Understand that for every action there can be a script attached to the objects you use. Like the front door, you touch the door handle and turn it (player mesh collides with front door), then what happens? Script attached to door detects player collision and door swings open, in other words you just turned the door handle and opened the door.

    Scripts are used to create actions on objects. You can create entire worlds without scripts, but then other than looking nice, nothing will happen. Think of your scripts like verbs.

    Once you identify your actions, you can see how one action can be attached to many objects. Like the door action can be attached to all doors in the house, or any thing that can swing open, like the cabinets, the appliances, the windows, etc.

    Start by understanding what is real and around you, then you can visualize what a script can do to those objects as verbs to make other things happen.

    HTH
     
  4. goodfoot

    goodfoot

    Joined:
    Jun 20, 2007
    Posts:
    21
    Some blank paper and some pencils??? Man oh man, nobody told me it was going to be THAT hard!!!lol

    Seriously though, that was exactly one tip that I didn't know before that I think will help me go from what I can do to what I can't do. Thanks alot
     
  5. nafonso

    nafonso

    Joined:
    Aug 10, 2006
    Posts:
    377
    For people who don't have that much experience in programming, one thing that usually helps is to create flowcharts before start coding.

    After creating a diagram for a specific function that you want to do, you try to pass it down to actual code.
     
  6. hsparra

    hsparra

    Joined:
    Jul 12, 2005
    Posts:
    750
    Are you more of a top-down learner or a bottom-up learner? This can make a difference on what advice will be more effective. Take me for example, I am more of a top-down learner. If someone starts with a detailed example, I can usually follow it. The problem however is I do not know how it relates to anything, which greatly inhibits my actually learning the task. However, if I have a broad picture (does not have to be detailed) then the specific example is much easier to remember and apply since I can place it in my mental construct. It is like having a bunch of hooks to hang little bits of knowledge on. I know of others that if you start with the big picture their eyes glaze over, much as mine do if someone starts with at a low level. A caveat with me is that once I have the broad picture, I like bouncing up and down between high and low level. Sort of like a spider moving around mending its web :)

    It sounds to me that you may tend toward the top-down learner since you have seen detailed examples but are unsure how to apply the examples in more general terms. Either way I will need to give a little more thought to the issue. At this time it sounds like a good tutorial/book/example that covers how to "structure" code might be helpful. I will have to root around this evening to see if I have some ideas I can recommend.

    A few things I can suggest independing of learning style:
    1. Do not be afraid to try something in code and have it break. Try it out. Take an example that works and just change one thing and then see the effect. Something not working is good; it means you just learned something.
    2. When coding, do a little and test. Do not just code away a bunch of code then press play and expect it all to work. The example of doing a little then testing/trying is that when something does not work, which for me is often the case, it is easier to determine what caused the problem since only a little was changed.
    3. Building on number 2, start small and grow what you do. So you have a vision of what you want to accomplish. Think about the smallest part and start with that. If your idea has a character that moves around, start with a plane and a capsule and get the capsule to move. Then modify the movement so it moves more like you want. Then add you character. Then add some animation. Then add some obstacles. And so on. Even if your idea also had cars zooming around, having accidents, gun fire, and flocks of birds, starting simple allows you to start building without getting overwhelmed by all the complexity.
    4. Computers are dumb. They will do exactly what you tell them to do, no more, no less. Code is only a set of instructions. Now Unity has done much of that for you, but you will still need to think at a detailed level. In the door example, if you have a character opening a door, then you must think about how to have the character reach to the door knob, how to syncronize the "pull" on the door with the door moving, limiting how far the door opens, how fast it opens, does it automatically close, how to keep it from moving your character, what to do it hits your character, how to trigger sound if there is any and when to trigger the sound, and so on.
     
  7. hsparra

    hsparra

    Joined:
    Jul 12, 2005
    Posts:
    750
    Blank paper and pencils and dry erase boards. Those are pobably the most useful and helpful tools you can have. Sometimes note cars are useful because you can move them around as you change your thoughts how how to organize things.
     
  8. HiggyB

    HiggyB

    Unity Product Evangelist

    Joined:
    Dec 8, 2006
    Posts:
    6,183
    Flow charts and story boards can definitely help you visualize the in-game experience so do consider those as very useful (whether done with pen/pencil/paper or tools like OmniGraffle). And from personal experience, I learned through a combination of books/tutorials and lots of small demos that built up to my first programming/scripting attempts. To me books are great to have around for reference but I learn by doing, and doing a lot. Sure, I made a lot of ugly demos, wrote a lot of poorly structured code, but only through doing that was I able to wrap my mind around things enough to begin feeling confident... Here some years later I still learn new things every day!
     
  9. pete

    pete

    Joined:
    Jul 21, 2005
    Posts:
    1,647
    >>Some blank paper and some pencils???

    do they really have to be from Wal-Mart? :p

    all the above is great advice. breaking things down into smaller pieces makes things much easier to manage. even for learning as opposed to a full game. i'm feeling pretty comfortable with programming in general now. there's a lot i still don't know but i no longer copy paste. one thing that helped a lot was much like zum's advice. i didn't try to make a game. i focused on one thing. ie, first i ported the c# mouse look script to javascript, then i took a stab at a script for vehicle controls, then one for instantiating objects and so on. one at a time helps you stay focused on learning the task at hand and gets you familiar with unity's api and docs. after a few, you'll hit the epiphany. :)

    ps... a li'l tip... comment your code so you can remember why you did what you did or even note why something didn't work!
     
  10. goodfoot

    goodfoot

    Joined:
    Jun 20, 2007
    Posts:
    21
    Wow, great advice everybody, thanks! You're absolutely right about the "take small bites" approach. It's funny because I totally started this very approach with Maya, yet I completely forgot to do that for Programming. It might be because operating the software with mouse clicks, pulldown menus, etc very intimidated me from the beginning. Programming just seems daunting right now. Thanks again.

    'foot
     
  11. pete

    pete

    Joined:
    Jul 21, 2005
    Posts:
    1,647
    don't be intimidated. if i can do it, you certainly can. one foot at a time my man! :p
     
  12. DaveyJJ

    DaveyJJ

    Joined:
    Mar 24, 2005
    Posts:
    1,558
    I agree with Pete. I can't stand anywhere near any of the progammer types here (you all know who you are) but am amazed at how quickly you can pick up the basic concepts and get stuff done in Unity. As I need help I either ask politely when it's for my own tinkering, or partner with one of the folks here for a serious project. You'll be fine, just jump in!

    And as many have pointed out above, flow charting it is a great way to break it down into manageable pieces.
     
  13. forestjohnson

    forestjohnson

    Joined:
    Oct 1, 2005
    Posts:
    1,370
    This thread is so wonderful and happy I think it should be a sticky. There isn't really anything left to say at this point other than good luck.

    Oh and if something is giving you trouble don't hesitate to pop into the irc channel: irc.freenode.net #otee-unity and ask away, or post here on the forums.
     
  14. goodfoot

    goodfoot

    Joined:
    Jun 20, 2007
    Posts:
    21
    lfrog:

    You hit the nail on the head. I can TOTALLY visually the entire game, even into minute details. And I can definitely get down into the guts of it and figure out what I want the objects to do/not do. But right now, I just don't know enough about scripting to tell the computer HOW to do what I want it to do. This fact is further complicated by the fact that there's so many class names and function names, etc. They're foreign to me, most I don't even understand what they mean or what they do.
    For example, I want the computer to shuffle these 8 tiles when the spacebar or a shuffle button is pressed on the screen. However, I don't have the first idea of which class names and function names would help he achieve it. And when I do figure THAT out, I don't understand the construct of codes (how to write everything in the right order, etc). However, I've heard a thousand times about just writing the code and learning from screwing up, so that's what I want to do next. Thanks to everybody sharing the love.
    'foot
     
  15. goodfoot

    goodfoot

    Joined:
    Jun 20, 2007
    Posts:
    21
    lfrog:

    You hit the nail on the head. I can TOTALLY visually the entire game, even into minute details. And I can definitely get down into the guts of it and figure out what I want the objects to do/not do. But right now, I just don't know enough about scripting to tell the computer HOW to do what I want it to do. This fact is further complicated by the fact that there's so many class names and function names, etc. They're foreign to me, most I don't even understand what they mean or what they do.
    For example, I want the computer to shuffle these 8 tiles when the spacebar or a shuffle button is pressed on the screen. However, I don't have the first idea of which class names and function names would help he achieve it. And when I do figure THAT out, I don't understand the construct of codes (how to write everything in the right order, etc). However, I've heard a thousand times about just writing the code and learning from screwing up, so that's what I want to do next. Thanks to everybody sharing the love.
    'foot
     
  16. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    Yep, a lot of it didn't make much sense to me at first either. Don't worry about trying to learn everything all at once. Just figure out really basic and simple ways of doing stuff, and eventually you'll pick up more as you look through the docs and see various forum posts. (I was constantly referring to the docs at first...write line of code, check docs, repeat. ;) )

    You'll probably do inefficient things early on that could be done more easily once you know more functions, or at least my early code is a lot stupider than what I can do now. But that's part of learning. I'd suggest not even trying to write a game at first, but just do silly little things like making an object move in a straight line across the screen. Add a few numbers together and display them with a GUIText object. Stuff like that, so you start to get an idea of how Unity handles things, because even the most complex stuff is built on a lot of tiny little steps. Once you figure out the tiny little steps on their own, you start to get an idea how they work together.

    --Eric
     
  17. tbelgrave

    tbelgrave

    Joined:
    Jul 29, 2006
    Posts:
    321
    Actually this thread should be a sticky! I didn't have time to search today, but after finding this thread, the poster and many here share my experience which is encouraging. I just hope I have enough tenacity to pull off in coding what I can do with art. It's such a great skillset to have.

    P.S. The flowchart idea is solid!

    Take care,

    ~t