Difference between revisions of "SummerOfCodeIdeas"

From The Battle for Wesnoth Wiki
(→‎Addon server)
 
(305 intermediate revisions by 74 users not shown)
Line 1: Line 1:
−
This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):
+
{{SoC2014}}
 +
== I want to be one of your Google Summer of Code students, what should I do? ==
  
−
== I want to be one of your Google Summer of Code student, what should I do... ==
+
Welcome! Here is a quick list of things to do:
  
−
Here is a quick list of things to do to get you started
+
* '''MOST IMPORTANT:''' Submit your application to [https://www.google-melange.com Google] before '''March 21st'''.
−
* Create an account on gna.org
+
* '''MOST IMPORTANT:''' Join our IRC channel, '''#wesnoth-dev''' on irc.freenode.net ([http://webchat.freenode.net/ webchat]), and talk about your project and your application. We will not give formal interviews, but we will clearly favor people we have learned to know during the selection process. IRC is the main, mandatory communication medium for the Battle for Wesnoth Project; for the same reason, it's also a good idea to regularly read the [http://www.wesnoth.org/irclogs/2014/ IRC logs].
−
* Create an account on the wesnoth forum
+
* '''VERY IMPORTANT:''' Create a wiki page about your idea, using our '''[[SoC2014 Template of Student page|student proposal page template]]''' as base.
−
* 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
+
** To create a new page, enter the desired URL for the page in your browser's address bar, e.g. <code><nowiki>http://wiki.wesnoth.org/New_Page</nowiki></code>. (See also http://www.mediawiki.org/wiki/Help:Starting_a_new_page)
−
* Contact one of our SummerOfCode people (Ivanovic, Sirp, Boucman, Mordante) to have your forum nick marked as a Summer of code student
+
** Go into editing mode on the template page http://wiki.wesnoth.org/index.php?title=SoC2014_Template_of_Student_page&action=edit and copy the contents to your new page. '''DO NOT ACTUALLY EDIT ANYTHING IN THE TEMPLATE!'''
−
* Start a wiki page about your idea, add a link on this page
+
** Fill the questionnaire.
−
** Fill the questionnaire on this page
+
** Describe and explain your idea in as much detail as possible. Look at other student pages, and provide a timeline, milestones, and studies you've done.
−
** Detail your idea as much as possible, look at other students pages, and please give milestones and studies you've done
+
* If you haven't done so yet, create an account on [https://github.com/ GitHub]. ('''Required''' for pull requests and for granting you commit access to the main repository later on.)
−
* 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
+
* If you haven't done so yet, create an account on [https://gna.org/ Gna.org], where our [http://bugs.wesnoth.org/ bugs tracker] and [https://mail.gna.org/listinfo/wesnoth-dev developers mailing list] are hosted. ('''Recommended''' for submitting bug reports with a single identity, '''required''' for managing bug reports if you are granted commit access.)
 +
* If you haven't done so yet, create an account in the [http://forums.wesnoth.org/ Wesnoth.org forums], and tell a leader of the [http://forums.wesnoth.org/memberlist.php?mode=group&g=6644 Summer of Code group] or a forum administrator on the IRC channel to give it SoC group membership.
 +
** Forum administrators: Ivanovic, Noy, shadowm, Soliton, Turuk
 +
** SoC group leaders: AI, Crab, mordante/SkeletonCrew, thunderstruck, Trademark
 +
* Though not mandatory, it is '''highly advisable''' to take a look at the [[EasyCoding]] and [[NotSoEasyCoding]] pages and implement one of the proposed ideas ideas (or any idea of similar scope) so we can have an idea of how you work. Be sure to use your GitHub account when submitting pull requests so we know who it is coming from. You can also implement features from our [http://bugs.wesnoth.org/ bugs tracker].
 +
** This should give you a good idea what the Wesnoth source code is like and help you get used to our coding style as well.
 +
** When you implement something, also list it on your own page with a reference to the pull request.
 +
** You can also start working on your project and submit patches/prototypes related to it.
 +
* For working on Wesnoth you '''must''' be able to compile Git master. See our [[WesnothRepository|repository information page]] and the guide on [https://github.com/wesnoth/wesnoth/blob/master/INSTALL.md Compiling Wesnoth].
  
 +
== Information about our Project ==
 +
The information we provided Google with about our project can be looked up at the site [[SoC Information for Google]].
  
−
 
+
Also see the [[DeveloperResources|Developer Resources]] listing (linked from the [[Project]] page).
−
== List of Ideas for the Project (Suggestions from the wesnoth developers) ==
 
−
 
 
−
 
 
−
=== 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: [[WesnothFormulaAIBranch]]
 
−
 
 
−
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 ====
 
−
 
 
−
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 fameplay 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 ===
 
−
 
 
−
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 ====
 
−
The general idea of this project would be
 
−
* To study the current lobby,
 
−
* To develop ifeas 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 STL. 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 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 to make the creative process easier.
 
−
 
 
−
==== 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 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 ===
 
−
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 ====
 
−
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 ===
 
−
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.
 
−
 
 
−
==== General description ====
 
−
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 ===
 
−
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.
 
−
 
 
−
== Other info to provide for GSoC ==
 
−
==== Describe your organization. ====
 
−
The Battle for Wesnoth, or simply Wesnoth, is a free turn based strategy game with role playing elements designed in June 2003 by David White (Sirp). David currently works at Google.
 
−
 
 
−
The first stable release (1.0) was on October 2 2005, the latest stable release (1.4) was on March 8 2008.
 
−
 
 
−
* A turn­-based strategy game
 
−
* On a hexagonal board
 
−
* Role playing game style elements
 
−
* Single player and multiplayer modes
 
−
* Runs on a variety of platforms
 
−
* Highly customizable and 'moddable'
 
−
 
 
−
What makes Wesnoth stand apart from the other open source games are the following aspects:
 
−
 
 
−
* A large developer and player community
 
−
** two servers (stable and developement) with a usual minimum load of more than a hundred players
 
−
** more than two thousands downloads a day
 
−
* A mature project, but with active development and many improvements
 
−
* High quality artwork: both graphics and music
 
−
* Very well­-balanced by a tireless team of playtesters
 
−
* Fun, unique gameplay
 
−
* Even after five years of development, and a very solid, fun product has been created, there are still plenty of new developers, and the number of commits to SVN is still increasing
 
−
 
 
−
The general [http://www.wesnoth.org/wiki/WesnothPhilosophy Philosophy] of the game (both for gameplay and coding) puts an emphasis on simplicity. The core rules are meant to be learnt easily but provide interesting gameplay and diverse strategies.
 
−
 
 
−
On the other hand, Wesnoth scenarios provides a simple language to easily customize scenarios, which has lead to a huge modding community providing us with a wide amount of content.
 
−
 
 
−
* Advanced C++, with some use of Boost
 
−
* The Simple Directmedia Layer (SDL) libraries:
 
−
* SDL, SDL_net, SDL_ttf, SDL_image
 
−
* gettext for internationalization
 
−
* Python to allow scriptable AIs
 
−
* Otherwise, most of Wesnoth's technology is “home grown”:
 
−
** WML : the scripting language used to write scenarios
 
−
** FormulaAI : our AI developement language
 
−
 
 
−
* 2.1 million downloads via sourceforge.net, many more via various mirrors of Linux Distributions
 
−
* best rated game at the [http://www.happypenguin.org/list?sort=avg_rating linux game tome]
 
−
* game of the year 2007 at [http://www.linuxquestions.org/questions/2007-linuxquestions.org-members-choice-awards-79/open-source-game-of-the-year-610236/ linuxquestions.org]
 
−
* One of the top 20 rated projects on [http://freshmeat.net/stats/#rating Freshmeat] (currently 16th highest rating, and the highest rated game).
 
−
 
 
−
==== Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating?====
 
−
 
 
−
Most of our developers have particular areas of interest in which they work. Though they are efficient in their areas, there are other, presently uncovered, areas of the code with a need for improvements but a high barrier to entry for casual contributors.
 
−
 
 
−
If a student were dedicated to any of these uncovered areas, we believe that person could be brought up to speed relatively quickly and function as a peer of the existing developers.
 
−
 
 
−
By bringing new people in and allowing them to be 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 project has applied 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 project has applied 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 else was taken from content that was checked to be GPL.
 
−
 
 
−
==== What is the URL for your ideas page?====
 
−
Our main summer of code page 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 domains 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/.
 
−
 
 
−
in particular, all art developement takes place on the 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
 
−
 
 
−
* Basics
 
−
** Just write a small introduction to yourself.
 
−
** State your preferred email address.
 
−
** If you have chosen a nick for IRC and Wesnoth forums, what is it?
 
−
** Why do you want to participate in summer of code?
 
−
** What are you studying, subject, level and school?
 
−
 
 
−
* Experience
 
−
** What programs/software have you worked on before?
 
−
** Have you developed software in a team environment before? (As opposed to hacking on something on your own)
 
−
** Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?
 
−
** What development model would you use (e.g. keywords: V-model, XP programming, agile programming, iterative; with the help of prototyping, formal specifications, tests, etc).
 
−
** Open Source
 
−
*** Are you already involved with any open source development project? If yes, please describe the project and the scope of your involvement.
 
−
** Gaming experience
 
−
*** Are you a gamer?  If so...
 
−
*** What type of gamer are you?
 
−
*** What type of games?
 
−
*** What type of opponents do you prefer?
 
−
*** Are you more interested in story or gameplay?
 
−
*** Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.
 
−
 
 
−
We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.
 
−
 
 
−
* Communication skills
 
−
** Though most of our developers are not native English speakers, English is the project's working language.  Describe your fluency level in written English.
 
−
** Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.
 
−
** Do you give constructive advice?
 
−
** Do you receive advice well?
 
−
** Are you good at sorting useful criticisms from useless ones?
 
−
 
 
−
* Project
 
−
** Did you select a project from our list? If that is the case, what project did you select?
 
−
** If you have invented your own project, please describe the project and the scope.
 
−
** Why did you choose this project?
 
−
** Include an estimated timeline for your work on the project
 
−
** Include as much technical detail about your implementation as you can
 
−
** What do you expect to gain from this project?
 
−
** What would make you stay in the Wesnoth community after the conclusion of SOC?
 
−
 
 
−
* Practical considerations
 
−
** Are you familiar with any of the following tools?
 
−
*** Subversion
 
−
*** C++
 
−
*** Python
 
−
** Which tools do you normally use for development? Why do you use them?
 
−
** What programming languages are you fluent in?
 
−
** What spoken languages are you fluent in?
 
−
** At what hours are you awake (please specify in UTC)
 
−
** Would you mind talking with your mentor on telephone / internet phone?
 
−
 
 
−
* Detailed answer (optional, but writing skill is a good predictor of ability to work on a programming team, so you will improve your chances by responding to this).
 
−
** Write a small essay (750-1000 words or more) explaining why you want to participate in a Wesnoth GSoC project. You can use the above questions as guides, but feel free to throw in more information if you feel it is relevant.
 
−
** What is your perception of 'open source'? Briefly explain what you think of the whole 'open source' concept, how you discovered open source, what you expect to gain/experience by participating in an open-source project. (Answer separately or as part of above mini-essay)
 
−
** What motivates or inspires you to write programs and develop software?
 
−
 
 
−
 
 
−
 
 
−
 
 
−
 
 
−
''''to be completed''''
 
−
 
 
−
==== Who will be your backup organization administrator? Please include Google Account information.====
 
−
David White (davewx7@gmail.com)
 
−
 
 
−
==== Who will your mentors be? Please include Google Account information.====
 
−
 
 
−
David White (davewx7@gmail.com)
 
−
 
 
−
Jeremy Rosen alias Boucman (boucman2|ATTT|gmail.com)
 
−
 
 
−
Mark de Wever aka Mordante (mordante.wesnoth|ATTT|gmail.com)
 
−
 
 
−
Jörg Hinrichs alias YogiHH (joerghh.hinrichs|ATTT|googlemail.com)
 
−
 
 
−
==== What criteria did you use to select these individuals as mentors? Please be as specific as possible.====
 
−
 
 
−
Our first criterion was that all the people had to be volunteers. According to other open source projects, being a SoC mentor takes a lot of time and the person has to be ready to spend quite some time with the student.
 
−
 
 
−
Dave is the project leader and one of the most knowledgeable in C++. He has also written the Formula AI code which we plan to develop via the SoC. He is well known in our community for formulating simple but effective explanations for complicated topics, and has good design intuition. The growth of Wesnoth demonstrates his capacity to get other developers to work together and keep them involved in a thriving community.
 
−
 
 
−
Boucman is one of the oldest active developers around. He has rewritten the whole animation engine and made it an easily pluggable system allowing artists to easily specify exactly how they want the units to appear. He also started many community oriented projects like the [http://wiki.wesnoth.org/UnsortedContrib Art Contribution] section of the wiki (now automated) and the [http://wiki.wesnoth.org/ReferenceWML WML Reference Manual]. He is responsible for dispatching and sorting the patches at http://patches.wesnoth.org and has created the new developer process we currently use.
 
−
 
 
−
Mordante is one of the most active developers on our IRC channel. Not only has he done preliminary studies and coding in multiple areas that are candidates for Summer of Code ideas, he also is one of the coders with the best overview of the Wesnoth code. A large part of his work involves refactoring polishing existing code. Next to that he's very active with fixing bugs which leads him to all areas in the code base.
 
−
 
 
−
YogiHH has been with the project for more than two years. He did a major refactoring to the gameplay engine and worked quite a bit on the multiplayer code. He also has been a professional trainer for C/C++, Java and C# for many years. Right now he works in a project where he serves as a mentor for a junior developer.
 
−
 
 
−
All other developers listed in the ideas page are the leading capacities we do have for the respecting areas. Have a look at our list of people who to contact for which regards. In general all our developers will mentor all students. That is, questions should just be asked in our IRC channel, where basically every developer who has an idea can directly answer.
 
−
 
 
−
When choosing the mentors, we have kept in mind that most developers can answer most technical questions, and we have chosen people that are well known for interacting with new-comers/external developers and can provide general guidance and design advice, more than people with specific technical knowledge.
 
−
 
 
−
==== What is your plan for dealing with disappearing students?====
 
−
The first thing to do is to avoid this situation altogether.
 
−
 
 
−
Wesnoth is a game, and as such has lots of developers that are not coders. In particular, artists are well known in the Wesnoth community for being very sensible about criticism and our community is used to people being sensible to critics.
 
−
 
 
−
We will try to choose students that accept criticism and are able to filter constructive criticism from useless one. The Wesnoth developer community is used to judging people according to these criteria and the special title we are going to give to applicants will allow us to easily spot any such problems and discuss them before they grow out of control.
 
−
 
 
−
If a student disappears, his mentor will be in charge of recontacting him to see what is going wrong (available time, tension with other developers, with members of the community etc...). Depending on the actual problem, the mentor and the student will have to agree on possible ways to defuse the problem.
 
−
 
 
−
If a student disappears completely and there is no way to get back to him, there is little the project can do except salvaging whatever can be salvaged from the code (the students will have SVN write access, so most of the work will be committed either to trunk or to a specific branch) and find a core developer to take on the job. This will probably be slower and less effective for the project, but it's the best we can do.
 
−
 
 
−
==== What is your plan for dealing with disappearing mentors?====
 
−
 
 
−
All our mentors are long time developers that volunteered for the job, so we don't expect that to happen. We took the time to ask other former GSoC projects about the workload needed to be a mentor, and our mentors accepted the job knowing the amount of work it involved.
 
−
 
 
−
 
 
−
However, should it happen, we would continue to mentor as a developper community the student until we find a new "official" mentor to take on the job.
 
−
 
 
−
==== 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.
 
−
 
 
−
We also plan to give a special forum title to any students. This will allow all forum members to tell them apart from normal users and give them read/write access to the developer only forums. This will also allow us to quickly spot any problem they might have interacting with the player community. We have a very mature developer community, but our player community is made of all sort of people of all age and education, and it can be rough at time.
 
−
 
 
−
==== What will you do to ensure that your accepted students stick with the project after GSoC concludes?====
 
−
 
 
−
Since our community has a history of having developers easily and quickly join, we expect the student to be a full-fledged developer quite fast (probably a little after the end of the bonding period).  
 
−
 
 
−
Thus there will be no "end of GSoC" transition. At the end of the Summer of code we expect the student to be responsible for the part he developed, and to continue taking care of it, like other developers are responsible for their part.
 
−
 
 
−
''''TO BE COMPLETED''''
 
  
 
== People to bug on IRC ==
 
== People to bug on IRC ==
−
Everybody feel free to edit/correct his entry!
+
We have prepared a list of people with their areas of competence. This should give you an idea of which areas those people can help you with. Of course you should always ask in the IRC channel first, but these are the most likely people to be able to help you.
−
 
 
−
=== 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 ===
+
[[SoC People to bug on IRC]]
−
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) ===
+
== List of Ideas for the Project (Suggestions from Wesnoth developers) ==
−
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 ===
+
{| border=1
−
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.
+
| '''Note:''' This list of ideas is automatically generated from the ''Description'' section of pages in the ''Summer of Code 2014 Idea'' category. '''DO NOT TRY TO EDIT THIS LIST BY HAND - IT WON'T WORK.''' Instead, create a new page using the '''[[SoC_Ideas2014_Template|GSoC idea page template]]'''.
 +
|-
 +
| '''Note:''' To add a student page, create a new page copying the contents of the '''[[SoC2014 Template of Student page|student proposal page template]]'''.
 +
|}
  
−
=== Noyga ===
+
{{#dpl:
−
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.
+
|noresultsheader=''No ideas yet. Why not create one?''<br/>
 +
|category=Summer of Code 2014 Idea
 +
|include=#Description
 +
|mode=userformat
 +
|format=,,<br/>,
 +
|nottitlematch=SoC_Ideas2014_Template
 +
}}
  
−
=== Soliton ===
+
==Student proposals not submitted to Google==
−
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.
+
{{#dpl:
 +
|resultsheader=''There are %PAGES% student proposals which were not submitted to google''<br/>
 +
|oneresultheader=''There is 1 student proposal which was not submitted to google''<br/>
 +
|suppresserrors=true
 +
|noresultsheader=''All the proposals were submitted to google''<br/>
 +
|category=Summer of Code 2014 Student Page
 +
|nottitlematch=SoC2014 Template of Student page
 +
|include=#IRC, #SoC Application
 +
|includenotmatch= ,/google/s
 +
|mode=userformat
 +
|format=,,[[%PAGE%|%TITLE%]]<br/>,
 +
}}
  
−
=== YogiHH or Piotr Cychowski (cycholka) ===
+
==Student proposals submitted both to the wiki and Google==
−
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.
+
(Marked by hand. If your proposal is not here, don't panic; check Google's site instead, and ping us if necessary.)
  
−
=== zookeeper or Mythological or Rhuvaen ===
+
{{#dpl:
−
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.
+
|resultsheader=''There are %PAGES% student proposals which were submitted both to the wiki and Google''<br/>
 +
|oneresultheader=''There is 1 student proposal which was submitted both to the wiki and Google''<br/>
 +
|suppresserrors=true
 +
|noresultsheader=''All the proposals were submitted to Google''<br/>
 +
|category=Summer of Code 2014 Student Page
 +
|nottitlematch=SoC2014 Template of Student page
 +
|include=#IRC, #SoC Application
 +
|includematch= ,/Submitted to google/s
 +
|mode=userformat
 +
|format=,,[[%PAGE%|%TITLE%]]<br/>,
 +
}}
  
−
[[Category:Future]]
+
==Results from Google acceptance==
 +
The list of proposals accepted by Google will be available on April 21st.

Latest revision as of 20:09, 15 May 2020

This page is related to Summer of Code 2014
See the list of Summer of Code 2014 Ideas


Contents

I want to be one of your Google Summer of Code students, what should I do?

Welcome! Here is a quick list of things to do:

  • MOST IMPORTANT: Submit your application to Google before March 21st.
  • MOST IMPORTANT: Join our IRC channel, #wesnoth-dev on irc.freenode.net (webchat), and talk about your project and your application. We will not give formal interviews, but we will clearly favor people we have learned to know during the selection process. IRC is the main, mandatory communication medium for the Battle for Wesnoth Project; for the same reason, it's also a good idea to regularly read the IRC logs.
  • VERY IMPORTANT: Create a wiki page about your idea, using our student proposal page template as base.
  • If you haven't done so yet, create an account on GitHub. (Required for pull requests and for granting you commit access to the main repository later on.)
  • If you haven't done so yet, create an account on Gna.org, where our bugs tracker and developers mailing list are hosted. (Recommended for submitting bug reports with a single identity, required for managing bug reports if you are granted commit access.)
  • If you haven't done so yet, create an account in the Wesnoth.org forums, and tell a leader of the Summer of Code group or a forum administrator on the IRC channel to give it SoC group membership.
    • Forum administrators: Ivanovic, Noy, shadowm, Soliton, Turuk
    • SoC group leaders: AI, Crab, mordante/SkeletonCrew, thunderstruck, Trademark
  • Though not mandatory, it is highly advisable to take a look at the EasyCoding and NotSoEasyCoding pages and implement one of the proposed ideas ideas (or any idea of similar scope) so we can have an idea of how you work. Be sure to use your GitHub account when submitting pull requests so we know who it is coming from. You can also implement features from our bugs tracker.
    • This should give you a good idea what the Wesnoth source code is like and help you get used to our coding style as well.
    • When you implement something, also list it on your own page with a reference to the pull request.
    • You can also start working on your project and submit patches/prototypes related to it.
  • For working on Wesnoth you must be able to compile Git master. See our repository information page and the guide on Compiling Wesnoth.

Information about our Project

The information we provided Google with about our project can be looked up at the site SoC Information for Google.

Also see the Developer Resources listing (linked from the Project page).

People to bug on IRC

We have prepared a list of people with their areas of competence. This should give you an idea of which areas those people can help you with. Of course you should always ask in the IRC channel first, but these are the most likely people to be able to help you.

SoC People to bug on IRC

List of Ideas for the Project (Suggestions from Wesnoth developers)

Note: This list of ideas is automatically generated from the Description section of pages in the Summer of Code 2014 Idea category. DO NOT TRY TO EDIT THIS LIST BY HAND - IT WON'T WORK. Instead, create a new page using the GSoC idea page template.
Note: To add a student page, create a new page copying the contents of the student proposal page template.


AI: Improve AI by implementing global attack/retreat decision

Page for the idea: SoC_Ideas_AI_Global_strategy

The Wesnoth AI works by making local decisions about moves and attacks. Teach it to determine if it's worth to fight offensively or defensively in a given situation.


There are 5 submitted student proposals for this idea

Aditya Pande - Global AI for Battle of Wesnoth

I propose to implement global AI using a combination of idea of Quiescence search on game tree with alpha beta pruning along with a few heuristics to make it possible to actually solve this complex game. Also this approach requires an evaluation scheme for the same.

The idea of using Quiescence search here is different than that in chess engines. Here my idea is to reduce the average branching factor for each choice made by considering the ones which do not affect the game drastically (hence called quiet moves). In this case the braching factor for a unit can be given by 

braching factor=Number of attacking moves + Number of Acquire village moves + 2

The 2 represent all Quiet moves based on retreat or charging forward towards enemy. As the quiet moves above do not affect the game drastically they shall be decided based on heuristics and here I plan to only consider the greatest retreat/charge.

The idea behind my approach is based on "Wesnoth can be treated much like a continuous game, because many positions tend to be very similar to each other. Additionally, unlike discrete board games, it is not common that a very small wrong move in Wesnoth is disastrous."

The aim of the whole approach is to simplify the game complexity using few heuristics and then use approach of negamax to select a good overall global move(not the best because of the simplication done) . Also the number of attacking moves and number of acquire village moves has to be reduced to actually keep the problem solvable. (Read all the heuristics for the same in Technical description).

I also plan to divide the whole problem into independent parts whenever possible. Let me give an example, lets say that the AI is under attack on 2 fronts but there is (currently) no relation between the 2 as to say that the AI units involved can't interact(i.e they are too far and can't 'get close' to each other in next turn). My idea is that by doing such division and focusing on solving each problem individually sharply reduces the complexity of the problem.

Lastly I plan to adopt some ideas from Fuzzy Logic, FSM and Behaviour trees to improve the current model I propose.
See Aditya Pande Global AI for more information.

Vahen_Improve_AI

I would like to improve the AI by implementing Global attack / retreat decision.

Elements : Anything around the unit that can cause a change to the behavior

Behavior : Determine what the enemy is going to do based on the elements.

Deliberation : Does the best move depending on the behavior previously set .

To do so I will use probality theory to determine what is best move to do.
See Improve AI for more information.

Arveanor Global AI

Give an ai player a set of potential objectives to pursue such as taking a village, killing an enemy, defending a village etc. Also give each ai different behavior modes based on the information they have access to. i.e. fight aggressively, fight defensively, fight cautiously etc. The ai would, depending on it's current behavior mode pursue the objectives more or less rigorously depending on how they align with the current behavior.

The behaviors and objectives would not necessarily mix strongly with recruitment, however a similar system to what would analyze which behavior to be used would also be able to inform recruiting patterns. Obviously certain unit types and a large amount of certain terrain hexes give good reason to favor certain units in recruitment, of course gaining vision and taking outlying villages (i.e. AI global objectives) would play into recruitment in terms of recruiting faster units.
See SoC2014 arveanor ai for more information.

Kevin Xi - AI: Improve AI by implementing global attack/retreat decision

A rule-based expert system style solution utilizing dynamic programming to make decisions
See SoC2014 kevin AI for more information.


See SoC2014 vorobeez AI for more information.


Improve the automated collection and display of multiplayer game data

Page for the idea: SoC_Ideas_Multiplayer_Data_Analysis

Multiplayer games are currently archived. This includes lots of interesting and potentially useful data, including recruits, deaths, number of turns and other things. The only way to access this information currently is parsing the WML one save file at a time. Additionally, which side(s) won the game is only recorded in some cases. We would like to record which side(s) won or lost (for as many games as possible) and then display useful information about these games for balancing and feedback purposes.

There is 1 submitted student proposal for this idea

Sachith Seneviratne - Multiplayer Data Analysis Proposal

Although Multiplayer games are being archived currently, no data is saved regarding the winner(s). Recording and presenting this information would allow for easier balancing and feedback for content creators. Specifically, this project will add a means by which players can indicate who won, as well as parse the saved data and store in a database as much useful information regarding the games as possible.


See GSoC sachith500 Proposal for more information.


SDL2

Page for the idea: SoC_Ideas_SDL2

The Wesnoth project uses the SDL library. Last year, a new major version (2.0) of SDL was released. This version of the library has better support for mobile devices like the Android and the iPhone. This project involves helping porting Wesnoth from SDL 1.2 to 2.0.

There are 5 submitted student proposals for this idea

Ben Kenawell - SDL2 Project Proposal

Descriptive Summary of Proposal
I would like to work on moving the event and input handling from SDL 1.2 handling to SDL 2.0. To accomplish this I will be considerate of the many differences between the versions including how text input is handled and the differences in event handling. In performing both these tasks, I will be aware of a possible Android or iOS port (since I would love to see that myself), so that my code will perform as smoothly on mobile operating systems as it already does on desktop OSes.

First Level Sections
One major change in event handling is how the thought process behind the keyboard works. The keyboard has become like a many buttoned controller, instead of text inputs. This will be a major change I will work on, in order to make Battle for Wesnoth more keyboard-layout independent. Mouse input will remain similar, except for the mousewheel which, with better support in SDL 2.0, will be more useful for scrolling around the screen. This change may also help with two-finger scrolling across a screen where the comptuer reports this as a mousewheel, ultimately aiding in the creation of a mobile port. Event handling will have similar ideas in mind. While the actual code has not changed very much, those differences will be taken care of as well as a new style of event handler for certain important events, i.e. events that affect the state of the app (open/closed) will be monitored more closely so that progress may be saved. I have taken this into consideration along with the other event handler changes in order to deal with the "garbage collector," which is the nightmare of mobile operating systems. I fear that in the near future (at least with Windows machines), that the garbage collector's presence might make an appearance in desktops, and this measure would increase the longevity of my changes as well as more easily enable mobile ports.
See Dragonofair0/GSoC2014 project idea for more information.

Juan Miguel Ruiz Ladrón, new SDL version

Project description I want to upgrade Wesnoth's SDL 1.2 version to SDL 2.0 version. Specifically the event handling system.


First-level The main problem to move Wesnoth to SDL 2.0 version is the event handling system. I would work with desktop version of the game, improve keyboard input to select actions, units, etc. Also, develop the mobile version of the game, i'm working with Android, using LibGdx framework, i think, it's similar to SDL 2.0 version for handling events and more.
See Juan Miguel Ruiz Ladron/GSoC2014 Proposal for more information.

lipkab - SDL2 transition

I propose to help with the SDL2 transition.

I'd like to work on implementing hardware accelerated rendering for Wesnoth and enabling it for the map/unit rendering system.
See SoC2014 lipkab SDL2 for more information.


See SoC2014 SDL2 DrawingTransition for more information.

TODO: Copy this page and write "your name - proposal title" in this h4 section

TODO: Write a small (1-4 sentences) description of your proposal here.

TODO: Add more first-level sections to detail your proposal
See SoC2014 SDL2 stevedes for more information.


SpriteSheet

Page for the idea: SoC_Ideas_SpriteSheets2014

Wesnoth uses thousands of images, each of them stored in separate files. It would be more efficient to store multiple images in a single file. In order to make that possible, the Wesnoth engine needs to be adapted to allow this change.

There are 2 submitted student proposals for this idea

ALourenco - SpriteSheet

I am proposing the development of a SpriteSheet compability, so the number of assets of Wesnoth can be decreased and it's coding gets cleaner. Instead of having a lot of pictures, we can have, for example, just one per character with all animations needed. It works like a chess board where you can acess the previosly separated pictures in it's respective position. Since Wesnoth uses SDL, we can use OpenGL directly and easily handle several textures from only one SpriteSheet.
See GSoCSpriteSheetsALourenco for more information.

Aishiko GSOC 2014 SpriteSheets

My proposal is to take the current functions for drawing sprites and move it to allow for spritesheets, while hiding any of the changes from campaign designers. It should allow for the seemless intergration of spritesheets and allow for a period of conversion from multiple files to sheets.
See SpriteSheetApplicationSAB for more information.


UMCD

Page of the idea: SoC_Ideas_UMCD_2014 Improving and completing the new add-ons server, UMCD (User-made Content Daemon).

There is 1 submitted student proposal for this idea

Spoffy - UMCD Extension Proposal

I intend to complete and extend the User Made Content Daemon produced by Trademark during GSoC 2013. This means implementing the basic functionality (Uploading, downloading addons, etc) in a secure manner. After this, I would continue on to extend it by adding administration tools, refactoring code, adding build scripts, adding cross-platform support (in principle), and other things (probably!). Outlined on this page is an in-depth proposal

More to come as I fill this out.
See SoC 2014 Spoffy Finishing and Enhancing the UMCD for more information.


Game Engine: Unify SP and MP

Page for the idea: SoC_Ideas_Unify_SP_and_MP_2014

Wesnoth has lots of user made content, but some of it works only for either singleplayer or multiplayer. To solve this, some of the engine's singleplayer and multiplayer code paths need to be unified and extended.

There are 2 submitted student proposals for this idea

RiftWalker - Game Engine: Unify SP and MP

Currently, certain add-on content works only in single- or multi-player games. The purpose of this project is to ensure that all user-made content works across game modes by unifying and extending the code paths that handle configs for single- and multi-player games. This will be achieved by making SP a special case of MP as described by Zaroth.

  • To begin with, I will implement the current single player campaign creation through the multiplayer code path, changing as little as possible.
  • Once I've sorted out all the problems that may arise from this, the door will be open to a host of potential new features and improvements which I will implement according to demand from the community.


See SoC2014 RiftWalker Unify SP MP for more information.

youngoli - Unify SP and MP

Abstract: This proposal is intended to unify the separate code paths responsible for handling configuration files in single player and multiplayer. This will allow content that previously would only work in multiplayer to work in singleplayer as well.
See SoC2014 youngoli UnifySPandMP for more information.


Other: Your own ideas

Page for the idea: SoC_Ideas_Your_Own_Ideas_2014

Suggested skills: C++ (depends on the project).

There are 9 submitted student proposals for this idea

Dugi - Campaign Wizard

I've seen on the forums that people frequently ask for campaign wizards and such and when they're told that there is no such thing, they struggle usually with the basics like writing a proper _main.cfg file. There is a project named Eclipse Java plugin, but it's not a part of wesnoth, only a few people know about it and it is basically just a text editor adapted to work with WML. This project is to make a campaign wizard, incorporated into the game, that would allow creating simpler campaigns in an intuitive way, without having to read or write source codes.

The idea is to create a campaign making GUI that would be accessible from the map editor or some other menu, and would allow making campaigns without writing any codes, just clicking and writing some dialogues, unit names and such. It wouldn't allow doing all the things that can be done with WML, just the more common things.

It would contain several windows or tabs, one for the entire campaign's properties (setting up the basic properties), one for the scenarios (setting up the basic properties, like assigning maps, sides' properties, then adding commonly used events) and something for adding custom units (basic properties, assigning images to attacks and animations).

