Difference between revisions of "SummerOfCodeProposal grantwu"

From The Battle for Wesnoth Wiki
(Timeline)
(Technical Details)
 
(9 intermediate revisions by 2 users not shown)
Line 17: Line 17:
  
 
===Patches for Wesnoth===
 
===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. 
 +
 
 +
[https://gna.org/patch/?1150 Patch#1]
  
 
==Experience==
 
==Experience==
Line 49: Line 51:
  
 
====Played Wesnoth====
 
====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 gameFor 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==
 
==Communication Skills==
Line 82: Line 84:
 
|-
 
|-
 
|align="right" width="125"|April 29th - May 23rd
 
|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="left"|Prototyping should begin nowThis 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="right" width="125"|June 14th - June 16th
+
|align="right" width="125"|May 24rd - July 10th
|align="left"|After a few weeks of rapid prototyping I hope to discuss the results of all the test runs with my mentorWe'll weigh the options and hopefully quickly come to a conclusion on what the ideal solution candidate.
+
|align="left"|Coding!  If this hasn't already begun it will at this point in timeActual programming of the new save system will begin now.
 
|-
 
|-
|align="right" width="125"|June 16th - July 10th
+
|align="right" width="125"|July 10th - July 13th
|align="left"|At this point I'll begin the final implementation of the codeOf course I'm still far from being doneI'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"|Midterm reviews are due at this point so I think my mentor and I will take a look back at everything we've doneCheck for giant gaping design holes, etcBasically 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"|July 10th - August 10th
+
|align="right" width="125"|July 13th - August 10th
|align="left" width="125"|So while my experience with open source is limited, from what I can see the success of any open source project is the communityAt this time I would like to release the final product to the community and try to use whatever good feedback I getI'll continue to polish it until the Google's given deadline and probably work on it beyond then.
+
|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 systemHopefully things will be done before the 10th so that some serious testing can happen before the final code is submitted.
 
|}
 
|}
  
 
===Technical Details===
 
===Technical Details===
I'm going to leave this section unpopulated for now until I become more familiar with Wesnoth's source code.
+
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. 
 +
 
 +
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.  Many of console_adapter.cpp's functions can be redone and should probably be placed in gamestatus.cpp.
 +
 
 +
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 [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 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.
  
 
===My Own Personal Gain===
 
===My Own Personal Gain===
Line 104: Line 113:
  
 
===Continued Involvement===
 
===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==
 
==Practical Considerations==
 
===Languages===
 
===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===
 
===Tools===
Line 124: Line 133:
 
===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]]

Latest revision as of 15:45, 3 April 2009

Basics

Introduction

My name is Grant Wu and I hope to work with the Wesnoth developers over the summer as part of Google's Summer of Code.

Preferred E-mail Address

grantwu at umich dot edu

Handles

My handle on the IRC channels is 'grantwu' while my name on the forums is 'zenneth'.

Why GSoC?

I want to participate in Google's Summer of Code in order to gain experience working with veteran coders on a project that interests me. I plan on entering the video game industry after I graduate so the Wesnoth project looks like the best fit to me.

School

I am currently enrolled at the University of Michigan in Ann Arbor. I am in my second year of studying Computer Science through the College of Engineering.

Patches for Wesnoth

I submitted one patch from the easycoding section. It was the only one about the savegame system so I did what it said.

Patch#1

Experience

Projects

My current experience is largely through assignments from my classes. One of my classes is entirely project based so I know how to handle larger tasks. The biggest programming project I've worked on so far was actually a video game. I made a 2D platformer with some physics twists to it. Not the most complicated but it gave me valuable experience.

Groups

My very first programming class at the University focused on pair programming. All of our projects were done with a partner. This taught me a lot of valuable lessons when it comes to just how fallible every programmer is. The video game project I described in the previous section was also done in a team of 4. The people I worked with were all passionate about video games and programming. I learned to appreciate being in such an environment and I'm well aware that some groups won't be as ideal.

Previous GSoCs

I have never participated in Google's Summer of Code before.

Open Source

I have very limited experience working with open source projects. By limited I mean I use Ubuntu as my standard operating system for my netbook. I hope to remedy this unfortunate situation.

Am I a Gamer

Am I a gamer? Hell yeah. Gaming is my passion. I play everything and anything. Unusually enough I was looking for a turn-based strategy RPG to play before I found Wesnoth. Convenient.

