Sign up to be kept up-to-date with news and offers, 100% spam free!!

Coding coding coding

I made big changes in the code. I replaced all the code using the old 2D system with the new system ex2D.
I reworked the multiresolution system that makes the App universal.
I replacde Itween with Hotween to reduce memory allocation.

5 full  days of works but almost no new feature.
I hope it will increase my productivity and allow me to add new things faster.

Next step:
– Finish the achievement GUI.
– Make the intro story cinematic.
– Make the easy/normal/hard mode

 

Redo or rework

When programmers want to redo things from scratch, that’s 90% time a wrong decision!

In which cases programmers want to redo things:

Redo to add some features:
What happen: They start redoing everything because they thing that’s the only solution to add a particular feature. Deadline coming closer they don’t have time to finish -> In that case, they will probably have fewer features than before and worked for nothing!

If code is too complicated to insert features -> rework it.
For the same result, redoing is always more time-consuming than reworking.

Read the article of the creator of Minecraft in the Game developer Magazine of February. He explain his experience on this point ( chapter “What went wrong” ).

Redo to simplify:
What happen: They saw a complex piece of code made by others that they don’t understand. They just don’t want to spend time understanding it and decide to produce a simplify version.
They program the simpler version they had in mind -> they stumble on an unforeseen problem -> add complexity to solve this problem -> new unforeseen problem -> again add complexity etc…
In the end, they get a solution as complex as the first one… They just lost several days/week of developement for nothing.

Rework is again the good solution: You can simplify the code faster.
Even if you choose to redo things, you should, at least, read the previous code to avoid falling in the same pitfalls.

Redo to take credits:
What happen: They can’t be proud of being the guy that has fixed all bugs. They just don’t have developed the feature, and can’t take credit from it, even if they have made all the dirty work by turning an unusable things into a perfect piece of code. They just prefer redoing everything.

Redo because it’s too buggy:
What happen: Bugs take way too long to fix because code are a mess.
This is the only case redoing can be a valid solution. Redoing can take you less time than fixing bugs in dirty code.

But be aware of not falling in previous cases.

Conclusion:
By adopting the reworking method, you will produce better code faster.
That’s a very good process if you want to respect Deadlines, and I think it should be a more common practice in the industry.

 

Rework

“Rework” and “Simple is beautiful” is my way of programming ( like Naruto’s “way of a ninja”..) .

How I’m programing:

1. First program version.
I make a first clean version. All essential features included. This version should be good enough to be shipped with the final product in case of a Deadline Rush.

2. Gather Feedbacks:
– I test it myself and see if my design have some flaws.
– I listen to artists feedback ( Game designer or graphic artist ).
– I ask fellows programmers feedback if I was developing some kind of code reused by others.

3. Decide what to do:
– Adding features ?
– Changing the code design to be more flexible ?
– Erasing code ? ( User found that they don’t need this feature anymore, or change everything… )

4. Reworking:
In this stage, we just :
– Move code.
– Change the class design. For example if you work on a text file parser, you can change the class structure but function used to read a float number is still the same.
– Rename function/class to be more understandable by others.
– Add features.
– Simplify code to avoid any Bug source.

We don’t redo anything !
We don’t restart from  the beginning ! I will explain why later.

5. Rework again:
We can rework a second time. This is only useful for code used on several productions.
This code should be “forgettable”.

For example I made a Text Manager when I was working in the Java Mobile Game industry.
It supports multiple language ( 7 different like russian, german, Italian etc.. ) , detects too long words, detects characters missing from the Font texture, distributes text in several pages on any screen resolution etc…
It suppress all Text’s bug which were almost 300 on each previous Game !
This code was tested on several productions. It was in this second working stage, solid and easy to use.

Rework don’t only apply on your own code, you should also employ it on code made by others. In this case you start at “2. Gather Feedback.”

 

I will explain why reworking is better that redoing in most case in a later post.