SummerOfCodeProposal Euschn

Euschn's SoC Proposal: Savegame Reorganization

hi, I'm euschn and I would like to contribute to wesnoth via GSoC

real name: Eugen

age: 26

location: Vienna, Austria

occupation: phd student for computer science, Vienna University of Technology

Questionaire

1) Basics

1.1) Write a small introduction to yourself.

My name is Eugen Jiresch, I live in Vienna, Austria, and I am 26 years old. I am a phd student in computer science at the Vienna University of Technology. My phd project is about formal models of computation and theory of programming languages. Despite the theoretic focus of my phd, I like coding a lot, which is one of my reasons for applying for GSoC.

1.2) State your preferred email address.

jiresch_(atsign)_logic_(dot)_at

1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?

euschn (same as my gna.org account)

1.4) Why do you want to participate in summer of code?

There are several reasons. First, I would like to take part in an interesting software development project. By doing so, I want to improve my skills and learn new things about programming. Then, being a gamer myself, I am very interested in contributing to the development a computer game, especially one that seems cool and fun to me (Wesnoth falls in that category). I have often dreamed about a job in game development in the future, and this could be a good opportunity to get started. Additionally, if I want a job for the summer, I want it to be something that is meaningful to me and needed/appreciated by others - like adding desired feature to a game. Finally, being a poor student, 4500$ is a lot of money to me.

1.5) What are you studying, subject, level and school?

As mentioned above, I am a phd student in computer science, at Vienna University of Technology

1.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for Wesnoth. If you have gained commit access to our SVN (during the evaluation period or earlier) please state so.

I submitted https://gna.org/patch/?1148 , improvement of random village (and landform) naming.

2) Experience

2.1) What programs/software have you worked on before?

Most of the software I have done was for university courses. I have done a bit of programming in games that support modding/custom maps like Starcraft of World of Warcraft, but nothing too fancy. Recently, I became a contributor to the inets project (see 2.4.1)

2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)

Yes, in university courses and the inets project (see 2.4.1)

2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?

No.

2.4) Open Source

2.4.1) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.

Yes, I recently became contributor to the inets project ( https://gna.org/projects/inets/ ). inets is a compiler from an interaction nets based language to C (for more information, see http://www.interaction-nets.org/) Interaction nets is an innovative formal model of computation, which is also a focus of my phd project. My involvement so far has been the implementation of extended pattern matching for the computational rules of the inets language, and some bug fixing.

2.5) Gaming experience - Are you a gamer?

Yes, since early childhood!

2.5.1) What type of gamer are you?

I am a passionate gamer, maybe even hardcore - allthough the definition of hardcore is quite fuzzy depending on game and community :). In short, I spend a *lot* of my free time playing computer games and checking out their respective communities.

2.5.2) What type of games?

My favorite genres and games include:

Role playing games: Final Fantasy series, Zelda series, Baldurs Gate series, Diablo series,...

Strategy games: Warcraft series, Starcraft, Spellforce, and just recently Wesnoth

Platforming: the usual old school nintendo stuff

Action: Quake series, Metroid series, Portal

singleplayer vs multiplayer:

I enjoy a good singleplayer game a lot. But I also like multiplayer, and I am doing a lot of online multiplayer gaming. For example, a few years ago I was playing Warcraft 3 online a lot, and got to know the online community pretty well. So while I have not played Wesnoth a lot, I have a good feeling for online gaming communities. (if they are comparable at all!)

2.5.3) What type of opponents do you prefer?

I like opponents that can teach me something and help me improve my skills in a game, or just generally make a game fun. To me, playing against a good and fun oponent in a multiplayer game makes winning or losing of secondary importance. Generally, I do not like oponents who are sore losers, and I am doing my best not to be one, either.

2.5.4) Are you more interested in story or gameplay?

I would say it depends on the game. Awesome gameplay can make a great game even with a lackluster story (or none at all). In my opinion, this is often true for multiplayer games, where most of the fun comes from human oponents (or allies). But singleplayer games with a weak story can be great, too (everyone who has ever enjoyed a Super Mario game has to agree). Then again, I remember many cool games especially for their story (RPGs mostly, but also some strategy games). So all in all, either can make a great game and I am interested in both.