It would need to use slightly different data structures than usual wesnoth because campaigns need including files and macros, preprocessor defines and similar things that are usually parsed out when reading the files. I think that they could be created through inheritance and a few modifications (especially a special tag for macros and a property to make it depend on difficulty).

The map editor can do a plenty of things around scenarioWML, so it might be used to create scenarios after some editing, but at least some sort of ActionWML editor would need to be added (supporting basic tags like message, creating units, killing units, moving units).

This is what the main window of the campaign editor might look like (sorry for not caring much about the layout's appearance, but that's not the point): 1Y6Og6S.png

Further expansions (if time remains or to be done in another summer) may include support for ifs, variables and objects in ActionWML, AMLA, custom abilities and weapon specials in UnitWML, maybe possible alternative scenario paths.
See Dugi's Campaign Wizard for more information.

GoblinThing Campaign Wizard

--LARGE MODIFICATIONS TO PROPOSAL UNDERWAY, INPUT WELCOME--

Due to my particular skill set, working on the eclipse plugin (the UMC editor) would be ideal. Once I manage to acquire a copy of the source code, the project will probably go something like this:

1) (main task) check the wizards that are supposed to exist within the plugin. Make any modifications necessary to keep it up-to-date with WML, then make any changes, additions, or modifications that might be useful to the users. Wizards should include a scenario wizard and campaign main wizard, as these are the most painful to build by hand. Additional components may include a unit wizard, event wizard, and anything else I can think up. Unfortunately, I can't be more specific at this time.

