Nicholas' Simple Unity Tutorials

Jashan, you're an angel. Seriously. What a gracious contribution!

 

I respect competence, intelligence, fairness, insight and motivation when I see it, no matter how old someone might be. No one here has shown bad manners or treated you poorly, quite the contrary. It's distressing, although understandable, to find attitudes such as yours in young people, but it's very unbecoming to see this kind of arrogance in someone who claims to be mature.

Like most worthwhile goals, making games isn't easy, even using Unity, and success requires an understanding of basic programming principles, and a lot of hard work.

Do - start at the beginning, follow the tutorials step-by-step, read the forum postings, stick with small, simple things and repeat them until you really understand them. Also, type in the scripts rather than copy/paste them, to help reinforce the patterns in your head. For more general, basic programming help, google is your friend.

Don't - sit around waiting for difficult skills to magically jump into your head, blame others for your own shortcomings, spend energy complaining instead of working, give up when it seems too hard.

Follow that advice, and you'll gain some competence in a year or two. Otherwise, 25 years won't be enough.

 

Jashan:

Thanks very much for your contributions and your eloquent discussion of the subject at hand. I enjoy reading what you write, regardless of the topic.

One minor issue remains: When I bought Unity, in 2005, I was, indeed, on a Mac. Since then, for cost reasons, I switched to Windows Vista 64. After your advice, yesterday, I went ahead and looked at what Microsoft provides for their C# support and found Visual Studio Express, which is free. I've downloaded and installed it.

With Unity soon to be released for the Windows platform, that would be my choice, if I can find a way to start to form a foundation of programming in C#.

So, I haven't had a chance to work in the Mono environment. I'm not even sure what it is. From your description it sounds like a whatchamacallit, a coding environment, (I can't remember the technical name for what that is).

You probably do not work with Vista 64 if you are a Unity guy, so it may be hard for you to give step by step instructions.

Greg Smith

 

Just to make a couple of things more clear. I don't wait for any ideas or skills or understanding to "jump into my head".

I have started at the beginning, with Javascript and tried, with all my mental powers and diligence, to follow the tutorials, every one of them, from the very beginning. I put many hours into trying to understand the leaps in logic presented in these tutorials. But, and I have never blamed anyone for my lack of ability to understand, I could not follow what was going on, from point to point, in the programs being constructed.

And, I don't think it is fair to expect anyone to lead me by the hand. I never asked for that. I really don't even want that. I didn't need any outside, personal assistance when I learned to make clocks. I think the same principle should hold true with regard to learning to code. I just wanted to be pointed to the beginning learning materials with which I, myself, working alone, could learn the concepts necessary to use the Unity environment. Maybe expecting a clear answer to that quest was my biggest mistake. Also, assuming that what I wanted to accomplish with Unity, though they seemed simple to me, were not simple functions at all.

Perhaps, to avoid any future confusion among potential Unity customers, a disclaimer should be placed somewhere on the website. I'm not sure what that disclaimer should say, but it was not apparent to me that Unity was a programmer's tool. I don't believe that anyone who does not already possess moderate programming skills would be able to get their money's worth from the program.

And that is fine, but, when we are talking about the need for 1 to 2 years of proper programming training as a prerequisite to creating even the most basic gaming functions, it would be nice to let potential buyers know what are the prerequisites. Everyone would be spared much controversy and grief.


Greg Smith

 

what's wrong with my punctuation and grammer?

do you mean my lack of capitalization? i'm a soft-spoken guy. either that or lazy. if you're referring to others, as rune said, this is a global forum and english is not the first language for many.

learn the language as a language and the tutorials will make a lot more sense. good luck with it!

 

I had no programming experience, and due to a couple really good tutorials that existed, and have since been taken off the site , was up and running on my first day with Unity. I think maybe the main difference between us is that I am somewhat comfortable with having holes in my knowledge - I know that no one can possibly understand everything about anything, so I don't delude myself into thinking it is possible. The more I know, the better, but I can say "oh, a semicolon goes at the end of the statement, got it.", and be comfortable with that.

 

Cool ;-)

That sounds like a good plan. Personally, I'm using Visual Studio for all my coding, too (I have Windows running in a VMWare virtual machine on my Mac, which basically means that I have Windows running as an application under Mac OS; and on that Windows I run Visual Studio).

http://en.wikipedia.org - a very helpful URL ;-) ... admittedly, Mono is a bit hard to find there, so here's the direct link:

http://en.wikipedia.org/wiki/Mono_(software)

