Difference between revisions of "SummerOfCodeIdeas"

From The Battle for Wesnoth Wiki
m (I want to be one of your Google Summer of Code students, what should I do...)
m (Student proposals not submitted to google)
Line 54: Line 54:
 
  |include=#IRC, #SoC Application
 
  |include=#IRC, #SoC Application
 
  |includenotmatch= ,/google/s
 
  |includenotmatch= ,/google/s
 +
|mode=userformat
 +
|format=,,[[%PAGE%|%TITLE%]]<br/>,
 +
}}
 +
 +
=Student proposals submitted both to wiki and google=
 +
(marked by hand)
 +
{{#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 2012 Student Page
 +
|nottitlematch=SoC2012 Template of Student page
 +
|include=#IRC, #SoC Application
 +
|includematch= ,/Submitted to google/s
 
  |mode=userformat
 
  |mode=userformat
 
  |format=,,[[%PAGE%|%TITLE%]]<br/>,
 
  |format=,,[[%PAGE%|%TITLE%]]<br/>,
 
}}
 
}}

Revision as of 16:57, 27 March 2012

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



Contents

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 at this time:

  • MOST IMPORTANT Submit your application to Google till April 6th.
  • MOST IMPORTANT Join the irc channel (#wesnoth-dev on irc.freenode.net) and talk about your project and your appilication. We will not give formal interviews, but we will clearly favor people we have learned to know during the selection process (basically communication via IRC is mandatory for our project! it is the main way of "every day communication" for Wesnoth. For the same reason, it's also a good idea to regularly read the IRC logs.).
  • VERY IMPORTANT Create the wiki page about your idea (Make a copy of the student proposal page template: SoC2012 Template of Student page):
    • Fill the questionnaire.
    • Detail your idea as much as possible, look at other students pages, and please give timeline, milestones and studies you've done
  • If you haven't done so yet, create an account on gna.org (required for committing later on)
  • If you haven't done so yet, create an account on the wesnoth forum, and tell an admin of the forum or leader of the group on the IRC channel to mark it as a GSoC Student account (admins/group leaders are: Boucman, Crab, fendrin/Fabi, Ivanovic, Mordante/SkeletonCrew, Noy, shadowm/shadowmaster, Sirp/Dave, Soliton)
  • 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. When you implement something, also list it on your own page with a reference to the patch. This should give you a good idea what the Wesnoth sourcecode is like and will provide a good start to getting used to our coding style, too. You can also start working on your project and submit patches/prototypes related to it

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 link (from the Project page).

People to bug on IRC

We have prepared a list of people with their "area of competence". This is to give you an idea on which areas those people can be of help for you. Of course you should always just ask in the IRC chan, but those are the most likely ones to answer questions in the respective area. And here is the list:

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 Summer of Code 2012 Idea category. DO NOT TRY TO EDIT THIS LIST BY HAND - IT WON'T WORK. INSTEAD, CREATE A NEW PAGE WITH THE 'Soc Ideas2012 Template' template.
NOTE: to add a student page, create a new page based on copy the student proposal page template: SoC2012 Template of Student page):


Addon Server [1]

Page for the idea: SoC Ideas Addon Server 2012

The goal of this project is to write a new addon server for Wesnoth from scratch.

There is 1 submitted student proposal for this idea

Ivan Savenko - Addon Server

The goal of this project is to write a new add-on server for Wesnoth from scratch. Original draft in S­­V­­N (latex): http://svn.gna.org/viewcvs/wesnoth/trunk/doc/design/

Will be written in C++, networking part - boost::asio. From existing codebase I'm going to use WML parser (class "config") and forum integration (class "fuh" aka "forum user handler")
See SoC2012 Ivan Addon Server for more information.


AI: Implement a 'total defense' strategy [12]

Page for the idea: SoC Ideas AI Defense Strategies 2012

AI in wesnoth's is good at killing things but is bad at defending. Therefore we are forced to make it attack at 2:1 odds. This is the single biggest limiter of the AI skill at the moment. To solve that, we need to teach the AI to defend.

There are 8 submitted student proposals for this idea

Andriy Andriychuk - "Total defence" strategy

The idea is to group own troops so they are in advantageous position and get less damage.
See Avrilfanomar for more information.


