User:KingofCamelot - Revision history

KingofCamelot: /* Proposed Timeline */

2009-04-03T11:33:37Z

Proposed Timeline

← Older revision		Revision as of 11:33, 3 April 2009
Line 50:		Line 50:
	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.		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===		==Proposed Timeline==
	'''April 20 - May 23: Beginning'''		'''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.		*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.

KingofCamelot: /* Proposed Timeline */

2009-04-03T11:25:06Z

Proposed Timeline

← Older revision		Revision as of 11:25, 3 April 2009
Line 51:		Line 51:

	===Proposed Timeline===		===Proposed Timeline===
	'''April 20 - May 23: ~~Beginnings~~'''		'''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.		*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.		*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.
Line 78:		Line 78:


	'''August 10 - August 17: ~~Endings~~'''		'''August 10 - August 17: Ending'''
	*Google's suggested 'pencils down' period.		*Google's suggested 'pencils down' period.
	*Document anything which was missed during the previous iterations.		*Document anything which was missed during the previous iterations.

KingofCamelot: /* Google Summer of Code Application */

2009-04-03T11:19:26Z

Google Summer of Code Application

← Older revision		Revision as of 11:19, 3 April 2009
Line 91:		Line 91:

	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.		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==		==Appendix==

KingofCamelot: /* Detailed Proposal */

2009-04-03T11:05:06Z

Detailed Proposal

← Older revision		Revision as of 11:05, 3 April 2009
Line 34:		Line 34:

	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.		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===		===Proposed Timeline===

KingofCamelot: /* Detailed Proposal */

2009-04-03T10:19:07Z

Detailed Proposal

← Older revision		Revision as of 10:19, 3 April 2009
Line 28:		Line 28:

	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.		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===		===Documentation and Community Input===

KingofCamelot: /* Detailed Proposal */

2009-04-03T10:18:29Z

Detailed Proposal

Show changes

KingofCamelot: /* Abstract */

2009-04-03T09:51:41Z

Abstract

← Older revision		Revision as of 09:51, 3 April 2009
Line 19:		Line 19:
	==Abstract==		==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.		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.		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.

KingofCamelot: /* Abstract */

2009-04-03T09:51:22Z

Abstract

← Older revision		Revision as of 09:51, 3 April 2009
Line 18:		Line 18:

	==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.

			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.
	~~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==		==Detailed Proposal==

KingofCamelot: /* Reflections On GSoC 2008 */

2009-04-03T09:31:01Z

Reflections On GSoC 2008

← Older revision		Revision as of 09:31, 3 April 2009
Line 12:		Line 12:


	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. 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.		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.

KingofCamelot: /* References/Links */

2009-04-03T09:29:02Z

References/Links

← Older revision		Revision as of 09:29, 3 April 2009
Line 109:		Line 109:
	* [http://www.uweb.ucsb.edu/~davidsanders/Old_Application.htm Google Summer of Code 2008 Application for BZFlag]<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/Old_Application.htm#About_Me Google Summer of Code 2008 About Me]<br>		* [http://www.uweb.ucsb.edu/~davidsanders/Old_Application.htm#About_Me Google Summer of Code 2008 About Me]<br>
	* [http://www.uweb.ucsb.edu/~davidsanders/GSoC_patch.diff Patch]<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>