WesnothStatistics - Revision history

Radx: /* Experience */

2008-05-19T19:39:39Z

‎Experience

Radx: /* Experience */

2008-05-19T19:39:23Z

‎Experience

Radx at 19:28, 19 May 2008

2008-05-19T19:28:12Z

Radx: Fixing typos in Idea section.

2008-03-27T19:39:28Z

Fixing typos in Idea section.

Radx: Fixing idea typo

2008-03-26T02:28:08Z

Fixing idea typo

Radx at 01:56, 26 March 2008

2008-03-26T01:56:32Z

Radx: Idea section ident changes.

2008-03-26T01:55:30Z

Idea section ident changes.

Radx: Changes to idea, timeline sections.

2008-03-26T01:53:34Z

Changes to idea, timeline sections.

Radx: Added crash report idea.

2008-03-24T17:44:01Z

Added crash report idea.

Radx: Fixing email address.

2008-03-24T17:29:07Z

Fixing email address.

@@ Line 13: / Line 13: @@
 * What programs/software have you worked on before?
-** I participated in several commercial projects, including a commercial FPS game (during my CO-OP). As far as open source goes, I wrote a semantic web plugin for the OpenBabel chemical suite (part of my research). This project is be published on Google Code.
+** I participated in several commercial projects, including a commercial FPS game (during my CO-OP). As far as open source goes, I wrote a semantic web plugin for the OpenBabel chemical suite (part of my research). This project is published on Google Code.
 * Have you developed software in a team environment before? (As opposed to hacking on something on your own)

@@ Line 13: / Line 13: @@
 * What programs/software have you worked on before?
-** I participated in several commercial projects, including a commercial FPS game (during my CO-OP). As far as open source goes, I wrote a semantic web plugin for the OpenBabel chemical suite (part of my research). This project will be published on Google Code soon.
+** I participated in several commercial projects, including a commercial FPS game (during my CO-OP). As far as open source goes, I wrote a semantic web plugin for the OpenBabel chemical suite (part of my research). This project is be published on Google Code.
 * Have you developed software in a team environment before? (As opposed to hacking on something on your own)
@@ Line 23: / Line 23: @@
 * What development model would you use (e.g. keywords: V-model, XP programming, agile programming, iterative; with the help of prototyping, formal specifications, tests, etc).
 **I would use a mix of iterative/agile model with unit-testing and prototyping.
 == Open Source ==

← Older revision		Revision as of 19:28, 19 May 2008
Line 153:		Line 153:
	At this moment I recompiled my Wesnoth client and forced it to submit campaign logs to my webserver; I rewrote the existing cgi script to parse the logs and upload them to local MySQL database; I also implemented a simple web service (in Ruby on Rails) which presents some statistical data to the user. The images are generated using the Google Charts API.		At this moment I recompiled my Wesnoth client and forced it to submit campaign logs to my webserver; I rewrote the existing cgi script to parse the logs and upload them to local MySQL database; I also implemented a simple web service (in Ruby on Rails) which presents some statistical data to the user. The images are generated using the Google Charts API.

−	~~This prototype can be accessed at http://wesnoth.radx.org/player~~

	[[Category:Summer of Code]]		[[Category:Summer of Code]]

@@ Line 120: / Line 120: @@
 At the moment Wesnoth has a statistics system which could be accessed at http://stats.wesnoth.org . In Wesnoth client, there's an option which enables anonymous log submission to the existing statistics server. If enabled, Wesnoth client will submit campaign logs to the statistics server. With this information available, developers could track potential problems across existing campaigns - check where people tend to have problems, where people tend to give up, or where they have an easy time, and so on.
-The main idea is to get people interested in submitting stats. Players could compare how they perform to the rest of players, while developers will get the necessary statistical data.
+The main idea of my proposal is to get people interested in submitting stats. Players could see how they perform comparing to other players, while developers will get the necessary statistical data.
 I propose two main ideas:

← Older revision		Revision as of 02:28, 26 March 2008
Line 132:		Line 132:
	**Finally, make the system visually appealing to both players and developers.		**Finally, make the system visually appealing to both players and developers.

−	*Secondly, build~~-in~~ chart/graph drawing system into the Wesnoth client. This system would let players upload and compare their results to the rest of the player base after each single-player or multi-player campaign.	+	*Secondly, build chart/graph drawing system into the Wesnoth client. This system would let players upload and compare their results to the rest of the player base after each single-player or multi-player campaign.

@@ Line 129: / Line 129: @@
 **Give developers the ability to log specific campaign parts (this could be implemented by tagging units as special units without any back-end changes).
 **Implement OS/platform specific log gathering.
-**Additionally for the statistics web system, remove slow and expensive chart drawing SVG routines and use of Google Charts API instead (offload this unnecessary work from the web-server).
+**Remove slow and expensive chart drawing SVG routines and use of Google Charts API instead (offload this unnecessary work from the web-server).
 **Finally, make the system visually appealing to both players and developers.

@@ Line 124: / Line 124: @@
 I propose two main ideas:
