This wiki was in read-only mode for many years, but can now be edited again. A lot of information will need to be updated.

User:KingofCamelot: Difference between revisions

From BZFlagWiki
Jump to navigation Jump to search
← Older edit
 
(19 intermediate revisions by the same user not shown)
Line 1: Line 1:
=Google Summer of Code Application=
=Google Summer of Code Application=
This is my proposal for enhancing the current BZFlag server listing.
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==
==Abstract==
In it's current implementation, the BZFlag server listing provides a basic listing of playable servers, with a basic server name search feature. However, it is lacking many of the more powerful sorting and filtering features that most modern games include in their server browsers. The C++ code for the server listing is also lacking any real comments, making it hard to decipher, and is designed at the moment to be rather singularly functional, written for the current listing, without much room for expansion without some serious re-writing. As the number of BZFlag servers continues to grow, a user-friendly server listing, with sorting and filtering options, is quickly becoming a necessity. While BZFlag doesn't need the end all of server listings, the current server listing is pretty bare bones, and makes it difficult for players to find specific servers which match their tastes.
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.




I propose revising the current server listing, using the current menu system. This revised server listing will include several new features, built upon a well commented code base, making future additions and renovations to the server listing quick and easy. The revised code will also be designed with future improvements in mind (such as a buddy list) and as such will be coded broadly, to allow for easy integration of add ons, instead of coded narrowly, like the current server listing, which is so specific to it's current form that it is hard to add onto without much re-writing. The new features I propose to implement will include: sorting options, filter options, a players on server list, and a recently played server view. The current server listing view will also be re-arranged and expanded upon in order to accommodate the new information. This new server listing view will best be discussed amongst the developers and the community, although I provide a mock-up of one possible solution (see appendix). The server sorting options will include: sort by domain name (alphabetically), sort by server name (alphabetically), sort by players (numerically), sort by map name (alphabetically), and sort by client to server ping (numerically). The filter options will allow server filtering by various server-specific settings, by server capacity status (show full servers, show empty servers), and will include a server name filter (including wild cards). If desirable, a domain name filter may also be implemented. The players on server list is fairly self-explanatory, displaying the name and team of players on the currently highlight server. The recently played server view will be an alternative server list, along with a favorites list. The user will be able to switch between the normal server list, the recent list, and the favorites list, and may set different filter and sorting options for each.
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.


One major 'concern' that must be addressed during all of this re-configuring of the server listing is to not make it overly complex, since one requirement is that the entire menu be keyboard accessible. This is a unique challenge since most server browsers in mainstream games use many mouse activated features. However, I feel with clever design a user-friendly, keyboard accessible menu can be designed. My mock-up gives a basic keyboard interface, and my detailed explanation will expand on this further. In the end, the user should always know how to use the menu, without being overloaded in a sea of explanations.


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.


This will all be implemented by expanding the current server listing code (and re-writing as necessary). As such it will be written in C++, and will work off of the current dependencies. All of the information needed for the enhanced server listing is already provided in the current code, it just needs to be tapped into. As mentioned earlier, the entire server listing code will also get generous commenting (but not too much), to ensure that in the future it is easily modified as new needs arise. I will also provide wiki documentation for the code, allowing me to be descriptive without overloading comments in the actual C++ code. The code will be written with re-usability in mind, and will be made as dynamic as possible, so that in the future it can be expanded upon, instead of re-written. Obviously no one can predict all future needs of specific code, but due to the fairly narrow scope of a server listing, I feel that most features can be written in a way that will lend themselves to future modifications.
===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.