Be warned, though: That is a very technical article. In a nutshell: Mono is the platform independent equivalent of .NET (.NET being "totally Microsoft"). You could say it's a "programming framework". There's a lot involved - but the two or three key things to know:

a) It provides a pretty large API ("application programming interface" - see http://en.wikipedia.org/wiki/API)
b) It supports several programming languages (like C#, Visual Basic)
c) it is very relevant for you if you want to develop games with Unity because Unity uses Mono, and Mono and .NET are "equivalent" (I use them more or less as synonyms in this forum even though that's not technically correct)

Since your goal is to develop games with Unity, there's one more thing you should know: While Mono in general supports multiple languages (but usually not JavaScript), the "Mono version" that comes with Unity supports exactly three languages: C#, JavaScript and Boo. I think C# is the only language that's available in all: .NET, Mono and "Mono within Unity"; which is one of the reasons why I'd recommend using C#. Because - another thing worth noting: C# is *exactly the same* in all of these three (except that .NET usually has newer versions of C#, but you can stick with C# 2.0 and all will be fine ... eventually, Mono catches up, and a little later, Unity catches up ;-) ).

Oh, one final thing: Whatever you learn for .NET is useful for Mono. In other words: Whatever you learn for .NET is potentially useful for developing with Unity (at least when you stay with C#). Except for Windows Forms and ASP.NET, so you might not want to invest any time into learning these when you come across them (you might not even want to worry about what Windows Forms and ASP.NET is ... but in case you do: Wikipedia will help) ;-)

Well, I haven't worked with Windows Vista 64. I'm using Windows XP for whatever I need to do on Windows. I think that Visual Studio Express comes with pretty good documentation but I've never read it from the perpective of someone who has never programmed or worked with an IDE before (link to description of what "IDE" means is either below or above ... for here, just let me say "Visual Studio is an IDE, Eclipse is an IDE ... and in a way, Unity is also an IDE ... but Unity being a game-development-specific IDE").


In the tutorial I've linked in my previous posting, there's also one really important note for when you're using Visual Studio (that's right in the first lesson):

VS.NET is an abbreviation for Visual Studio - so they're talking about you ;-)


I'm pretty glad you can use Visual Studio because I think it's the best IDE available for C# (IDE = "integrated development environment" - http://en.wikipedia.org/wiki/Integrated_development_environment - but don't get tripped out on visual programming, which is mentioned there ;-) ).

Using Visual Studio will save you a lot of time looking for typos or class / variable / method names (remember that "tab" thing in my previous posting? you got something similar in Visual Studio and it'll also save you an incredible amount of typing ;-) ).

So I guess the best thing you can do is "befriend Visual Studio". Learn how to create a simple "Console Project" (Menu: File / New Project ... I have Visual Studio Team System, so I'm not sure what exactly you will see, but you should get a dialog "New Project" with "Visual C#" somewhere under project types; when that is selected, you should find "Console Application" under "Templates"; enter a name like "Tutorial01" and find a good location ... possibly the default will be fine). Don't worry about solutions for now (leave "Create directory for solution" unchecked; it might be you don't even have that in Visual Studio Express, so if you don't find that, don't worry).

Click on OK.

There you have it. Your coding environment ;-)

You're ready to work through: http://www.csharp-station.com/Tutorial.aspx ;-) (

Ah: You start a program in Visual Studio via "F5" or the menu "Debug / Start Debugging". So while debugging is actually more than "starting a program", for now, we could say "it's almost the same" ;-)


If you have any questions, feel free to ask (maybe start a new thread under "Scripting", with a subject like "Learning C# with Visual Studio and a Tutorial" - then it'll be useful for the people to come ... there will be lots of them once the Windows version comes out, so it might be very helpful to be able to just say "there's a very nice thread at XY that might answer many of your questions" ;-) ).

... just a final note (in reply to your last message): 1 to 2 years should be way more than what you need. If you stay with it, I'm pretty sure that you'll have a fun time with Unity 2.5 when it comes out (there's no official release date and you never know what happens, but my guess would be that's the case in around 2 or so months unless unexpected stuff happens which could always be the case so don't blame me or UT if it takes longer ;-) ... it might even be that you'll be "ready" before Unity 2.5 is ;-) ).

 

Angry Ant:

I didn't know that this discussion was a form of pampering. I just like a good discussion as long as people have something meaningful to discuss. And I'll go on discussing until their is nothing left worth discussing.

Don't pamper me.

Greg Smith

 

wow people really type alot here.

can some one tell me the concept/summary of this cause I'm too lazy to read that for 20 minutes.

 

Jashan:

Thanks again for all your help and explanation. We aspiring coders need a teacher with your kind of insight and expression. Time to write a book or make a video series? Money, Money, money!

Through your understanding, it seems we finally got to the root of my problems and objections - and, hopefully to those of many more like me.

Now, we know how to begin at the beginning. I think.

Greg Smith

 

You're welcome - I'm glad it helped!

I'm planning to eventually make money with my game, for which I need time to finish it (and which is intended to pay for creating my second game) ... but who knows where the flow of time will take me - it's always nice to be open to all possibilities ;-)

Btw, there's quite a lot of helpful people on these forums (some typing less ;-) ). This community is an incredible resource with an incredible amount of talent - so keep your eyes open!

Hehe, yeah - going to the root is something I do like ... that's where the power is (while scratching on the surface, IMHO, is where the frustration is ... which is why I spend 1-2 hours meditating each day: all the way down the rabbit hole, hehe)

 

Well, you've expressed dissatisfaction with Unity as a tool (which at the risk of being labelled a "fanboy" is the best, easiest-to-use tool for making 3D games this side, as they say, of a million bucks), and with the documentation (which is of extremely high quality, and geared to help beginners) and with the way you've been treated (which has been with patience and great indulgence).

So yeah, I think you are projecting your frustrations where they do not belong. There is no controversy, there is no grief, there is you drastically underestimating the difficulty of achieving something you want. Lots of people, including me, are self-taught programmers, it doesn't take "years of training" it just takes sustained focus - the toots and docs weren't clear to me at first either, but I keep at it, and I have to struggle with these concepts everyday.

If you really want to succeed, the answer to your "problem" is simple: keep at it, don't give up. Ask specific questions about stuff you don't understand (after searching, of course). Nobody here gets annoyed with questions, we all want to help noobies learn. Unity is democratizing (or democratising) game creation for aspiring developers all over the world, and while it's not quite as easy (yet) as plugging lego blocks together, all it takes to learn it is determination.

But perhaps it's not for you - have you tried Torque? It's much easier to use, no programming required! And the documentation is fantastic... :wink:

 

polytropoi:

I believe it was you who suggested the need for 1 to 2 years of programming training. The need for me to take that much time wouldn't surprise me at all.

And, please, don't indulge me, it's bad for my gall bladder.

Greg Smith

 

I suggested no such thing. I said, stick with trying to learn Unity, and in a year or two, you'll gain some competence. That's how long it's taken me, with no prior "programming training". Lots of people here can say the same. If you're not prepared to do that, maybe you don't want it enough. Maybe next lifetime.

And Emil is correct, indulgence and pampering is exactly what you seem to want. With apologies to your gallbladder.

 

polytropoi:

Thank you for setting me straight on those points.

I looked into it, and the Torque game making environment is definitely not a "no-coding" system of development. Like Unity, it requires knowledge of their flavor of C++ coding for any real game creation.

It is good to know we have resident psychologists on staff at all times, as well.

Greg Smith

 

I was kidding about Torque, and please forgive my snarky tone. But trust me, if you stick with it, you'll be rewarded, and what seems impossibly difficult now will become second nature. Then it gets to be fun.

 

polytropoi:

Great!

Greg Smith

 

I think that greg, thanks to St Jashan got what he need

Now the next step is the hardest: make a question that is actually specific and meaningful, instead of saying "it doesnt work" knowing the problem is half of what is needed to get to the solution (whoever has work experience in Design or QA knows that).

Not saying that you did that, simply foreseen the common path that these kind of discussions follow in these cases LOL

In case you are too tired to read, you can watch video tutorials for VC# on lynda.com, vtc.com or buzz3d.com; stick them on an ipod and you are good to go and learn even while you commute to work ^_^

Good luck!

 

Jashan:
You and your devilishly long posts

True, however I have witnessed quite a few artist learning programming on their own just because they wanted to. Picked up a book or some online resources and got down and dirty with it. I don't see how ones location / upbringing or whatever should deny one that possibility.

I find it is a form of pampering. It seems to me that you're looking for some divine shortcut from picking up existing books or web resources on programming and I simply cannot se why you'd attempt that unless you're hoping that his community can magically invent a completely new way of learning/teaching programming.

I'm not saying that this discussion is useless or anything silly like that, but I just fail to see where you're going with this and why.

 

Now THAT would be great, in fact !

Imagine Jashan's excellent posts, together with some others', "ported" to a big Unity project... I would pay $$$ for such immersive learning tools.

 

I guess the key point to understand is that - unless you "have it in your blood" - Unity is not the best environment to start programming with.

I'm thinking about pulling some of these postings together into a more general format and putting that up on the Wiki for people who want to use Unity for creating games but have no programming experience and need a "slow start" to get up to speed.

For people who already have a grasp of programming, there's really an incredible amount of excellent materials already available (see Tom's posting somewhere in the beginning of this thread). So, my feeling about what is still needed is something that guides people who actually want to use Unity but don't know about programming, yet.