2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.

I only recently got to know Wesnoth. I have played some of the singleplayer campaigns, and I like it a lot so far. It is a nice mix of strategy and roleplaying, and I plan to continue playing it (apart from getting to know it for GSoC!). I understand that being an experienced wesnoth player helps with some projects, I hope this is not so mandatory for savegame reorganization.

3) Communication skills

3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.

I am a German native speaker, but I feel I can fully express myself in English.

3.2) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.

Yes, I am fine with interacting with other players, even if it is going to be rough. As mentioned in 2.5.2), I have experience with online gaming communities (especially Blizzard games), so I am used to their not so friendly aspects.

3.3) Do you give constructive advice?

Absolutely, I try to keep my advice as constructive as possible.

3.4) Do you receive advice well?

Yes, constructive advice is a chance to improve myself, and I always give my best to take that chance.

3.5) Are you good at sorting useful criticisms from useless ones?

Yes.

4) Project

4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?

Yes, I selected Savegame reorganization.

4.2) If you have invented your own project, please describe the project and the scope.

4.3) Why did you choose this project?

There are several reasons. First, I want to work on a project that is deemed necessary or desired by the wesnoth community. I think redesigning savegames is such a project. I do not want to work on some feature that noone really wants. Second, I like the concept of multiplayer campaigns. Cooperative multiplayer games are good fun (I like them a lot myself), but they are rare. Only few games have coop modes, especially in combination with story-driven game types like a campaign in wesnoth. So if I can help to promote cooperative game types by improving wesnoth's savegame design, I will be very glad to do so. In general, it seems to me that studying a "messy" design (Im quoting the wiki here) and trying to come up with a better one is a good challenge that I would like to take. Also, I am curious how this component works in a project of this size, as I have not yet worked on such a big program and I would like to learn what makes it tick. Finally, I think I have the required skills to succeed at this project (with help from my mentor of course!). I have good C++ skills and I feel up to study the current implementation and develop a deliberate design in cooperation with my mentor.

4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".

My estimated timeline is affected by both "special things" mentioned in the question. First, I will have to spend some time on university stuff up to mid June. In this period, I can of course still work on the GSoC project, just not full time. I think that I will be able to work 20-25h a week on wesnoth during that time. To tackle this problem, some people at #wesnoth-dev have suggested that I start early, which is generally possible. I could start on the actual work as soon as May 16th, which is a week earlier than the official date. This could help me to regain the lost time. Note that this estimation is more on the worst-case side. update: It looks like I will have more time in June anyways, but I still cannot guarantee it. I will do the "early start" in any case.

Still, if you think this is not feasible, please tell me so I can reconsider my options. Second, I will most likely be on vacation from July 12th to July 19th. I hope this would not be too much of a problem.

see below for a more detailed timeline.

4.5) Include as much technical detail about your implementation as you can

The description of the Savegame project in the wiki suggests that several technical details will be unclear until the design, which is a rather large milestone itself, is fleshed out. Concerning the design milestone, I plan to deliver a UML model describing the new savegame organization.

4.6) What do you expect to gain from this project?

I would like to:

* gain insight on the development of large open source projects
* learn more about game design
* improve my coding skills
* last but not least, I want to gain the satisfaction of contributing something worthy to such a big project

4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?

The success of my project and/or the feeling that I have not completely made a fool of myself :).

5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?

  * Subversion (used for all commits)

Yes, I have used SVN for university projects and my master thesis.

  * C++ (language used for all the normal source code)

Yes, I think I have good C++ skills. To elaborate with the C++ quiz on http://www.wesnoth.org/wiki/Hackingwesnoth : I fit in the "can answer most questions" category (I looked up the ones I did not know of course).

  * Python (optional, mainly used for tools)

Sorry, I do not have Python skills.

  * build environments (eg cmake/autotools/scons)

I used autotools in a university project.

5.2) Which tools do you normally use for development? Why do you use them?

For larger projects: Eclipse, Netbeans. I use them for their debugging capabilities and for convenience features like code completion for smaller stuff: vi, sometimes jEdit, gdb. I use them for their simplicity and their wide availability.

5.3) What programming languages are you fluent in?