See Kripsi for more information.

Sanka Darshana - "Implement a 'total defense' strategy"

The AI will decide the best movements considering the resources available, enemy positions and their types, enemy distribution and etc... The generated movements will be decided on the values of the each troop. As an example, a shaman will be more important if there are more troops with low health, and Archers if there are troops with health. So the AI will determine which actions to take depending on a list of variables in the game environment
See SankaD for more information.

Geoffrey Hart - Maximizing Utility

A good offense is made by identifying an opponents vulnerabilities and exploiting them. As such, a good defense is made by reducing the number of weak spots. Since there is no perfect unit and all have their own imperfections, the idea is send them out in groups of units that compliment each others strengths and weaknesses. This will allow them to rearrange themselves in a way most suitable to handle nearby enemies. Since the number of predictive steps the AI can make is limited, it can become "surprised" rather easily. Therefore, it's a good choice to maximize utility and the ability to be flexible in order to handle these surprises. Then, within action-packed skirmishes, raw processing power can be brought to bear more effectively.
See SOC - Geoffrey Hart for more information.

Christopher Conway - Defensive AI

My goal is to develop an AI which is capable of “total defense” behavior, as opposed to the current aggressive AI. It would allow for the AI to function in scenarios like controlled retreats, unit escort, or holding a given area while minimizing unit loss.
See Soc2012 Borgrumm Defensive AI for more information.

Conor Nevin - Implementing a Total Defense AI

Implementing a defensive mode of the AI, so that it is able to heal units whilst holding ground against an advancing enemy.
See Soc2012 cnevin92 Total Defense AI for more information.

Nikolay Agafonov - Line Defence Strategy

The idea of this strategy is to stick together the troops and create the defencive line. All the units should be put on hexes where they would be on the defensive in most effective way. THere would be some kinds of AI's behaviour (full retreat, banking, passive attack etc.) depending on on game factors.
See SoC2012 LineDefenceStrategy for more information.

Ed Kim - Total Defense AI

Often, the best defense is a good offense. In Wesnoth, lacking either can get you slaughtered. It is particularly important that the AI learn not only to consider immediate gains and losses off a linear formula, but to take other considerations into account, especially some foresight into human reactions and macroscopic army flux. Similar to a chess engine, if the AI could learn to take "next move" heuristics into account as well as consider positional strategies such as defensive formations (line, square) by taking unit relationships into account, the AI would become a much more versatile and formidable foe.


See SoC2012 Yokipi Total Defense AI for more information.


AI: Make lua AI development and usage easier [2]

Page for the idea: SoC Ideas AI Lua AI Usage 2012

We have the capability to write lua ai scripts in lua. However, we need to improve the infrastructure and make their use easier:

- add a way to debug lua code
- reduce the number of boilerplate code required to get lua ai running
- add missing AI-related functions and fix bugs.

There are 2 submitted student proposals for this idea

Dmitry Kovalenko(Nephro) - Further Lua

Simplify LuaAI
Right now, the LuaAI system is in a state, where it can be used for artificial intelligence system development for Battle for Wesnoth campaigns, but it's usage is quite complicated and requires effort to get the system off the ground and make it run. To simply to launch a campaign with an empty LuaAI(by empty, I mean, not doing anything) a UMC developer is required to write a couple dozens of lines of code(not even mentioning the bugs that he will encounter on the way). While it seems, that we could simply hide the boilerplate code in a template or behind a macro, the situation is a bit more sophisticated(Later I will describe that in more detail). Instead of running away from this problem, I will work towards an elegant solution, creating an effective back-end system, and a clean user development environment.
See SoC2012 Nephro for more information.

Tyrannodogg - Make lua AI development and usage easier

At the moment the parts, which make a lua AI, are scattered around several WML Entities, resulting in a load of boilerplate code.

My approach is to shift more parts of the functionality into lua code, in a way that simple scripts can handle all steps necessary.

This includes wrapping the current default AI for lua usage.

I will also provide scripts for logging and further debugging.


See SoC2012 Tyrannodogg Make lua AI developement easier for more information.


AI: Refactor recruitment algorithm [5]

Page for the idea: SoC_Ideas_AI_Recruitment_2012