==Detailed Proposal==
One of the first steps to my proposal involves re-writing much of the current server listing code. Not because there is necessarily anything wrong with it, but to clean it up, comment it generously, and to create a strong foundation for the rest of my enhancements, as well as future enhancements. As DTRemenak said in IRC while discussing my abstract: "the big problem is that the code and the interface are both indecipherable, so nobody's sure quite how it all works together :)" and "it's a stack of hacks :)". I consider cleaning up and documenting the code as a crucial first step to any server listing update, so that not only I am comfortable and confident with the code, but so that any future developer can read the comments and quickly understand what is going. While it is the nature of open source projects to become a "stack of hacks" in the sense that multiple developers build upon one another's code, sometimes things need to be cleaned up and unified for simplicity's sake, hence coding conventions, etc. The first thing I did once I had BZFlag compiling (which was only about a week ago) was find the server listing code and explore. After fooling around for a few hours, I feel like I've got a pretty strong understanding of what's going on in most of the server listing code, and already have ideas on how to re-write it and improve it as a foundation for my proposal. In fact, my patch submission (which can be found in the appendix) was a test in both my understanding of the current code and implementation of some changes which allow for multiple server lists to be maintained, updated, and filter/sorted separately, which is crucial to the server listing enhancements in my proposal. Lest I be called a hypocrite for submitting a patch which isn't very well commented, I'd like to apologize for the lack of comments. I only recently discovered Google Summer of Code, and so the whole process has been rather rushed. In my mind it is better to have a complete application and good working code then to spend time commenting when I need to be doing other work. I can, however, briefly describe the main code changes I made. I created a pointer server list variable, which can be pointed to either the regular server list or the ping-sorted server list. So, when the user requests it, the pointer variable changes which list it is pointing at. This allows the two lists to remain independent of each other.


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 Changes===
===Proposed New Functionality and Changes===
I'll begin by describing the basic layout of my proposed changes, the sorting/filtering options, and finally give a mock-up example and discuss keyboard accessibility of the entire menu. My proposed layout will be similar to the current server listing, with a few key changes. At the moment there is a server list, a server information area, and a search feature. I will keep the server list and the server information area, and fold the search feature into my proposed filtering options. So, in addition to the server list and server information area, I will add a filtering options area, which will allow the user to select several filtering options based on server settings, server capacity, and a server name filter. Another possible filter option includes a domain name filter, although I don't consider this a critical part of an enhanced server listing. However, it should be a trivial addition in the future since I will code the name filter to be able to be used across several different areas (server name, domain name, map name, etc). To compliment the server information area there will also be a players on server list, displaying the players on the currently highlighted server, as well as their team and score, and possibly their ping (from their client to the highlighted game server). The server list will be revamped to include headered columns for domain name, server name, players, map name, and ping (from client to game server). The server list view will be able to be easily switched to a favorites view, and a recently played view. Code-wise each of these server lists will be treated as separate lists, allowing the user to sort and filter each one separately, and switch between them while keeping everything intact from list to list.
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.




The columns in the server list will be able to be sorted by the user. The user will select one of the columns, and choose to sort in either direction. Columns which have text entries (domain name, server name, map name) will be sorted alphabetically, while columns with numerical entries (players, ping) will be sorted numerically. Only one column will have sort preference at a time, meaning that users can either sort by domain name, server name, players, map name, or ping. As mentioned previously, each separate server list (normal, favorites, recent) will be able to be sorted separately, and will retain their sorting even when the lists are switched between.
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.




The filtering options will work alongside the sorting done on the server lists, allowing users to narrow down the server list through filters, and then sort as they please. Just as with the sorting of columns, the filter options will be list specific, and will retain their settings even when the user switches between the lists. The filter options will range from different server settings, to server capacity, to server name. A basic check box style filter option will be used to allow the user to specify whether they would like to see empty servers or not, and another option to specify whether or not they would like to see full servers. For the filter options relating to server settings, the user will chose to show only servers with that specific setting on, off, or they can choose to see servers with that server setting either on or off (in other words, no preference on that setting). The server name filter will basically be the relocation of the current server search function into the filter options area, allowing the user to show only servers that match the server name filter they specify (which will allow wild cards for the most flexibility). As a thought that just occurred to me, perhaps an overall on/off switch should be given to the filter options, that way the user can easily turn off filtering options without having to manually reset each option.
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.


I've put together a mock-up of how my proposed server list enhancements could be neatly integrated into a clean and simple UI for the end user. This mock-up can be found in the appendix, as well as a 'bastardized' version, which combines an in-game screenshot with the mock-up, to give a better idea of what the finished product would like. You have to use your imagination for that one. Also in the appendix you will find screenshots of server browsers from a few mainstream video games. I used these as references when creating my mock-up, giving me ideas for what I considered the best of all worlds. My mock-up is in no way set in stone, and since the actual coding cares little about where on the screen it is placed, I consider this part to be quite flexible, and would love to illicit input from other developers and the community. I expect the overall layout to be tweaked several times throughout the completion of the proposal before a perfect balance is struck.


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.


