Most Efficient Way of Learning Dev > Re:Learning GameDev
I'am a 3D Artist trying to learn game development. I will be starting with Unity and C#.
My question is : What advice you would give to yourself if you were re:learning gamedev.
What is a good practice?(and bad?)
What 'terms' that were most usefull to learn?
What are the best resources out there?
Replies
Hey Jumbee,
Just grab one end and start :)
Everybody has its own speed and way to do things. Real life will quickly teach you about the do's and dont's then. A good starting point is the Unity learning ressources. A good place to ask when you are stuck is the Unity forum.
Question is what your exact goal is, and if you really want to write code*. Developing games is so unbelievable time consuming. You can easily spend years at one project. I have. More than once. And you might want to specialize yourself at one point. So when you don't work in a team** you better use everything that speeds things up. In Unity there is the Playmaker addon. Unreal has Blueprints. And the asset store of both is full of scripts and assets for every need.
*One word about programming here. Some people might want to convince you to learn C# first. Don't. You will waste your time with learning lots of bad habits (Unity is a game development environment, not a C# IDE. And does quite a few things different. I have seen C# programmes writing their own C# scripts because they didn't realize that Unity has the same functionality already built in) and a ton of knowledge that you will never ever need. I would suggest to learn C# at your way, when you need it. Important is the Unity API, not the C# API. You can always deepen and extend your knowledge at a later point if you really want to.
**I wouldn't recommend to join a team at this point. Hobby teams are highly problematic in general. You most probably just learn how to not do it. Everybody wants to be the king and to give the direction. And chances are very high that the other people in the team are as inexperienced as you. You could though join a promising existing project that made good progress already and get a job as a graphics artist there. Hobby projects are always short of graphics artists. But then you don't learn the development part. And as told, hobby teams are problematic in general. Chances are big that a hobby project will never be finished. And professionals or more experienced hobbyists usually simply doesn't have the time to teach you the basics. This step is something that you have to do by yourself.
That said, start as small as possible. DON'T start with something like an RPG. I talk from experience here. My first project was an RPG. And this was already my first fail ( how unexpected. Didn't see it coming :D ) . My second game was something in the scope of pong then. And from there i progressed fine :)
Start very small, and build the games on top of each other. A pong or breakout teaches you basics of movement. A Pac Man is the mother of AI. A jump n run teaches you to desing levels. And so on. From small to big. These small projects teaches you also what is possible for a single person and what not. A simple 2D jump n run can already eat months of work.
And work with prototypes. They will show you what is possible and what not. Prototypes are also a good way to develop your games in a modular way. You need movement? Then make a prototype to toy around how this movement has to be. You need pathfinding? Then make a prototype to toy around how this pathfinding has to look. At this point it should be clear why i recommend to start with the smallest possible games. They are already prototypes for your bigger projects ;)
You will quickly notice when a project is too big or above your skills. Then go one step back, everything else is wasted time. A prototype could help you out here though in case you don't want to trash the project completely. Did i mention prototyping before? I'm a big fan of evolutionary prototyping :)
And always FINISH what you start. Even the fails. Finishing a project is the hardest part. And even with finishing a fail you will learn lots of new things. It takes several tries to understand UI UX design for example. And you can analyze why it failed.
These smallest possible projects is the proof of your skills and your progress. The portfolio with which you can convince other peoples about your skills. So better don't take the shortcut here. You might need them in the one or another way :)
Oh, and keep your hands away from games academies. The business model of them is to make money from the inexperienced game developers. The only valuable thing may be the real life contacts and connections. But you can also make such contacts online nowadays. And there is not this much that a games academy could teach you that you couldn't learn without it. And proper researching is one of the most needed skills.
Hope this helps
Kind regards
Reiner
here's a few things that work for me:
don't try to learn anything academically. just set a goal and only learn what you need to solve the problems right in front of you.
don't try to learn anything "the hard way". Only learn the hard way as a last resort. Hard way = trial and error. First thing I always do is check and see what solutions exist. Will it work for me? If so, use it. If not, take a few more looks and if I can find any hints, then trial/error. I still end up figuring out a lot via trial/error, but if I didn't try to leverage the collective power of internet, I'd be on step two right now instead of step 20.
That said, don't over esteem anybody else's solution or ideas. Whatever you are doing, it has to be done in a way that you can understand and work with in the future.
Don't get pedantic about doing things the "right" way. Make things work and only solve problems that you can actually see and define.
learn troubleshooting techniques ASAP
build the entire game loop from main menu to game over ASAP and don't try to fill in any details until you've got that basic framework in place
test out every new addition to the project in an empty project first - this way you dont get overly confused with project complexities when you are just trying to get basic functionality down for something new. So, make a two step process: 1. figure out new system in isolation, 2. figure out how to integrate it into main project
don't get too deep into details of any one discipline. I.e. dont try to become a master programmer, or a grate artiste. Keep the "good enough" stamp at the ready otherwise you'll take too long and get fatigued.
As far as "terms" and "practices" go, I'd recommend try to get SOLID principles and game dev programming design patterns in your head early. If you don't understand the principle I wouldn't waste too much time trying to figure it out - but as long as seed is planted, once you hit the problems a particular design pattern or SOLID principle aims to solve, then it will become clear.
A lot of the basic ideas from SOLID isn't only applicable to programming - the way you develop your art pipeline can benefit a lot from certain ideas like single responsibility for instance. It's really just principles for working in a way that you get maximum reuse and flexibility from your effort, so try to see big picture and not get focused on details.
Sounds great. The world needs more Game and Tools Developers, Technical Artists and other techies with an art background like us.
Some pointers:
-Doing many small, or even tiny, projects trumps large projects by FAR. In fact, large projects are one of the main motivational killers for a lot of people including myself. So if you try and keep a minimal scope and instead try and learn something new with every project, you will learn a hell of a lot more things in a shorter amount of time.
-Don't try and be an expert at anything. Early in a career - any game dev career really - it's often better to know a little about many things than knowing a lot about only certain things.
-Things to learn (and each of these can be an individual project) include things like player controls, procedural level generation, procedural audio/music, network programming, graphics/rendering, VFX, tools/pipelines/workflows, hooking up Unity with Houdini, configs, databases, creating a map/minimap system, User-Interfaces (menus and HUDs).
-Create a github user - upload your mini projects there. Learn how to use git properly (creating branches, pushing/pulling, branching, creating and handling merge requests) and once you get comfy with that: rebasing.
-Hook up one of your github projects with CI/CD (continous integration/delivery).
-Look up some tutorials on how to debug C# and Unity projects. This is an incredibly important skill to have.
It's easy to feel overwhelmed by just how much there is to learn so remember to keep in mind: you DON'T have to be an expert at anything! Do small projects/tasks for like 2 weeks, write a blog post about it or something, then move on to the next project. Always have a goal and a scope, like something along the lines of these examples:
1) "I want to make a procedural 2D dungeon crawler -level - but I won't focus much on player controls".
2) "I want to create some player controls with a jump that feels as good as Mario - and I want some nice audio with that. But I won't focus on making much of a level - and no menus or pretty art".
3) "I want to create a character customization system based off data read from a config file and I want to have some nice UI with that. But I won't make any levels or game logic".
Worst thing you can do is to get stuck with a pipe-dream of a project where you are banging your head against a brick wall for weeks, never really learning anything but just debugging.
following youtube videos is ok for programming too
https://www.youtube.com/c/javidx9 has many tutorials on basic concepts for game design (he is using c++), from understanding how to use seeds in random generation to writing your own 3d engine all chopped up in digestable bits