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
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
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.
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.
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.
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.
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. Although the code is now commented, I'll give a quick description of what I changed. 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. When the user toggles the sort by ping view, the pointer variable is pointed at the ping sorted list. If that list is empty, which it will be the first time, all the servers found on the list server will be pinged and then sorted into the list.
Proposed 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.
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.
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.
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.
Keyboard Accessibility
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.
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.
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.
Technical Aspects
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.
The 'players on server' list is another technical aspect that I'd like to touch upon. There is already a current players list maintained at http://my.bzflag.org/currentplayers.php. While it would be possible for me to have the game clients query individual servers for a list of current players, this would be inefficient both in the fact that clients are querying the game servers, and that the functionality already exists at the aforementioned address. So, the more logical approach will be to parse the information from the current address. This will also make it very easy to add a buddy list function in the future, since the code will already exist to grab the current players list, parse it, and use the information. After talking with Manu on IRC, he suggested that a plain text version of the current players list could be created to make it easier for the client to parse, since it is easier for the code to parse plain text than PHP. I would have to rely on someone with previous knowledge of the current players list to create a plain text version, so if that is not possible I can always just parse the current PHP list.
The last 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.
Proposed Timeline
April 20 - May 23: Beginnings
- 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: Endings
- 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.