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 enhancing the current BZFlag server listing.
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 http://my.bzflag.org/currentplayers.php 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.
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.
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.
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.
Appendix
Patch/Mock-ups
- Patch Submission
- Full Resolution Mock-up
- Resized Mock-up
- Bastardized Full Resolution Mock-up
- Resized Bastardized Mock-up