2) (additional task) Check with the original author (Timeotei, I beleive,) and see if there are any things he wanted to include from GSoC 20(11? 12?) and try to implement them. It would be nice to contribute to the original vision.

3) (additional task) Once all other possible tasks have been completed, start a forum thread in the "wml" section and see if anyone has a unique/much needed addition. If they do, I can work on that...

4)...and if they don't, ask the devs for more work. IF my proposal is selected, I see GSoC as a job, and will work like a rabid horse.


I'm still working at convincing eclipse to load the UMC editor properly, and will post additional (much-needed) details as soon as I can.

Thanks for reading, 

 -goblinThing


See GoblinThing Wizard for more information.

TODO: Copy this page and write "your name - proposal title" in this h4 section

TODO: Write a small (1-4 sentences) description of your proposal here.

TODO: Add more first-level sections to detail your proposal
See GSoCMindblank for more information.

Improve Random Map Generator

The aim of this proposal is to create better random-generated maps for singleplayer and multiplayer game using new elements and options

Using different "biomas" in the same map (not only desert for example) to make more "unique" scenarios, also, including other elements like peninsulas so the general form of the map changes
See Improve Random Maps for more information.

AI: Improve AI by implementing global attack/retreat decision

Page for the idea: SoC_Ideas_AI_Global_strategy

