User:KingofCamelot

Google Summer of Code Application

This is my proposal for continuing to enhance the BZFlag server listing.

Reflections On GSoC 2008

Since this application would be a continuation of my work from last year, I thought I should mention my thoughts on the original project from last year.

First off, because of time constraints due to school, I have not been able to continue to participate in BZFlag, or keep up with any developments. I did set up the code to compile on my desktop a few months ago, now using the VC9 project files. I am glad to see that my work is being used in BZFlag, but after looking at it again, I feel it could still use some work.

One major point I underestimated in Google Summer of Code 2008 was time management. I did not lay down a very concrete time schedule for myself, partially because I was not sure what to expect, and partially because I wasn't positive of strong milestones, due to the refactoring nature of my project. I think this, along with underestimating the time to learn the current code, which gets a bit tricky with navigation focus, nested controls, etc, caused me to fall short of my own expectations for my project. My school quarter did not end until a bit into the start of coding for GSoC, I moved in July, and then fires knocked out power and caused problems for a week or two, so some other issues played a factor in time management. As such, in this application I will try to lay out a more concrete time schedule which I can abide by to keep myself in check.

I think I did a decent job last year, and because I received a passing evaluation I assume it was mostly satisfactory. However, I fell a bit short, and due to focusing on functionality near the end rather than form, it is not the prettiest at the moment. I also fell far short of my goal of commenting the code, since I was quite busy with functionality. These are all reasons why I would like to continue working on the server listing. I have also learned more about computer programming and design over the last few months, and am currently taking a course in C/C++, and I feel these factors will help me improve my work.

Speaking on a slightly unrelated note to this section, but on time management, it is worth noting that this application is being submitted quite close to the deadline. This is mainly due to school-related issues, and should not affect GSoC 2009. Last quarter was quite stressful school wise, and especially around finals, when GSoC 2009 was starting to crank up. After that, I've been trying to find some place to live next year, which has been taking up a large amount of my time (trying to coordinate a place for 5 people), and the last week I have been trying to nail down my schedule for this school quarter. So due to unfortunate timing all of these events have left me with little time to work on my application.

Abstract

Improvements to the BZFlag server listing during Google Summer of Code 2008 added quite a bit of new functionality. However, not all proposed functionality was added, and not nearly enough input from developers and community was solicited. As such, this proposal seeks to build off of the work done in GSoC 2008, while adding any new functionality that is suggested by the community/developers. Another major goal of this proposal will be to improve the usability of the server listing as it stands now. While it has quite a bit of functionality now, it is a bit awkward to use, and has a few glitches. As work in GSoC 2008 showed, adding functionality can quickly overwhelm the usability of a menu when keyboard accessibility is a constraint. As such it is important to add any new functionality which the community wants, and improve current functionality, while keeping keyboard accessibility in mind. Functionality may have to be limited due to the fact that we can't list a thousand commands at the bottom of the screen. Developer and community input on how best to deal with the ratio of functionality to keyboard accessibility will be sought out, and used to keep things balanced.

The overall end result of this proposal is a complete and robust server listing for BZFlag. Since BZFlag is preparing for a major release, it is important that the final product of this project will be a fully functioning, and easy to use server listing. As such, addition of new functionality will be weighed to ensure it does not produce too much work which will limit the completeness of the server listing. GSoC 2008 saw a lot of new functionality implemented, especially in UI controls to accommodate new features such as nested controls, and this new functionality came at the cost of a polished and ready to ship server listing. Now that a lot of the needed functionality is in place, more of the focus can be on the actual server listing, and producing a complete and polished server listing. With all of this in mind, the proposed timeline for the project has been laid out into three iterations, which should deliver a workable server listing at each step. The iterations' scope narrows as time goes on so that major new functionality will not be added near the end of the project, and instead the focus will be on finishing up and making it all come together.

Detailed Proposal

This detailed proposal will go over the main goals of the proposal, and how they will be achieved. Much of the main goals of the proposal are based on the proposed timeline at the end of this section. The use of a concrete timeline is of importance to this project, especially since BZFlag is working towards a release. While the results of GSoC 2008's efforts on the server listing produced a working version (although some functionality was inadvertently broken soon after completion, see patch), I would not call it release worthy. Most all of the functionality that was proposed was added, but much of this remained largely completed in code itself, and not necessarily in usability. One proposed improvement which was not completed as of GSoC 2008 which is worth noting is the players on server list. That improvement requires some major code writing to implement, and as such should be carefully reviewed before inclusion in the continuing work on the server listing. As such, this proposal seeks to implement this functionality in a user friendly way, while adding any new functionality that the community wants. The scope of any new functionality will be closely watched to prevent the project from drastically expanding.

