Any tips to go from "scripting" to "programming"?

I feel like I'm hitting a barrier with my skills.

I can navigate the Manual and the API to figure out how to do specific tasks. I help others to reinforce what I've picked up. And I'm getting pretty good at reverse engineering how things are done. And I'm getting a knack for making clean efficient code.

What I suck at now is the big picture.

I'm not getting how to structure code. How to make code re-usable. How to create systems that I can add to. How to manage data. How to manage versions. How to make a complete game that saves data between plays.

Right now I feel like I can tinker and do a whole lot of things, but I'm still not able to reach that next level and do more than just over glorified "hello world!" programs and Unity Tutorials.

I've got all these tiny pieces of knowledge in front of me like puzzle pieces, but I can't figure out how to put them together.

Does that make sense?

I'm looking for books, tutorials, wikis, sites, vlogs, blogs, projects, anything please!

 

The best thing to do, in my opinion, is leave Unity for a bit. Try writing an application in pure C#, just a console one at first and then maybe look at GUIs. The more you do the more you'll learn new skills and tricks that you can apply to Unity.

Leaving Unity meant I got to learn a lot more generic programming skills, things that aren't applied in the Unity context as often, like design patterns, interfaces, static classes/singletons LINQ, heck I even moved onto vastly different subjects like OpenCL and functional programming for a while. For me leaving Unity was genuinely one of the best things I've ever done.

The way I learn best is to just do things and work them out. You hit a problem and so you look on stack overflow and you discover something new, next time you hit that problem you can solve it. When you come back to Unity you've suddenly got the skills to make reusable, modular code and it's going to be a lot better code.

Go write and ship some code, something on the asset store, that way you have to maintain it and you'll be forced to make it maintainable and you'll learn what to do and what not to do in terms of maintainability.

Jamie

 

Practice. Practice. Practice.

You have now entered the stage of conscious incompetence. You simply need to spend time programming.

For me it was helpful to drag programming into my day job. I spent time automating some of the common tasks with simple computer programs. These tasks got more and more complex until I started getting recognized within the company as a programming resource. Working on other people's problems from answers helped too. Any opportunity you get to program a task where you have not set the parameters is worth attempting.

Practice.

 

Sounds like planing is not your thing, just join a team and problem solved.

 

Two problems with joining a team.

1) My schedule would never allow me to keep with a team project. I may be called in at any time for any length of time at my job. Also, I have some hefty family obligations with two senior family members that me and the misses need to help constantly.

2) I don't know if a team would have me if I can only write scripts and not really code.

 

I don't consider myself a programmer but even I can tell you you're thinking it backwards. You want to become a programmer so then you can do all these programmer things. But it's the other way around.

You need to start solving problems so build your own skill set. That's why not all programmers are created equal. So you must create yourself by practicing, practicing and practicing.

 

Yes, deliberate practice is a must.

How do I do that?

Seriously, everywhere I look I see how to do scripts for this or that. But I'm not finding a whole lot on structure and other larger programming concepts.

 

I'm not generally a proponent of so-called "programming patterns" and trying to force the use of them, however they can be a good source of inspiration when trying to structure a big-picture sort of thing. There's a book called Game Programming Patterns that I recommend every chance I get. It applies the pattern concept to games and shows where you would use common methods for structuring common game-related things. The entire text is available online for free as well so it might be worth a perusal. It's easily one of the best books I've read on the topic.

Otherwise, what others are saying - practice. You'll eventually learn how to fit things together out of necessity.

 

You realize how crazily generic that question is, right?

 

Get off the computer. Get a notebook and a pencil. Start designing.

To get the "big picture" you simply need to focus on design instead of implementation. Not game design. Architectural design. System design. Application design. I think perhaps all of the Unity tutorials around the net probably fail on the aspect of design and planning. They all seem to cover writing tiny scripts. Of course this is probably a direct result of the Component-Based approach Unity emphasizes.

You need to step back to the point before writing the tiny scripts. Pick a system maybe an Inventory Manager or maybe an entire little game.

Write it all down, draw some doodles, show relationships and dependencies. Identify the key systems and components. You can take it as far as you want or need. You could do class diagrams and flow charts.