The Wesnoth AI works by making local decisions about moves and attacks. Teach it to determine if it's worth to fight offensively or defensively in a given situation.


There are 5 submitted student proposals for this idea

Aditya Pande - Global AI for Battle of Wesnoth

I propose to implement global AI using a combination of idea of Quiescence search on game tree with alpha beta pruning along with a few heuristics to make it possible to actually solve this complex game. Also this approach requires an evaluation scheme for the same.

The idea of using Quiescence search here is different than that in chess engines. Here my idea is to reduce the average branching factor for each choice made by considering the ones which do not affect the game drastically (hence called quiet moves). In this case the braching factor for a unit can be given by 

braching factor=Number of attacking moves + Number of Acquire village moves + 2

The 2 represent all Quiet moves based on retreat or charging forward towards enemy. As the quiet moves above do not affect the game drastically they shall be decided based on heuristics and here I plan to only consider the greatest retreat/charge.

The idea behind my approach is based on "Wesnoth can be treated much like a continuous game, because many positions tend to be very similar to each other. Additionally, unlike discrete board games, it is not common that a very small wrong move in Wesnoth is disastrous."

The aim of the whole approach is to simplify the game complexity using few heuristics and then use approach of negamax to select a good overall global move(not the best because of the simplication done) . Also the number of attacking moves and number of acquire village moves has to be reduced to actually keep the problem solvable. (Read all the heuristics for the same in Technical description).

