AddonServer

Me

account names:

gna: giebfried

forum: giebfried

irc: giebfried

preferred email: andrewgiebfried@gmail.com

Introduction

Hi, I'm Andrew Giebfried and I'd like to participate in Summer of Code primarily to learn first hand how programs are written in a group environment. In addition, working for GSoC will help fulfill some of my academic program's "Work Term" requirements. Currently, I am in first year engineering with the intent of going into computer engineering.

Experience

I have worked on many of my own small to medium-sized programs on various things. I have only worked on individual projects so far. This will be my first time participating in Google Summer of Code. I am not involved with any open-source projects so far.

I am a bit of a gamer, most of the games I find myself playing mostly turn-based strategy games with a few real time strategy games as well. I find game play crucial, but the storyline is still very important. I've played Wesnoth for awhile, probably 2 years. I play single player - mostly with the campaigns but I've also played some multiplayer maps versus the AI as well.

I take advice very well and can discern good advice from useless advice.

• Programming Languages
  • Java (over 3 1/2 years of experience)
  • C++ (over 2 years, but I haven't made very large programs with it)
  • Python (over 2 1/2 years, but I haven't made very large programs with it)

I have two years of AP Com Sci and a year of Independent Study in Computing in high school where I used Java. For a post AP-exam project I developed a simple graphical game one year and a very crude IDE for Java. I currently am taking a required class in basic programming in C++. I learned Python in my spare time. In my independent study, I studied drag and drop, networking, the implementation of the math library, and I partially made a simple paint program similar to MS paint.

• Miscellanea
  • Linux - I've used Linux for over 2 years
  • S­­V­­N - I am very new to this.
  • Terminal - I know my way around.

For this project I would use the Iterative and Incremental development model.

Idea

I intend to work on the suggested project:SoC_Ideas_Addon_Server. In this project, I plan to update the existing server code for strong integration with WesCamp and use certain WML tools on content. For the client side, I plan to make the addon server GUI more informative to the user as well as simple and straight-forward to use. I also plan to make updates simple to notice for the client. Map Packs, Eras, etc. would be shown in separate categories from campaigns and easier to download and use for the client.

I plan to spend about half of my time on the server side and half on the client side. For the server side, I will also spend about half of that time on WesCamp work and the WML tools work. On the client side, I plan to work on functionality first and then enhance the GUI. For the GUI I plan to redesign the current screen

Client side

For the client side I think the way the data is presented is not intuitive for the user. The current client in the does not inform the user of the type of download (i.e. campaign, Era, map pack) except by the name of the file. In addition it does not notify the user if they already have the addon. The age of the addons is also missing from the data; the date is helpful to see how new the content is. The Addons also can only describe their usability by version number; the author(s) cannot say how usable the campaign is. The remove addon feature is distant from the rest of the client gui. I would like to split the addons into two sections on the same window; one for existing downloads and the other for potential downloads. The existing downloads section will have an upgrade option if a newer version of an addon is detected. Upgradeable addons will have some sort of emphasis to show that a newer version is available. It will also include a remove option in case the user wants to remove the addon. The type of addon will be shown by either a by color code or placement. All of the downloads will contain the currently implemented information, but also show the date the addon was uploaded. In addition, a tooltip (or a dialog perhaps) will have a short description of the state of the addon (i.e. "completed" or "done first 3 scenarios", etc.) The stand-alone client will show the same data, but in a non-graphical way.

Server side

According to the original idea, the server is in need of improvement. It needs to integrate with WesCamp more than it currently does and it needs to run python as well. I plan to modify the existing server, which is written in C++. Although one of the server's requirement is to run python code, the Python code can easily be embedded into C to fulfill this requirement. Although not much of a change, I would like to rename the "campaign server" in the code to a more correct "Addon server" for correctness and clarity. Since there will be campaigns on the server in the old format, there will be some tool to convert them into a new format to easily interact with the client.

Translations

The translations will be in a separate file from the rest of the addon. When the user downloads UMC they will download the the translations of choice and the rest of the addon.

The client will have a "get translation option" for each addon which will allow the user to add or delete a translation for th addon they chose. When the user downloads an addon, the client will also download the translation for the user's current language setting. If the user decides to change his or her language in the main menu, he or she will receive a prompt asking if they would like to check for translations for all of the downloaded UMC.

The server will have a cron job to get the newest translations from WesCamp. Also, when a user updates his or her campaign, the pertinent information will go to Wescamp for the translators to work on.

Timeline

• Initial Planning (now-ish to first week or so at most)
  • Go over the wiki and read the Developer Information
  • Try implementing an Easy Coding ideas to get a feel for S­V­N, the code
  • Brush up on my Python skills, I need to look at the libraries some more.
  • Study the existing Addon Server (some more)

As per YogiHH's suggestion the first 3 iterations of my project:

Iteration 1 - initial planning:

• requirements:
  • determine feature set
  • changes in protocols
  • how to integrate WesCamp & WML tools
  • plan out client (GUI already mostly explained above)
• analysis & design:
  • study the requirements, lightly

Iteration 2 - elaborate on server & client

• requirements:
  • how to integrate WesCamp & WML tools (more in depth than before not completely; this is just to make iteration 3 easier)
  • format of UMC saved on server for ease of WesCamp's and WML tools' use.
  • enable python client to get addons in the new format

analysis & design:

• • new UMC format
  • converting to new format
  • server
• implement:
  • above
• test:
  • use client to get new-format UMC from server
  • get translations together and separately from UMC
• evaluate
• deploy:
  • python client
  • new UMC format
  • server still needs more work

Iteration 3 - WesCamp & WML tools

• requirements:
  • server integration with Wescamp
  • server integration with WML tools
• analysis & design:
  • study WesCamp some more
• implement:
  • integration with WesCamp
  • integration with WesCamp
• test:
  • see if server sends/receives translations
  • see if WML tools do their job
• evaluate
• deploy:
  • server

later: work on gui for client, as explained earlier. I'll have to study the new GUI system around here as well.

I plan to finish the first iteration early on, at most early week 2. I plan to spend equal time on the two next iterations, but iteration 3 will probably take less time than I expect, assuming I did adequate research in iteration 2.

Why?

I chose this project because it covers many different areas of programming. It incorporates networking, and GUIs, both of which I have some experience already. Also, I feel like this is an important part of Wesnoth that might be overlooked at times since it isn't directly involved with gameplay. After the GSoC ends, I plan to stay with the community; my appreciation for Wesnoth and the friends I will make will keep me in the community.

Practical

After I complete this project I would like to have improved my coding skills and more importantly learn about how coding is done in community projects.

My only spoken language is English and I am fluent in written English. I am awake at 10:30AM to 1:30AM (UTC) an I would not mind talking with a mentor over VOIP.

Short Essay

I wish to join this project for GSoC and beyond because of Wesnoth's strong community I wish to be a member of. The Battle for Wesnoth was one of the first open source games I used. Wesnoth stood out against most of the other games I previously played. It had a professional feel and had a strong sense of how I now view open source.

When I first took Computer Science in High School, I enjoyed the lab time writing programs. However, it took a bit longer for me to realize why. Coding for an assignment was enjoyable, but it was coding with a group of people that was more enjoyable. Talking about our assignments and working as a team was where the most enjoyment came from. I feel The Battle for Wesnoth has the strong community where I won't just be working on my project, but contribute to a project surrounded by a helpful community. To me, Wesnoth is a strong example of an open source project.

Open source is defined by the community that makes it. If the community is strong, the software will also be strong. This community has people all working together to make something worthwhile, for the good of the world. This community is open: it lets anyone come in and contribute ideas, art, code, etc. It also teaches people about everything. The source code given to anyone who wants to read it, however looking at the Wesnoth forums is stronger proof of the teaching power. When someone contributes art, it almost always is improved by the advice of others in the Wesnoth community. The same for translations: this community helps people find the right words for languages that they might not even speak. When I think about open source, I immediately think of the people who make projects like Wesnoth work.

I discovered open source through Linux and Wesnoth. A friend suggested that I should try Linux and I did. However, I decided to choose Debian because it was completely free, although I didn't grasp the true meaning until later. I saw open source as simply source code that could be read. After I finally got KDE to work, I played some of the games that were included on the disks and one of them was The Battle for Wesnoth. When I the main menu appeared, I knew that this game was a work of art; The music, drawings, and the underlying code were all integrated to make a masterpiece. All of this work was done by a group of people not for profit, but for making an excellent game. This was all their work. Wesnoth defined my idea of open source from the naïve notion that it is merely code that can be read to the definition explained above.

I have much to gain working for open source software. I have all the benefits of working for a software company, and much more. I get to meet people across the world. I join an open source community. I will learn many things from this community. I will have an deeper understanding and appreciation for this project. I will improve my developing and coding skills. In addition, I will learn things not directly tied with coding. I may improve my art skills, for example, when I'm working on the GUI for the client with the help of the many artists who contribute to Wesnoth.

I also believe I have much to give to the community. I will be contributing with my project, but I will be contributing much more. This is another reason I wish to participate with Wesnoth for GSoC. This community facilitates communicating with different groups in Wesnoth. I will be contributing to different aspects of this software, it may be art, ideas, maybe even the Latin translation.

I enjoy trying to solve the problems I encounter. Whether in a game, life, developing or programming, I look for problems and try to fix them. It's an engineering thing I think. When I wrote my own programs, I always did something I knew I would have a little difficulty in. I would have to learn how to fix the problem. The satisfaction of solving a problem keeps me wanting to solve more problems. When I am writing part of a program that is not much of a problem, I keep motivated by remembering my goals for the program I'm writing. For the project for GSoC I would also be motivated by my sense of responsibility to the Wesnoth community. My thirst for knowledge also keeps me coding, I find researching what I have to do as enjoyable as designing programs.

I would be honored to work for The Battle for Wesnoth through GSoC.