|
|
| Line 15: |
Line 15: |
| | == List of Ideas for the Project (Suggestions from the wesnoth developers) == | | == List of Ideas for the Project (Suggestions from the wesnoth developers) == |
| | | | |
| | + | Here is only a short description of possible Ideas we have, each has a page of its own with a more detailed version on it. |
| | | | |
| | === Writing an AI based on the formula AI === | | === Writing an AI based on the formula AI === |
| Line 22: |
Line 23: |
| | 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, because the skills required to understand and modify it are rather arcane, it is also one of the most neglected parts of the Wesnoth code. This is a place where a lot of research and useful work could be done. | | 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, because the skills required to understand and modify it are rather arcane, it is also one of the most neglected parts of the Wesnoth code. This is a place where a lot of research and useful work could be done. |
| | | | |
| − | ==== General description ====
| + | [[SoC_Ideas_FormulaAI]] - Full version of the idea, with detailed information |
| − | | |
| − | 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 behavior of the enemy on a given scenario (aggressiveness, intrepidity...)
| |
| − | * ''specific behaviors :'' there are some typical behaviors that are not optimal for winning a force-on-force battle but are needed for storyline reasons, such as: guarding a given unit, a given position, wandering aimlessly, attacking randomly, always fleeing. The AI should implement such behaviors, and allow easy addition of new behaviors
| |
| − | | |
| − | ==== 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 gameplay patterns used by human players. This will require a lot of interaction with the player community. Our gameplay developers are communicative and can give some good starting points, but a lot of game experience and good interactions with the player community will be essential for doing a good redesign.
| |
| − | | |
| − | ==== Milestones and deliverables ====
| |
| − | | |
| − | It is hard to set 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 behavior they need
| |
| − | * ''Main AI delivery :'' This milestone goal 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 behavior 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 behaviors 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 behavior desired.
| |
| | | | |
| | === Extending the Multiplayer server === | | === Extending the Multiplayer server === |
| Line 51: |
Line 29: |
| | Our multiplayer community is generally strong and healthy, but we believe its growth is limited by some problems in the interface of the multiplayer lobby. | | Our multiplayer community is generally strong and healthy, but we believe its growth is limited by some problems in the interface of the multiplayer lobby. |
| | | | |
| − | ==== General Description ====
| + | [[SoC_Ideas_Multiplayer_server]] - Full version of the idea, with detailed information |
| − | The general idea of this project would be
| |
| − | * To study the current lobby,
| |
| − | * To develop ideas about how our multiplayer interface could evolve to allow it to scale to a much larger community
| |
| − | * And to implement as many of those changes as practical
| |
| − | | |
| − | 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 by IRC
| |
| − | * Having some way to find the type of games you are interested in. filtering by:
| |
| − | ** game type
| |
| − | ** number of free slots/players
| |
| − | ** any other criteria you might find interesting
| |
| − | | |
| − | Other ideas we are not yet 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
| |
| − | * game matching when players are ranked (poker, bridge...)
| |
| − | | |
| − | The scalability of the design (both in term of number of players, and in term of the possibility for players and developers to extend the concept) will be an important criterion.
| |
| − | | |
| − | Administration/moderation problems and techniques should also be studied.
| |
| − | | |
| − | Interaction with the Add-On server/forum should be explored.
| |
| − | | |
| − | ==== Required knowledge and talent ====
| |
| − | | |
| − | * A fair amount of experience with C++ is required. Wesnoth uses some advanced C++ features and is heavily based on BOOST and SDL. We can train you in some of the libraries used, but learning all of them would be a big hurdle.
| |
| − | * 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 opinions 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 === | | === Scenario/Campaign editor === |
| Line 97: |
Line 35: |
| | 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 to make the creative process easier. | | 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 to make the creative process easier. |
| | | | |
| − | ==== General description ====
| + | [[SoC_Ideas_Scenario_and_Campaign_Editor]] - Full version of the idea, with detailed information |
| − | | |
| − | A scenario editor for Wesnoth supporting everything possible by Wesnoth's engine would be a huge project, so the scope of the actual project must be limited for feasability. 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 (but see the note on Python below). 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 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 === | | === Addon server === |
| Line 146: |
Line 45: |
| | client side need to be improved. | | client side need to be improved. |
| | | | |
| − | ==== General description ====
| + | [[SoC_Ideas_Addon_Server]] - Full version of the idea, with detailed information |
| − | Neither the server nor the client side of the addon server have
| |
| − | seen much improvement over the years; both are overdue for a reworking.
| |
| − | The client side GUI needs polishing. For the
| |
| − | server side we would like to allow better integration with
| |
| − | various tools (such as wmllint), 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 may choose the language for the server, but because some of the code that needs to be integrated is Python we'll need to hear a specific justification for any other choice.
| |
| − | | |
| − | * The server only needs to run on Linux systems. Cross-platform portability 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;
| |
| − | one built in to the C++ game binary, and a standalone inmplementation 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 summary and status information on addons. 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.
| |
| − | * Knowledge of Python, various tools have been written in Python which need to be integrated 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.
| |
| − | ** Justify the choice of language.
| |
| − | * These points will need 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.
| |
| | | | |
| | === Map editor === | | === Map editor === |
| Line 187: |
Line 51: |
| | a new map and helping the terrain artists to test their new terrains. | | a new map and helping the terrain artists to test their new terrains. |
| | | | |
| − | ==== General description ====
| + | [[SoC_Ideas_Map_Editor]] - Full version of the idea, with detailed information |
| − | The current editor hasn't been actively maintained for quite a while and the
| |
| − | quality of the code isn't up to par with the main game. The student
| |
| − | will either revive the current editor or start from scratch, the latter
| |
| − | will probably be easier. When rewriting from scratch the student can
| |
| − | pick the language of his/her liking as long as the result is crossplatform
| |
| − | (at least Linux/Windows/OS X).
| |
| − | | |
| − | (Note: Unlike the add-on server, there is no specific code-integration reason to prefer Python for the editor rewrite in advance. However. the project has been trying to reduce its dependence on other scripting languages in order to hold down overall maintenance complexity. Thus, the student should be prepared to justify the choice of any language that is not Python or C++.)
| |
| − | | |
| − | Some of the things the new/revived editor should be able to do:
| |
| − | * Include all features of the current editor.
| |
| − | * When rewritten, great care must be taken that the render engine works the same as the render engine in the main game. When rewritten in C++ it can simply use the game sources, otherwise the student needs to turn the main game C++ files into a library which can be called in the language the editor will be written in.
| |
| − | * The editor needs to be able to handle so called ''custom terrain'', these are terrains used in maps but not loaded by default.
| |
| − | * The editor needs to be able to reload the terrain graphics config files, this way terrain artist can test the changes to the config files without having to reload the editor.
| |
| − | * The current editor can generate random maps with help of a config file, which contains a generator definition. The editor can only use one generator hardcoded. This needs to be modified to be able to use every generator config the user has installed.
| |
| − | * Various ideas exist to help the artists to make it easier to tune their terrains and config files, this is a secondary goal. We think it will be too much work to do this in one summer.
| |
| − | | |
| − | ==== Required knowledge and talent ====
| |
| − | * The current editor and the main game are written in C++ therefore knowledge of C++ is required. Even if the editor is rewritten in another language the render engine needs to be converted to a library.
| |
| − | * The student needs to be able to make a user friendly user interface.
| |
| − | * Depending on in which language and toolkit the editor is (re)written in the student will need to have skills in that language and toolkit. The current editor uses the SDL toolkit with our own widget toolkit.
| |
| − | | |
| − | ==== Milestones and deliverables ====
| |
| − | * The first step is to make a priority list of features. This means the student has to interact with the community and determine what is most wanted.
| |
| − | * From this list the student needs create a sublist of items he/she will be able to do within one summer.
| |
| − | * 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.
| |
| | | | |
| | === Make your own ideas === | | === Make your own ideas === |
This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):
I want to be one of your Google Summer of Code students, what should I do...
Here is a quick list of things to do to get you started
- Create an account on gna.org
- Create an account on the wesnoth forum
- Join the irc channel (#wesnoth-dev on irc.freenode.net) and introduce yourself. We will not give formal interviews, but we will clearly favor people we have learnt to know during the selection process
- Contact one of our SummerOfCode people (Ivanovic, Sirp, Boucman, Mordante) to have your forum nick marked as a Summer of code student
- Start a wiki page about your idea, add a link on this page
- Fill the questionnaire on this page
- Detail your idea as much as possible, look at other students pages, and please give milestones and studies you've done
- Though not mandatory, it is highly advisable to go to the EasyCoding and NotSoEasyCoding pages and implement one of these ideas (or any idea of similar scope) so we have an idea how you work. Be sure to use your gna account when submitting these patches so we know who it is coming from. You can also implement some features from our feature request database at gna.
List of Ideas for the Project (Suggestions from the wesnoth developers)
Here is only a short description of possible Ideas we have, each has a page of its own with a more detailed version on it.
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: FormulaAI
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, because the skills required to understand and modify it are rather arcane, it is also one of the most neglected parts of the Wesnoth code. This is a place where a lot of research and useful work could be done.
SoC_Ideas_FormulaAI - Full version of the idea, with detailed information
Extending the Multiplayer server
Our multiplayer community is generally strong and healthy, but we believe its growth is limited by some problems in the interface of the multiplayer lobby.
SoC_Ideas_Multiplayer_server - Full version of the idea, with detailed information
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 to make the creative process easier.
SoC_Ideas_Scenario_and_Campaign_Editor - Full version of the idea, with detailed information
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.
SoC_Ideas_Addon_Server - Full version of the idea, with detailed information
Map editor
The map editor in Wesnoth serves two goals, making it easy to create
a new map and helping the terrain artists to test their new terrains.
SoC_Ideas_Map_Editor - Full version of the idea, with detailed information
Make your own ideas
If you have your own idea the best thing is to join IRC wesnoth-dev at irc.freenode.net and discuss the idea with the developers there. If the developers think your idea is interesting and like the feature you can start to turn it into a full proposal. Once done discuss it again on IRC so the developers can accept your idea.
Other ideas to be fleshed out
- A MapGenerator rewrite - better scalable for outdoor maps, plus the possibility to define areas (similar to the caverns in the cave generator) etc.
Information about our Project
The information we provided google with about our project can be looked up at the site SoC Information for Google.
People to bug on IRC
Everybody feel free to edit/correct his entry!
boucman
As our "patch monkey" he accustomed to critiquing patches of every kind. Beside this, he knows many areas of the game due to working on applying patches. He is particularly used to answering question from new coders, and doesn't mind explaining trivial stuff. He was the one who started the "two patches, you're in" policy and the ReferenceWML part of the project.
Dave alias Sirp
Sirp started Wesnoth and is our lead developer. 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.
Elias Pscherning (elias)
He wrote 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 his knowledge will be really helpful.
Eric S. Raymond (ESR)
ESR is our project toolsmith; he has written several tools that semi-automate various aspects of WML maintenance. While most of our developers/designers concentrate on either the C++ core or WML but not both, he has a balanced understanding of both levels and may be helpful in helping students develop a grasp of the overall architecture. Finally, he did the last overhaul of the Wesnoth UI and understands UI design principles; he is well-equipped to guide students working in that area.
Karol Nowak (grzywacz)
Last year he participated at GSoC as a student, so he will understand the situation of GSoC students. Beside this he is our top expert on embedded devices, and is actively working on the gp2x support.
Mordante
Many of the possible projects involve the code for which he is an area expert. Also, many of the possible projects currently listed on the ideas page require GUI parts to work. Given that Mordante wants to tackle a rewrite of large parts of this, he will be our expert there as well as already being our area expert for the terrain engine.
Nils Kneuper (Ivanovic)
He is doing nothing special, he just does some "administrative work" like packaging fresh tarballs when it is time for them and works on setting up any kind of deadlines and timetables related to releasing. He has administrative powers in most areas, no matter if website, forum or IRC. Beside this he uploads translation updates, tries to communicate with the translation teams when it is required and translates a little bit himself every now and then. But in general he is not a real expert in anything, just has a look at things that come up and redirects people to the correct contacts.
Noy
Noy is an oddity among developers; he's got no coding skills whatsoever and possesses a limited understanding of computers, which is illustrated by his difficulty operating a Mac. Instead, Noy makes his contribution in gameplay and multiplayer design, drawing upon his background in social sciences research, military strategy and playing games online, to understand the effects of development on the playing community behavior. Along with Soliton, Noy is a useful conduit to discuss any issues in this area; just don't ask him about revising the level of randomness in the game.
Noyga
Another versatile developer, on the C++ side he doesn't concentrate on a particular area, did some tweaks to improve translations in some languages (like enabling the female forms for names in various place) but know quite well the C++ side of units, abilities and WML. On the WML side he's an expert.
Sapient
This developer started working on the GUI and widgets, but recently he focused more on improving the internal mechanics of the WML engine such as variable look-ups and filtering. Sapient is not very active anymore but he does come one IRC in the evenings (U.S.A.). He has touched-up many areas of the code in small ways over time, thus he has a good general knowledge of the C++ code and also has worked a little on some python maintenance scripts. He keeps an eye on the quality of incoming C++... especially if you plan on making any changes to GUI or WML, Sapient will be reviewing it closely and with a critical eye.
Shadow Master/ShikadiLord
He joined the development team very recently, but has enough knowledge to help newcomers with trivial questions about the code and/or the C++ language. His primary focuses are the various WML handlers, such as game events code. His knowledge of the WML language itself is also enough to answer most questions and solve most problems, but only if they are not related to multiplayer games. He also has some basic knowledge of the autotools machinery we use to configure Wesnoth for foreign computers.
Soliton
He knows our MP server setup best. Beside this he has already done a lot of work on the MP server himself. So he probably has most knowledge about it and, being one of our MP-developers, might provide important help from the perspective of the MP player community and what is needed there.
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.
zookeeper or Mythological or Rhuvaen
As our leading WML experts those are to be contacted when it comes to anything related WML problems since they know this stuff best. They do maintain most of the campaigns and improve them whenever they have a good idea for changes.
GSoC Student Applicant Ideas
This project idea uses Formula AI and Dynamic Scripting to create a tunable and adaptive AI.
This project implements Unit Behavioral Stances that are determinet by Search & Evaluation algorithms to determine a flexibile AI.