I also plan to divide the whole problem into independent parts whenever possible. Let me give an example, lets say that the AI is under attack on 2 fronts but there is (currently) no relation between the 2 as to say that the AI units involved can't interact(i.e they are too far and can't 'get close' to each other in next turn). My idea is that by doing such division and focusing on solving each problem individually sharply reduces the complexity of the problem.

Lastly I plan to adopt some ideas from Fuzzy Logic, FSM and Behaviour trees to improve the current model I propose.
See Aditya Pande Global AI for more information.

Vahen_Improve_AI

I would like to improve the AI by implementing Global attack / retreat decision.

Elements : Anything around the unit that can cause a change to the behavior

Behavior : Determine what the enemy is going to do based on the elements.

Deliberation : Does the best move depending on the behavior previously set .

To do so I will use probality theory to determine what is best move to do.
See Improve AI for more information.

Arveanor Global AI

Give an ai player a set of potential objectives to pursue such as taking a village, killing an enemy, defending a village etc. Also give each ai different behavior modes based on the information they have access to. i.e. fight aggressively, fight defensively, fight cautiously etc. The ai would, depending on it's current behavior mode pursue the objectives more or less rigorously depending on how they align with the current behavior.

The behaviors and objectives would not necessarily mix strongly with recruitment, however a similar system to what would analyze which behavior to be used would also be able to inform recruiting patterns. Obviously certain unit types and a large amount of certain terrain hexes give good reason to favor certain units in recruitment, of course gaining vision and taking outlying villages (i.e. AI global objectives) would play into recruitment in terms of recruiting faster units.
See SoC2014 arveanor ai for more information.

