Difference between revisions of "SoC Ideas Persistent Gameworld"
m |
m (→Description) |
||
| (15 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{Template:SoC2010Idea}} | {{Template:SoC2010Idea}} | ||
=Description= | =Description= | ||
| − | + | <h2>Implement persistent storage of gameworld data between semi-related scenarios</h2> | |
| + | 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. | 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. | ||
| + | |||
| + | {{#dpl: | ||
| + | |resultsheader=''There are %PAGES% submitted student proposals for this idea'' | ||
| + | |oneresultheader=''There is 1 submitted student proposal for this idea'' | ||
| + | |notcategory=SoC 2010 Not Submitted To Google | ||
| + | |suppresserrors=true | ||
| + | |noresultsheader=''There are no submitted student proposals for this idea'' | ||
| + | |category=Summer of Code 2010 Student Page&SoC Ideas Persistent Gameworld | ||
| + | |include=#Description | ||
| + | |mode=userformat | ||
| + | |format=,,<br/>See [[%PAGE%|%TITLE%]] for more information.<br/><br/>, | ||
| + | }} | ||
| + | |||
| + | =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= | =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 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 | ||
Latest revision as of 22:56, 9 April 2010
| 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 |
Contents
Description
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
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.
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