Java, C++, Haskell. I have mostly used them in university courses. Additionally, I have been a tutor for undergraduate Java courses and used Haskell for my masters project.

5.4) What spoken languages are you fluent in?

I am a German native speaker and I am fluent in English. I also speak a bit French and Russian

5.5) At what hours are you awake and when will you be able to be in IRC (please specify in UTC)

Austria is UTC+2, so my usual working/availability hours would be UTC: 7am - 3pm, but its flexible to some degree. On some days, I will most likely be available longer into the evening.

5.6) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail.

I would mind not at all. I am fine with both phone and voice chat if you can bear with my german accent :).

Ideas on Savegame Reorganization

work in progress

config_adapter vs game_state

The game_state class populates its fields directly from a config object (supplied as constructor argument). config_adapter::get_player_info takes existing C++ objects - a vector of team objects, a unit_map, a gamemap,... - and populates them with a config object and a game_state object.

While the layered approach of config_adapter does create some separation between C++ code and raw persistence information, it results in worse encapsulation: config_adapter needs to be able to access a lot of data of game_state and gamestatus. encapsulation could be improved with the method of directly populating game state.

It seems the current design favors the latter approach. I would stick to this general design for savegame processing.

This leads to the (already posed) question of how to remove config_adapter. Actually, the methods of config_adapter are already hardly used: only play_controller::init uses get_player_info(), get_first_human_team() and get_unique_saveid(). get_theme() is used by a couple of other classes, but that is only a few lines of code, which could be easily moved somewhere else.

From my first impression, it would make sense to move the code into game_state or gamestatus (which could be merged aswell, see below), as they already have code for similar purposes (e.g., the game_state constructor or game_state::get_player() ).

player_info vs team_info

most of player_info's fields are also stored in team.team_info. Therefore, it would make sense to merge those two.

From my current understanding, the only information that is exclusive to player_info is gold_add and the recall list available units. These should be added to team_info. This also makes sense with respect to multiplayer campaigns: Several teams might have recallable units and carryover gold from previous scenarios.

Note that at the moment, carryover gold is stored in player.gold, where as the current gold is stored in team_info.gold (meaning replays rely on player_info to determine the correct starting gold value). This seems confusing to me. An easy fix would be to add a carryover_gold member to each team_info. (see also: comparison of [player] and [snapshot.side] below)

gamestatus vs game_state

game_state contains most of the savegame information, such as general information (label, version, campaign_type, etc.), a list of players and the config objects corresponding to the snapshot, the initial state, and the replay data (basically all steps/events/moves since the start of the scenario).

gamestatus seems to act as a wrapper class for a game_state, containing some "global" game information itself (time of day, number of turns). gamestatus also contains a vector of team objects, whereas the player_info objects are held by game_state. Since they share a lot of information it would make sense to have them contained in the same class.

It could be an option to merge gamestatus and game_state. Both classes seem to serve the same purpose, and the distribution of game information between them seems arbitrary: why should game_state not contain the list of teams? why are some fields of game_state not considered "global status" (e.g., campaign_type or random_seed) and hence put in gamestatus? Additionally, merging these two classes might improve encapsulation aswell (Since gamestatus needs to access game_state fields at the moment).

WML Mapping Redundancies

In general, we can distinguish between two types of redundancies:

A: information is stored in two or more places in a savegame file (WML), but is mapped to the same c++ object.

B: information is stored in two or more places in WML, and is mapped to more than one c++ object.

Both types are worth fixing.

As mentioned on SoC_Ideas_Savegame, WML events can change a lot of information of a scenario, which makes some redundancies, e.g., between [snapshot] and root/[replay_start], necessary. I will list some info in WML that I think is unnecessarily redundant. (and verify my thoughts with a WML expert).

root vs [snapshot] (type A)

serveral fields appear on the root and again under [snapshot]. The following are candidates for redundancy elimination:

* abbrev
* version
* campaign (SP only)
* campaign_type
* campaign_define
* random_seed
* difficulty
* random_calls
* underlying_unit_id (task?)

I think these need to be stored twice: (as they can change through the course of the scenario)

* label (different in root and [snapshot])
* completion
* end_text_duration (different endings possible)

[player] vs [snapshot.side] (type B)

