SummerOfCodeProposal grantwu - Revision history

Grantwu: /* Technical Details */

2009-04-03T15:45:45Z

‎Technical Details

Grantwu: /* Played Wesnoth */

2009-04-03T13:57:57Z

‎Played Wesnoth

Grantwu: /* Continued Involvement */

2009-04-03T13:55:09Z

‎Continued Involvement

Grantwu: /* Technical Details */

2009-04-03T13:54:15Z

‎Technical Details

Grantwu: /* Technical Details */

2009-04-03T02:26:47Z

‎Technical Details

Grantwu: /* Technical Details */

2009-04-03T02:26:09Z

‎Technical Details

Grantwu: /* Languages */

2009-04-03T02:20:40Z

‎Languages

Grantwu: /* Timeline */

2009-04-03T02:19:26Z

‎Timeline

Grantwu: /* Patches for Wesnoth */

2009-04-03T02:13:13Z

‎Patches for Wesnoth

Yogi Bear at 22:59, 27 March 2009

2009-03-27T22:59:49Z

@@ Line 103: / Line 103: @@
 For the game_state and gamestatus classes, the gamestatus class takes a game_state object as in argument for several of its methods and it also for some reason is the method that reads in the player data even though game_state is the class that writes to a save file.  This seems unusual and should probably be changed with either a merger of the two classes or some reorganization of who reads and writes what data.
