CODE, RE-CODE AND START AGAIN

Preamble

A few years ago I read an article called "La cathedrale et le Bazar" and which, to put it simply, compared the ultra-structured programming of large companies which design software from a plan before coding any line and the more anarchic programming of Open Source software, or the idea would be rather to move relatively quickly towards something functional to improve it later.

The article concluded, 20 years ago, that the two models were equal in terms of development cost and application stability.

What has changed in the last 20 years is access to code and the expansion of the Internet.
Not only are thousands of "text" or video tutorials now available, but it is now possible for a developer to offload display on a rendering engine, physics on a physics engine, or management. music.
Suddenly, developing becomes easier.
Add to that the power of machines that allow ultra simple and (ultra slow 🙄) scripting languages to run a video game and systems that allow you to see almost instantly the result of what you are programming and you understand that we have definitively switched to the Bazaar collectively!

We code quickly, often not very well, and that's not a big deal because we get the same number of successful projects in the end. The only difference is that you see a lot of "awesome" project starts that don't go beyond a vague start.
With a more structured design technique, all of these projects would have just been scrapped before they even got to the programming phase.

Manage the Bazaar

I was once told, when I was in video games: " It is easier to start the most exceptional of games than to finish the simplest! "
I have always kept this sentence in mind because it is so true!

You are therefore embarking on a project (the best in the world, of course), full of confidence and certainty about your abilities, and it is so much the better because if you do not believe in it yourself then you will not go. nowhere !

At first, everything will go quickly.

  • For Hillgreen, it didn't take more than a week for me to load a level created in mapeditor and display it on the screen.
  • After 2 weeks, Hillgreen could run and collisions with the ground were handled, more or less well.
  • At the end of 3 weeks, it jumped (even if I did not have the adequate animations at the time) and I had added a significant number of characteristics planned in the final rendering of the levels: the paralaxis for example.

So it's cool, it works, it's fun, it's graphic. You can show what it does to your friends and even if there are some small bugs to correct, small subtleties to make to make the ergonomics more fun, feel that nothing is going to stop you ... đŸ’Ș

Except that in the months that followed, even if I continued to advance, I had to recode several parts of the game.
It wasn't a surprise at all, I knew that. I wrote thousands of lines of code without any (a little bit) thinking about the "durability" of the code. My only goal was to go quickly to find out as soon as possible if I was going to encounter an insurmountable problem!

This is where the Bazaar is! : You are testing a concept of code, which you will improve, sometimes by going quite far in the richness of the functionalities, and if all goes well and that does what it does must do, then you recode the whole thing while trying to structure your code a little better.

You are going from the prototype to a beta version!

Sometimes you will even have to recode the same thing 2 or 3 times because you are going to add functions, you will realize that certain methods that you have associated with such type of objects would be better in such type of objects.
Or you will have to re-code the same thing again just because what you have done can be done better, more clearly!

The problem is not to redo.
The problem is not knowing it's going to happen and not knowing when is the right time to rethink part of your program.

Why redo what works?

There is only one reason to redo what we have already done and that is working.
It is to make the code clearer, more readable and easier to maintain.

When you code at the beginning, everything is fine, it's hot in your head. You know exactly what you have done, where this or that piece of code is.

  • But is it the same if you go on vacation for a month and when you return you get back to the screen?
  • And what about a possible other developer who would like to poke his nose into your code (to help you for example)?

Signs that it is time to recode

So, at what momnet should you seriously take a break, and agree to waste 1 or 2 days to recode this or that part of your code!
In my opinion there are several signs that this is the right time.

Understanding what you've coded becomes complicated

The first reason is that you start to not quite understand what you did!
Obviously overall you know it, but if at some point someone says to you (or if you say to yourself):
What is this line for?
And your answer is: Wait let me watch! Hmm ... I don't really know!

Sometimes you have initialized the same variable several times and obviously, you are now wondering why you did that!
Sometimes you've already gone over the code, and a comment like "I don't know what this is for ..." hangs around the corner.

Well, there it is, it's time!
Pushing back will only make things worse.

You have magic constants

Another very clear sign that things are starting to be a mess in your code is when you have used a value somewhere without really knowing why!
For example, you calculated the moment of the collision between 2 objects.
This does not work every time, on the other hand if you move one pixel upwards one of the two objects then it works perfectly!
This is the perfect example of a magic constant.
You don't know why it works, but you know it works.

Say otherwise, you do not have mastery of your code.
You can let your program run like this for a while, but one day or another, it's very likely that this constant will cause you more problems than it solves.

And then of course, if you have several like that. So there it is already over!
If you don't know, or can't remember how a function you wrote works, then rewrite it!
Writing comments can also be a good idea!

Too many if ... elseif ... end

Another sign that you are nearing the optimal time to rewrite part of your program is when you have stacked the if ... elseif ... ends on top of each other and the file you are on work starts to be disproportionately long!

You know very well why your code has become so long!
You have to stack the cases. At the beginning you thought that there would only be a few and finally there are many more than expected!

In concrete cases, I will give you a good example of this type of Luanesque outgrowth.

your badly segmented code

Your code isn't just one huge file (well I hope).
You have several files for your libs and / or your object declarations (or whatever!).

And sometimes, you have developed a method or a function in the "wrong" file, either for simplicity, or because it seems logical to you or rather because there is no reason to put it here instead of there!

I give you an example.
Does the function that calculates the intersection between a segment and a polygon have to be:

  • in the physics engine library, since it is he who will need the result?
  • in the library which decodes and manages the levels (and which owns the collision polygons)?
  • in a separate math library, since I have one!

In this specific case, the answer is not easy. I don't even know if there is an answer, but in other cases it is simpler. We know that some functions are not in the right place and taking the time to move it around and generally adapt the way you access them can be a good idea!

Sometimes we even have several functions that do more or less the same thing.
When I decided to deport all the calls to trace or debug functions in a separate object, I found (it was not a surprise) that several of my libs had their own trace function. polygons used only for debugging purposes.

Concrete cases

Physics engine

Animation manager

Debug object


Commentaires


Hillgreen Dream Team

Etienne: DĂ©veloppeur
Manu: Graphiste et développeur
Luis: 3D Graphes et animations
Reynald: Musiques et sons