SoC Ideas Persistent Gameworld

From The Battle for Wesnoth Wiki


This page is related to Summer of Code 2010
See the list of Summer of Code 2010 Ideas



This is a Summer of Code 2010 Idea


Description

Implement persistent storage of gameworld data between semi-related scenarios

Page for the idea: SoC_Ideas_Persistent_Gameworld

Allow WML authors to store/access persistent data 'in context' of a specific campaign/add-on/group of addons/ group of games. This will allow things like 'achievements' or 'massive multiplayer campaigns' to work.

There are 3 submitted student proposals for this idea

Guilherme Souza - Implement persistent storage of gameworld data between semi-related scenarios

I want to implement the persistent gameworld idea. If I got accepted, I would discuss with the community and the developers about the best way to do this, searching for a solution that would be easy for the campaigns and maps developers to use. The basic idea is to improve WML so developers can store and read variables for maps and campaigns, using them to create an different scenario each time the map/campaign is played.
See SummerOfCodeProposal GuilhermeSouza for more information.

Jody Northup - Implement gameworld data persistence

This is the Persistent Gameworld idea.
If accepted, I would communicate extensively with the community to determine a solution that provides gameworld persistence with the greatest ease of access and implementation for the established community of world and campaign builders for Wesnoth.
Currently, I expect that this will involve extending WML, and creation of some system of communication about the extended WML for multiplayer games.
See SummerOfCodeProposal JodyNorthup for more information.

lfernando - Implement persistent storage of gameworld data between semi-related scenarios

The general idea of this project is introducing variables that are independent from savefiles and campaign lines. They will be accessible from any context and not lose validity once a particular game/campaign has ended. We'll call them global variables.

Global variables will be stored and retrieved using two special tags, [get_global_variable] and [set_global_variable]. They should be used on scenario WML, and their usage will allow that variables, as defined by the [set_variable] family of tags, (from now onwards we will call those ones "local" variables) should be saved to/loaded from an external source.

I'm planning to store global variables on simple wml files with syntax borrowed from uncompressed saves. Each add-on will have its own set of variables, and its own file for global variables.
See SummerOfCodeProposal lfernando for more information.

Additional information

Right now, WML can store/load information inside a save game. a save game is a single thread of play through one or multiple scenarios.

We would like to make it possible to store (save/load) information inside a different context, such as 'shared data for all games played locally on a particular map/campaign/addon/wesnoth installation'. This will allow WML authors to implement many interesting things like 'achievements' system for their campaign, or additional replayability things.

Also, we would like to make it possible to store such information for MP games. This will allow things like 'massive multiplayer' games with persistent gameworld - where each MP game changes some data for one of 'global' massive multiplayer campaigns.

Example: Imagine a game where there's a 'game master' - who creates a scenario, where you, for example, as a captain of a royal army, play for loyalists vs orcs. and then, if you win, the 'game master' changes the 'geopolitical map' to represent the fact that the border was defended, and orcs were defeated. Or imagine several games played in parallel, where you can transition from one game to another 'right-in-the-middle' (e..g, the gamemaster can store your units in one game and spawn them in another). and, it will not be hardcoded in c++ code. Every rule, every fantasy, can be achieved in wml, if we give a 'language' for it and implement engine support.

Definition of Done

WML authors are able to store and load WML snippets in their core campaigns/addons/groups of addons/groups of games. It is possible to use this system for displaying per-addon 'Achievements'. 'massive multiplayer' games with persistent gameworld are possible to code using WML and possible to host using stock wesnoth multiplayer server.

WML Syntax

[get_global_variable]
 side=1
 namespace=my_addon
 from_global=my_variable_name
 to_local=foo
[/get_global_variable]
[set_global_variable]
 side=1
 namespace=my_addon
 from_local=my_variable_name
 to_global=foo
[/set_global_variable]
[clear_global_variable]
 side=1
 namespace=my_addon
 global=foo
[/clear_global_variable]

Notes:

There might be need for a [global_variable] tag for use in an [if] (similarly to how [variable] works there)

Whom to ask about this

Ask Crab_ on #wesnoth-dev

This page was last edited on 9 April 2010, at 22:56.