Difference between revisions of "SoC Ideas Savegame"

From The Battle for Wesnoth Wiki
(See also)
(See also)
Line 34: Line 34:
 
=== See also ===
 
=== See also ===
 
[[SummerOfCodeIdeas|Summer of Code Ideas]] - The root where all information regarding SoC is (or better should be) linked from.<br>
 
[[SummerOfCodeIdeas|Summer of Code Ideas]] - The root where all information regarding SoC is (or better should be) linked from.<br>
[[User:SkeletonCrew#Savegame_format|savegame contents]] - Some ideas about the current and future content of savegames.
+
[[User:SkeletonCrew#Savegame_format|savegame contents]] - Some ideas about the current and future content of savegames.<br>
 
[[SavefileWML|Savegame WML]] - Information about the format used for storing savegame information.
 
[[SavefileWML|Savegame WML]] - Information about the format used for storing savegame information.
 
[[Category:Summer of Code]]
 
[[Category:Summer of Code]]

Revision as of 20:48, 19 March 2009

Reorganizing the savegame format

Wesnoth basically supports two types of scenarios: Single player campaign (one campaign consists of several scenarios) and multiplayer (one isolated scenario). The savegame information for both share a lot of stuff, but there are also differences, information which is unique to each of them.

Lately, there is another development showing up, which wasn't really considered in the beginning of wesnoth: Multiplayer campaigns. Those kind of work at the moment, but they are a little uncomfortable, because the savegame format does not support them good enough.

Your task will be to develop a uniform savegame format, that allows to store all information needed for any kind of scenario and to write the code supporting this format.

General description

The idea behind this project is that there won't be any significant differences (at least regarding the savegame format) between single player and multiplayer anymore. Rather, multiplayer is seen as an enhancement to single player with the main difference being that multiple player information will have to be stored.

From the coding side of perspective, you might think that you will be able to reuse lots of existing code. In a way this will be true, but there are also some specialties about it:

  • At the moment, the code for processing savegames is spread along several files and it is full of workarounds to serve the three main 'consumers': Single player scenarios, multiplayer scenarios and replays. In other words: It is a mess, one of the worst you will be able to find within the wesnoth codebase. Every new coder has to struggle just to find the functionality he is looking for and senior developers desperately try to avoid any changes to it.
  • Although you will be able to reuse some of the code, you also will have to think of a new design, that combines the current still separated approaches to the different types of scenarios. It might turn out, that starting your code from scratch is a better idea than rewriting the existing stuff.
  • Basically, the challenge of this project won't be writing the code in the first place, but rather figuring out what is the best way to rework it: How do i minimize impact? How can i design the code so that it is easy to understand and maintainable? What information is needed upfront to achieve that?. These are the important questions that you will tackle in close teamwork with your mentor.
  • The intent of this project is to adapt the content of savegames, not the format that content is stored in. WML has been proven to be an efficient format and we don't want to change it.

Required knowledge and talent

  • A minimal knowledge of C++ is required, a good knowledge of C++ is desired : The main challenge will be to become familiar with the common style of wesnoth coding, since we widely use some advanced C++ features like STL and rely on a couple of libraries. However, the savegame processing code is relatively straightforward and not as complex as many other areas.
  • Design capabilities: Because your code will have to integrate into the current wesnoth architecture, you can't just grab the keyboard and start hacking (well, you shouldn't do that anyway but that's another topic for another day ;-). So a very important part of this project will be to provide a good design and put some thought into that. It is also essential, that this won't happen solely inside your head but that you also provide some visible results (see the list of milestones and deliverables below). Static (or maybe even dynamic) UML models would be really cool, but they are not required. Any other technique, be it a diagram or simple text will do as well, as long as it contains the needed information. Depending on your experience and skills, your mentor will closely interact with you throughout this work and give you the support you need.
  • Good social interaction with the multiplayer community : As mentioned before, multiplayer campaigns are one of the triggers for this task. There are some multiplayer campaigns and part of your work will be to get in contact with the maintainers and get an understanding of the current problems in order to decide how to support needed features with savegame information.

Milestones and deliverables

Some of the milestones will become obvious after the design phase is finished, but here are some ideas of what needs to be done:

  • Being familiar with the code : To get a better understanding, you will have to examine the currently available code, find all the places that deal with savegame information and roughly understand what their specific task is about. This should be documented. You will also have to learn the text representation of savegame information which is done by WML, a markup language that is widely used within wesnoth. Play a little with the different kind of scenarios and see what savegames get out of that and what the code is doing with them.
  • Design : Evaluating the current problems with multiplayer campaigns will be needed for this phase. After you have done this, you will have to develop a new savegame format and a design for the code that is processing it. The delivery will be at least some kind of static model (preferably UML but other techniques will do as well) and a roadmap of steps to get from the current code to the new one.
  • Implementing : It is hard to give detailed information about the content of this phase. But basically it will be implementing the roadmap steps one by one.

See also

Summer of Code Ideas - The root where all information regarding SoC is (or better should be) linked from.
savegame contents - Some ideas about the current and future content of savegames.
Savegame WML - Information about the format used for storing savegame information.