GSoC student applications are now open

Google has now opened the student applications for Google Summer of Code 2010.
This year, in order to help you figure out if you have the skills needed to work on Ember, and in order to help us to filter out non-serious applications, we ask students who are applying for ember to find and fix two errors in this special code drop. Also see the Ember prerequisites on this.
We encourage students to apply as soon as possible, so that there's time for us to give feedback and work out the details. The sooner the better.
If you have any questions please use the general mailing list.

Worldforge in Google Summer of Code 2010

Worldforge has for the third year in a row been accepted into the Google Summer of Code 2010 program. This means that students now have an opportunity where they can spend the summer writing code for free and open virtual worlds rather than flipping burgers and mowing lawns.
Student's applications will open on March 29, but if you are interested in applying the sooner you contact us the better.
We prefer that students use the general mailing list for discussing project ideas, or send mail to the mentors directly.
More information about the program, and a list of project suggestions can be found at the Worldforge GSoC page. Note that the suggestions are just that; suggestions. Any interested student is encouraged to also build on the suggestions, or propose their own project.

New world

For quite some time we've had our default world Mason. While Worldforge is a project aimed to provide basic tech for any kind of virtual world, we still need to have a showcase world in which we can try out different things. The default world has had some issues however.

• It's not using much of the new media provided by Jayr, and the media used is often outdated.
• It's confusing for newcomers. There's not clear direction of what new players should do in the world.
• The steep mountains surrounding the area are hard to manage in a client, as the steep cliffs makes level-of-detail optimized rendering hard.
• It's a quite small world.

All of this is changing as I've been working on a new default world. There are a couple of improvements to both the server and client which allows for this.

• Persistence on the server. As cyphesis is a work in progress, it's possible that bugs are uncovered when developing the world which will cause a crash. Having the whole world disappear when the server crashes is quite unproductive. With constant database persistence there's no risk of that.
• The ability to take a snapshot of the world on the server. This snapshot is saved as an xml file, which can then be added to a versioning system. This way it's possible to try things out, and revert to older versions if needed.
• Freezing the world on the server. When designing the world it's important that it doesn't change. That means that trees shouldn't grow, animals shouldn't move, living things shouldn't starve. Through a new feature which allows the server to be frozen any world author can first design the world, and once that's done unfreeze it.
• Advanced entity editing on the client. It's important that it's easy to edit all aspects on the fly on the client. The advanced entity widgets available in Ember allows for this. Aspects such as terrain areas or terrain modifications are easily editable through a point and click interface.
• Easy entity creation. Just as important as editing entities is making sure it's simple and quick to create new ones. The Entity Recipe system in Ember allows for entities to be created with point and click, with a powerful scripting environment in the backend.

The new world is therefore created in a series of steps. The first step involves working with a frozen world, where all entities are placed, and all terrain is sculptured. Once the world is complete it needs its npcs and creatures to be given behaviour and goals. This should be done using the existing python scripting in cyphesis. Once that's done the world should be available as both an xml file defining all entities and an accompanying python script file which defined behaviour.

When creating the new world there are a couple of goals I've had in mind.

• Use as much of the new media as possible, while clearing out any out of date media (i.e. media which simply doesn't look so good any more).
• Provide a large enough world that it will take some time to traverse it.
• Make the terrain friendly to any clients. That means avoiding too steep cliffs as that brings havok to any LOD mechanism.
• Provide a clear path for any new player. There should never be any confusion of what the player is supposed to do once he or she has entered into the world.
• Provide new game play. Apart from our current pig herding and fishing game play we have many ideas of additional tasks. These tasks also require a larger terrain, and new media.

So far things have gone very smoothly. Working with a much larger world is also good for Ember since it really pushes the engine in terms of memory usage and performance. Our current world is simply too small to really take advantage of the many dynamic paging features in Ember.

Below are a couple of screenshots of the work in progress. Some of them show the new starting area, which is on a peninsula with a clear path to the main area. Together with a couple of helpful signs and a greeting npc it should be much more clearer for any newcomer where they should go.