Difference between revisions of "SummerOfCodeProposal grantwu"
(→Technical Details) |
m (→Continued Involvement) |
||
Line 113: | 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== |
Revision as of 13:55, 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.
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 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.
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 [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.
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).
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.