In an attempt to keep new functionality in check, to work towards a release ready result, and to maximize community involvement, this proposal has laid out an iterative approach. Specifically three iterations are called for, although this can be flexible if other developers have any suggestions, etc. The proposed three iteration plan would go as follows. The first iteration will implement any major new functionality, like the players on server list, to the server listing. It will also focus on fixing bugs that exist in the foundation code, especially the code from GSoC 2008. The second iteration will implement any minor new functionality, while expanding existing functionality and that added in the first iteration. The third and final iteration will focus completeness of added functionality from iterations one and two, as well as focusing on usability and navigation of the server listing. Polishing of the visuals, while not overly important to this project, are part of producing release ready code, and as such this iteration will also see improvements to the visual aspects of the server listing. Each iteration should produce a working version by the end of it's allotted time which can be used and played with by developers and community, in order to provide input to help guide the next iteration. The scope of each iteration narrows in order to ensure that the final weeks focus on completeness and usability.

Documentation and Community Input

The first major aspect of this proposal seeks to correct some of the mistakes with the original GSoC 2008 project, mainly documentation, and community input. Taking into account the experience gained in GSoC 2008, time is an important commodity, and must be managed as one. As such, this proposal sets aside the time before the beginning of coding for documenting, and soliciting community input. Community input is of particular importance during this time, as it can provide a guide moving forward once coding has begun. A forum post seems to be the most efficient way to get community involvement, and as such should be made as soon as possible to begin to get comments and suggestions for the current state of the server listing, as well as any desired functionality. Community input is important, but the final decisions of what to include and focus on will be up to the developers. This forum post will be updated as each iteration nears it's end, allowing major community input at four major intervals: project start, first iteration, second iteration, and third iteration.

In addition to community input, the time before coding begins will also be used efficiently to fulfill another lapse of the GSoC 2008 project: documentation. There is a fair chunk of time before coding begins, and this should be enough time to document code produced in GSoC 2008, and the code which was affected/used during that time. Most of this documentation will done through in-code comments, as can be seen in the patch submission. If these comments become too dense, external documentation can be used. More complex subjects, such as the in-menu navigation system, deserve more complex documentation, and ideally could have a wiki page of some kind to provide a reference on how to use them. Any overly messy code found during this documentation period would be cleaned up, but the focus would be on documentation, as this will provide a good base for finishing the project on time.

Proposed New Functionality and Changes

This proposal will suggest one or two new features for the server listing, but mainly it will leave suggestions for new functionality to the community and other developers. I view my main priority as making the server listing release ready and bug free, but I believe I have enough time to implement some new functionality, and as such am open to suggestions. Due to the community contribution aspect of this proposal, there iteration milestones can not be too concrete, until a list of new/extended functionality is made.

At the moment with the current server listing, there are several columns featuring information about each server. One part of the original project idea from GSoC 2008 was a country listing for the servers. So long as this can easily be obtained in the BZFlag, it should be simple to add to the server listing as a new column. Of course, servers tend to have fairly long names. The more columns of information added, the more likely columns like name will have to be cut off. This could be overcome by changing font size, but it's worth noting. Too much information will just start to overwhelm the students. Along the same line, currently the game mode indicators from the original server listing are grouped together on the far left, in one giant column. This could perhaps be cleaned up to make it easier to view and understand. The placement of the selection icon is also awkward at the moment, and a new location for that should be found.

A list of players on a server is a potentially nice feature, but also somewhat extensive to implement. As such, I feel that input should be solicited from the community on how useful/desired this feature would be. Since this data does not exist in BZFlag at the moment, it has been suggested to parse the data from http://my.bzflag.org/currentplayers.php. This of course will require a decent amount of code, and is somewhat constricting. However, suggestions on how to accomplish this would be greatly appreciated. If a viable solution and evaluation of the players on a server list can be completed before, or by the start of the first iteration, I think it is a realistic possibility. After that it will begin to eat into other resources and could prove to be a strain on the project.

Usability

Currently the server listing is not the clearest about how to use it. This mostly stems from rushing to complete functionality at the end of GSoC 2008. The choice of keys for various commands was entirely arbitrary, and as such may even conflict with other main menu functionality at times. While choice of key usage is not a critical aspect of usability, it is definitely something to be considered, and should be more refined then the current version. There are also several keys which are undocumented, such as using S to sort a column, or +/- to resize a column. The latter was added mainly for design purposes and not necessarily meant for general consumption, although it certainly could be incorporated as such.

That last point brings up something which is worth noting. At the moment, there is quite a bit of functionality in the server listing, but not much room to explain how to use it. Much of BZFlag uses text on the screen to briefly describe what keys do what. However, the server listing has lots of different potential functions. A usable solution needs to be devised to this problem. Potential features like column resize may be left out for the sole reason that functionality clutter can begin to weigh down on usability. Potential solutions to his include cutting down on functionality, use of commonly understood navigation methods common throughout BZFlag, and possibly extension of the server listing onto a sub-page, or some kind of sub-division. The last method is perhaps the least desirable out of the bunch, as it adds complexity, both in code, and navigation.