===Keyboard Accessibility===
==Proposed Timeline==
The introduction of my mock-up leads me into the next part of the proposal, and one I consider to be quite important, which is the keyboard accessibility of the enhanced server listing. This is obviously a unique constraint that the referenced server browsers didn't have to deal with, although I don't think it will be much of an issue during development. However, it is very important, in my opinion, that it come out simplistic and smooth, because no matter how pretty the new server listing menu may look it means nothing if users can not easily find their way around it. In the mock-up I provide some keyboard commands along the bottom, like the current server listing does. Although it seems like quite a few commands, I think most of them are fairly intuitive, and really it would be hard to implement with any less commands.
'''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.




I'll explain the significance behind each command in the mock-up. Users can use the '+' key to add a server to their favorites list. This command only works on the normal server list, and the recently played server list. When the user is viewing their favorites list, this command will be exchanged with '-', which will remove the selected server from their favorites list. The 'f' key can be used to switch to the favorites list, and the 't' key can be used to switch to the recently played list. As with the add/remove favorites command, these commands would change depending on which list you were viewing, allowing for an 'n' command which would switch the user back to the normal server list. The 'i' key would change the keyboard control to the server information area. This would allow the user to use the left and right arrows to switch between the server information and the server player list, and the user could use the up and down arrows on both areas to view the different pages for each area. The 's' key would allow the user to modify the sort options for the server list. Once keyboard focus is given to the sort options the user can use the left and right arrows to switch between different column headers, and would use the up and down arrows to sort, or reverse-sort the servers based on that column. The 'o' key would give keyboard focus to the filter options area, where the user could use the up and down arrows to scroll through the options, setting them with the left and right arrows, or typing where necessary. The last command, 'r', would refresh the information in the server list, such as player counts, pings, etc.
'''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.




The key to making all of this keyboard accessibility work is to have the command list at the bottom of the screen change depending on which area/server list has focus at the time. This is important because the usable commands change with the focused area/server list, and the user will always need an accurate command list that shows them how to change back to the normal server list, etc. I think the system I've laid out is pretty intuitive, but as with my mock-up, I plan to illicit input from other developers and the community, and overall tweaking the keyboard access to the menu should be a fairly trivial task. I will be making every effort possible while coding the enhanced server listing to ensure that keyboard accessibility changes are easy and painless to implement.
'''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.




===Technical Aspects===
'''June 25 - August 10: Iteration 3'''
There are a few technical aspects that I'd like to address at the close of this proposal. First up is the pinging of the game servers by the client. This was brought up by both JeffM and Manu in the IRC channel while I was discussing my proposal, so I feel it warrants some special attention. There was some concern expressed over the client pinging all 260 some game servers. However, every modern game I have seen has a game server browser that does just that, and doesn't seem to have any problems doing so. The servers would only be pinged when the user first opens the server listing menu, or when the user manually refreshes the server list. Concerns over the pinging can be broken up into client-side concerns and server-side concerns. On the server-side, I can see the potential for the concern that servers could come under a constant ping barrage by clients browsing the server list. To alleviate that concern I can implement a maximum in the server ping code to ensure that the server just starts ignoring pings if it is receiving too many during a time period. Next would be client-side concerns, which is what I think JeffM was more concerned about. He mentioned that my patch code had created a 'flood machine', I assume in reference to the number of returned pings the clients are going to be receiving. I can definitely see this as a valid concern, which is why I added a 10 ping maximum into my patch code. I arbitrarily chose this number, so a higher limit is possible upon further investigation. Basically this will ensure that the client never sends out more than 10 pings at a time, waiting for the pings to be returned before sending out a new one. This should prevent any flood behavior associated with the pinging of the game servers.
*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.




The other technical aspect I'll cover is about the scope of my proposed changes. The changes I have proposed will stay within the current server listing code for the most part, although there will be foreseeable changes to the server ping code, and any code that relates to grabbing the list of players on a server. Other than that, from what I've seen from experimenting with the current code, everything else should be easily contained within the current code files, and will not require any kind of new dependencies, resources, etc. Maybe a texture or two will need to be added for the new cleaned up UI, but we'll see.
'''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==
==About Me==
My name is David Sanders, and I'm a first-year Computer Science major at the University of California at Santa Barbara. My nickname in the BZFlag IRC channel is KingofCamelot, and I have been idling in there the past few days, talking to several of the BZFlag devs (including JeffM, blast007, Manu, and DTRemenak). I have experience working in BASIC, VisualBasic, 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.
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.




