SummerOfCodeIdeas

Ideas for Google Summer of Code projects

This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):

List of Ideas for the Project

Writing an AI based on the formula AI

Wesnoth has always had a simple C++ based AI. David (our lead developer) has been working on a simple language to write AI in Wesnoth link to formula AI page here

The Wesnoth AI is used as an opponent in most campaigns, and as such is an important piece of code for the Wesnoth project. Unfortunately it is also one of the most neglected piece of code and a place where a lot of research and work could be done

General description

The aim of this project is to develop a new AI that would replace the original C++ AI. The main criterias we would want for this new AI are

• Plugability : It should be trivial for any content maker to change the behavior of the AI in specific case. The exact cases are still to be defined but should typically include
  • hardwiring the first few turns of the AI
  • changing the recruitment pattern
  • completely controlling a given unit (scenario unit)
  • taking control then giving back control of a given unit
• tunability : It should be easy for a scenario author to specify the general behaviour of the enemy on a given scenario (aggressiveness, intrepidity...)
• specific behaviours : there are some typical behaviours that are not smart to win the scenario but are needed, such as guarding a given unit, a given position, wandering aimlessly, attacking randomly, always fleeing. The AI should implement such behaviours, and allow easy addition of new behaviours

Required knowledge and talent

• A minimal knowledge of C++ is required, a good knowledge of C++ is desired : The formula AI framework is a work in progress and chances are high that some changes in the wesnoth code base will be needed. The wesnoth developer community is used to handle people that are familiar with coding but not C++, however the Formula AI framework uses advanced C++ features and a good knowledge of the language would avoid a major hurdle when plugging in new entries or functionalities for the AI
• Good social interaction with a large player community : A preliminary phase to coding any AI is to know the strategies and game pattern used by human players. This requires huge interaction with the player community. Our Gameplay Developers are open and can give some good starting points, but a big game experience and good interaction with the player community will greatly help in the study of the design

Milestones and deliverables

It is hard to give milestones at this point, but here are some ideas of what could be done

• AI design description, and basic function library : This first deliverable aims to conclude the study and analysis part of the project : becoming familiar with the formula language, study of multiplayer strategies and of the need of scenario writers with regard to AI. We would like to have a description of the code structure of the AI, some basis of the play strategies it would use and how external scenario writers could configure it for the particular behaviour they need
• Main AI delivery : This milestone's aim is to deliver a working AI implementing the strategies described in the first phase. It would not have to systematically beat the standard C++ AI at this point, but should be able to play the game correctly (recruit, early deployment on villages, grouping units to attack, holding its ground, protecting weak/important units). Moreover most plug-in entries should be available and a test-case for these entries should be provided.
• Fine tunning and behaviour library : The third phase would validate the actual strategy of the AI. The AI should consistently beat the default C++ AI, and do fairly well against an average human player. At that stage a library of scenario behaviours should also be delivered. The AI does not need to be as efficient with all scenario tweaking, but should act correctly with regard to the particular behaviour desired.

Extending the Multiplayer server

When the development team met at FOSDEM, we had our multiplayer community, though it is strong and healthy, had its growth restrained by the interface of the multiplayer lobby.

General Description

The general idea of this project would be

• To study the current lobby,
• To present some ideas of evolutions both in interface and functionalities of our multiplayer interface to allow it to scale to a much larger community
• To present some well constructed thought on our MP community and how that interface would develop it
• Of course to implement those changes :)

Some ideas that we had (but that are in no way mandatory)

• Having a simple way to register and authenticate nicknames, similar to what IRC offers. The point is not to have cryptographically safe logins, but to have something simple that gets the job done
• Having a simple room system? again inspired on IRC
• Having some way to find the type of games you are interested in.
  • game type
  • number of free slots/players
  • any other criteria you might find interesting

Other ideas we are not convinced are good, but that are certainly worth studying (especially how the communities based around these concepts are different from ours)

• ranking players
• guilds
• official tournaments
• titles for players
• metaservers

The scalability of the project, both in term of number of players, and in term of the possibility for players and developers to extend the concept will be a valued criteria

Administration/moderation problems and techniques should also be studied

interaction with the Add-On server/forum might be an interesting field to expand to

Required knowledge and talent