We need to refactor existing wesnoth's recruitment algorithm to:

  1. support recruiting with multiple leaders.
  2. support per-leader recruit/recall lists.
  3. support easy limiting of recruitable units.
  4. analyze map terrain better
  5. recruit units that are more useful
  6. improve counter-recruiting strategies.
  7. improve recruiting for AI-playable campaigns where AI has to not spend all the gold.

There are 4 submitted student proposals for this idea

Aline Riss Recruitment Proposal

For the moment, AI recognize only one leader even if he has more. Moreover, the recruitment algorithm is very basic. So we can set the list of possible amelioration below:

  • support recruiting with multiple leaders
  • support per-leader recruit/recall lists.
  • support easy limiting of recruitable units.
  • analyze map terrain better
  • recruit units that are more useful
  • improve counter-recruiting strategies.
  • improve recruiting for AI-playable campaigns where AI has to not spend all the gold.

In order to treat these problematic, I have highlight two points which will be my principals axes for this project and will be treat separately :

  • The placement of leaders
  • The recruitment algorithm

Each point are, at begin, independent for each other.

First, I will treat the recruitment algorithm which is the principal problem of this project. It's only in a second part that I will treat the placement problem.
See GSoC Akihara Proposal for more information.

Kseniya Buraya - Refactoring AI Recruitment

The project is to improve current AI recruiting system. I will develop and implement these options:

  • To recruit with a lot of leaders instead of one
  • To consider the terrain type where the possible battle will be
  • To consider enemy and allied units together as to create great counter-unit mix
  • To provide the scenario editor an option to choose recruiting strategy ("defensive", "agressive", etc.) and to set limits on particular units


See SoC 2012 HappyKsuh AI Recruitment for more information.

Talbot Pierre - Refactor Recruitment Algorithm

The current recruitment algorithm is based on a WML recruitment pattern which specify the recruitable units. Apart for scout, no real strategy is established because most of the units are chosen randomly from this pattern list.