Also, thinking about how often there's questions like "which programming language to use", a little "C# compared to JavaScript guide" sure would be helpful. Basically, that's just a matter of going through the existing postings and "objectifying" what's written there (and if sure would be nice if someone with an understanding of Boo could add to that, too).

 

Sounds good. Perhaps add in somewhere in that section some info about .net .dlls vs. binary .dlls - its somewhat related and a topic often seen on the forums I think.

Regarding boo, perhaps you could contact Ricardo (Arges) and Neil (NCarter) - I know both of them have been dealing with it one way or another.

 

Although the exact title slips my mind it is something like, "Head First Programming in C#". It looks like a very long and thick book, but actually that is because of the format - lots of side notes, illustrations, etc.

I saw this book the other evening at Barnes Noble, and if I had in my wallet a spare $49, I would have purchased it. The two authors were very sincere about teaching by certain methods that have been proven to be the best way to get learners to retain what they read. So, it is a very extraordinary text, just from that viewpoint, alone. In addition, the programs they include as tutorials look very interesting and, even possibly, fun.

People of different sorts do learn differently, and whatever you technically call the approach they have used, it seemed to slip very easily down my mental gullet. One of the key principles they present is that textual presentation of information is best comprehended and then absorbed when placed right next to, or in the middle of an illustrative graphic that represents an analogy of the concept, as apposed to putting a similar graphic somewhere else on the page or on another page, altogether.

