Bad Game Dev Habits & how to beat them
I was talking with some friends the other day about bad game dev habits when it comes to making games. Since I seem to have more than my fair share of them, I decided to write a blog about them and how I am working to prevent them.
For those of you who don’t know, I have been coding for at least 35 years. I learned my craft back in the days of 8 bit computers and BASIC. I am also entirely self-taught, so I have no doubt picked up a few bad habits along the way.
Let me tell you about some of the worst habits I have with regards to game development. As well as what steps I am taking to avoid repeating them in the future.
Not commenting clearly
This is a big one for me, as I am a champion for clear and concise commenting in projects. I’ve even written about it previously >here< on the blog.
Comments which make sense six months down the line can save hours of reading through the code when you return to the project. Especially if you have been working on other, completely different things in the meantime.
I try and leave single line comments which describe what a variable is or does, above the line where the variable is defined.
// Sets the players initial velocity
player.yVelocity#=0.0
I also leave blocks of code at the top of a function definition. These contain the usage parameters of the function, as well as a couple of lines of code with a usage example or any information which may be helpful.
//********************************************************************************
// null = UpdateZones( speed# as float)
//********************************************************************************
// This function updates the positions of the zone sprites and maintains the
// distance variable
//********************************************************************************
Lastly, I also leave the occasional comment on blocks of code to explain what it does where necessary. Some code is so simple that it doesn’t need a comment. Sometimes a single comment will suffice for four or five lines of code.
// Creates the sprite and sets the properties
bgLayers[layerID].spriteID[0]=CreateSprite(imgID)
SetSpritePosition(bgLayers[layerID].spriteID[0] , 0 , 0)
SetSpriteSize(bgLayers[layerID].spriteID[0] , width# , height#)
Even with Flappy-vaders, I recently found myself trying to find out what a variable did because I had not commented it, or indeed given it a sensible name. This leads us nicely onto the next section…
Poorly named variables
When I first learned to code on the ZX Spectrum, all some variables* had to have single character names.
Nowadays there are few limitations on variable naming outside of coding conventions. The trick with variable naming is to use as few words as possible to accurately describe what the variable is or what it does.
So when I was working on Flappy-vaders the other day, and found a variable called missionTotals which itself is quite an ambiguous name, I was understandably miffed. But to add insult to injury, I hadn’t left a comment explaining what the variable did either.
I eventually found comments in another function which explained what the variable was intended for, but again, that was time wasted looking through the code which could have been better used for writing it.
* I had mis-remembered this, It was only some variables, like strings or for/next loops which required a single character name. For regular variables, you were much freer and could even use spaces (although the compiler ignored these)
Overwriting graphical projects with single layer images
It’s not just the programing side of things where bad habits can cause hours of extra work down the line. Graphical assets are just as susceptible.
One of the most frustrating things I have found myself doing inside Paint .net (my favourite free paint tool) is removing the layers of a project file so I can copy/paste the image into another image, and then accidentally overwriting the original project file with the single layer one.
This could easily be avoided by copying the existing project file into the new project folder, leaving the original existing project file untouched.
Not saving the ttf file or even writing the font name down
Sometimes you need a specific font style to base a logo around or the like. You know what it’s like. Hunting around font sites looking for the perfect font.
It doesn’t usually take too long to find a few suitable candidates, and before you know it you have the logo created, and saved and forgotten about.
Until the next year, when you need to reproduce the logo in a higher resolution for some promotional material. But you’re on a different PC now, this new one doesn’t seem to have the font you used installed.
Thanks to the time which has passed, and the fact that the project you worked on needed a dozen fonts, you have absolutely no idea what the font you used for the logo was.
I have lost count of the number of times I have done this.
These days when I am doing this, I not only write down the font name and URL, but also the sizes and whether or not I used Bold or Italics. I also ensure the font .ttf file is stored in the project folder with its license file.
Leaving (often rude) debug stuff in production
As I said at the beginning of this post, I learned to code in the 80s on a ZX Spectrum, using BASIC. There was no fancy IDE with auto code complete and intellisense. And there definitely wasn’t any debuggers or tools like code stepping or break points.
I learned early on that if I needed visual confirmation of a section of code was being executed, I could simply drop a print statement into the code to display on screen that the code had been executed ok.
This is how I prefer to debug now. It comes as second nature to me.
Now somewhere along the journey through the years, I started using random words to make it easier to track down debug statements. I could simply use the search function to look for the specific word I had typed in the print statement. The more unique and less likely to appear in other comments, the better.
Because I have the mind of a 14 year old boy at times (we never truly grow up), a lot of these unique debug phrases were erm, rude. Often they were several words strung together, any one of which would have your granny clutching at her pearls.
Now, sometimes, these debug lines hide in the depths of the code, and only show themselves on very very rare occasions.
So occasionally that they have gone unnoticed when we are cleaning up a project ready for release to production.
On at least one occasion, they have made it onto the store!
These days I use a simple search of the entire project for every Print or Debug.Log command in the entire project and make sure that they are commented out.
Conclusion
That’s I think all I can think of for this post. I’ll leave you with some general advice which will hopefully save you from wasting hours of your time in the future.
- Make sure you save often, and back up your project. Use a source repository like GIT, especially if you are working as a team.
- Ensure you have a copy of every asset used in the creation of all the assets you make. Put them all in a folder, and never use the original file to work with, always copy it and work with the copy.
- Keep a written log of what you have done/changed and what you are planning to do next. I find OneNote is ideal for this.
I hope this post is of some help to you all. Feel free to get in touch with me to let me know about your bad game dev habits.