Kevin Xi - AI: Improve AI by implementing global attack/retreat decision

A rule-based expert system style solution utilizing dynamic programming to make decisions
See SoC2014 kevin AI for more information.


See SoC2014 vorobeez AI for more information.


See Jchb AI Global Strat for more information.

neonosos - Improve AI by global world analysis

My goal is to contribute Wesnoth AI by improving AI players with global-analysis skill. This skill makes AI players able to not only react on local impulses (such as attack or presence of another player), but also to make deeper-planned strategies.

Economical aspect
The AI player should be able to decide which enemy to attack according to his economical needs. It means, that if AI player needs gold, he should attack player with high gold resources.
War-strategy aspect
AI player should not attack if it's not appropriate. Why to attack player, that is much stronger than the AI? Maybe some kind of indirect (for example economical, diplomatic) attack would be more appropriate.
Planning for future aspect
Should I attack the nearest enemy's village? Why not to attack the further one, cutting of the escape from the nearest village?


See Neonosos for more information.

Daniwa: Improve the AI's Attack and Retreat decisions.

Abstract: Implement a process that would allow the AI to make correct decisions in regards to attack and retreat. It will be based off probability focused on current metagame habits.

Proposal: The focus of my implementation is not on outputting the optimal result in every case but instead will aim at mirroring a player like decision. The goal for this is to foster and develop good game decision making in new players and prevent bad habits. Ideally, the AI should act correctly but unpredictably (which is technically impossible) and be able to be a training aid.
See SOC2014 Daniwa Ai for more information.