So, they use this technique all the way through the book. I wholeheartedly agree and rejoice that they have taken this approach. The book is also written to make specific use of the "Visual C# Express" programming environment, (which is free), where much time is saved the coder by automatically filling in the parts of code that are simply repetitive and tedious.

This may fly in the face of some of you who may find it another form of pampering and indulgence, however. So, and you know who you are, those of you who think all the learning materials necessary for a determined and aspiring programmer already exist and have existed for eons, and that they are enough - well, ignore this book, entirely.

Greg Smith

 

Jashan:

One thing I forgot to ask you: since the bulk of the Unity sponsored tutorials are written for Javascript programmers, do you think a novice C# aspiring programmer will be able to translate his knowledge into the Javascript equivalent? Will such a person have the framework to write the same code in C# that he reads about in the Javascript tutorials?

I think someone like me might have difficulty there.

As you have expressed, a kind of "bridge" between the two languages seems necessary - a "C# as compared to Javascript" kind of text.

Or, better yet, all new tutorials written specifically for the C# language. If only you had more time than you do, a vast fortune could possibly await you.

Greg Smith

 

I think the best approach is really to get a good understanding of C# first. It's not that hard after all. Once you've grasped the concepts of C#, have a look at the JavaScript examples and you'll realize: It's not really that different. Some stuff is missing (which makes it harder to understand in my opinion), some stuff is written differently; but in general, it's a simple conversion from one to the other.

The cool thing about this is that it's actually a nice exercise: When you take a JavaScript file, and copy it into a C# file with the same name, you'll first get a lot of compilation errors. Then you can start fixing one after the other - and soon you'll get the hang of it. But you'll also start to learn about the Unity APIs because there are a few things you'll need to look up (in the beginning, when you're not familiar with the Unity API, yet).

As long as you don't do this too early and as long as you're aware that the first few times might take a little time to complete, it'll be easy. There's also a page in the Unity documentation which outlines some important differences (I think somewhere under "advanced stuff").

One thing that will also help you is that on the Wiki, there's quite a few examples that are available in both JavaScript and C#. Look at both, notice the differences, and you'll start to get a first understanding.

If I find time, I might take some "mid-size" class and move it to C# and write down the actual steps. That could serve as the "bridge" you were referring to.

Personally, I'd prefer the tutorials being written in C# - not because I prefer C# in general but because that way, the tutorial code would contain a bit more information which would make it easier for newbies to look things up in the Unity API documentation. Aside of that, however, you'll be able to read JavaScript and understand it pretty soon, so the tutorials will be very useful for you, too ;-)

