Getting more advanced in programming

Hello,

I'm trying my best at getting more advanced at programming.
I know the basics like, arrays, lists, if statements, state machines etc.
But that's it.
Im going to look up more about enums, because i think they're really important.

Im making a small 3D RPG with a friend of mine, what would you recommand to script to learn more about programming,
Ive worked with fog, a pause menu etc.
Enemy AI ( nav )

But i'm aiming to create an inventory, but it doesnt matter how many tutorials i watch, it's still far out of my league.

I hope to hear from you guys how youve gone from the basics, to more advanced programming!

 

Read up on design patterns. Go through other peoples' code that does what you want, and figure out what's going on step by step, until you can build it from scratch without having to copy and paste.

 

enums are simply a way to give discrete values such as 1, 2, 3 names such as One, Two, Three. You can create discrete values and then refer to them by name to clarify what those different values do. However, enums are often a sign of procedural code. There are almost always more expressive ways of describing behavior than with enums. For that reason, I would suggest you gain an elementary understanding of them and then try to avoid them. If you see them in other's code, make it a mind game to come up with ways to eliminate them.

I think design patterns are very important but they are an abstract concept that can be difficult to understand without more practical experience. If you focus too much on these you may become discouraged.

Keep in mind the Unity scripting system is a complex framework built atop another complex framework: .net. This itself is a complex framework built upon the C# language. You can improve your coding skills a lot just by focusing in on one of these lower technologies. Much of Unity also makes heavy use of geometry and algebra given that it is designed for dealing with graphics. You can improve your skills in game making just by improving you knowledge of these fundamental sciences. Again, these can seem like dry topics and it's easy to get discouraged if you spend too much time here.

My suggestion is to find a book or website which can teach you about these foundational concepts so that you are able to improve your skills even when you're not able to work inside Unity -- read a book on C# or applications of geometry in game making while you take the bus. When you do have time to spend with Unity, keep experimenting and creating simple things -- this will keep your interest.

 

eisenpony is correct.

I think it is also important to add that learning things abstractly without a concrete "real world" example is actually very difficult and dare I say - boring. Take for example design patterns, you will learn them much more quickly if you have real life examples of how they apply in games as apposed to the incredibly simple examples that are contained in the books that describe them.

Don`t get too bogged down in wanting to learn for learning`s sake. Make sure you actually have a need for the new technique/pattern/formula you are learning.

 

This is good advice. My wife has this problem. She tries to follow every little associated rabbit hole of information, trying to grasp the whole of a subject, and as a result she wears herself out on a topic before she even gets a project started.

I'm not personally a big fan of patterns -- but I'm a crusty old man who was programming when CPU speeds were measured in single-digit MHz. Patterns are useful as concepts, but I know a lot of newer programmers who get so focused on them they have trouble thinking outside the box. It's as if they're almost scared of doing anything that doesn't fit a pattern defined by somebody else. I once used a fractal solver algorithm to realize a 100-fold increase in a critical mortgage processing routine used by such large entities as PNC Bank and Chemical Bank. You won't find that kind of thing in a book on design patterns.

 

Like any language, you get better through practice. Find simple projects to do and do them. Learn what works well, what doesn't. For your inventory example, break the problem down into smaller pieces. What sort of things does the inventory need? Lists of things, scrolling, displaying objects on the screen that are composed of other objects (UI), and so on. Then look at each of those things and break them down if possible. Then do what you need to do to learn how to solve each of those problems.

I'm with @MV10 - I learned programming on a 6502 CPU running at 1.79MHz, well before "patterns" were a thing. You can be a successful programmer without them, and you will eventually learn many of them naturally. But if you do want to read about them, Game Programming Patterns by Robert Nystrom is one of the best I've found on the subject. The web version is the full book and it's free.

 

Design patterns are complete utter nonsense. Spoon-feed material for programmers incapable of independent thought. They'll make you write super over-engineered garbage. If you really want to go advanced check out Handmade Hero. But by all means try everything, it's the only way to learn. You'll never know how S***ty design patterns are until you try them in your game.

 

I'd rather deal with over-engineered code than under-engineered code.

 

You're doing complete projects with no design patterns whatsoever?

 

I'm not a huge fan of a formalized way of structuring code either, but to call design patterns "utter nonsense" is, um, utter nonsense. If nothing else they provide a good way to organize things in your head and they provide a decent direction on how to organize your code when there are complex interactions.

It can be argued that they're overkill for many games, and I would probably side with you on that.

 

Design patterns are mainly an attempt to standardize vocabulary for what anybody but the greenest hacker was already doing anyway. It's an extremely useful shorthand. I can tell you I'm using a singleton that serves as a factory for objects that use the strategy pattern for their steering behavior, and if you're a professional programmer (or an experienced amateur), you will have a pretty good picture in your head of how it works.

It doesn't mean you have to start with the Design Patterns book and use it to build your app, or that you can't make up new stuff or combinations of stuff that aren't in there. It just means that you're aware of what you're doing, and when you're making a factory, you call it that instead of making up some other term for the same thing.

(They also provide helpful ideas for how new programmers can get themselves out of thorny tangles, but yeah, if you've been doing this a long time, then you probably don't need such help most of the time.)

So design patterns are well worth learning about, I think. But for leveling up your mad skillz, I would even more highly recommend learning about refactoring. The basic idea of refactoring is to not over-engineer your code; instead to always make it as simple as possible, secure in the knowledge that you can always refactor it later as needed.

(But these are really intertwined, since there are some common design patterns — or coding habits, if you prefer — that make refactoring much easier, and it's worth starting with those from the get-go.)

 

Everything JoeStrout says rings true for me.. I was halfway though this response so I will post it anyways.

I think design patterns used to be widely recognized as an "advanced" topic. Unfortunately, the term become a catchall for anyone hoping to sound like they knew how to program. The design pattern names can be used as jargon without any actual understanding to hide incompetence from managers. This gross overuse has led a lot of prominent technology leaders to resent design patterns and what they represent. Let's try not to "throw the baby out with the bath water" though.

By the time I had gained enough experience to really wrap my head around the original GOF design patterns book I discovered, to my surprise and dismay, that I was already using 90% of them. There is nothing particularly magical or revolutionary about this book or this way of thinking. The primary contribution wasn't a new way of making software; it was nomenclature.

I think there are two very important aspects of nomenclature in general, and at least in how it applies to the way I use software design patterns.

1. This is the most commonly touted benefit: it provides a way for programmers to communicate ideas very quickly. I can tell someone I'm going to apply the decorator pattern and they instantly understand what that means.
2. Less commonly spoken about, but I believe even more important: it provides a way for me to categorize techniques and draw relationships between similar and related patterns. When I think of the decorator pattern, I also instantly think of the composite, adapter and strategy patterns; how they are related and how they can be used to achieve similar results. Knowing the nomenclature gives me a tool to discover alternative solutions very quickly and choose the best fit for the scenario.

Anyways.. if nothing else, design patterns make for hilarious conversation starters..