Zubin Kapaida: Improve AI by implementing global attack/retreat decision

I believe that the key to making a good AI bot is to keep your ideas clear and simple. One must evaluate the gravity of the situation using the given parameters and accordingly act offensively or defensively.

Sometimes it is more beneficial to risk one unit’s death or even sacrifice a few and perform the attack, the tricky part is to figure out when. In this game “Battle of Wesnoth” several factors affect the decision making like terrain, time of day (i.e. day / night), special abilities, enemy units’ status etc.

Positioning is a crucial part, ideally we should try to position every unit such that it has backup from other units and is away from critical danger, also positioning in terrain that would support maximum defense if ideal. Next we must try to exploit the enemies weakness, e.g. if the enemies unit has no defense in range, then we should attack that unit with heavy range units. Also while attacking we must try to surround the enemy from multiple directions and then synchronize the attack.

For implementation I propose use different parameters like aggression, depth etc. Here aggression parameter would specify how much the AI values its own units as opposed to that of the enemies. Depth parameter indicates the number of units that will attack a single opponent unit. protect_leader (radius) parameter, it is used to target any enemy unit which comes within the specified radius around the leader, and many others will be needed.

The value of aggression will determine whether to play offensively or to retreat. Next I propose the use of decision tree to determine the value of aggression. The decision tree will be a binary tree and in each node we check some condition like terrain, time of day etc. which affects our strategy. So we start from the root node and after validating all the conditions we end up on a leaf node. The value of aggression will be determined on the basis of the leaf node we end up on.