That stuff is basically what separates a programmer or at least software engineer from a "script kiddie". That engineering part. You simply think through the problem, design the architecture first then you start implementing it. It's probably the missing piece.

 

Few years of practice programming and banging your head against the wall occasionally.
I wish there was a faster way, but I don't know of it.

By writing programs. You get an idea, you try to implement it, then you hit a wall. Then you destroy the wall. And hit another. Then you overcome that wall too. That's learning by doing. Try to have fun in the process.

That's because there is almost no training material for non-beginners on the web. From this point on you'll be mostly on your own, hunting for small pieces of information all over the place. For a start you could look at "design patterns", "yagni", "kiss principle"... and see where the breadcrumb trail takes you from there. Also, one thing to keep in mind - when someone claims that their methodology is "the one true solution for every problem", they're always wrong. There will be always an edge case where you'll be better off without it.

---

You should also ask yourself if you even NEED that. It may be wiser to just find a programmer to work with.

 

Maybe someone can tell us if the book "Code complete" would be a good recommendation in this case?

I have read only parts of it and I liked those, but I'm really not in the position to judge if it's any good for the kind of knowledge you are seeking.

 

What you're looking for sounds like programming design and theory. You won't typically find these in tutorial form though as they're often relegated to books. Very big books at that. Code Complete, for example, weighs in at 960 pages.

http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/

Recommendations for programming books can often be found on Stack Overflow.

http://stackoverflow.com/questions/22873/language-books-tutorials-for-popular-languages

 

Why don't you simply try writing a bigger game in Unity? The best way to learn is to try to do it and see what needs to be done. Then you'll probably have some more specific questions. Unity has a few projects on the Asset store that you could also unravel.

I don't agree with people who are saying to get off the computer and write stuff in a notebook, or write some boring learning program outside of Unity. I have found that for me this quickly kills my motivation...when you need to push yourself to learn new things you need motivation, and the best way to motivate yourself is to be aiming at a real goal such as creating your own game.

The best way I have found to learn is to decide what I want to do and just tackle every problem as it comes along.

 

Game Programming Patterns, Code Complete, Stack Overflow... Got it!

I actually already have an account on Stackoverflow and have Programming Patterns in my book marks.

Code Complete sounds familiar, I'll give it a look.

Thanks everyone!

Any other suggestions?

 

Advice: Don't ask questions on stackoverflow. The site went nuts a while ago, and is extremely hostile to everybody. If you come across informaiton on stackoverflow, though, use it.

 

Yeah... I've found it's quite a gamble if your question will be well received or not... Even posting answers to people I'm a little afraid I will be shot down for it

 

You should still be able to find some sane people if you post questions about common lisp or prolog.
For anything else assume that you'll be dealing with lunatics and will be screamed at and downvoted into oblivion.

I think books will be a better learning material than SO at this point.

 

I know right... I don't know why people are suggesting to waste time on things outside of their dream project. Make the game and solve problems as they come into question. Learn on a need to know basis. Efficiency will keep you motivated. Dont waste your time and energy by going off track. The knowledge will come while you chip away at the problems that are apart of your main goal.

You need to learn how to learn efficiently first.

 

Often the quickest way to learn is to accomplish small, specific tasks. Or to study a topic in detail.

Sure you can only learn how to do a big project by doing big projects. But a lot of things aren't specific to big projects, and can be learned more effectively on small projects. A lot of things are also best learned by specific study.

 

I'm a book learner so I just download a book, read it through, and immediately use it in a project. I have other peers who learn better in other ways, so it varies based on your particular learning style. If you don't use the concepts in real code(not copy and paste but by hand, repeatedly) you will forget it though, this seems pretty universal.

For Unity in particular one of the better learning resources for me has been other people's code. I'm not talking about the tutorials and such, but for instance, NGUI is a good one. I spent a week just reading all of that source and seeing how he architected it and how simple, clean, and concise the code was(it is kind of beautiful). I also have a Grids asset, which has some great code and also exhibits those traits.

But, YMMV.

 

I agree with the premise of what you're saying, but the question of how to structure programming in a game is not IMO a good reason to go off and study some abstract stuff out of a book, especially when the OP is at the beginner level. I love good textbooks, and a good reference manual is gold, but only as a reference and not as an exercise in itself.