• A fair amount of experience on C++ is required. Wesnoth uses some advanced C++ features and is heavily based on BOOST and STL. We can train you in some of the libraries used, but learning all of them would be a big hurdle
• Various experience with multiplayer games, in order to have a good idea of what multiplayer lobbies of other game look like, and (more importantly) a good idea of the social behaviours of multiple MP communities, how teams are formed in games and things like that

Milestones and deliverables

• A first milestone would be a presentation summarizing the different studies, and the proposed interface. preliminary informal stages would probably be desirable, to make sure the proposed idea is already a consensus within devs
  • Study of other MP game-matching interfaces and functionalities
  • Study of other MP communities
  • Study of other MP moderation practices
  • Study of the Wesnoth MP community, including needs, various opinons from different developers and players
• A second milestone would be the main code delivery. Code should be functional for it will be delivered in the next Wesnoth development release

Scenario/Campaign editor

Currently, in order to create campaign or multiplayer scenarios, it is necessary to manually edit WML files - XML-like configuration files. The goal of this project would be to create a graphical editor allowing the same.

General description

A scenario editor for Wesnoth supporting everything possible by Wesnoth's engine would be a huge project, so the scope of the actual project would of course be limited - what exactly should be implemented would be decided by initial discussion. Implementation details and choice of language/tools would also be up to the student to choose. The main ideas would be for the scenario editor to be:

• cross-platform (at least Linux, OSX, Windows)
• easy to use (someone who tries reasonably hard should be able to create a simple scenario/campaign with it, even if not knowing WML)
• powerful (there already is a map editor coming with Wesnoth - the scenario editor will provide more/different things)
• extensible (also after the SoC project, it should be easy to add additional features)

There exist at least two attempts at a scenario editor, an OSX-only one which shipped with early Wesnoth versions, and CampGen, an external tool written in WxPython. The student could look at them for ideas or even use one of them as base, but that should be discussed first. The below assumes a new application is developed from scratch (which likely will be much more motivating for the student than reviving an existing attempt). The actual things to be done would be:

• Decide on a cross-platform GUI which would be best suited (Qt4, Wx, GTK, Wesnoth's builtin GUI (in that case, could maybe integrate with the existing map editor, but would have serious other problems), or others...).
• Decide on a platform/language to use (C++, Python, or others...). Wesnoth is written in C++, so it's what most developers would prefer, but as long as it can be expected to work on Linux, OSX and Windows, this is completely open.
• GUI design. This is the main part of the project. The editor should make it easy to create scenarios, so the GUI must not be confusing/hard to use.
• Decide on base features. ReferenceWML lists everything currently supported by WML. Theoretically, the scenario editor could support everything, but for the timeframe of the SoC project, it will be necessary to decide on the most important features and implement those.
  • WML-centric or not? Two opposite views for such an editor would be to either strictly follow WML, as extreme case have one dialog for each WML element. Or on the other hand make a scenario creation tool which completely hides WML and then simply can export to WML, translating features as necessary. The final design likely would be somewhere in between.
  • Ability to read existing WML? The editor will export to WML, but need to decide if it also should be able to read it.
  • Built-in map editor? Wesnoth comes with a map editor, but it can only be used to define the terrain. The scenario editor has to allow placing events and units and other things, so it will need a way to display maps as well. Would be worth investigating if the existing C++ map-drawing code of Wesnoth can be re-used.
  • Ability to enter custom WML code? For advanced users this might be nice, if it can integrate well.
  • Story screen editor for campaigns?
  • How powerful should the events editor be? WML basically is a turing complete language, so must decide what should be supported and how to present to the user.
  • Custom unit animations?
  • Custom multi-hex terrains?
• Extensibility (leave the possibility to extend the application with plugins for some of the above things, either with a plugin architecture or by making the source code modular enough)
• WML-export. The second major part besides designing and implementing all the GUI will be exporting the result to WML, and depending on some design choices this could prove more or less hard to do.

Required knowledge and talent

• Knowledge of C++. Even in case the editor is not written in C++, it will be necessary to look at some parts of Wesnoth's source code (WML-parser, editor, ...) and understand them, possibly even integrate/re-use them.
• Ability/interest in GUI/application design. A not negligible part of the project likely will be spent designing various GUI dialogs.
• Prior use of level creation tools/modding tools. Knowing existing tools for other games will help a lot in the design phase, as many good ideas can be seen there. Not required though.
• Having played Wesnoth and knowing what scenarios look like would help. Someone who never played Wesnoth before would risk losing a lot of precious time playing the game instead of working :) But it's not required of course.
• Knowledge of WML. A candidate who already knows Wesnoth's WML could save the initial time studying it. (On the other hand, not knowing WML might mean less technical bias and might lead to an application which is easer to use for non-technical users.)
• Ability to interact with developers/users. Presenting GUI mockups and test versions and incorporating early user feedback likely will improve the end result a lot. The Wesnoth community is big enough that there should be quite some willing testers.