As mentioned earlier positioning is very important. Positioning of units is different for aggressive and defensive approaches. To plan out the positioning we will use threat map. A threat map is a 2D array which describes the level of danger on every position. While building a threat map, the positioning of the enemy units, type of units and other factors are taken into account.
See SoC2014 Zubin AI for more information.

ykanarev - AI task implementation

TODO: Write a small (1-4 sentences) description of your proposal here.

TODO: Add more first-level sections to detail your proposal

TODO: Set the proper Category in the top of the page ([[Category:XYZ]]), to match the one you'd like to apply for, from the list on the main summer of code page (e.g.: [[Category:SoC_Ideas_AI_Global_strategy]]). Otherwise your idea will be marked as a new one.
See YKanarev AI impl for more information.


Student proposals not submitted to Google

There are 25 student proposals which were not submitted to google
adityapande Aditya Pande Global AI
dragonofair0 Dragonofair0/GSoC2014 project idea
Dugi Dugi's Campaign Wizard
goblinThing GoblinThing Wizard
sachith500 GSoC sachith500 Proposal
TODO: Put only your IRC nickname in there. In case of alternate nicks, separate with commas.

Example contents for this section (without the quotes): "user" "user1, user2" GSoCMindblank
ALourenco GSoCSpriteSheetsALourenco
Vahen Improve AI
demiurgos Improve Random Maps
jchb Jchb AI Global Strat
juanmi91 Juan Miguel Ruiz Ladron/GSoC2014 Proposal
neonosos Neonosos
spoffy SoC 2014 Spoffy Finishing and Enhancing the UMCD
arveanor SoC2014 arveanor ai
Daniwa SOC2014 Daniwa Ai
Kevin_Xi SoC2014 kevin AI
lipkab SoC2014 lipkab SDL2
RiftWalker SoC2014 RiftWalker Unify SP MP
zerophase SoC2014 SDL2 DrawingTransition
stevedes SoC2014 SDL2 stevedes
vorobeez SoC2014 vorobeez AI
Youngoli SoC2014 youngoli UnifySPandMP
ZubinKapadia SoC2014 Zubin AI
Aishiko, Aishiko_laptop SpriteSheetApplicationSAB
ykanarev YKanarev AI impl

Student proposals submitted both to the wiki and Google

(Marked by hand. If your proposal is not here, don't panic; check Google's site instead, and ping us if necessary.)

All the proposals were submitted to Google
Aditya Pande Global AI
Dragonofair0/GSoC2014 project idea
Dugi's Campaign Wizard
GoblinThing Wizard
GSoC sachith500 Proposal
GSoCMindblank
GSoCSpriteSheetsALourenco
Improve AI
Improve Random Maps
Jchb AI Global Strat
Juan Miguel Ruiz Ladron/GSoC2014 Proposal
Neonosos
SoC 2014 Spoffy Finishing and Enhancing the UMCD
SoC2014 arveanor ai
SOC2014 Daniwa Ai
SoC2014 kevin AI
SoC2014 lipkab SDL2
SoC2014 RiftWalker Unify SP MP
SoC2014 SDL2 DrawingTransition
SoC2014 SDL2 stevedes
SoC2014 vorobeez AI
SoC2014 youngoli UnifySPandMP
SoC2014 Zubin AI
SpriteSheetApplicationSAB
YKanarev AI impl

Results from Google acceptance

The list of proposals accepted by Google will be available on April 21st.

Retrieved from "https://wiki.wesnoth.org/index.php?title=SummerOfCodeIdeas&oldid=65625"
This page was last edited on 15 May 2020, at 20:09.