In general however there is a lot to be said for breaking up larger tasks into small ones, or practicing solving easier examples of what you're trying to solve. But learning must be goal-driven, I even say this as a generalization, it has to be directly applicable to something you're trying to accomplish, or otherwise you'll end up swallowing metric tons of random information with no way to tie it together or any reason to remember it. It kind of sounds like what I did at uni, the only stuff I can remember is the work experience, all the years of learning-for-the-sake-of-learning classes just went in one ear and out the other for what should be obvious reasons.

 

I think it's a great reason to study stuff in a book, especially when the reader is just at the level where they start to realise that such topics are important. I agree that book study alone isn't especially useful, but combining book study to learn new concepts with deliberate practice and/or real world projects in which to apply them is golden.

Also, there's plenty of stuff that's really hard to learn when you're down in the trenches all the time. Learning how to do the big picture architecture/design won't happen if all you're ever thinking about is how to implement small things.

To me the process was something like this:
1. Identify some opportunity for improvement or challenge yet to be faced.
2. Have a go at it.
3. Identify all the stuff that didn't work well.
4. Learn about that stuff. Books, online discussion, self reflection.
5. Do it all again, applying the outcomes from 4.

The first project is generally a mess, but you learn really rapidly.

 

Perhaps its just the industry I come from. Learning how to build a chemical plant as you go it is a good recipe to die in a fireball.

Game programming is nice in that most of the time making mistakes doesn't kill people. That doesn't mean that its a bad thing to go get advice from someone that has already done the job and wrote a book about it. Sure you won't ever learn everything you need to know from reading a book. But reading a book is a great way to learn what other people have already discovered, without requiring you to make all of the same mistakes they made.

 

I think we agree more than you realize.

@BoredMormon you're making the mistake of comparing apples and oranges. Self taught programming has virtually nothing to do with learning how to run a chemical plant.

To teach yourself games programming you require more than anything motivation, you're doing this for pleasure/hobby and nobody is paying you or supervising you to attend workplace health and safety seminars (or programming structure guidelines seminars) or testing your ability on it or going to die if you do something wrong. Also your supervisors when you learned how to run the plant were experienced people who developed and used clear, strict guidelines, knew how to teach you and test you, and all you had to do was put yourself in their hands and learn what they taught you. Whereas a programming book is a collection of generic abstractions that may or may not be relevant to you, and you can't ask questions of the author, and nobody is going to test your knowledge. Consider what the general response is to a question on stackoverflow, or even Unity Answers - basically "OK but what exactly are you trying to do?" - nothing is set in stone, there's 10,000 ways to skin the cat depending on what you want to do and digesting all of them for the sake of studiousness is a complete and utter waste of time.

So what you need to do is test yourself by learning in step with trying to achieve your goal, by first running into your particular roadblocks and then looking for the answer in some abstract example in a book. Don't get me wrong, like I said a good textbook is worth its weight in gold but it's utility is as a reference resource.

The reason why I referred to uni classes as being a waste of time has probably more to do with private universities and their lack of coordination with industry, so it probably isn't relevant. My work experience wasn't unstructured at all, it was structured like the classes, except that it also happened to be directly relevant to something in reality and that made all the difference to me.

 

Haha, you say that having cut out the single most important line in what I posted!

 

I didn't mean to try to change what you'd said, sorry if it looks that way. I was just trying to highlight what you wrote that is basically the same as what I've said.

Which line would it be that I missed, that makes all the difference?

 

Maybe not so much apples to oranges. I still maintain the absolute best way to get into the game industry if you really are serious is to do time working for another studio. Get some mentioning from people who are already making money in the business. Many successful professional game devs started out this way, including some of the greats.

Either way I think we've both pretty much run out of useful things to say on the topic. Internet forums seldom change people's minds. So I'm out on this one.

 

I agree totally with this. I just think that self-teaching requires a different approach, but it's going to be less efficient one way or the other.

 

The only one that you removed from the section you quoted. The one where the theory learned gets applied in practice, in turn becoming a starting point for whatever is learned next.

The point is that learning (from books or discussion or whatever) isn't a thing you do at the end. It's something you should be constantly doing, and you should be constantly looking for opportunities to put the new ideas presented into practice.