[player] (SP only) only holds a few items, most of which occur in [snapshot.side]. Additionally, both map to different c++ objects, player_info and team.info_ . [player] only has a few attributes, most of which occur in [snapshot.side] aswell. These are:

* save_id/id/current_player
* name
* gold
* can_recruit/recruit

The only attribute of [player] that does not occur in some form in [side] seems to be gold_add (whether carryover gold is added to the start_gold or the max of the two is taken as start_gold).

Hence it makes sense to integrate [player] into [side], though there are a few things to consider. For example, the information on gold is saved in a messy way: For each team, the game needs to store the current gold, the starting gold and (in campaigns) the carryover gold. At the moment, the current gold is stored in snapshot.side, the starting gold is stored in [snapshot.side] and [replay_start], and the carryover gold is stored in [player] and [snapshot.side] (in start_gold, as a sum of start+carryover). So, assuming replays do not access snapshot data (its empty in replay files), they rely on [player] to get the correct starting gold. Obviously this can be organized in a better way.

[player] vs [snapshot.player] (type A)

These two tags have exactly the same values. (depending on the status of http://www.wesnoth.org/wiki/EasyCoding#consistent_player_information , this might be fixed already?)

[replay_start.side] vs [snapshot.side] (type B ?)

[replay_start] needs to have information on the initial status of a side. Therefore, it should save all attributes of side that can be changed by WML. Yet, as replays do not access [snapshot], there are also some unchangeable (and hence redundant) attributes in [replay_start]. It would make sense to move them to a central place (e.g., the root).

These seem unlikely to be changed with WML events:

* flag
* flag_icon
* flag_rgb

These are probably changeable:

* controller
* fog
* shroud

the following keys are associated with units. They do not necessarily need to be saved in [snapshot.side], as side contains all unit information in [unit] tags anyways:

* unrenamable
* side
* type
* canrecruit
* recruit
* id
* name

[replay_start.side] also has a 'gold' attribute storing the starting gold (without carryover), where [snapshot.side] stores the starting gold (with carryover) in 'start_gold' and uses 'gold' for current gold.

game events (type A?)

It seems that most game events are stored redundantly in [snapshot] and [replay_start]. Can WML events change other WML events? If not, they could be moved to a central place aswell?

<silene> yes, you can have more event in the snapshot (created events are added), and you can also have less events in it (consumed events are removed)

How to improve the organization

To summarize the thoughts above, these are the first ideas to reorganize savegames:

C++ changes

* remove config_adapter (add the code to game_state)
* merge player_info and team.team_info
* merge game_state and gamestatus (or make a clearer distinction between them)

Savegame WML changes

* remove redundancies between root and [snapshot]
* get rid of the [player] tag, add its exclusive information to [side]
* remove redundancies between [replay_start.side] and [snapshot.side] (where possible)

Another suggestion from the developers is to change the layout of AI information in a [side]: currently, there are some AI related keys at the root of [side], others are wrapped in an [ai] tag. This could be improved to add all keys below a new top-level AI tag.

Milestones and Timeline

work in progress

Possible Milestones

1) the UML model of the new design

2) removal of WML redundancies in savegames (where possible)

3) implement the unified design (partitioned into a pre and post midterm milestone)

4) documentation of the implementation

Timeline

april 20th - may 15th: "bonding peroid":

* get familiar with the code and WML
* start the documentation of the current implementation of savegames
* evaluate the problems with/needs for multiplayer campaigns

may 16th - may 31st: the actual start of work:

* finish evaluation of problems
* develop a new design of "unified" savegames
* deliver UML model

june 1st - june 15th:

* start of implementation:
* determine set of features/milestones to be ready for mid-term
  examples: singleplayer functionality, replay functionality, multiplayer campaign features,...

june 16th - june 30th:

* implementation of mid-term feature set
* track progress, compare to timeline

july 1st - july 11th:

* finish implementation of the mid-term feature set
* goal: have a (partially) functional implementation for mid-term

july 12th - july 19th:

* vacation

july 20th - august 2nd:

* implementation of missing features

august 3rd - august 17th:

* testing, bug fixing
* documentation of implementation (additions and changes to the UML model)

back to: GSoC Ideas