User:Paul

You can find me on IRC or use the discussion to post any comments or questions.

Google Summer of Code application

Abstract

This is a proposal to work on the game clients server listing section in BZFlag. While coding for this project I would like to concentrate on providing useful features in an intuitive way. As by now, the listing provides very limited means of managing and finding game servers. In addition to low functionality, it does not make use of the already available information. Taking into consideration the future increase in the player quantity, this becomes an even more serious problem. During the Summer of Code I would like to improve BZFlag so that it becomes more user friendly and ready for the future community growth.

Assumptions

The project is specific due to the fact that the server list is an important part of the UI. As a consequence, a constant community contact as well as frequent prototyping is a crucial condition of its success. Therefore, modifications can be introduced to some aspects of my idea during the process, but, if any, they will be just minor changes. I have put stress on planning the project in a way making it most extensible, adding e.g a new kind of special tab or filter would need a minimal effort.

My idea is to keep the UI as simple as possible, I am going to base the future look and code on the present ones. On such approach everyone takes benefit, the users, who will not have to learn how to use the new interface, as long as they are satisfied with the current functionality, and the project/developers, because the number of external dependencies will not grow.

The new menu has to meet two main constraints. At present the HUD does not allow displaying small fonts, especially in lower resolutions, and still keeping them readable, limiting this way the amount of text that can be shown. What is more, the whole system has to be accessed keyboard-only what creates the need of intuitively planned shortcuts which could be learned quickly. Remembering this I will create a tool both for players satisfied with the current menu, not forcing them to change their habits, as well as for more demanding ones seeking advanced functionality.

Detailed project description

The new features will include:

Tabs

1. Replacing the current 'toggle view' system with shortcuts or a shortcut-opened menu allowing to choose the tab to be displayed. It will consist of the following default tabs: server list, favorites, recently used, buddy list and of those defined by the user. Every tab is going to have the form of listed servers, so that the set of actions one can perform on them will consist of those identical for all of them and some context specific ones, e.g adding a friend to buddies list. In the matter of the favorites tab, I am going to add the possibility of giving user-specified names to the servers and dividing them into categories, thus releasing the player from the need of remembering any additional information. The number of saved, recently used servers will be set in the options.

1.1 The buddy list will be an useful, completely new feature. Currently, the player has to leave the game to check whether and where his friends are playing. This tab is going to allow making a buddy list and on its basis create a list of servers, accessible on one keystroke. I am thinking of getting the required information from the current users database used by the web page http://my.bzflag.org/currentplayers.php. We can also create a list of current players on every server this way. I am thinking of two different ways of adding buddies: by choosing someone from the 'players on the server' list and by using an 'add buddy' command, which will require entering the proper callsign.

1.2 Creating new tabs is essential as it will remove the need of performing repetitive actions. There will be several methods of modification of the tabs content. One of them is employing the currently seen list, either by appending it to a tabs content or by replacing it. This approach allows fast creation of tabs with previously filtered lists. The other way of modification will be a simple ‘add this server to a tab’ option displaying the list of possible targets. There will be means of removing elements from the list and creating blank tabs too. The filter settings of each custom tab will be saved separately. This feature will be a great convenience providing a powerful tool of server managing. Some of the exemplary adaptations are: saving performed searches, creating themed tabs- e.g for leagues, making pre-defined search masks- using them would need only replacing the tabs list with the complete server list.

Features that will serve modifying the list displayed in the tab

2. The elements named in 2.1.2 and 2.2.2 will be thoroughly discussed with the community during the May Interim Period as changing them does not have greater relevance in the project complexity. The feedback of players is necessary because this is one of the most common used parts of the UI.

2.1.1 Dividing the server information on the list into columns, each having its own header. This way more details about the servers can be shown in a transparent way. It will make the information not only more readable but also create an easy way of sorting it by column selection.

2.1.2 My current idea of a column headers list includes: server name, ping, number of players, number of free slots, port, time, country, map name.

2.2.1 Creating a list of filters. The filters will be simple multi-choice fields, like those in the options, sometimes with the need of specifying a number value. This way the user can narrow his selection to servers, closely matching his needs, by simply hiding large, unwanted groups.

2.2.2 My current idea of a filter list includes: maximum ping, max/min number of players, number of free player slots, game version, required registration, public or private server, server specifics (jump, ricochet, number of shots etc.).

Other changes

3.1 Making the font smaller. The current font size makes it impossible to show long server names. Because the new features will add even more information to the server list box this change will be inevitable.

3.2 Creating a settings menu in the options which will make the server listing configurable. Among others it will allow changing such parameters as: size of the history of recently used, scrolled/paged server list style, columns viewed in the server list.

3.3 Adding a 'refresh view' option.

3.4 Highlighting the text found with the help of the search tool.

Technical aspects

I am planning to write everything from scratch because this allows me to create a clean, coherent code. However, as I said before, I will base on the current implementation so the idea of most classes will not have to change. What is more, creating everything by myself allows me to write a clear and useful documentation. The most affected piece of code will be the server handling part as the project concerns it directly. The settings menu will be extended by the necessary options too. The list of the most important classes will look like this:

