Ryzom

Hi there,

In this topic i will expose you my experiences during the Google Summer of Code 2011.
I'm a student at Epitech (a French IT school) and i will begin my 5th and last year in this school.

My project for Ryzom was the implementation of Guild Missions. Guilds must be able to pick up a mission, complete it and each member of this guild or the guild it-self can get a reward. Also, in a guild mission we can have objectives that must be completed by several guild members.

This project was very interesting and i'm now gonna tell you some of my experiences and difficulties during the program.

Being part of the GSoC¶

I heard about the GSoC in January 2011. I was really motivated to be part of this program. I looked for some organizations and i found Ryzom. I played this game a little bit in the past and i remembered it was Open Source and it was a great project.
When the program has been announced i contacted Ryzom to tell them that i wanted to join them in the GSoC. They told me that it was great and that i could join the IRC channel to know the community. sfb gave me some "missions" to do like: compiling the projects, setting up a shard, adding new mobs, etc...
I completed these missions and a few days after came the moment to begin the proposals.
Many guides suggest that we write proposals for several organizations but i was only interested in Ryzom. Nevertheless, i contacted other organizations and tried to know their community. However, i wanted to join Ryzom and not another organization, so i decided to take all the time i needed to write a very good proposal for Ryzom. It was a risky choice because if the proposal was not good enough for Ryzom i would have no other opportunity to be part of the program.
After the proposal i wrote for Ryzom i still had some time, so i tried to write another proposal for another organization but i didn't know the project as well as i knew Ryzom and the proposal i wrote was not really good.

To write a good proposal you must know your mission and the project. You must dive into the code and understand how you will implement your mission because in your proposal you will have to write a detailed timeline to prove that you understood your mission and the project in which you will implement it.

The main tip i can give you for your proposal if you plan to participate in the next GSoC is to understand the project, understand your mission and figure out how to implement your mission in the project before you write your proposal.

Understanding the code¶

I told you in the previous section that you must understand everything to write a good proposal and a good timeline. However, things are always more complicated than they appear, this is why you will always have to do things you didn't plan.
This is even more true when you are working on a very big project (which is usually the case) because implementing something can change a lot of things in the project. Also, when you implement a new feature maybe there are parts you have to edit but you didn't see all of them.
Working on a big project is difficult. In a small project you can easily read and understand the entire code, but not in a big project, it would take too much time, so you can only understand the basis.
Because of this, when you have to implement a feature, you have to read again the code and try to understand how it works exactly, and this is one of the most difficult part of the mission, because you begin to realize that you missed a lot of things in your schedule, you thought that your task would be easy, but it's actually not, and the worst thing is that you can't do anything about it, because you can't understand the entire code from the beginning.
So try to imagine how your feature should be inserted in the big project, try to find all the dependencies of your feature in the project, try to think about everything in your feature.

Fulfill the schedule¶

As i said, it's hard to think about everything from the beginning, so we will meet another issue: fulfilling the schedule.
Someone told me one day that when we make a schedule, we have to double the time we estimate for a task because there are always bugs and things that don't work. That was a very good and useful tip, but even with this tip it's hard to fulfill a schedule, it's hard to make a good schedule, because sometimes you think you will need 2 days for a task but you actually need only 1 or vice versa.
This point meets the previous point about the code comprehension: to make a good schedule you have to understand your task and the project source code.

During the GSoC program i figured out that my estimations were not always accurate, for the first tasks i needed less time than estimated, and for the last tasks i needed more time than estimated. It happened because i thought i understood the source code of the project, but i actually didn't (or at least not entirely). Sometimes i had "bad" surprises because i thought a task would be easy to do, but i didn't see i would have to change a lot of things beside this.
Finally, because i was ahead of schedule i managed to complete my tasks on time, but i realized that i have to be more careful about the schedule i make and the comprehension of the project's source code.

Wrong choices¶

It happened, during the program, that i wanted to change a feature because i realized it was not convenient. However, changing a feature can be costly in time, because you took some time to complete the feature and you will need more time to complete the modifications.
My advice is: be careful and try to anticipate as possible.

A lot of experiences¶

Finally, this was a great experience, i leaned a lot of new things. Being part of a big project is something great, we can learn a lot of things from the source code and from the community. Everyone can share its experience. I learned from my mistakes: the schedule, the wrong choices, the code comprehension, etc...

I met great people. I would like to thank ulukyn my mentor, he was really nice and patient with me during the program. He also helped me a lot and i guided me. I also would like to thank sfb because he also helped and guided me during the program, and i would like to thank all the people i met on IRC for their kindness and their assistance.

I hope this post mortem will be useful for some of you, and i hope i didn't make too many mistakes in writing this article (my english is not perfect yet).
If you have any question or suggestion feel free to add an answer here.

Thank you for reading me, and thank you for this experience !