Google Summer of Code

On this page we will discuss our intention to let the Widelands project participate in Google Summer of Code. We intend to form a mentoring organization, write an application and create a list of suggested projects.

We should have several mentors with overlapping skills, so that Google sees us as a reliable and capable part. If you have some skill that is useful to be a mentor of any of the suggested projects (you may add some projects yourself), and time during the summer (5 hours per week is a reasonable estimate), please add yourself to this list of mentors. Skills that are especially useful for us is knowledge of the Widelands codebase and experience of evaluating student achievements. So far, we have the following mentors available (with their areas of special knowledge):

• sigra (Widelands' game logic, Widelands' UI toolkit, Widelands' game/editor user interface, Widelands' coding style and checks, Krazy2, cppcheck, C++, Valgrind, Ada, Subversion, PostgreSQL, Swedish, German, English)

Suggested projects

Add suggested student projects here. They should be specially suited as student projects. This means that they should not require major rewrites of central parts of our codebase. Preferably, they should be self-contained and orthogonal to existing features. It should be possible for us to predict what changes to the existing code would be required to integrate the feature. A student without experience with the Widelands codebase should be able to get sufficiently familiar with our code and complete the project within the timeframe of the GSoC. The project should not be too small either, but it is possible to define additional features that are not required to make the result of the student project useful, but improve it (or some other part of Widelands). If the student project appears to be too easy for the student during the GSoC, such additional features can be taken into it.

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)

An additional feature to this project may be diplomatic states that affect how players interact with each other (War, Neutral, Peace, Alliance). Another additional feature may be to teach our default computer player implementation to accept and propose treaties.

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.

Improve multiplayer capabilities

Widelands has only very basic multiplayer capabilities. It can start new games and continue from savegames. But other free real-time (or turn based) strategy games such as OpenTTD (and Freeciv) have much more complete multiplayer capabilities (all of them are present in some of the other mentioned game projects):

• Several connections (users) can control the same player.
• Game state is transmitted from the server to the client when the game begins or when a client connects to a running game. (Currently the savegame has to be distributed manually (e-mail, ftp/http download link, IRC) to all users. And if a player is disconnected and wants to rejoin, everyone has to quit, get the current savegame, go back to the game setup menu and start the game from there.)
• Let a user set a password for his player.

An additional feature for this project is to implement random map generation for new games. Currently there is a Widelands map generator in the map editor, but it can not yet be used directly when starting a game. The easiest way would be to let it generate a map on the server and send it to the clients. But the preferred way would be to send map generation parameters and a random seed, so that each system will generate an identical map. This would save network bandwidth. But it would require rewriting some of the map generation code to use integers instead of floating point numbers. The map generator does not yet place starting positions for players.

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.