Application 2012
This article covers the organization application.
For information on how to apply as a student, please visit Ideas 2012#Your steps to apply
Google would like to know our answers to the following questions:
Our mission statement sounds as follows:
 It is written in Python.
We apply together with our engine FIFE1.
FIFE stands for Flexible Isometric Free Engine and is a cross platform game creation framework written in C++.
It provides you with the ability to create a game using Python interfaces.
FIFE also comes as a DLL or static library so you can use C++ as well.
The first commits to a repository of Unknown Horizons were made in October 2007, but the actual development started as a C++ project "OpenAnno" mid-2005 already.
Since then we have achieved a lot in terms of development and gameplay:
- Building a core development group and attracting many patchers2
- Releasing several highly playable releases of an open source real time strategy game
- Using only high quality media under terms of a free, open license
- Setting up an excellent infrastructure3 that helps to focus on actual development
- successfully introducing three students to open source development during Summer of Code 2011
Students now have the opportunity to work with this infrastructure and a grown development team while they will add and refine some very important features of Unknown Horizons like the multiplayer mode, Artificial Intelligence or the combat system.
Because these topics are very interesting, we hope that we can retain students after the Summer of Code and will put much effort into this.
FIFE on the other hand has several clients that base their games on it4, contributing improvements and feature requests alike.
Engine development thus helps many projects and not just one organization -- all three FIFE mentors know their code by heart and could come up with many own, concrete suggestions what to work on.
Several of our proposed ideas allow students to assign priorities on their own where we suggest some possible fields, but are very open to modifications on the student side.
We believe that practicing autonomous coding is more rewarding than working through a bunch of open tickets and feature requests in our tracker.
Code refactoring and optimization also is an important field in programming, so we hope to help students prepare for this while still having fun and motivation to continue contributing.
The FIFE ideas thus include refactoring, but never as the main task:
Instead, students will work together with engine clients and also implement new features which were not possible before the code polishing.
Why is your organization applying to participate in Google Summer of Code 2012? What do you hope to gain by participating?
Last year, the continuous success of another FOSS RTS game (Battle for Wesnoth) inspired us to apply for the program.
We were lucky enough to be accepted and to work with three bright, highly motivated students who exceeded the expectations we had by far.
Furthermore, our two mentor summit attendees returned from the awesome summit with a lot of ideas and suggestions as well as praise :-)
After discussing the ideas with the team and applying most of them, such as polishing and pruning of the important homepage and wiki parts, we saw the contributor amount to our project rise sharply.
The success of our students also dramatically increased the general development speed (measured by the amount of fixed tickets, to about 400% of the previous level).
From there on, it was clear that with our knowledge gained both through our own mentoring experience and those of all other mentors, we would love to again be part in another Summer of Code.
We hope to attract a few fresh coders to realize ideas which have been tossed around some time ago but were never tackled.
With interested students around, not only will we add more features, gameplay and fun to Unknown Horizons, but also find what we ourselves need to further improve in order to help new contributors and ease their start with us.
Unknown Horizons is already played by many people throughout all operating systems.
We hope to make open source gaming even more attractive by improving Unknown Horizons and taking it to a new level by participating in the Google Summer of Code -- just as the participation did last year.
Our interaction with the game engine project FIFE will also continue to improve since we offer ideas for interested students to look into the machine room, literally.
We believe that Unknown Horizons will benefit from these efforts as well as all other game clients of FIFE.
By proposing projects at the heart of the game engine we are able to supply interested developers with very challenging tasks in game development.
Did your organization participate in past Google Summer of Codes? If so, please summarize your involvement and the successes and challenges of your participation.
Yes, we have participated in 2011, where two students were working on Unknown Horizons and one on FIFE.
All projects were successful both considering the actual work done and also the goal of gaining new long-term contributors.
Of the three students we mentored during last summer, all are still participating on IRC, which is our main communication channel, and two still pushed new commits to our repositories in February alone.
Looking at the code progress, we now have a working AI as well as a combat system, as well as major performance improvements in FIFE.
The students' tasks in Unknown Horizons were mostly concerned with setting up a base system which has been thoroughly tested and shipped to our players in a release only a few weeks after the final evaluations.
This year, we look forward to having follow-up projects, where e.g. the AI would actively engage in combat and otherwise interact with the players in multiplayer mode as well as interesting projects to ease contributing content to Unknown Horizons without the need to edit actual code.
Regarding our main intention of attracting new team members and retaining them after the summer, we call the Summer of Code a huge success for the whole project.
Not only are our students still active and contribute, but also did we find a lot of possible obstacles and challenges for everybody interested in joining our project.
We were able to improve our "Get started with UH" guides in a lot of ways due to the feedback we received from students (not only those we could accept in the end, but also several other applicants)
and saw our contributor amount increase since last summer thanks to this.
On the scale of projects participating in the Summer of Code, we were still a rather small and new organization last year though, so figuring out the best approaches to mentoring was the major challenge we had to face during the coding period.
Since the whole team guided our students, communication worked well and we could focus on mentoring the students instead of mentoring their work only.
The students would send brief scrum-style mails several times a week with a summary of their current challenges and plans, based on which we would quickly notice something going off track, which fortunately didn't happen.
Attending the mentor summit was another huge success for two of our mentors (of course), but also for the remaining team since we got a lot of highly useful experience, knowledge and ideas which we applied and plan to apply should we be accepted again this year.
If your organization has not previously participated in Google Summer of Code, have you applied in the past? If so, for what year(s)?
We were accepted in 2011 and did not apply for an earlier instance.
not applicable.
In short:
- Code: GPL
- audiovisual content: CC-BY-SA 3.0
- special content: different other free licenses
In detail: http://github.com/unknown-horizons/unknown-horizons/blob/master/doc/LICENSE
http://wiki.unknown-horizons.org/w/Ideas_2012
Our mailing list for users and devs alike is found here:
http://lists.unknown-horizons.org/cgi-bin/mailman/listinfo/uh-user
Address to send to: [email protected]
Be however aware that not all developers regularly answer posts to it verbosely, the reaction time between question and a useful answer may be unnecessarily long. Visiting our IRC channel is a better idea: Even if nobody seems to be online, many developers read the (non-public) channel logs and come back to you if you stay around for a while.
#unknown-horizons on freenode
Does your organization have an application template you would like to see students use? If so, please provide it now.
http://wiki.unknown-horizons.org/w/Student_application_template
nihathrael
What criteria did you use to select these individuals as mentors? Please be as specific as possible.
From last year's experience, our mentors know they have to be ready to spend enough time with students to ensure they can work in a purposeful and effective way. When we discussed applying for GSoC again, our two main UH mentors both stepped up and signaled readiness. After asking our core engine developers about joining our application as they did last year, they also volunteered to look after one student.
As a short summary for both parts of our application: The Unknown Horizons mentors that we currently list as possible have worked on the game resp. the engine for years (and one of them excelled at last year's GSoC project). They added an overwhelming amount of features and fixed uncounted bugs. All of them also work together on several tasks or designs frequently, so they will continue to mutually exchange mentoring experience while the SoC projects go on.
On the FIFE side, prock and vtchill together are nothing less but the core development team of the engine. Various client developers and last year's SoC student of course also contribute features, but prock and vtchill always know what's going on.
They both have excellent connections to all game communities that rely on FIFE, so knowledge is shared amongst everybody rather than buried somewhere. Together they will be the most apt mentor team we could imagine for a FIFE project.
In general, everybody involved in the project will serve as mentor to a certain degree as we found out last year. Since our team is not too big, most developers know the basics of each field where students could ask questions in. We highly encourage our students to ask these on IRC (1 is a short overview that gives directions on whom to ask) and expect our developers to hang around there2, providing helpful answers. Since we are very active on IRC anyways, this has worked very well in the past.
We want that our students feel accepted and identify themselves with our organization. To achieve this, all SoC work will be merged into our master branch on a regular basis (at least once each two weeks). This will additionally lead to students receiving more helpful feedback because our developers review master more often than other branches -- and are known to word their comments in a friendly way. Seeing that we use the code our students gave them a lot of motivation to continue in the past, so we'd like to keep this.
So far, we had no serious trouble with GSoC students, but life still happens and we will actively try to counteract signs of disappearance. Our action plan:
First of all, nobody disappears without a good reason, especially if he or she put a lot of work and enthusiasm into applying for it.
We have weekly IRC meetings with the whole development team and tightly integrate our students into these. Each of them gets a time slot where new features worked on during the week are presented and we collect feedback1.
With this integration, we hope that we are able to notice if a student shows signs of having a serious problem.
If students do not attend two of our weekly meetings in succession, the mentors are encouraged to use the emergency contact information stored in the private application part for such situations2.
Should students ever toy with the idea of aborting all work on their idea, we will hold a private IRC meeting3 as soon as possible where student, mentor and organization admin try to find out what happened and how we can still continue.
3: There exists a secret, invite-only channel which is registered at freenode for this purpose by our organization admin to ensure privacy of this meeting
Our mentors are chosen from amongst the core development team that has worked on UH for years and always been within our reach. We trust their estimations in whether they have enough time to mentor participants or not.
Should there happen something unforeseeable, the project administrator is able to temporarily look after the mentee and put efforts into finding a replacement closely matching the previous mentor's experience and field of work as soon as possible. Our mentors volunteered to temporarily care for more students than they were assigned to in case of emergency. Additionally, our mentors organized at least one co-mentor on their own, so we will pair all students with two mentors.
To ensure this supervision quality, we attached great importance to only selecting ideas that could be guided by at least two of our regular mentors. This allows us to handle the temporary disappearance of a single mentor without substantial losses.
Our organization administrator himself is not directly mentoring a student. If he gets hit by a bus, we thus do not have to replace both a mentor and an admin. Of course, we still have our backup admin available who knows the ropes as well (both of us were org admins last year already).
What steps will you take to encourage students to interact with your project's community before, during and after the program?
The team ensures that our IRC channel on freenode stays as friendly to guests as it is now.
We provide an IRC webchat applet on our homepage1 and many developers have alerts configured that trigger if guest nicknames join -- there are however many players or users otherwise related to the project that also try to help everybody as much as they can.
Further on, our public mailing list uh-user is open to anybody who wishes to discuss questions concerning game or code design.
Most discussion happens on IRC though and is posted to the list and our wiki after something has been agreed on in consensus.
During the project, our students will introduce the changes they made to our community in the meeting each week, answering questions and collecting opinions. The meeting summaries are posted on our dev blog on the main homepage2 which serves as additional motivation to interact with our player community.
These steps are not something new to us but already taken for years now and thus we can say that it worked pretty well in the past.
Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here.
Battle for Wesnoth has been of invaluable help to us in providing guidance on how to structure a SoC application and which parts of infrastructure need to be set up.
They also gave us a lot of background information on the problems possibly arising and how Wesnoth dealt with these in the past.
Wesnoth gained a lot of experience over the last years and most of that holds true for us as well since we approximately work in the same field (RTS game development) -- I'm not sure we had seriously considered applying without their support.
But from what I can tell now, we have been prepared in an excellent way to undertake this exciting journey and as such look forward to be one of the new and small organizations which were attracted by this encouragement :)
Are you an established or larger organization who would like to vouch for a new organization applying this year? If so, please list their name(s) here.
Our project repository is found at http://github.com/unknown-horizons. It includes our source code as well as source files for graphics and audio content. Everybody can get the latest development version of UH running with a clone of the source code repo, but if you are interested in raw blender files for instance, our gfx repository is public as well.
If you are not familiar with git, check out our section about taking to it.
We believe that all development should happen in the master branch as long as it does not heavily affect usability of the game.
The reason for this as long as is that we from time to time ship new releases or weekly packages based on the master branch.
So if students have a task like creating a new GUI, they most probably want to do the first steps in an own (remote) branch and collect opinions on their progress there ;-)
Before our move to git, we used svn as source code management system. Because of this fact, trac was chosen as bugtracker years ago for its integration with svn.
Times changed but we still run trac together with a git plugin to keep the old tickets.
To be honest: trac improved over time, the git plugin works really well and some devs like its source code browser way better than the one github offers.
Trac also has built-in support for important points in time (milestones) and for grouping tasks and bugs where they belong (components).
All in all there are many useful features for project planning and management, so we will really make sure that students check out what we talk about here -- they are likely to also work with bugtrackers when working for other organizations or companies.
The developer wiki serves as Design Document and provides several cheatsheets together with e.g. documentation about the database and YAML scenario structure. It is not meant to be an official source of information since some articles can be outdated or under construction due to a specification with many discussions going on.
Because wiki platforms are well known and require little special skills to edit, we chose to manage our SoC applicants with a User Page in our dev wiki where possible.
As a starting point and to ensure creation of accounts, students will answer the public part of our question template there, introducing themselves and their project.
If you're not a developer or want to discuss aspects that are not strictly development related, our [http://forum.unknown-horizons.org/ forums] are a good place to post.
Be however aware that not all developers regularly check the forums, the reaction time between question and a useful answer may be unneceesarily long.
Visiting our IRC channel is a better idea, even if nobody seems to be online, many developers read the (non-public) channel logs and come back to you if you idle a bit.
We also allow forum posts without registration in our guest area there to help players who are not comfortable with IRC but still want to find solutions.
For the Summer of Code, students can also work with the forums to get to know other participants, their mentors and the team. Forums are especially helpful if there is a time zone difference which inevitably leads to certain phases of silence and reduces real-time communication.
c++, game_engine, opengl, optimization, sdl,
ai, ai_development, artificial_intelligence,
game, games, game_development, python,
graphical_user_interfaces, user_interface_design
Each mentoring organization is expected to provide:
- A pool of project ideas for students to choose from, publicly published by the mentoring organization as an [Ideas list](Ideas 2011):Ideas 2011
- An organization administrator to act as the project's main point of contact for Google: chrisoelmueller
- A person or group responsible for review and ranking of student applications, both those proposals which tie into the org's [Ideas list](Ideas 2012) and "blue-sky" proposals: organization administrator, all mentors, members of our dev team
- A person or group of people responsible for monitoring the progress of each accepted student and to mentor her/him as the project progresses: all [mentors](Mentors 2012)
- A person or group responsible for taking over for a student's assigned mentor in the event they are unable to continue mentoring, e.g. take a vacation, have a family emergency: organization administrator, all mentors, members of our dev team
- A written evaluation of each student participant, including how s/he worked with the group, whether s/he should be invited back should we do another Google Summer of Code, etc.: organization administrator, all mentors
In addition to these responsibilities, a mentoring organization should actively encourage each student developer to participate in the project's community in whichever way makes the most sense for the project, be it development mailing lists, idling in the project's IRC channel, participating in the project's forum, etc.
A truly successful mentoring organization will work diligently to ensure that as many of their students as possible remain active project participants long after the conclusion of the program.
