The WorldForge project is “A Complete Gaming System for Massively Multiplayer Online Roleplaying.” Also, it’s one of the SourceForge projects that participated in the Google Summer of Code this year. Erik Ogenvik, one of the developers on the project, wrote to me about their summer, and what they learned in the experience.
Rich: Congratulations on a successful completion of the Google Summer of Code. Could you give us an overview of what your project is?
Erik: Worldforge is a project aimed at providing tools for building virtual worlds. We provide server, clients, protocols, utilities and assets for making it possible to easily creating and experiencing multi user virtual worlds. All of our work is released under free software licenses.
The main focus of the project currently is on the “Ember” client, and the “Cyphesis” server.
It should also be mentioned that we acted as a umbrella project for both the CEGUI and the Ryzom project. CEGUI is a GUI library, often used in games. Ryzom is a MMORPG project.
Rich: What did your students work on this summer? How much did they get accomplished?
Erik: Worldforge had three students, two working on the Ember client and one working on the Cyphesis server. I mentored the two working on Ember, as that’s my main area of responsibility. Both Ember students worked on improving graphical performance.
Arjun Kumar implemented a system in Ember for automatic graphical adjustments. Here’s a video of the final result. He successfully completed the task which implements a system whereby graphical detail is automatically adjusted so that a smooth framerate is kept. The system is fully functional but will need some tweaking in order to provide a smooth experience as possible. The aim is to make it non intrusive enough so that the user won’t really notice it, except through a smooth frame rate.
Péter Szücs added support to Ember for an extensive geometry level of detail system. Here’s an older video from halfway through the program. The system allows for both detailed as well as automatic LOD generation for arbitrary meshes. All LOD generation happens on a thread separate from the main rendering one. It’s fully implemented and functional, already merged into the main branch. Combined with Arjun’s work it becomes even more powerful, as it allows for much larger scenes without making the client grind to a halt.
gsoc2012/worldforge: Automatic mesh Lod management system from sajty on Vimeo.
Rich: What did you learn in the process of running a GSoC project? Would you do anything different next time?
Erik: This is our fifth year participating in the program and we have by now a pretty solid way of working which we’ve found to be very successful. Both in getting students to produce high quality work and learn from it in the process, but also in making sure that they feel welcome in the project. In general, the main lesson we quickly learned is the value of communication, communication and communication (I feel I need to stress that!). For one, the value of having multiple communication channels. Make sure there’s always more than one way for the mentors and students to reach each others. However, by far the most valuable routine is to mandate daily SCRUM like reports for each student. Each morning each student sends me a report of what they did the day before, what they plan to do during the day and any impediments they can foresee. And I give feedback in return. In our experience this single regiment makes a huge difference in making sure that the student feels part of the project and confident that their mentor is putting time into helping them.
Rich: What advice would you give to other projects considering applying for GSoC next summer?
Erik: My main advice to other projects considering to apply is to make sure that they’ve set up multiple and redundant channels for communications. Mail server, chat rooms, IM accounts and so on. But also ways of communication about the code. We ourselves use Github, and reap huge benefits from the ability to directly comment on individual commits. This greatly eases the flow when discussing implementations.
I would also advise projects to put some kind of required test in place for submitting applications. Earlier years we had trouble with too many flippant or spammy applications. Nowadays we require that students first complete a trivial task (fixing a compilation and a runtime error) in order to consider their applications. This dramatically cut down on the number of uninteresting applications.
Rich: What advice would you give to students considering applying for GSoC?
Erik: For any student, consider what a community project is looking for. We want to see independent, mature and helpful students. Sharing knowledge, being proactive and reading instructions are positive traits. Remember that the mentors will often be overwhelmed with questions, so the ability to phrase your questions in an efficient way (and of course not asking about things that should be obvious) is valued. Start discussing or submit your application early on, so that any mentors can give feedback. Never submit at the last minute; all applications usually go through revisions and you need to have time to allow for that.