I have not worked on any open source projects before, but I do have quite a bit of experience in video game modding. I've modded Civilization III, Battlefield 1942, Battlefield Vietnam, and Battlefield 2. Most of this modding was just exploration for my own curiosity, but after Battlefield 2 came out, I joined the Project Reality mod team, and spent almost two years as an active developer. I'm proud to say that in that two year time span the mod won 2nd place in ModDB's Mod of the Year contest twice (2006, 2007). Although video game modding and open source projects are obviously not the same thing, I feel that they have quite a few similarities, and that the modding community has been especially influenced by the open source community in recent years. During my time on the Project Reality mod we used SVN extensively for all of our coding and changes, so I am more than comfortable and familiar with the system. The modding project was also very collaborative with much discussion between developers, community, etc. After spending some time on the BZFlag IRC channel, it seems to me that the BZFlag team is very much the same way. I like to think that my experience with Project Reality has made me quite good at communicating and collaborating with other developers, and has made me comfortable with the critiquing, debating, and discussion that goes into making strong releases. With Project Reality's team extending from the United Kingdom to Germany to Brazil, etc, I feel I have improved my people skills quite a bit. Project Reality, like BZFlag, is very community oriented, and we took a TON of input from the community, asked for input on potential changes, etc, so I am more than used to including and respecting the community during development, as well as interacting with them.
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.




I hope that wasn't too much description, I just wanted to make it clear that I have quite a bit of experience in a similar field to open source. One thing that always frustrated me about modding for Battlefield 2 was the lack of source code. As such, I am more than excited to work on a project that gives me full access to the code and the freedom to be innovative and creative. In fact, the night I got MSVC 2005 set-up and got BZFlag compiling I was so excited to begin working with the code that I stayed up until 7:30 AM before I realized I should sleep. Now that I've begun modifying BZFlag I can tell that I'm probably going to get sucked in, whether or not my application is accepted. The developers I've talked to in the IRC channel seem like great guys, and have been really helpful. The reason I stopped being an active developer on Project Reality (although I still maintain a presence in the community) was that after entering college I did not have nearly as much time as I had in the past to work on it. I will have to get some kind of job over the summer one way or another, so I am really hoping that my application gets accepted, allowing me to focus my attention on BZFlag and my proposal. As mentioned before, with Project Reality the lack of full control through source code was also becoming increasingly frustrating as we tried to push the game engine's limits further. I see working on BZFlag as the next logical step in my own progression of video game coding, from video game modding to open source coding. With the summer coming up I can't wait to focus my attention on BZFlag, and I hope to become a long-term developer for the BZFlag community, like I became with Project Reality.
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.


==Appendix==
[http://sourceforge.net/tracker/index.php?func=detail&aid=1930606&group_id=3248&atid=303248 Patch Submission]<br>
[http://www.uweb.ucsb.edu/~davidsanders/mockup.jpg Full Resolution Mock-up]<br>
[http://www.uweb.ucsb.edu/~davidsanders/mockup_shrunk.jpg Resized Mock-up]<br>
[http://www.uweb.ucsb.edu/~davidsanders/mockup_shrunk.jpg Bastardized Full Resolution Mock-up]<br>
[http://www.uweb.ucsb.edu/~davidsanders/mockup2_shrunk.jpg Resized Bastardized Mock-up]<br>


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.


[http://www.uweb.ucsb.edu/~davidsanders/BF2_server_browser.jpg Battlefield 2 Server Browser]<br>
==Appendix==
[http://www.uweb.ucsb.edu/~davidsanders/q4_server_browser.jpg Quake 4 Server Browser]<br>
===References/Links===
[http://www.uweb.ucsb.edu/~davidsanders/CSS_server_browser.jpg Counter Strike: Source Server Browser]<br>
* [http://www.uweb.ucsb.edu/~davidsanders/Old_Application.htm Google Summer of Code 2008 Application for BZFlag]<br>
[http://www.uweb.ucsb.edu/~davidsanders/server_browser.jpg Tom Clancy's Rainbow Six: Vegas Server Browser]<br>
* [http://www.uweb.ucsb.edu/~davidsanders/Old_Application.htm#About_Me Google Summer of Code 2008 About Me]<br>
* [https://sourceforge.net/tracker/?func=detail&aid=2727995&group_id=3248&atid=303248 Patch Submission]<br>
* [http://www.uweb.ucsb.edu/~davidsanders/GSoC_patch.diff Patch (Same as above, but just the file)]<br>

Latest revision as of 11:33, 3 April 2009

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

Retrieved from "https://wiki.bzflag.org/index.php?title=User:KingofCamelot&oldid=5678"