I'll dedicate my summer around three axes:

  • Multiple leaders: We must manage a list of leaders and free keeps, to affect each leader to a keep and change it if needed (because it's too far from the battle...). AI should choose where an unit (on which castle) will be recruited to be more efficient, taking into account the number of enemy units and their weaknesses.
  • Recruiting better units: The units must be chosen for a specific purpose such as getting a village, fighting a specific unit, protecting another... AI should be able to keep in mind the original purpose of an unit to take further decisions. By the way, this design should be discuss with the community and the other GSoC participants because it has a large impact on the entire AI.
  • WML parameterisation: The recruitment pattern will be improved to allow scenario editors to be more specific on which units should be recruited.


See Soc2012 Talbot Pierre Refactor Recruitment Algorithm for more information.

Paolo De Luca - Refactoring recruitment algorithm

Refactoring recruitment algorithm as stated in the proposed ideas. I think those points are quite enough yet. However I would consider to detail what I've intended for "recruit units that are more useful" for I suppose it's highly connected with the rest of AI playstyle. Different behaviour based on

  • current map;
  • AI mission objetives: chase, retire, kill specific units;
  • initial Time of Day;
  • distance from enemy;
  • allies (which will repeat the above points if it's an AI);
  • current and future gamestyle ( aggressive/defensive) MUST include the fact that AI have to switch between them;


See Soc2012 Teugon Refactor Recruitment Algorithm for more information.


AI: teach the AI to play Wesnoth's mainline campaigns [3]

Page for the idea: SoC Ideas AI Scenario Objectives 2012

We want the AI to be able to play campaigns, both on its own and as a ally for a human player. There are some things that are frequently required in campaigns :

  1. move a unit to location
  2. keep a unit alive
  3. keep an ally alive
  4. keep as much money and high-level recalls as possible
  5. do a proper recall
  6. protect units close to level up better.
  7. improve interaction of the player with AI allies.
  8. if you almost lost, try to make it possible for an ally to save you (by retreating the leader and critical units, for example)

This should be coded in lua (so there might be need to expand low-level lua AI capabilities), because we want the resulting list of behaviors to be scriptable and modifiable by scenario editors.

A proper test would be to let the AI complete all the mainline campaigns.

There are 4 submitted student proposals for this idea

Yigit Demirag : Development of AI to Play Mainline Campaigns in Battle For Wesnoth

Battle For Wesnoth is a great game to feel a war especially in Linux platform. Mainly, I can teach AI to play Westnoth's mainline campaings while it can interact user well.I want to develop its AI and put in opportunities of any kind of AI and machine learning algorithms such as supervised and unsupervised learning.

I am planning implementing feasible logical and reasoning algorithms which suitable for this. Decisions trees and inductive learning again, if it is suitable, are good to code in the game. But the most important part is playing and feeling how it works once than I can fill the necessary parts with the help of any algorithm we can apply.
See Artemius23 for more information.

Kevin Wyckmans - Teach That AI!

As stated on the idea page I want to extend the lua capabilities and implement the necessary code to allow the AI to finish the main Wesnoth campaigns. On top of this it should be able to this in a more or less optimal way, that may or may not be specified by the user.
See SoC2012 Fristi Teach That AI for more information.

Thomas Martinet - AI: teach the AI to play Wesnoth's mainline campaigns

As stated in the description, I propose to develop an AI able to complete the campaign alone or in collaboration with a human player.
See SoC2012 Hankerspace AI Campaigns for more information.

Philipp Battenberg - AI: teach the AI to play Wesnoth's mainline campaigns

Well, what the title says, which includes some AI improvements in general.
See SoC2012 TorminaTor AI Campaigns for more information.


Improve wesnoth's engine to allow better transitions between scenarios [1]

Page for the idea: SoC_Ideas Multiplayer Engine Refactoring 2012

We have a piece of code which links scenarios together. We need to improve the quality of that code (the code is rather messy at the moment) and we need to allow fun things to happen between scenarios, - like 'changing from singleplayer to multiplayer or back again, changes of difficulty level, changes to recall lists and player sides, etc). This code would interact with the new GUI2 dialogs which would allow the players to select 'what to do next' in a better way. An example of usage: after completing a campaign scenario, a 'big interactive map' might appear on a user screen and the player (or players) would select who plays next. This would replace the current 'assign players to sides' dialog, as well, allowing other parameters of 'next scenario' to be customizable.

There are 2 submitted student proposals for this idea

Anja Keicher - Improve wesnoth's engine to allow better transitions between scenarios

The idea is to clean up playcampaign.cpp and make loading/saving multiplayer campaigns more stable and less error prone. The code that handles transitions between scenarios should also be improved to make transfer of gold, units and recall lists easier for campaign designers. Other functionality, such as changes to difficulty between scenarios and interaction with GUI2 dialogs could also be added.
See SoC2012 Ayne Multiplayer Engine Refactoring for more information.

Nicholas Colclasure - Improve wesnoth's engine to allow better transitions between scenarios

I will clean up the code which dictates scenario transition and alter it to allow for more sophisticated transitions.
See SoC2012 Valectar for more information.


Implement a particle engine in the animation engine [4]

Page for the idea: SoC Ideas Particle Engine 2012

A particle engine allows to draw pixel per pixel where each pixel's position is given by a piece of code or a mathematical fomula. This is used to display interesting physical phenomena like water flow, explosions or fire

The aim of the project is to add such an engine within the animation engine and, if time permits, within the terrain engine.

A good understanding of the animation engine will be needed, but the particle engine will fit quite nicely in the existing structure

for performance reasons the formulas will probaly have to be given in Lua, but other approches could be interesting

there will probably be some needs to go into the wesnoth-SDL infrastructure for the display part

googling for "particle engine" and "particle engine SDL" should provide lots of groundwork for writing proposals


There are 3 submitted student proposals for this idea

Alexandru Busila - Particle Engine

Abstract: I will be improving on the current animation and terrain engine (though I don't see why they are separate) by adding an extension to it. This extension will be in the form of an interface that contains all the rendering info for each frame (for the particle object) and will use SDL to do its rendering internally. This class will have programmable parameters that will be used through Lua.
See GSoC Chopper Particle Engine for more information.

Naman Gupta - Particle Engine

I’m going to be implementing particle engine into existing animation engine. Since Wesnoth current infrastructure uses SDL. I’d be using SDL to make my particle engine. I’m not sure but it’s going to be slow as SDL isn't really designed for particle. I’ll optimize it or Use OpenGL instead.
See Naman22 for more information.

Justas Tomkus - Particle Engine

Implementing particle engine in a library-like fashion, using existing game's graphic functionality and SDL library. Final version of this engine would allow to use it anywhere on map with other drawing functions, given required init is done.

In addition to simple pixel drawing, I am ready to implement version where small alpha transparent images are blitted for particles. Color transitions for particles wouldn't be a problem either.
See SoC2012 Bloodycoin Particle Engine for more information.


Whiteboard: Refactor the backend [1]

Page for the idea: SoC Ideas Whiteboard Backend Refactoring 2012

Improve the whiteboard's (the wesnoth action-planning system) backend code by refactoring the data structure which holds the planned actions. Also refactor the verification and mapbuilding processes by combining them, and use this single new process to cache as much data as possible to avoid redundant lookups. You can also propose other simplifications.

Produce complete unit tests to cover all operations on the new planned action storage and the new combined mapbuilding/verification.

Document this new backend, explaining your design approach and including all diagrams necessary for the reader's understanding.

Finally, do exhaustive playtesting and bugfixing involving devs and community members to make sure the whiteboard is fully reliable.

There are 2 submitted student proposals for this idea

Étienne Simon - Whiteboard backend polishing

My project is to make the Whiteboard code cleaner and to redesign small parts of it to speed it up. The global design of the Whiteboard won't be changed a lot, each part will be reviewed individually. I'm not only planning to improve the Whiteboard backend, but also to document the overall design and each part of it as well as to write a wide variety of test to improve its stability. Moreover, I'll factorise action handling outside of the Whiteboard so that the same code will be usable in all Wesnoth.
See Ejls/GSoC 2012/Whiteboard Backend Refactoring for more information.

John Gamboa - Whiteboard Backend Refactoring

There is a lack of optimization and consistency between the mapbuilder and the validator. These two classes big "entities" are intended to be integrated in one only mapbuilder-validator. Since the validator asks for the information available in the mapbuilder frequently, this should provide more efficience and solve the consistency problems.

In a 4 months based approach, a very preliminar cronogram shall be:

  • integrate the mapbuilder and the validator - 2 months
  • test, bugfix and document the changes - 2 month

Initially, I can't give have a better calendar.
See Soc2012 vaulttech refactor the backend for more information.


Whiteboard: Multiple Chance-to-kill calculations and interface polish [3]

Page for the idea: SoC Ideas Whiteboard Multiple CTK 2012

The whiteboard (the wesnoth action-planning system) allows you to plan several attacks on a single unit. Wesnoth already shows the player his chances to kill an attacked unit in a 1v1 fight in the battle dialog: reusing the existing code already used by the AI for this purpose, extend the dialog to present to the player total kill chances taking into account all successive planned attackers.

In addition, the whiteboard interface still has some outstanding bugs or incomplete features and usability issues. Identify as many of those problems as possible and propose ways to solve them (see details for some ideas).

Finally, do exhaustive playtesting and bugfixing involving devs and community members to make sure the whiteboard is fully reliable.

There are 2 submitted student proposals for this idea

Sandy Carter - Whiteboard: Organic Multiple Chance-to-kill preview and attack.


See Bwrsandman Whiteboard: Multiple Chance-to-kill calculations and interface polish for more information.

Angel Guevara - Whiteboard: Multiple Chance-to-kill calculations

Using the whiteboard feature a user can set several units to attack a single enemy unit but currently there is no way for the game to show you what are the chances to kill that enemy unit after all the attacks. The idea is to create a 'planned attack' dialog which would show the chance-to-kill (and, potentially, allow to reorder the attacks from within the dialog then recalculate the chance to kill taking into account wesnoth specials and abilities (like slow, illuminate and leadership).
See SoC2012 Multiple CTK Calculations for more information.


Make your own ideas [4]

Page for the idea: SoC_Ideas_Your_Own_Ideas2012

We would like to consider the ideas on the above list, and not self-proposed ideas. Exceptional proposals might be considered, however. 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.


There are 2 submitted student proposals for this idea

Nikolay Agafonov - Chatrooms for Battle for Wesnoth

My proposal is to make message system much more comfortable for looking and useful without changing current sending mechanism. It would be implemented through the separate chat window which would be looks like IM-clients (like Pidgin, Miranda etc.). In this window you can make the converstions with anyone on the server with any number in one time.
See SoC2012 chatrooms for more information.

Angel Guevara - Social Network Integration with Battle for Wesnoth

The wesnoth users will be given the option to integrate their forums accounts with their social networks permitting the game to send information to their networks about their games, profile and replays to games they played. This integration will be customizable and optional.
See SoC2012 SocialNetworkIntegration for more information.


Student proposals not submitted to google

There are 5 student proposals which were not submitted to google
Artemius23, Artemius Artemius23
Avrilfanomar
Bwrsandman Whiteboard: Multiple Chance-to-kill calculations and interface polish
Ejls/GSoC 2012/Whiteboard Backend Refactoring
Akihara GSoC Akihara Proposal
GSoC Chopper Particle Engine
Kripsi
Naman22
SankaD
SOC - Geoffrey Hart
SoC 2012 HappyKsuh AI Recruitment
SoC2012 Ayne Multiplayer Engine Refactoring
SoC2012 Bloodycoin Particle Engine
Soc2012 Borgrumm Defensive AI
SoC2012 chatrooms
c_nevin92 Soc2012 cnevin92 Total Defense AI
SoC2012 Fristi Teach That AI
SoC2012 Hankerspace AI Campaigns
SoC2012 Ivan Addon Server
SoC2012 LineDefenceStrategy
SoC2012 Multiple CTK Calculations
SoC2012 Nephro
SoC2012 SocialNetworkIntegration
Soc2012 Talbot Pierre Refactor Recruitment Algorithm
Soc2012 Teugon Refactor Recruitment Algorithm
TorminaTor SoC2012 TorminaTor AI Campaigns
SoC2012 Tyrannodogg Make lua AI developement easier
SoC2012 Valectar
vaulttech Soc2012 vaulttech refactor the backend
SoC2012 Yokipi Total Defense AI

Student proposals submitted both to wiki and google

(marked by hand) There are 25 student proposals which were not submitted to google
Artemius23
avrilfanomar Submitted to google Avrilfanomar
bwrsandman Submitted to google Bwrsandman Whiteboard: Multiple Chance-to-kill calculations and interface polish
ejls  Submitted to google Ejls/GSoC 2012/Whiteboard Backend Refactoring
GSoC Akihara Proposal
Chopper Submitted to google GSoC Chopper Particle Engine
Kripsi Submitted to googleKripsi
naman22 Submitted to google Naman22
SankaD Submitted to google SankaD
ghart2010 Submitted to google SOC - Geoffrey Hart
HappyKsuh Submitted to google SoC 2012 HappyKsuh AI Recruitment
Ayne Submitted to google SoC2012 Ayne Multiplayer Engine Refactoring
bloodycoin, S_arms, bloodyGP Submitted to google SoC2012 Bloodycoin Particle Engine
Borgrumm Submitted to google Soc2012 Borgrumm Defensive AI
nagafono Submitted to google (withdrawn) SoC2012 chatrooms
Soc2012 cnevin92 Total Defense AI
Fristi, Fristii, Fristilus Submitted to google SoC2012 Fristi Teach That AI
hankerspace Submitted to google SoC2012 Hankerspace AI Campaigns
IvanSav Submitted to google SoC2012 Ivan Addon Server
nagafono Submitted to google SoC2012 LineDefenceStrategy
Faryshta Submitted to google SoC2012 Multiple CTK Calculations
Nephro, neph Submitted to google SoC2012 Nephro
Faryshta Submitted to google (withdrawn) SoC2012 SocialNetworkIntegration
trademark Submitted to google Soc2012 Talbot Pierre Refactor Recruitment Algorithm
Teugon Submitted to google Soc2012 Teugon Refactor Recruitment Algorithm
SoC2012 TorminaTor AI Campaigns
Tyrannodogg,tyrannodogg Submitted to googleSoC2012 Tyrannodogg Make lua AI developement easier
Valectar Submitted to google SoC2012 Valectar
Soc2012 vaulttech refactor the backend
Yokipi, HelloIRC Submitted to google SoC2012 Yokipi Total Defense AI