Milestones and deliverables

The initial design will decide on many later things, and likely a lot of talking to developers and users will be necessary. But some general milestones I'd expect:

• Create a base test application in the chosen language/platform. This will not do much yet, maybe load some WML and display it as text. Try to package it for Linux, OSX and Windows (there will be help from the Wesnoth community, so no need to have access to all of them), and see if it can be expected to work. If a standard GUI like C++/Qt4 is used, this will be rather trivial. Something like Python/Wx or C#/.NET might take more time.
• Add ability to edit some very simple, maybe only textual properties of a scenario, and export to WML. It should already have base features like Save/Load/Undo, copy/paste, multiple documents, and so on. Depending on the chosen GUI this may be easy or already require some work.
• Finish design. Should list the intended features and demonstrate how the GUI will work.
• Start implementation, a natural milestone would be to make it possible to create and export a very simple, but playable scenario.
• Add more of the features (which ones and in which order depends on the design above, a detailed roadmap will be part of it).

Addon server

Wesnoth has an addon server which offers users to upload user made content (UMC). This allows all other users of Wesnoth to easily download and install this content. The server was originally written for user made campaigns but contains a lot more types of addons nowadays. Both the server side and the client side need to be improved.

General description

Both the server and client side of the addon server haven't been improved over the years and can use quite some improvements. The client side GUI needs quite some improvements. For the server side it's wanted to allow better integration with various tools, which improve the quality of the addons.

Server side

The server code either needs to be updated or rewritten, the student is free to make this decision him or herself. The student is free to choose the language for the server.

• The server only needs to run on Linux systems, crossplatform would be nice but isn't required.
• At the moment there's a rudimentary integration with our translation project Wescamp. This needs to be improved. Upon uploading the new content needs to be send to Wescamp (via a svn commit). And the translations need to be fetched on a regular basis.
• We have various tools to check the WML code and also upgrade it to newer version. The addon server needs to be able to run those tools on the content.

Client side

The client side needs improvements, there are two main clients the ingame version and a standalone version in Python.

• Upgrade the GUI, Mordante is working on a new GUI library which is intended to make it possible to make the wanted changes.
• Make it easier to see what kind of addon it is, at the moment a lot of new users download something and have no clue what kind of addon it is.
• Make it easier to see whether a newer version of the addon is on the server and update the addon.
• Make it easy to select which translations you want to download and also look for newer versions of the translations.

Required knowledge and talent

• Knowledge of C++, the game is written in C++ and modifications need to be made there.
• Knowlegde of Python, various tools have been written in Python which need to be intergrated with the new server.

Milestones and deliverables

• The first step is to determine what exactly needs to be done and determine in which language the server will be rewritten. This includes, but isn't limited to:
  • Determine the exact feature set.
  • Protocol changes needed.
  • Methods to integrate with both the WML tools and Wescamp with the new server.
  • Determine the GUI for the client side.
• This needs to be presented and discussed with the mentor(s).
• The next thing in to implement the feature set. The code needs to be fully functional and committed in trunk.

Other ideas to be fleshed out

• Working on the GUI engine (needs to be defined more precisely)
• The editor can use quite a revamp
• A MapGenerator rewrite - better scalable for outdoor maps, plus the possibility to define areas (similar to the caverns in the ave generator) etc.

Other info to provide for GSoC

Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating?

Most of our developers have interesting areas in which they work. Though they are efficient in their areas, there are areas that are interesting but have a high barrier of entry.

By having a student dedicated to any of these areas, we could quickly get someone up to date with that particular area, efficient, and responsible of this area.

Basically, by getting new people in and making them actively responsible for an area of code we hope to kickstart some areas of the project that have lagged behind

Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.

This is the first time the Wesnoth projects applies to Google SoC

