Initiative: Red Dawn



May 27, 2016

Coding: know when to stop

Before we delve into some actual coding, there are a few snippets of experience and ideas I want to share that may help to overcome issues in your development. Programming is tough. Developing a game is even tougher. It is very common to get discouraged when bugs start to appear, or when you can’t achieve what you’re trying to do, etc. All I can say is, keep focused on your final game. Picture it published with people playing it. 1- Bugs There will always be bugs, it’s just the nature of the beast. You’ll simply will never get rid of all of them. You are going to hunt them down, fix them, and a new one will emerge at some point. Learn to live with them and fight them with as many tools as you can. There are just so many layers going on between your player and your game that something is bound to fail: there’s the hardware (with its own layers of hardware and firmware), the OS, the software you use (Unity in our example), external libraries (such as the Facebook SDK), your code, etc. 2- That cool feature I just can’t program As a developer, you’ll find yourself -sooner or later- at a feature you really, really want to implement, and you just can’t wrap it up. Unless is the key to the game, and I mean the real key as in “there’s no game without it”, learn to stop, simplify it, and move on. You can always return later on and improve it, but don’t delay the rest of your game for a simple feature. You can always hire someone to write for you, or do research while you keep working on the rest of your game. 3- The rubber band of programming Most likely, just like me, you are learning as you code and create your game. You learn a new method, a new pattern, a new way of doing things. That’s not only expected, but also a great thing! So chances are you are coding some script and suddenly you learn a new thing, look back at your previous code and find out you “should have done it differently!”. That’s also expected and great! So, usually, you code a few scripts, you learn something new or find out a better way of doing things, and you go back a bit, refactor some code, and then continue with the new way of doings things. Until that happens again, and you go back a bit, refactor, and continue. And so forth. But there’s a catch: you need to know when to stop. This rubber band motion of going back and forth refactoring code is normal, but the key is to, at some point, accept the way you’ve done things is not wrong, just different and you need to accept that. If not, you may fall on an -almost- endless loop of learning that will end in one of the following ways:
  • You get bored of the game you are doing and start lowering quality or even abandoning the game
  • The idea, concept or even the technology eventually passes and your game or idea becomes obsolete
  • You grow up, get married, have kids and suddenly no more time for daddy’s hobbies
  • You get abducted by aliens (hey, it can happen!)
You get the idea. It’s ok to go back and forth and refactor your idea, just don’t get caught too much in it, accept a few things, and move on. I don’t think you can find a single programmer (game programmer at least) who will not go back and refactor a few scripts of a game they’ve already built. 4- Optimizing for velocity of programming Another big aspect is programming velocity. Most likely, if you are reading this, you’re a one-man team or an indie developer. As such, you don’t have enough money, time, or team to do everything on your own every single time. So, obviously, you accept that fact and that’s why you develop on Unity: you just don’t have the time, the knowledge, the team, or at the end, the money to develop the engine by yourself. The same goes with some code snippets, which is why you purchase plugins and add-ons. But also, the same goes to your actual code as you develop. You should code in such a way that is the fastest way you can get things done. There’s very little chance you’ll need to do serious code optimization to get more FPS on your game. Unless you are doing something extremely wrong, these days mobile or desktop CPUs and GPUs can handle the work load for simple games. So, you should code in whatever way you can code faster (without rushing of course!). But if its easier for you to use a certain method of doing things, naming variables, using patterns, etc., then by all means, do so if it makes things easier and saves you time to complete your game. As long as you follow general guidelines for you or your team in a way you can look back at the code and understand it, then go ahead! You are limited in time and resources, so make the best of them. Optimize your code and improve it but, as always, know when to stop. 5- DRY This is the key to all programming: Don’t Repeat Yourself. And its a rule of thumb. If you have code that’s exactly the same in two places, you should create a method (function), put the code there, and call that function from both places. But, even with this you also need when to stop. You should definitely merge as much code as you can, and centralize as much functionality as you can (it really is going to pay off in the long run). But what if you have two methods that are “almost” the same? Well, you should merge them if the merged function ends up clear. If the merged function is a constant repetition of “if” sentences to check for conditions, then that’s your stop sign. Then say to yourself: “it is ok to have -some- code repeated”. Just keep core functionality grouped as much as possible, but clean. 6- Documentation! It’s paramount to document your code. You may think: “why should I document the code? I know what it does!”. Let me tell you: you do know, you may not know it in a few weeks when you have to come back to that specific script and change that specific feature. Also, you may know the code, but when someone else needs to change it, they won’t and will be asking you to explain it. It’s very easy to document the code, and once you get used to it, you simply can’t leave without it! Make a habit!  
Ok, sorry for the interruption, now lets actually start with Spell Run. Don’t forget to follow us on twitter for news regarding articles and game development [twitter-follow screen_name=’indelvestudios’]  

One Comment

  1. Spell Run – Single scene or multiple scenes? – Indelve
    June 30, 2016 @ 1:05 pm

    […] Let’s talk a bit about the code evolution. […]

    Reply

Leave a Reply