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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