... it'll be interesting to see how the demographics shift with the coming Windows users, though. I think it's very likely that there'll be a lot of people with a .NET background who will probably not like JavaScript that much (but that's just speculation ... currently I think there's more people with a JavaScript background which is why having the tutorials in JavaScript makes sense).

 

Haha - I wasn't aware of that, but there's actually already a pretty good C# Unity guide on the Wiki. Check this out:

http://www.unifycommunity.com/wiki/index.php?title=Programming

 

Maybe after Unity hits the PC (Unity 2.5) and opens its door to the rest of the world we may get a few more tutorials.

And a way to make the learning curve much easier... even though Im kinda of greedy I wish it would stay a mac app only thats not gonna happen. lol

I think once the masses have it learning will be much easier for us artists that are coding challenged but never give up hope if you stare at the code long enough it soon starts to make sense

Sincerely,
Michael

 

It'll be interesting to see if you reach the point where "the penny drops" once you have that moment of insight you'll find that coding is easy, there's probably only about 6 things you actually need to remember. What is difficult is learning the logic required to design a game/program. I think some people are more naturally inclined to think the right way to do that. Please report back if you are it'll be interesting to see.

I've taught a number of people how to "code" from scratch (one guy used to call expressions "magic spells" so you can see where he started from) in the most part they were only interested in learning to write very short pieces of scripting just to automate otherwise boring tasks. They now have all the "skills" required to write a complete app but I don't think they would have any fun doing so and would find the structured logic required too far removed from the artistic process to get very far with it.

Coming to this discussion very late but I find it very interesting, you don't mention your actual age (as far as I remember) but you hint at it. I think people here won't necessarily all realise how much assumed knowledge is involved in something like Unity. All the material for learning is scattered around, this is a modern situation where there are Wiki's and pdf's and help files and books and what not. It's great but people have "learned" how to navigate all this information and filter out what is useful and really don't take a step-by-step approach any more. That happens to suit me so I'm not complaining about it but I think its a generational thing. I've met enough people who "don't get it" to know its not as obvious as everyone who does thinks it is.

One final thing to add to this rambling post. I know I'm not adding much but had to join in as its a pet interest.

I wonder if when you did this the book took the time to explain how to use a chisel? If it didn't and you'd never used one I imagine you're probably a 1 finger typist, not through lack of skill at learning typing but because you lost them all making the clocks! My point here is that even in that situation there was probably a massive amount of assumed knowledge, its very hard when teaching anything to go back so far as to teach everything required.

But I think you are right there may be a market for writing a book that is both step-by-step and does go back at least as far as the basics of coding, but I think assume that people know how to type.

 

Monark:

Yes, it is the assumed knowledge that has been the biggest problem for me. But, I have been using personal computers from the beginning and have acquired some of those abilities related to gleaning the knowledge I need from many different sources. I had to do this gathering information for making clocks.

I think the reason the accumulated knowledge finally clicked, for me, with clocks, was the fact that it was modularized and set out in specific design "phases".

First, you acquire the material of the proper thickness, then you lay out the teeth along a circle - then you cut the teeth. With clocks, you always start this way and it never varies. Once mating wheels and pinions, (gears), are made, you determine the proper spacing between them so that they run smoothly, etc. Additionally, the knowledge presented was "hands on" and basic, not very theoretical.

With clock making, whether you are using a chisel or a saw is important, since a chisel would not work to cut teeth on wheels and pinions. So, one must acquire the skill of moving a saw. Quite simple, really.

Couldn't the presentation of "game building" be approached in a similar fashion? Piece by piece, step by step, clearly, leaving out nothing, until the simple parts of the "machine" are made, and then describing how each piece or module of pieces is assembled into a portion and from this portion into a whole?

Some of the presentation would cover "physical assets" and, right along side of this could be the code which applies to these assets, and, most importantly, why these code snippets are applied - and, line by line, jot by jot, what each phrase accomplishes.

I realize this might fall into the category of a "monumental endeavor", but, if I had the ability, myself, I would approach it this way.

Greg Smith

 

Its like my clock has chinese instructions and comes with a chinese dictionary but the only books out there are to actually assemble the clock are in korean language but they should be close enough languages for you to put it all together

It seems to me that the tutorials are not broken down enough into its simplest form. The 3D Platform Game is a great tutorial but if you want to vary something and change a bit of code to suit your needs to learn from youll be lost in the amount of Console errors, because the game is a whole with all its parts followed step by step that cant be changed.

As I posted in the wish list section of the Unity forums, I wish there were a lot of mini or short tutorials, because they would be easier to learn from and later be able to be built upon.