Proposed Timeline

April 20 - May 23: Beginning

• Document existing code related to the server listing. This includes code I wrote last year. Mostly internal code comments, but maybe a wiki page for more complicated concepts, like the navigation queue. Clean up any code which is glaringly messy during commenting.
• Create a suggestion thread on the forums, based on the current state of the server listing. State what is realistically possible in the time frame, and take suggestions from the community on functionality and form for the listing.

May 23 - June 27: Iteration 1

• Fix any known bugs with the current implementation of the server listing, while keeping in mind anything which might change due to changes to the server listing.
• Implement new functionality agreed upon in the forums, and/or among developers. Attempt to implement the most major changes/functionality here, in order to deal with any problems early on.
• Continue to flesh out current functionality if need be.
• Have a functioning copy by the end of this iteration.
• Near the end of this period, make a new post, or update the existing post on the forums, highlighting the new server listing, and again taking thoughts and suggestions. Provide enough time, perhaps a week, to allow users to comment. Have this week overlap the end of iteration 1 and the start of iteration 2.

June 27 - July 25: Iteration 2

• Similar approach as Iteration 1.
• Implement new functionality from forum suggestions, etc.
• Try not to take on any major new functionality, or if so, keep it to one major function.
• Again, update the post on the forums with the latest status, take suggestions and ideas. At this point solicitation of any new functionality should cease, and the focus would be on navigation, ease of use, etc.

June 25 - August 10: Iteration 3

• No new functionality should be implemented in this iteration. The focus will be on improving current functionality.
• Improve the robustness of the code, and flesh out any functionality that is lacking.
• Special focus on navigation and ease of use of the server listing.
• Any visual clean up that is needed. Polish the visuals to go along with the rest of the menus, and to look nice.

August 10 - August 17: Ending

• Google's suggested 'pencils down' period.
• Document anything which was missed during the previous iterations.
• Bang on the server listing and fix any bugs that might come up.
• Clean up any code that got messy.
• Continue to make superficial visual tweaks to the server listing, as time allows.

About Me

My name is David Sanders, and I'm a second-year Computer Science major at the University of California at Santa Barbara. My nickname in the BZFlag IRC channel is KingofCamelot. I have experience working in BASIC, Visual Basic, C, C++, Java, Python, and HTML/CSS. I have worked the most extensively with Python and Java, although I am proficient in C/C++, as my patch submission should demonstrate. I have no formal training in either C or C++, so some I'm somewhat rusty in certain areas, but I am constantly expanding my knowledge through online resources when problems arise, and I am definitely a competent programmer in both.

During the next 10 weeks or so I will be taking a class which focuses on C/C++, so I should be able to improve my C/C++ skills and become a better programmer in both.

I participated in GSoC 2008 with BZFlag, so I'm not going to re-hash too much of the about me here. I will provide a link to my application from last year, which has a more detailed information. Last year I worked extensively with DTRemenak, and worked in the IRC channel, so I believe there are some people who remember me.

Time Considerations

As has been mentioned in other places in the application, time management was a short coming in the original GSoC 2008 project to extend the functionality of the server listing. As such, this proposal seeks to lay out a time management schedule as specifically as is currently possible. In addition to the proposed schedule, I would like to lay out some information about my personal availability and potential drains on time.

My spring quarter at UCSB does not end until about June 10th (should be last final then). As such, this will limit the amount of work I can do up until June 10th. In GSoC 2008, this overlap of school and GSoC led me to not start any work until the coding start date. This year, I have specifically chosen a lighter schedule for my spring quarter, and as per the proposed outline, would start work (even if just documentation and some bug fixes) earlier on. I believe it was a mistake to be so unproductive last year during the time period before the coding start date, but my school schedule played a large role in that.

Another impact on time in GSoC 2008 was due to two events, one expected, one not. The very end of June and very beginning of July saw me moving to a new house, which required cleaning out years of junk at my old house, packing, moving, and then re-assembly. As such, this took a chunk of time out from working on GSoC. Unfortunately I will be moving again this year, possibly in the same time frame. However, the move should be quicker this year, less stuff to clean/pack, as well as a shorter distance to move. The unexpected event last year occurred around the same time, and was constant black outs for a few days due to fires in the area. This cut productivity entirely, since nothing could be done without power, especially at night in the dark.

However, those should be the only constraints on my time that I can foresee, school, and moving. I do not plan on taking any vacation, so that should not be a problem. Anything else that occurs will at most prevent me from working for a day or so. Of course, some unexpected event like the fires could happen again, but let's hope not.

Appendix

References/Links

• Google Summer of Code 2008 Application for BZFlag
  
• Google Summer of Code 2008 About Me
  
• Patch Submission
  
• Patch (Same as above, but just the file)