-First is to modify/upgrade the existing stats system and make sure it is scalable (will perform well enough under increased amount of log submissions). I plan to test the current cgi log submission system and see how it performs under these conditions. If there's a problem with this approach, I will rewrite this part as a daemon (using c++, boost, perhaps asio library). This part most likely will be implemented as a lightweight HTTP based daemon (so we could still accept logs from old clients and use port 80).
+*First is to modify/upgrade the existing stats system and make sure it is scalable (will perform well enough under increased amount of log submissions).
-Increase the number of useful stats for both players and developers. Let developers compare statistical differences between versions. Give developers the ability to log specific campaign parts (this could be implemented by tagging units as special units without any back-end changes). Implement OS/platform specific log gathering. Additionally for the statistics web system, remove slow and expensive chart drawing SVG routines and use of Google Charts API instead (offload this unnecessary work from the web-server). And finally, make the system visually appealing to both players and developers.
+**I plan to test the current cgi log submission system and see how it performs under these conditions. If there's a problem with this approach, I will rewrite this part as a daemon (using c++, boost, perhaps asio library). This part most likely will be implemented as a lightweight HTTP based daemon (so it could still accept logs from old clients and use port 80).
-Secondly, build-in chart/graph drawing system into the Wesnoth client. This system would let players upload and compare their results to the rest of the player base after each single-player or multi-player campaign.
+*Secondly, build-in chart/graph drawing system into the Wesnoth client. This system would let players upload and compare their results to the rest of the player base after each single-player or multi-player campaign.

@@ Line 120: / Line 120: @@
 At the moment Wesnoth has a statistics system which could be accessed at http://stats.wesnoth.org . In Wesnoth client, there's an option which enables anonymous log submission to the existing statistics server. If enabled, Wesnoth client will submit campaign logs to the statistics server. With this information available, developers could track potential problems across existing campaigns - check where people tend to have problems, where people tend to give up, or where they have an easy time, and so on.
-This current statistics system has a couple of problems, however. In this idea I will try to address some of these problems and discuss possible solutions.
+The main idea is to get people interested in submitting stats. Players could compare how they perform to the rest of players, while developers will get the necessary statistical data.
-First of all, in order to receive more accurate results about campaigns we would need to increase our dataset. This could be achieved by making 'log submission' option more accessible to the player; for example creating a dialog which would ask user if it's ok to submit the data upon the first run of the Wesnoth client. This would bring more people into the statistics submission program.
+I propose two main ideas:
-However it would also increase the stress on the server part which is responsible for accepting logs from players.
+First is to modify/upgrade the existing stats system and make sure it is scalable (will perform well enough under increased amount of log submissions). I plan to test the current cgi log submission system and see how it performs under these conditions. If there's a problem with this approach, I will rewrite this part as a daemon (using c++, boost, perhaps asio library). This part most likely will be implemented as a lightweight HTTP based daemon (so we could still accept logs from old clients and use port 80).
-Another problem with the current statistics system is that the charts which are used to present statistical information are drawn using slow and resource hungry SVG generation routines; It would make more sense to offload this part onto the 3rd party service, such as Google Charts (please see http://code.google.com/apis/chart ).
+Secondly, build-in chart/graph drawing system into the Wesnoth client. This system would let players upload and compare their results to the rest of the player base after each single-player or multi-player campaign.
@@ Line 145: / Line 133: @@
-* Until the end of April I plan to hammer out the requirements and have a strong prototype model. I plan to interact with developers and get into the Wesnoth source.
+* Until the end of April I plan to hammer out the requirements and have a strong prototype model. I plan to interact with developers and get into the Wesnoth source. I also plan to post several threads on Wesnoth forums regarding my idea and collect interesting, insightful ideas from the Wesnoth community.
 * Unfortunately I cannot start working on this early as I have exams which are coming up in April.
-* I expect to have a completely tested and working statistics system by the end of June.
+* I expect to have a completely tested and working statistics system (web part) by the end of June.
-* At that point I will start working on integrating additional statistics gathering routines into the Wesnoth client.
+* At that point I will start working on integrating statistics system into the Wesnoth client.
-* I am quite flexible with my time; Should the time permit (if I finish everything mentioned above before the end of term) I could work on integrating a basic crash report system.
+* I am quite flexible with my time; should the time permit (if I finish everything mentioned above before the end of term) I could work on integrating a basic crash report system.

@@ Line 4: / Line 4: @@
 My name is Myk and I am currently a full time graduate student (Masters, Computer Science) at CU, Ottawa, Canada.
-My preferred email address is 'gamedev_A-T_konyk_D-O-T_org'. On IRC/forums/gna I am 'radx'.
+My preferred email address is 'mkonyk_A-T_gmail_D-O-T_com'. On IRC/forums/gna I am 'radx'.
 My main reason for participating in this project is that I am passionate about any kind of game development. I would certainly want to work in a gamedev industry once I graduate; I have also never participated in the Google Summer of Code, which I hope will prove to be an exciting, interesting, and of course challenging, experience.