A decade ago, while I was finishing my master’s degree, I also started developing games with a few friends. Nowadays, I can’t overestimate the benefits those years of late-night-coding brought me, and here are a few lessons I learned in the meantime:
Data is important to the user
In online games, players are your customers, and they pay the high price of their free time to use your product. As most of us know, free time is a scarce resource, and your players won’t stay for long if you mess with their time, such as because of a bug, they lose all their possessions (technical issue), or if their character is killed too often (game logic issue), …
Having no backup of your database is the surest way to lose all your players at the first server crash.
Lesson: backup systems should be designed at the same time as your product, so you never lose a customer because you screwed up 10 years of accounting and the backups are unreadable.
Data quality is important to the coder
If you want to know where you are going, what happens in your game, and feel the effects of the changes you make to the world, you need some feedback systems. And there you start to pull your hair when you try to automate checks or data aggregation with non normalized data. For instance, if you want to make statistics over genders of in-game characters, and let’s say gender is a free-text field, then you’re in trouble: most people won’t fill the box, some will fill garbage, and some will try to fill it, but are not able to spell properly (yes, it happens). Therefore, you have useless statistics, stating that 30% people play a girl, 60% a boy, 1% a ‘dude’, and 9% of players actually play a droid.
Lesson: the earlier you freeze possible entries for your data, the less corruption you will have in the future. You never know what data could be useful one day.
“Hell is other people”
Amongst all the different behaviors you can meet, the script kiddie is the most difficult you can have to deal with. This guy will try to input all kind of data into your forms, hoping it will crash and get him access to something interesting. He will hammer your server with requests, because he read somewhere he could become root somehow by doing it.
Needless to say, he will more often crash your game than root it, and also make a lot of people frustrated because they just try to play and the game is down again. He will also create a myriad of fake game accounts, and automate them so he becomes a one man army.
Lesson: you should build your security model first, and then add features on top of it it, not the other way around, or there will always be a hole in which a malicious user will try to sneak in.
Copy-Paste is your best friend as long as you’re not sleep deprived
“I’m in a rush, I’ll just copy this old code and change it so I’m done earlier”. Except you don’t change it. Or worse, you don’t change it enough, and suddenly have all those crazy bugs coming from everywhere. You check and double-check the changes you just made, but can’t find where the issue is. Usually, it’s because you just replaced 3 parameters, but forgot the 4th, and your brain skips it every time you read it.
Lesson: instead of copy-paste, think about refactoring your code, write generalist functions and don’t duplicate code anymore !
Version control or die
There was a time, I did not know about version control at all, and trusted my luck to revert changes made over 3-5 files. It can sometimes work, but sooner or later, you’ll forget one of the changes, and then you’re stuck in a looong bug hunt. Repeat again, and then your entire code base start working against you, showing incorrect data to your players, or granting them with unwanted powers. This actually happened to me, and I decided to restart the whole project, from scratch, but with version control from day one.
Lesson: programming without version control is like walking on a tightrope: one day or another, you’ll fall, and this day, you’ll regret not to have a safety net.