ELEVEN TIPS FOR BEGINNER GAME DEVELOPERS

Credits: Gamefromscratch

Credits: Gamefromscratch

 

A conversation just happened on /r/gamedev with the confusing title “What don’t new game developers know that they don’t know?”.  Essentially it was a question asking what important advice new developers don’t know (for lack of experience) but should.  My answer seems to have been extremely well received and the question is quite good, so I figure I would replicate the answer here for those of you that don’t frequent reddit.

So essentially what follows is my advice I would give my beginner self if I owned a time machine.

  • most people fail and fail hard. Perseverance is probably the most underrated but required skill of a successful game developer.
  • learning tasks in parallel is rarely productive. While I know you want to learn everything now… don’t. Learn one task/language/skill to a base level of competency before moving on to the next. It’s hard because everything is shiny and new, but it’s critical. Trying to learn too many things at once results in learning nothing at all.
  • when you are 90% done, you’re actually 50% done. Maybe… if you are lucky.
  • there is no ego in programming, or at least there shouldn’t be. A plumber or carpenter come into a job with a toolbox full of tools, and don’t limit themselves to a number three hex drive because “it’s cool”. They use the best tool for the job and sometimes that tool is a horrific hack and that’s ok too. Programmers… have often failed to learn this lesson. People invest themselves in “their language” and this frankly, is stupid. Working in C++, Java, Haskell, F#, Go, Rust or whatever other language doesn’t make you cool, just as working in GameMaker, Lua, JavaScript doesn’t make you uncool. Only exception, PHP. %#@k PHP. Moral of the story… use the right language or tool for the job. Sometimes that means performance, sometimes that means maintainability, sometimes that means quickness, sometimes that means designer friendly and sometimes it means using the tool the rest of your team is using. Be pragmatic, always be pragmatic. I personally would never hire a programmer who claimed there was a “best” language. If you have been programming for several years and don’t have several languages in your arsenal, you are probably doing it wrong.
  • if it feels wrong, it probably is. If you encounter such a code smell, even if you can’t fix it, comment on it and move on.
  • even if you work alone, comments are good. But comments for the sake of comments is worse than no comments at all. Take the time to write legible code, take the time to smartly comment what you’ve written. Six months or six years down the road, you will thank yourself.
  • version control or at least automatic backups. Do it. Now.
  • premature ejac…. er, optimization is the root of all evil. Yes, you need to be mindful of performance on a macro level, but don’t sweat the micro level until you have to. If you are just starting out, but your primary concern is performance, you are doing it wrong.
  • learn how to use a debugger. Early. It will be an invaluable skill and will help you understand how your code works better than any other single task you can perform. Also learn how to use a profiler and code linter, these will give you great insights into your code as well, but you can do this later. If you have learned the basics of a programming language but haven’t groked debugging yet, stop everything and dedicate yourself to that task. For a somewhat generic debugging tutorial start here. Seriously, learn it, now.
  • if you have access to a peer, TAKE IT. Peer reviewed coding, while at first annoying, is invaluable. Even if there is a large skill mismatch between the two people. Even just having someone go through your code and ask “why did you do this?” forces you to explain it… and often you realize… hey… why did I do that? Many programmers are solitary creatures, so the idea of peer code reviews or paired programming is anathema. Or people can be very shy about showing their code… it’s worth it to get over it. Of course not everyone has access to another programmer to use as a sounding board and not being in person makes it a lot harder and a lot less useful.
  • books are great, as is a gigantic collection of links to great articles on the web. That said unfortunately, you can’t just buy a book and learn via osmosis… you actually have to read the thing. More to the point, if you are following a tutorial or video, DO THE WORK. You will learn it a great deal more, develop muscle memory of sorts, if you actually do it. This means typing out the code and getting it to run, instead of just loading the project and pressing play. Trust me, you learn a lot more actually recreating the project.