Experience (practice) is important to solidify your own understanding and skills. Learning from others is important to gain new ideas, insight and concepts that you might not have come across on your own (because there's loads of people out there getting experience that's different from yours). You get far more from those things together than you do either one on its own.

 

I assumed it was a given that the knowledge gained would be in turn applied, I guess my misunderstanding was that I thought Step 1 was the identification of a particular challenge related to whatever your current project was. If the whole point is to begin by picking a random challenge or starting point, then I don't agree, I believe it should always relate to your end goal or otherwise it will be quickly forgotten.

On a somewhat related point, at least in engineering, it is becoming popular in Australia for new graduates to encounter 2-year 'Graduate development programs' when they apply for their first jobs - which basically involves a 2-year contract on very low pay where you learn how to be an engineer. In my view this is a clear indication that they pretty much consider the average 4-5 year private university course to be worthless (which I agree with) and don't want to pay a full salary while they teach graduates what they should already know - and which they might not recover if the graduate switches jobs early. If only the courses were carried out in step with the industry with work experience reinforcing learning all the way, this probably wouldn't be necessary.

But anyway, i don't want to derail the thread, my point of view is simply that learning 'on the job' - where the job is your current game project - and only using programming books for reference when you need them, is the way to go.

 

https://en.wikipedia.org/wiki/Internship

 

A related question, then. How do you know when you need them?

On many occasions I've heard programmers describe some problem as being "just a part of the job" or "the nature of writing code" or somesuch, when there's plenty of documented research and/or knowledge about how to manage, mitigate or remove it. To those programmers it remains a problem because they aren't aware that it doesn't have to be that way. They're not going to jump to a reference book about how to apply the solution because they're not even aware that their problem is a thing.

 

The graduate development program is not an internship for undergraduate or postgraduate students, it's 2 years of low pay to gain entry into your field as a professional, after having forked out 50-100 thousand dollars and worked for 4-5 years already to gain your qualification.

If what you're saying is that you can get an internship as an undergraduate student during holidays to reinforce your learning, well then what are you paying your university for exactly? The classes are often mindless rote learning with very little practical value, and you could cut upwards of 50% off it and replace it with industry experience. And there is no structured reinforcement, it's just, study for exam, pass exam, move on... it really struck me one when I tried hard to remember what classes I'd even taken in the first year, let alone the content, and I had to look it up.

Anyway, hope the OP is ok with this derail, if not I'll stick to the point on hand.

 

There's no cure for that unfortunately, beginning learning by studying a reference manual is a bit like getting sick with something and going and taking one-of every pill at your local pharmacy, . The crucial point is that as a self-learner your learning is structured by you, who doesn't know what you don't know. It's going to be inefficient one way or the other, as @BoredMormon said there's no better way than learning in an industry job. But if you have to, IMO, the best way is to do a small-area sweep, so to speak, of material directly related to the problem you've got at hand.

 

So does anyone have a suggestion how I can work on structure?

 

That's precisely what an internship is.

A formal education is about providing a solid foundation that enables you to understand enough of the concepts that you can perform your job without killing someone as well as continue learning both on your own and at the job site.

 

I learned perl from a book.

I wrote and released a handful of games when I was young. They were alright for what they were. A few years later, I was working as a front end designer for enterprise educational software, and we had an opportunity to develop a suite of math based games for grade school level. Because I was into building games I got to be on that project. There were four of us and the lead was a guy named John Butler. He was a fairly well known shareware game developer at the time. He was my mentor for about 3 years. I owe a good chunk of my success to him. He was a brilliant game designer and software architect and was passionate about teaching us and learning new things. I wouldn't be as good as am had I not spent that time with him (and the others).

 

Pretty standard for engineering globally, at least with bigger companies. A lot of the time is spent inducting grads into specific systems, programs and standards in the company. These grad programs are pretty competitive to get into. And are often pretty highly paid for grad positions. (When thinking about engineering wages in Australia its worth realizing that the mining collapse has skewed things dramatically. Most years engineers are very well paid). Of course its possible to get into engineering without the grad program, but the grad program is often a fast track into leadership.

Where you make your mistake is in assuming that these programs are instead of degrees. That is generally not true. These programs are on top of degrees. They build on the knowledge earned in degrees. You can't into one of these programs without a degree. And you certainly will struggle to get anywhere in the industry without a degree.