ServerMenu

As this is the core of the server list UI system, it is going to be changed the most in comparison with what we have today. Almost all the features mentioned above will be implemented or used in this class. This is where the elements location and content is defined. Its precise shape will be the effect of user opinions, gathered after creating each prototype. The new version will have to handle multiple tabs, therefore I will move the whole logic into a new Tablet class.

ServerList, ServerItem, ServerListCache

These will have to cope with additional server information so a few new elements will be introduced. There will exist one global cached list. Just the main list tab will have dynamic content, changed after every refresh. The remaining tablets will have static lists as this is closer to their nature. They are meant to hold precisely defined groups of servers or those chosen by the user. However, I will add a simple way of informing which servers are available, what will need only looking for them in the global list. I have been thinking about creating tabs with dynamic content modified with the filters, but I came to a conclusion that this will only complicate the usage and duplicate the already planned functions. If the users decide that throwing the main list into a mask tab is far to demanding I will add this option too.

Tablet

It is going to encapsulate the structure of a tab and it will be used to sort and display the lists as well as perform tab-specific actions on them. Tablet will serve as a base class from which other tabs will inherit. All the tabs which I planned will be built on it but what is more important any new ones could be made easily, what is significant for the future development.

BuddyList

It will be responsible for retrieving necessary data from the database, managing the list of buddies(adding/removing friends, saving/loading from file) and creating a list of servers to be displayed. I think that using the already available data from the previously mentioned web page is the best solution. If the client gathered all the information on its own, massive traffic would be created unnecessarily wasting the bandwidth. The refresh rate of a few minutes is enough to provide reliable information.

Main : Tablet, Buddies : Tablet, Favourites : Tablet, RecentlyUsed : Tablet, Custom : Tablet

The names are salf explanatory.

Exemplary Interface

As I underlined it through my proposal, the final look of the UI will evolve during the project. I created a simple mock-up to show what one of the possibilities could be. Some of the ideas are the result of IRC discussion so they might sound familiar. Below I explain the appropriation of some sections. One key, e.g Tab, could be bound in order to move between them.

Exemplary User interface

Tab names: Only the name of the active tab can be fully displayed as we are space limited. The other names would be truncated to a few first characters. Binding the Shift + F# shortcut with the tabs would be a good idea as it is already used in the chat window. This would limit the the tabs to a number of 12 which is a reasonable maximum considering the available space.

Server list: Left, right arrows would allow moving between the columns, hitting Enter would sort by the active one and hitting it twice would sort in the opposite order. Up/Down arrows would be used to select a server. Some values, like the server name would have to be truncated. The current one-letter abbreviations would be kept.

Filters: Up/Down arrows would allow choosing the filter and the left/right arrows the possible values. Enter would be used for entering number values.

Search: Despite keeping its current shortcut it would be also Tab-accessible.

Server Info: All the information about the server would be displayed here without being truncated( unless e.g the name is extremely long).

Miscellaneous: The content of this box would change, providing an universal input/output area. By default the list of players on a server would be shown here but after using the B key it would be replaced by the list of buddies while the buddy tab is active. After pressing ‘+’ the list of tabs would be displayed in order to add the currently seen server list to one of them. Any other options which would need to display something would make use of this box.

Shortcut help: All the shortcuts available in the current situation would be listed here. Some of them would be persistent: r-refresh, /-search etc.

Timeline/deliverables

April 21- May 25

Discussion with the users on the subject: ‘What would you find most useful in the new menu?’, based on my ideas from the proposal as well as on their suggestions. This is when the final look will get clarified

May 26 - June 1

Writing of ServerList, ServerItem, ServerListCache. These simple data containers can be managed together in one week.

June 2 – June 22

Implementation of ServerMenu with the filters as one of its major parts. This is the main class so it has to be created at the beginning. Creating a dummy-tablet providing a list of servers will be necessary to check whether ServerMenu works correctly. Making the first major prototype will be possible at this stage and some opinions can be gathered.

June 23 – July 6

Implementation of Tablet and the first inheriting class- Main : Tablet. The new element will be integrated with the rest of the code and tested. From this moment on we will have a functional menu and further writing will include only adding new items. The dummy-tablet will be no more useful.

July 7 - July 13

During this week I would like to concentrate on giving a final touch to the code so that everything works perfectly by the mid-term evaluation. This will also include making the next main prototype.

July 14 – August 3

Creating of all the remaining tablets together with BuddyList necessary for the Buddies : Tablet to work.

August 4 - August 10

By this moment I will have completed almost the whole project. The remaining piece will include adding the settings menu in the options and some cleaning works. As the latter I understand removing bugs, re-writing any temporary solutions (//FIXMEs) and making sure that the new implemented classes work well together and with the rest of the game clients code.

August 11 – August 18

This is the last week so no major changes should have to be done here. I will use it for performing additional tests, fixing any remaining bugs and completing the documentation. I am also going to create a 'How To...' which will explain in an easy manner how to add new tablets, filters etc. without the need of digging through the entire documentation.

Links

• Submitted patch
• Full proposal on the Wiki