Latest Posts

Changes in GoogleSummerofCode

Revision Differences of Revision 2

#Google Summer of Code ¶
On this page we will discuss our intention to let the Widelands project participate in [Google Summer of Code](http://code.google.com/soc/). We intend to form a mentoring organization, write an application and create a list of suggested projects. ¶

So far, we have the following mentors available (with their areas of special knowledge): ¶

* [sigra](http://wl.widelands.org/profile/sigra) (Widelands' game logic, Widelands' UI toolkit, Widelands' coding style, C++, Valgrind, Ada, Subversion, !PostgreSQL) ¶

##Suggested projects ¶

###Multiplayer treaties ¶
Required skills: C++ ¶

Implement a system that lets players create treaties during a game. A treaty can have multiple clauses of different types, such as: ¶

* Transfer ownership of certain land. ¶
* Giving vision to another player for limited time. ¶
* Non-aggression for limited time. ¶

Players can modify the clauses during negotiation. Each time that a clause is modified, a new revision of the treaty is created. When all players that give something in a clause of the treaty has accepted the same revision of the treaty, it will take effect. The player does so by clicking on a button in his user interface (in the dialog window of that treaty). When a new revision of the treaty is created, the button is disabled for a certain time period (such as 2 seconds), so that the user does not decide to accept revision n of the treaty, then it is updated to revision n + 1 just before he clicks. Of course, when the client sends the accept treaty packet to the server, it includes the revision number, so that the packet can be ignored if the revision is outdated. ¶

The treaty system should support at least the types of clauses that have been mentioned as examples above, so that the treaty system can be tested and is useful. In addition to that, there can be future clause types about: ¶
* transferring militarysites to another player ¶
* delivering wares to another player ¶
* letting another player's soldiers walk over owned land to attack a third party (this right can of course not be given if the giving player has a non-aggression agreement with the third party) ¶

####Details about the clause types ¶
#####Transfer ownership of certain land ¶
To create a clause of this type, the player should first select which player's land should be transferred. The map should then be presented in a certain mode, where each node that he owns has an overlay with his color. Then he has a toolbar where he can select which player should receive the land. Then he can flip the nodes to the receiving player by clicking on them. The tool should have configurable radius (like regular tools in the Widelands editor), so that larger areas can be flipped easily. There is a constraint to consider; land that the giving player has military influence over can only be transferred to another player that also has military influence over the land. ¶

#####Giving vision to another player for limited time ¶
The receiving player sees everything that the giving player sees, for a time that is specified in the treaty. If the time is 0, the receiving player will only get a static snapsnot (he will see what the giving player has explored). ¶

#####Non-aggression for limited time. ¶
The giving player will not be able to attack the receiving player for a time that is specified in the treaty. There should probably be a maximum time that can be set. ¶

###Web-application for code responsibility management ¶
Required skills: Some kind of database such as !PostgreSQL and some web development framework such as Django (written in Python) ¶

This project would be useful for Widelands and we would have it on our website, but it is not at all specific to Widelands and would be equally useful to many other (software) projects. The function of the application is to present a table, where each row is a part of the project's codebase and each column is a developer that is a member of the project team. Each cell in the table shows the relationship between the part of the project's codebase and the developer. The rows form a hierarchy with collapsible subrows. For Widelands, it could look something like this (incomplete example): ¶

* Build system ¶
* Game engine ¶
* * Event/Trigger/Objective system ¶
* * * Event types ¶
* * * * Allow building type ¶
* * * * * Reveal Objective ¶
* * * * Trigger types ¶
* * * * * Building ¶
* * * * * Time ¶
* * Economy/Transport system ¶
* * Map geometry ¶
* * Player vision ¶
* * Worker programs ¶
* * Land ownership/conquering ¶
* * Battle/Training ¶
* Game user interface ¶
* * Map rendering ¶
* * * Terrain rendering ¶
* * * Map object rendering ¶
* * Map editing tools ¶
* Computer player ¶
* Picture management ¶
* Filesystem access ¶
* Sound output ¶
* Network game meta-functionality ¶
* * Lobby/game setup ¶
* * Chat ¶
* UI toolkit ¶
* * Button ¶
* * Listselect ¶
* * Table ¶
* * Window ¶
* Game data ¶
* * Tribes ¶
* * * Barbarians ¶
* * Tutorials ¶
* * Maps ¶
* Localizations ¶
* * de_DE ¶

Each developer can take on responsibility for a certain part of the code, thereby declaring that he understands the code well enough to fix any bug in it and that he is prepared to do so (although not within a short time since it is all volunteer work). This registration should expire automatically after a certain time period (such as a year). This avoids having a developer listed as responsible for some code, when he has disappeared a long time ago. The developer should be reminded by e-mail when the registration is about to expire, so that he can renew it. ¶

In addition to the headline of each row in the table (such as "Build system" in the example above), the row could also have references to particular source files or packages/namespaces/functions). ¶

Developers should be able to use the application when they are logged in to the website. For Widelands, this means that the application must have some kind of integration with Django. ¶

Such a table would give a good overview over which parts of the code are well maintained (covered by developers) and which lack a maintainer. It might even be a good place for a potential contributor of the project to look for an area that needs attention.