Type of Gamer

I'm a hardcore gamer. There's no other way to describe my relationship with video games.

Types of Games

Like I said before, I play pretty much anything. My favorites right now include Left 4 Dead, Civilization IV, Team Fortress 2, and Dawn of War II. I also play a lot of FIFA 09 and I still play Mass Effect now and then. I plan on getting more into Wesnoth too.

Types of Opponents

My ideal human opponent is a mythical beast that does not exist. Someone who is respectful but not afraid to do a little trash talking to put an edge on things. My ideal AI opponent also probably doesn't exist but I'm pretty sure devs fake it. The one thing that I feel an AI opponent has to do is be adaptable and challenging while remaining fair. I hope that gone are the days where computer bots could see through walls in shooters and have laser vision to pierce through fog of war in strategy games.

Story or Gameplay

I'd love to have both, but sadly its usually only one. If a game has poor story and good gameplay just the experience of playing the game will push it through. I feel like this is usually the case with games, not ideal at all. There has been the rare game where the story was what kept me playing. For example, when I'm in the right mood I like to burn through Japanese RPGs. Japanese RPGs so often fall into the same trappings when it comes to gameplay but the story keeps me mashing the attack command for hours and hours.

Played Wesnoth

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

English

English is my native tongue and I think I'm pretty good at communicating with it.

Player Community

Being a pretty competitive gamer myself I'm well aware of how nasty the player community can get (NERF PALADINS! NERF THE DEMOMAN!). I'm more than prepared to handle that.

Constructive Advice

In my opinion, if it isn't constructive then really is no reason to give it. When I give feedback I try to form it in a way that is most useful to the recipient.

How Well Do I Receive Advice

One of the positions I hold at my University is the Publications Chair for a student organization. I create flyers and basically mold the image of the org. Because of this I receive constant feedback from the other members about my work and I'm experienced with taking in a wide variety of suggestions. My group programming projects also had a lot of back and forth communication. After implementing a new feature we'd all sit down and discuss what's good, what's bad, and the person in charge of that feature would go back and make whatever changes we decided on.

Filter Feedback

Again my previous experiences have taught me a lot of about taking in and digesting feedback. You can't take every piece of advice as gospel. I've burned a lot of time sitting down and mulling over the feedback I've gotten on my work.

Project

Which Project I Picked

I picked the save game project. I hope to make the multiplayer and single player experience of Wesnoth indistinguishable, at least when it comes to saving.

Why This Project

If there's one thing that I love about games, its working together with another player. Getting a multiplayer campaign option working for Wesnoth would be a huge step for it and add a hugely valuable feature. In addition to this, I feel that this project is very doable with my current experience with C++. Finally, the class where I created my first game emphasized the important of UML and language-independent representation of code. I feel like I can use what I learned from that class on this project.

Timeline

March 25th - April 29th These are the remaining days of the school semester. I plan on using this time to familiarize myself with everything Wesnoth. Code, the community, everything.
April 29th - May 23rd 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.
May 24rd - July 10th Coding! If this hasn't already begun it will at this point in time. Actual programming of the new save system will begin now.
July 10th - July 13th 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.
July 13th - August 10th 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.

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 for 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. Many of console_adapter.cpp's functions can be redone and should probably be placed in gamestatus.cpp.

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

My Own Personal Gain

I hope to become involved in an active open source project and community while gaining experience on working with a video game. I'm pretty sure Wesnoth will provide both.

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

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

I write my code in either gedit or emacs. I use gedit because its a convenient and modern editor while I use emacs when working on my schools remote computing environments. I use g++ to compile my C++ code and I haven't needed to use anything else as of yet.

Fluent Programming Languages

I am most familiar with C++. I've spent two years working with it pretty extensively now. I also feel that one of the courses I'm taking now is covering some of the most vital aspects of the language and object oriented programming in general. The first part of the course was review but now we're going over abstract data types and the very important features that OO programming provides (from what I read, Wesnoth's lead dev is very passionate about encapsulation).

Fluent Spoken Languages

I am fluent in English and spoken Mandarin Chinese. I also know a bit of German.

Waking Hours

I'm usually up from late morning to early morning. 10AM - 3AM are most likely. During the summer I can be on IRC at almost all times though I like to keep an active and healthy lifestyle so I'll have to stray away from the keyboard at times.

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.

This page was last edited on 3 April 2009, at 15:45.