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

How can you improve your coding quality with a versioning Tool?

A versioning tool can be used for purposes other than saving different versions of your files.
One of the key feature, is to make code review easier.

Let’s start by explaining what code review is:
Code review entails looking at source code with the intention of finding mistakes to improve overall software quality.
All you do is read it and try to understand it, like you would read a math book.

Most of the time, by doing this simple thing, you will discover bugs! Fixing these bug will be far easier than using the usual process (no need for testing and tracing into the code to find these bugs.)

– How a versioning system can help you ?
It stores different versions of a source code, so before sending your new version (submit/commit) you can display which lines in the source code have changed!
There are usually 3 “human” configurations:
A senior programmer and a junior programmer: Before sending code produced by a junior programmer into the main code base, an experienced programmer should carry out a code review.
If modifications are good, it’s submit/commit. If code quality is not good enough, the junior programmer will continue working with the help of the senior.

Two senior programmers: Even a senior programmer can create a bug… Even a senior programmer can produce obscure code. A scan over from another programmer can help to give code quality another perspective.
It’s sometimes hard for the ego (programmer’s egos are usually verrryy big), but it will certainly progress you further.

One programmer: You are alone…Sniff. Or other programmers simply don’t have time to review your code (They are too busy.) Carrying out your own code review is a must!
It should be done before every commit/submit. It should even be done before another programmer reviews your code.
It helps you detect bugs and improve quality (simplifications etc..) but it also helps you memorize your own code!
If your source code is in your head, you will be able to fix bugs more quickly, find solutions faster. I myself find bugfixes on my way home, in the subway! And the fix is usually something small like adding a ‘+’ or an uninitialized variable.

A versioning tool is a must for every developement process. It can save you time and greatly improve software quality.



Continuous Collision

I stumble upon an article on an interesting collision technique:
Speculative Contacts – a continuous collision engine
There is some nice live demo on this article.

In the past, I’ve implemented myself a 2D collision system. I used a classical discrete method and had stability issue.
If this technique is simple and stable I will use the algorithm on my next unity project.

I’ve bought the source code to thanks the author.
If you like it I advise you to do the same.





“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.

Unity lightning Contest

I participate in the Unity lightning contest, with the hope to win a Unity pro licence.

You can see all entries on the unity contest page.

You can even try my beauuutifullll Unity lightning demo:

Unity lightning contest entry
Unity lightning contest entry

I only work on it 1 big day and a half. I should have worked a little more to  ensure me a victory but my other job eat me all my time.

My Unity project will be delivered for free at the end of the contest !
I will post a link of the Unity package with all the source code in this blog for everyone who want to download it !

The code is clean, and commented. I made a framework to easily draw multiple line. So you will be able to use it for other projects if you want, or take it as an example.