-Some of the redundant information between the [player] and [snapshot] and [replay_start]->[player] tags has been removed in the patch I submitted.  But in addition to this I realy wonder if the [player] tag in the [replay_start] section is really necessary.  I think maybe the starting information for a player should just be written to and read from the [snapshot] section since that's where this information is always read from after the start of a mission anyway.  Also, both [snapshot] and [replay_start] sections contain a lot of similar data.  This is like the player information idea where the game only uses [replay_start] for the beginning of missions and then uses information found in [snapshot] after that.  I feel like this is unnecessary and the replay_start section could be potentially removed.
+Some of the redundant information between the [player] and [replay_start]->[player] tags has been removed in the patch I submitted.
-My vision for the format of the savegame file is more or less summed up from the paragraph above.  I want to reduce the redundant information so that savegame info is read and written to one location.  This will also make it potentially easier for savegame files to hold new info such as persistent kill information for a unit (I think this would be very cool, unless of course its already there and I just wasn't looking hard enough).
+My vision for the format of the savegame file is more or less summed up from the paragraphs above.  I want to reduce the redundant information so that savegame info is read and written to one location.  This will also make it potentially easier for savegame files to hold new info such as persistent kill information for a unit (I think this would be very cool, unless of course its already there and I just wasn't looking hard enough).
 This is just a brief overview of what I've learned so far from looking at the code and speaking with other Wesnoth devs.  I'll definitely have more to change after some more time with everything.

@@ Line 51: / Line 51: @@
 ====Played Wesnoth====
-I have played a little bit.  I didn't know about it until I saw it on GSoC's list of projects.  I plan on sinking my teeth into it more and if worse comes to worst at least I was introduced to a good game.  For the moment I'm going to try to get better at the game through single player and eventually make the dive into multiplayer.
+I've played a good amount of Wesnoth now.  I definitely enjoy both single player and multiplayer but my favorite way to play is cooperatively with a friend against AI opponents.  I'm definitely not a veteran Wesnoth player but I've probably wasted time where I should've been working on my proposal and such by playing the game a little too much.
 ==Communication Skills==

@@ Line 113: / Line 113: @@
 ===Continued Involvement===
-I feel as though after reading the documentation and just lurking around the IRC channel and forums that the Wesnoth community is a very healthy one.  My continued involvement with the project is directly related to the activity of the community as a whole.
+I feel as though after reading the documentation and just lurking around the IRC channel and forums that the Wesnoth community is a very healthy one.  My continued involvement with the project is directly related to the activity of the community as a whole.  Also, getting the multiplayer campaigns fully functional is something I'm very interested in and will probably stick around and try to help push this initiative.
 ==Practical Considerations==

@@ Line 97: / Line 97: @@
 ===Technical Details===
-There is a lot of redundant info floating around in different places with the current savegame system.  There is also some code that takes away the encapsulation of some pretty vital objects.  Specifically, the team object found in team.cpp contains nearly all of the vital information on a player.  Despite this, the gamestatus.cpp file contains a player_info struct.  This struct basically duplicates all the info already found in team.cpp.  There's really no reason fro the player_info struct to exist.  When it comes to encapsulation, the console_adapter.cpp file contains methods that have write access over data vital to save files when it really shouldn't.
+There is a lot of redundant info floating around in different places with the current savegame system.  There is also some code that takes away the encapsulation of some pretty vital objects.  Specifically, the team object found in team.cpp contains nearly all of the vital information on a player.  Despite this, the gamestatus.cpp file contains a player_info struct.  This struct basically duplicates all the info already found in team.cpp.  There's really no reason for the player_info struct to exist.
 This is just a brief overview of what I've learned so far from looking at the code and speaking with other Wesnoth devs.  I'll definitely have more to change after some more time with everything.

@@ Line 99: / Line 99: @@
 There is a lot of redundant info floating around in different places with the current savegame system.  There is also some code that takes away the encapsulation of some pretty vital objects.  Specifically, the team object found in team.cpp contains nearly all of the vital information on a player.  Despite this, the gamestatus.cpp file contains a player_info struct.  This struct basically duplicates all the info already found in team.cpp.  There's really no reason fro the player_info struct to exist.  When it comes to encapsulation, the console_adapter.cpp file contains methods that have write access over data vital to save files when it really shouldn't.
-This is just a brief overview of what I've learned so far from looking at the code and speaking with other Wesnoth devs.
+This is just a brief overview of what I've learned so far from looking at the code and speaking with other Wesnoth devs.  I'll definitely have more to change after some more time with everything.
 ===My Own Personal Gain===

@@ Line 107: / Line 107: @@
 ==Practical Considerations==
 ===Languages===
-All the required Computer Science courses taught through the College of Engineering here use C++.  I'm very familiar and comfortable with writing code in it and learning with C++.  I don't know very much Python and I'm not familiar with build environments.  Build environments are number one on my list of things to learn though.
+All the required Computer Science courses taught through the College of Engineering here use C++.  I'm very familiar and comfortable with writing code in it and learning with C++.  I've built Wesnoth enough times with scons I've looked around some of the scripts so I think I'm pretty comfortable with it now.
 ===Tools===

@@ Line 84: / Line 84: @@
 |-
 |align="right" width="125"|April 29th - May 23rd
-|align="left"|Begin working with my mentor on the overall design of how to change the save file structure.  I should be familiar enough with how everything works by this point to keep things moving, however, this is the most important part of the process so I a significant amount of time should be devoted to design.  UML diagrams and such will be drawn up during this time.
+|align="left"|Begin working with my mentor on the overall design of how to change the save file structure.  I should be familiar enough with how everything works by this point to keep things moving, however, this is the most important part of the process so I a significant amount of time should be devoted to design.  UML diagrams and such will be drawn up during this time.  I'll still probably be getting fully up to speed with some of the deeper more intricate aspects of the source code.
 |-
-|align="right" width="125"|May 24rd - June 14th
+|align="right" width="125"|May 24rd - July 10th
-|align="left"|Prototyping should begin now.  This is also the prescribed "start coding!" time from Google.  Hopefully with the early start on the project this will give me time to come up with more than one prospective implementation idea to work with.  This way I can start prototyping and see if there are any unforeseen shortcomings to the proposed solutions.
+|align="left"|Coding!  If this hasn't already begun it will at this point in time.  Actual programming of the new save system will begin now.
 |-
-|align="right" width="125"|June 14th - June 16th
+|align="right" width="125"|July 10th - July 13th
-|align="left"|After a few weeks of rapid prototyping I hope to discuss the results of all the test runs with my mentor.  We'll weigh the options and hopefully quickly come to a conclusion on what the ideal solution candidate.
+|align="left"|Midterm reviews are due at this point so I think my mentor and I will take a look back at everything we've done.  Check for giant gaping design holes, etc.  Basically the midterm will be a good time to assess everything that's happened so far and see if there needs to be any change of direction with the original plan.
 |-
-|align="right" width="125"|June 16th - July 10th
+|align="right" width="125"|July 13th - August 10th
-|align="left"|At this point I'll begin the final implementation of the code.  Of course I'm still far from being done.  I'll work closely with my mentor to get the final product up and running by when Google requests us to turn in midterm reviews.
+|align="left"|This is it!  The last month of work.  I'll be working frantically these days to finish up the new, reorganized, restructured, and more unified save system.  Hopefully things will be done before the 10th so that some serious testing can happen before the final code is submitted.
 |}

@@ Line 17: / Line 17: @@
 ===Patches for Wesnoth===
-I have not yet submitted anything to the Wesnoth project but I plan on doing my best to change that.
+I submitted one patch from the easycoding section.  It was the only one about the savegame system so I did what it said.
 ==Experience==

← Older revision		Revision as of 22:59, 27 March 2009
Line 124:		Line 124:
	===Phone Calls===		===Phone Calls===
	I'd actually prefer to communicate on the phone. Makes for a stronger relationship. Unfortunately, computer science lends itself to digital communication due to the technical nature of the subject.		I'd actually prefer to communicate on the phone. Makes for a stronger relationship. Unfortunately, computer science lends itself to digital communication due to the technical nature of the subject.
		+
		+	[[Category:Summer of Code]]