Like one on how to make the blast effect you see from a gun firing, where the flash comes from the tip of the gun, (muzzle effect) the end.

Another one on how to shoot a machine gun and raycast ( I think its called raycast) the the bullets and object it hits, the end.

Another one on when the bullets hit the wall there is bullet holes left after the impact, the end.

It could be Many small simple Tutorials. This way new users can learn and expand their knowledge. There can be many short tutorials on many different topics like how to shoot, animations.

This way the code would make sense and there would be an arsenal of code snippets and a way to refer back to everything.

Learning Javascript online is tough because its all about webpages and html and you have to try and mash it all together with unitys api a different dictionary.


Monark I sure hope I can get it? I keep trying

 

I did some more or less line-by-line explaining in this tutorial. Might help, might not--I never actually sat down and said "I know, I'll write a tutorial" and planned it all out--it just sort of happened for some reason. As such, I'm not quite sure who the audience is, and I don't know how effective or helpful it is, but it's gotten some positive comments, so I guess it's not all bad.

--Eric

 

I've just finished reading this thread.

@brucegregory: You are right, sir, when you talk about willingness.

Willingness, my friend, is the master word for your problem. You need to be willing to learn, no matter how hard, no matter the quality of your tools, no matter the quality of your books.

You talk of clocks and the minutia that went with the learning process of clockwork, but have you thought of how many years it took to develop the concept of a wheel? how about the mastery of metal work? the making of glass? or even, the very concept of time (which probably was noticed first by a true ancestor-geek)?

Many things are taken for granted in our everyday life, and that basic principle applies to every field you will work in, programming included.

Now we're not asking you to learn about binary and opcodes, but you will need to familiarize yourself with some basic programming concepts, no matter what area you wish to apply your knowledge to.

It now seems you are genuinely interested and there is no reason in the world that you should not succeed. You have been around long enough to know that patience and perseverance are keys to success.

So good luck to you in your learning, and I hope you one day will enlighten these forums with your newly acquired knowledge.

 

Jonaphin:

You are right about willingness. And, if I have learned anything over the years, willingness to learn something new is inseparable with the time one must dedicate, (and assessing the amount of time needed to accomplish any particular goal, in an accurate fashion), to learn such and such a thing. Time spent versus benefits gained.

For me, assessing the time needed to moderately master C#, for instance, to a degree sufficient for programming games in Unity is still an unknown - and this disturbs me.

As you also said, time and effort are needed to gain some kind of grasp of general programming concepts - and others have stated that this is often more difficult than mastering the syntax and application of any particular programming language. And, I am debating about dedicating a certain amount of time to that task, using a tool which teaches the logical concepts of programming, independent of any particular programming language.

I'll try to keep everyone posted regarding any progress I might make.

Greg Smith

 

This is true for all learning. However, you need to balance the time spent in learning X with the time saved once you have done so. This is a classic cost:benefit calculation. As you get older, you tend to find your time becomes more expensive -- let alone the raw financial outlay in getting hold of the required information and tools -- and this makes learning something new harder to justify.

For many students and school-age Unity users, time is effectively 'free', so they can be more profligate with it. As we get older, with more commitments on our time, what free time we have left becomes more precious to us. (This is a major reason why people tend to slow down their learning as they age and become increasingly fearful of change: Change means learning new things, but learning new things is 'expensive'; ergo "Change is Bad".)

This entirely depends on your ability to master basic concepts like logic, cause-and-effect, and simple algebra. Computers are extremely dense and this catches a lot of people out. Computers NEVER do what you mean. They do only what you say. To the letter.

Order a soldier to "JUMP!" and he'll yell "SIR YES SIR! HOW HIGH, SIR?"