If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?

This is the first time the Wesnoth projects applies to Google SoC

Who will your organization administrator be? Please include Google Account information.

Nils Kneuper aka Ivanovic

crazy.ivanovic |ATTT| googlemail.com

What license(s) does your project use?

Our project is entirely GPL.

All code is GPL.

All art is GPL, 99% was made for the project, everything was taken from content that was checked to be GPL.

What is the URL for your ideas page?

Our main summer of code pages is located at http://www.wesnoth.org/wiki/SummerOfCodeIdeas

This page contains various coding ideas and the thought the development team has already given them.

It also contains a list of the developers that are the most active on IRC and their domain of interest.

What is the main development mailing list or forum for your organization?

Most development work takes place on "wesnoth-dev |ATTT| gna.org". Beside this some work happens at http://www.wesnoth.org/forum/.

What is the main IRC channel for your organization?

All our IRC channels are on the freenode network

• #wesnoth-dev is the main development channel, where most discussion takes place
• #wesnoth is a generic channel for the community
• #wesnoth-mp is a separate channel for multiplayer games and balancing

Does your organization have an application template you would like to see students use? If so, please provide it now.

We plan mainly to meet potential students through our IRC channel, but the following questions are wesnoth-specific and are worth pondering for any student, even if we don't need a formal answer

• What type of gamer are you? What type of games? What type of opponent? Are you more interested in story or gameplay ?
• Are you good at interacting with other players ? Our developer community is quite nice, but the player community can be a bit rough.
• Do you give constructive advices? Do you receive advice well? Are you good at sorting useful criticism from useless ones?

'to be completed'

Who will be your backup organization administrator? Please include Google Account information.

Jeremy Rosen alias Boucman

boucman2|ATTT|gmail.com

What steps will you take to encourage students to interact with your project's community before, during and after the program?

Wesnoth has a particularly healthy community, both for developers and for players.

Our general policy regarding new coders has always been "two patch... you're in" In other word, anybody that is able to get two non-trivial patches applied is offered commit right.

We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our EasyCoding pages (these project are usually a couple of hours long and has been chosen to provide easy access to code)

Usually, patches go back and forth a couple of time, to make sure that all secondary things are in place (indenting, coding style, modified makefiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to maintain our project alive.

If the student is a little proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.

to be completed

People to bug on IRC, possible mentors

Everybody feel free to edit/correct his entry!

Dave alias Sirp

Sirp started Wesnoth and is our lead developper. He is currently our C++ expert and is also the one that is working on the new Formula AI. Any questions regarding the formula AI should be directed to him.

Mordante

Many of the possible projects do at least partly go into the area of code where he knows most of. Plus many of the possible projects currently listed on the ideas page do require GUI parts to work, too. So if Mordante wants to tackle a rewrite of large parts of this, he will be our expert there as well as he already is our expert for the terrain engine (cf. editor / scenario editor works).

Elias Pscherning (elias)

He has written the original version of campgen and as such will know a lot about what is needed to to make such an editor work correctly. The work on a scenario editor might be based upon campgen and as such make his knowledge really helpful.

Karol Nowak (grzywacz)

Last year he was participating at GSoC as a student, so he knows at least this side of the medal. Beside this he is our top expert regarding embedded devices support since he is actively working on the gp2x support.

boucman

As our "patch monkey" he has valuable knowledge in comments and critics for patches of every kind. Beside this he knows many areas of the game due to working on applying patches. He is particularly used to answer question from new coders, and doesn't mind explaining trivial stuff.

If you want to have a feeling of the developer spirit, it is recommended to go to our EasyCoding page.

Soliton

He does know our mp server setup best. Beside this he already has done a lot of work on the mp server himself, too. So he probably has most knowledge about it and due to being one of our mp-developers might provide important help from the perspective of mp-community and what is needed there.

zookeeper or Mythological or Rhuvaen

As our leading WML expert it would be good to have him in the list when it comes to WML specific problems. That is for work on the scenario editor he probably knows best what should be implemented in it and what is a usable way for things.

YogiHH or Piotr Cychowski (cycholka)

Since they are the two developers who know most about building under Windows, they will probably be really helpful. Either if the student comes from the Windows side, or to help test resulting work to make sure that it does work on Windows and, for the case that it does not, to show them where problems are.