50-100 thousand dollar degree? You are getting a degree in Australia right? I'd suggest shopping around, or perhaps jumping the ditch.

It is. A engineering degree requires 800 hours of industry placement. Its not exactly the same work as a fully fledged engineer, but its typically on actual job sites doing actual engineering.

Anyway that's probably enough about my industry.

 

A mentor would be nice.

Unfortunately there's not a lot of Game Design in Northwest Arkansas.

I do have a programmer friend that offered me a job that pays well and it would be in programming in C#, but it would mean not working with abused kids and I don't think I can step away from that.

 

Not quite. According to your wikipedia link an internship is typically a 2-4 month arrangement for undergraduate or postgraduate students during their studies. What I'm talking about is a program developed for graduated, qualified engineers who are trying to get their first job. These engineers, due to the lack of quality of the education at university, know virtually nothing, have to be taught everything, and have been told that it's typical to switch jobs every couple of years in their career. It's a perfect disaster for companies trying to hire graduates as well as graduates looking for first employment. Considering the circumstances, the Graduate development program is a reasonable way to mitigate that disaster, but it doesn't prevent it.

That's what it should be, but it's not, because there's no structured real-world reinforcement, simple as that.

@BoredMormon 2 years on low pay for every new job you get? Not typical in my experience. The universities have the monopoly on handing out degrees, that's why no one can cut them out of the equation. In my opinion, 4-5 years of training is more than enough to qualify for a professional salary, if it's not, then you're wasting time. I can only go on my own experience, but it was clear to me that there was very little I learned at Uni that I ever used in my work experience or my first job, and nothing in my job I could not learn there, much faster and more efficiently.

Anyway, that's enough from me, back to the topic.

 

There were a few. At least one of them should apply to you and your learning style.

And then we wandered off topic talking about different ways people learn and which one was better and is BoredMormon prettier then Billly4184. But this is the general discussion form. It actually lasted on topic for quite a while. Now its up to you to take one of the ideas and run with it.

 

Yeah, I know.

I was trying to be funny.

 

Yes

Yes

No

You have some facts right, but you have drawn an erroneous conclusion.

 

@BoredMormon, 4-5 years, tens of thousands of dollars in debt, and it's ok to know nothing? Anyway, agree to disagree

 

I agree with this, and believe it is sound advice. The industry and tech moves fast, and change so quickly at times, that most approaches have their challenges today. Self/internet taught leads to bad habits/knowledge due to the increasing amount of utter garbage on the net in terms of tutorials, the fact the most vocal peddlers of advice out there come from who usually have no experience to back their claims, and of course the "journalist" (who seem to outnumber

developers), constantly have to write endless ill conceived articles claiming insight into the state of things. Like all of their ilk, they need readers, and over-hyping some things and FUDing others, help do that. PROTIP: if you read an article/blog on any of the game news sites, follow the author's link. Unless they have finished successful games, skip it. nothing to be learned there. And lastly as was mentioned about "Game Develop Schools" are out of date from day one.

That said, I am self-taught, as are many of my peers. We are all roughly around the same age, so the fact that we are self taught, wasn't a choice. It was pretty much the only option. You are correct that is very inefficient. and the web wasn't around to make it easier, no schools and few places to get. Peach Pit press was my professor in many languages/skills. Mentors>Schools>online resources>books>tutorials;

 

Wow. for those that are unaware of your background, that sentence kinda has a disturbing vibe to it. Especially with a beat up teddy bear icon. Just saying...

 

Nothing is an exaggeration. Not enough to be valuable to the company is more accurate.

But yes. I'm quite happy to say that its okay my industry demands a degree and several more years of on the job training, before we trust grads with the live of their colleagues and the community.

Now I know how @zombiegorilla must feel each time I chime in about the business side of making games.

 

At the same time the web wasn't around to distract you.

 

Personally I've tried the college route and took one class. I was NOT impressed.

Everyone just wanted to get a piece of paper to get a job and no one had an actual interest in it. I even asked out loud if anyone else was interested in game design and got more than a couple scoffs.

Then the teacher clearly didn't know anything at all. She just droned off from the text book.

It just felt overly scholastic and under passionate.