It’s been three days since I released TowerUp, since them I listened to feedback and I considered everything that people have said to me to make my future games better and stronger. So it’s time to talk about a full retrospective of TowerUp, what I did wrong and how to not do it in the future.
WHAT DID GO WRONG ?
A. Hard coding
For me, there are two types of coding : dynamic coding, which is a more flexible type of code, made with the future in mind and how easily things can be implemented in a code, and hard coding, which is more making it work before everything else, to the detriment of future proofing the game.
What I did for most of the development of TowerUp is hard coding, I was so eager to make things work that I didn’t though about the future at any point in the game, the game I had in mind changed gradually during development, but sadly my code didn’t. Changing the game was gradually more painful and time consuming, and now that the game is finished I can’t look at a single line of code without thinking “Damn, what the hell was I doing here ?”
Which lead me to the second point.
B. No comments
“WHAT DOES THIS THING DO ?!“
Me everytime I saw old code
Coding is vast. Very vast. And you tend to forget things you did in the past faster, it would not be a problem if you don’t had to go back to old code everytime to add, complete or fix things. Not commenting is the way to go if you want to spend three hours a day cursing yourself for not commenting things in the first place. And not only commenting can help you remember what script is used where, what function is doing what, it also can help you find things faster since you don’t have to translate in your head what everything does.
And sometimes you are so lost without comments that you need to go back and check the documentation to understand what you were doing, which is even more time consuming
In the end commenting is crucial.
C. Not using prefabs
This one is more for Unity alone, because they have a thing called prefabs, basically it’s an object with a set of propriety you can define (Like if it have physics, if it have a collider, if it have a certain script ect…), it makes it easier to change things, go back, change the model, material, scripts…
And you can call that object later with one line of code instead of hard coding everything in the code. Prefabs are awesome ! And I didn’t used any single one of them. The worst thing is I knew it existed, I just didn’t thought that they were that useful. Oh stupid me.
D. Not preparing myself for the future
Basically if you take everything listed above, you can come down to this conclusion : I didn’t prepared enough for the future of the game, I thought “Alright, I’m going to release it, fix two or three bugs and call it a day”, but now that the game is released I realized how I was wrong and how you NEED to prepare your game for the future from day one.
D. Not doing enough researches
Researches is essential, like for example the outline in TowerUp is made with two images, one of top, the white part, and an another one on the bottom, slightly larger than the one on top. The result is a very thin outline, at the time I thought it was a smart to do it.
Well today I researched a better way to do it, and behold, there is actually a script included in Unity for that ! Literately two clicks would have save me a lot of time doing the UI and would have grant me a better control.
And that’s a problem I needed to tackle, doing researches, reading the documentation can save a lot of hassle.
E. What can be improved ?
A lot, which I try to pursue right now in my new project. I learned from my mistakes and I am not coding without thinking before. Which now lead to a lot of optimization from the day one, a lot of dynamic code, and believe it or not, a really faster development because of slower coding, which is pretty paradoxal, but taking your time is actually a better way to make things faster. Think before acting is also true for coding.