Order a computer to "JUMP!" and it'll go right ahead and make a dent in the ceiling. (Or, more likely, respond with: "SYNTAX ERROR IN "JUMP": COMMAND NOT FOUND".) You have to explain everything to it, often from first principles. 3D models? Computers don't even know what they are. (The graphics card doesn't either. It's merely been designed to deal with certain elements of graphics processing really quickly. What those vectors and matrices are being used for is entirely beyond the wit and comprehension of the chip. It's just a machine.)

The wooden cogs you build for your clock have no clue that they're there to help tell the time. Your clock doesn't know it's telling time: it's just being subjected to basic laws of physics and moving long, thin bits of wood around in a circle accordingly. That it happens to do so in such a way as to help us tell the time is merely why it's been designed that way; the clock doesn't know.

Programming is actually a lot easier than it first appears. Once you realise that 70-90% of programming is just putting up structural and organisational scaffolding, you soon learn to see past the magic incantations and spot the strings. All those brackets, braces and keywords are just the plastic bubble-wrap, the labelling and the cardboard box. The useful stuff takes up only a fraction of the code.

Software development tools are never designed by professional interface designers. In fact, I'm hard pressed to find a single programming tool that was actually designed by anyone who wasn't already fixated on text-based interfaces dating back to the 1960s.

For some reason, every program tool on the planet appears to revolve around typing magic spells into a text editor, feeding those spells to a spell interpreter, which translates them into something the computer can actually understand, producing loads of disparate bits of magic spell strewn about all over the place. It then hands the lot over to an IKEA Furniture Assembly Tool, which nails, screws and bolts all those bits of magic together, finds it has some components left over, along with a weird metal thing with spikes, and tells you it's finished building the bookshelf you asked for. Usually, you'll remember you weren't trying to build a bookshelf, so you go back to rewriting the instructions until the final assembly process results in something vaguely resembling what you wrote down.

Programmers are sado-masochists, basically. Unity goes some way towards putting programming in its place -- namely, somewhere over there where all the weird people and winos are, rather than front-and-centre on a pedestal -- but it isn't anywhere close to bypassing the whole typing-magic-spells-out-into-text-files bit altogether. I suspect that'll take some time to achieve, but it is achievable.

And that's why there's still programming required. It's nowhere near as bad as it was in the Bad Old Days, when we had to roll our own graphics engines, sound engines, etc. But you still have to explain what you want that spaceship to do, when the player moves the joystick a half-inch to the left.

Unity does take care of some of the structural scaffolding too -- especially if you use the Javascript option. (It's not quite as seamless if you're using C#.) But there's still some way to go.


(And yes, to all you other naysayers: I am indeed agreeing with Bruce Gregory's sentiments. Programming is needlessly hard. It's been made harder than it has any right to be, without any justification. There are better ways of doing this. It is my sincerest hope that the UT folks rise to the challenge.)

 

Well, the simple truth is: It just is the way it is.

Of course there's a potential that this will evolve - as it has done already (think about what you're "moving" with just a couple of lines of code ... imagine you'd have to do it all in assembly code ... all of it).

It's not like people are sitting together and discussing how to make it more difficult and complex. However, people ask one very smart question: What is the quickest and most fun way to get my game done? What are the costs of certain tools / technologies? What is the benefit?

With Unity, they took a really state-of-the-art programming environment (Mono) which is under very active development and has a huge community (anyone who knows .NET immediately knows how to use Mono ... and even better: anyone who knows Java ... the "real Java" made by Sun ... immediately understands Mono and C#).

While there sure is room for improvement built upon this (look at some of the stuff that AngryAnt is doing - it's cool stuff), I think it'll still take quite a while until using some non-text-based programming approach will make you significantly quicker than using the text-based approach. In a few cases, of course, it'll be just fine ... but for the "general cases" (i.e. you want to create something new), it'll take a long time until coding is gone.

I've seen so many attempts: JavaBeans ... yeah, "Visual Programming" ... that was many years ago. No one talks about this anymore. It just didn't do what text-coding does (however, if you're developing larger-scale systems you do have a whole set of "modelling" tools ... check out UML, Unified Modelling Language, for some details ... and that "language" is, in fact a visual language, and you can perfectly use it with Unity since there's quite a few C# UML tools available).

Anyways, I have this wonderful Mac OS GUI. And I love Mac, and I use the GUI a lot. Nevertheless: There's quite a few tasks that I do with the command-line. Why? Because it's the most and efficient way to do those things. And that way, it's most fun for me ;-)

If you come up with a better way of explaining to this dumb machine how to "do all the builds of my game I have thought of" - I'm right there, if it serves me, I'll use it. But as long as it's not there ... well ... someone's gotta come up with it, and that it must be more efficient to use than quickly writing it down.

... and as long as there's a huge mass of game developers out there looking for tools to help them get their game done in the shortest possible amount of time - with the skills you currently need; I think there's a *lot* of work for UT to do before they'll find time to re-invent programming ;-)

 

I respectfully disagree.

For your information, I was writing (published) games in the '80s and '90s in assembly language, C and C++, so it's not as if I'm just having a rant from a position of ignorance. I've been paid to make games which went on sale in shops.

I have spent years researching ways of doing it better. At the same time, I've spent years using development tools and environments that have become progressively more cumbersome and bloated over the same period.

Something which took me minutes to achieve fifteen years ago now takes hours. And it's less stable, less predictable and far, far less rewarding because of it.

Only hardcore programmers insist on all the pomp, circumstance and distractions. And they do so because they know damned well their emperor has no clothes: They've added needless complexity where they should have been simplifying. They've made "The Holy Code" an end in itself -- when the damned thing was only ever a means to an end. They've taken it so far that there's an entire movement and culture of sadomasochists -- I call it the "Cult of Open Source" -- who revere programming as if it were a blasted religion! These people are WRONG. Stallman is WRONG. Worse still, they are harming the IT industry by their persistence.

Software development is not programming. Programming is just an interface. A means to an end. The tools and processes must change. I want to be able to stand by my games, know they are 100% bug-free, the way I did back in the days of the Sinclair ZX Spectrum and the Commodore Amiga.

I don't want to see a better version of Unitron in Unity 4. I don't want to see a text editor at all. It's an anachronism.

 

@ Sean and Jashan

You know we've considered in the office here making a special forum section just for the two of you to compete in who can make the longest post in internet history

Sorry...couldn't resist,
Ethan

 

I love Unitron.

And I do sit in a dungeon, stroking a feline and laughing diabolically at how to made code more difficult.

My latest theory is to remove the ; from everyone's keyboard and replace it with the emoticon.

@Greg, hang tight, a third party solution is on the way.

 

Indeed. I was surprised to discover multiple people as wordy in their posts as Jashan :wink:

 

What? I've written longer texts on my mobile!

 

@stimarco: Why aren't you building an easy to use game engine?

What was easier back when you had to input 0's and 1's into the computer to make it draw a pixel?

I'm lost here.

*lols*

 

@stimarco
Calling you out on this now. Explain the alternative to code that is in your mind and is superior. You must have some idea of the direction that it should go. Obviously, you imagine it going away from text editors and code, but I'm curious where you think it should go.

Diagrams please. No text. It is archaic.

 

Because I'd rather pay someone to build tools for me instead of starting from scratch. Besides, Unity is still way better than anything else out there and I'm using it to build games now. (It's been over a decade since I did my own graphics, so it's not going quickly. It's taking some time to scrape the rust off my 2D pixel art skills.)

I didn't input zeroes and ones. I wrote games for the ZX Spectrum, Atari ST, Commodore Amiga, etc., in assembly language. I still find it easier to read Motorola's 680x0 assembly language than code written in either C or C++. (Motorola also bothered to look up the word "mnemonic" in a dictionary before designing their assembly language, unlike a certain, well-known CPU manufacturer I could mention.)

Programming the hard way was tolerable back then. I find it intolerable now. I can just about cope with doing it in Unity as it hides most of the tiresome stuff. (And I don't have to worry about initialising myriad OS components, checking graphics card caps-bits, dealing with sound card issues and all the other folderol I'd have to fart about with that have absolutely nothing to do with my game.)

On top of that, I'm confident enough in Unity's stability and code quality that I don't need to worry about building on shaky foundations. Nevertheless, there's still that sense of walking a tightrope when I do a project like this. I have no guarantee that the graphics driver my game might have to use won't explode. Worse still, the people who wrote that graphics driver refuse to guarantee its quality and stand by their coding skills. And THAT is what I find difficult to accept.

I used to be able to guarantee my games 100% bug-free. I can no longer do so using present software development tools and interfaces. I hate that. It rankles.

I therefore contend that said tools and paradigms are no longer fit for purpose.

 

** Atari ST **, I miss you, old friend...

 

Will interpretive dance do?

[EDIT: I'm going to start a new thread on this as we're clearly wa-a-a-y off-topic. It's now a new "Gossip" forum thread named "Programming languages considered harmful".]

 

Hehe ... well, when it comes to response time I guess I failed on this one (now everyone go look up which posting I'm replying to ... ages ago) ;-)

... but hey, I do have a couple of "less than 15 words" postings, so I guess the average is not that bad ;-)

 

also there is a book for unity now see the blog blogs.unity3d.com.
i am not sure if it teaches javascript or not.

you can learn javascript syntax in microsoft MSDN web site at msdn2.microsoft.com

if it's hard for you to learn the most simple scripting languages like javascript. (you don't need to think about pointers, casting, references, memory management and much more). if it's hard, game development is not for you. also you can use 3Drad that is a software for creating interactive content but even 3drad needs scripting for complex projects. 3Drad is free just like our lovely unity!

all people here love the product and no one closes threads for telling your idea so be polite about the devteam the unity itself and the community please.



there are tools for visual scripting like quest3D but those tools have scripts too. just that is a block instead of a function name