Difference between revisions of "SoC Ideas New Alliance System"
(Created page with ' '''WML Handling''' To allow UMC to work with the alliance parameters, each of them * should be setable by WML * should be lockable/unlockable by WML * unlocked parameters can be…') |
m (→Description) |
||
| (14 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| + | {{Template:SoC2010Idea}} | ||
| − | ''' | + | =Description= |
| + | <h2>New Alliance system</h2> | ||
| + | Page for the idea: [[SoC_Ideas_New_Alliance_System]] | ||
| + | |||
| + | Wesnoth currently has a very simple alliance system, players are either allied, neutral, or enemies. The idea is to replace this with a system of privilege granting. Each player can grant privileges to other players but can't force other to grant the corresponding privilege. Thus it's only through diplomacy and trust that you can build an alliance. | ||
| + | |||
| + | {{#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 New Alliance System | ||
| + | |include=#Description | ||
| + | |mode=userformat | ||
| + | |format=,,<br/>See [[%PAGE%|%TITLE%]] for more information.<br/><br/>, | ||
| + | }} | ||
| + | |||
| + | =WML Handling= | ||
To allow UMC to work with the alliance parameters, each of them | To allow UMC to work with the alliance parameters, each of them | ||
* should be setable by WML | * should be setable by WML | ||
| Line 8: | Line 27: | ||
| − | + | =List of parameters= | |
* can unit attack this side | * can unit attack this side | ||
* do we take village from that side | * do we take village from that side | ||
| Line 19: | Line 38: | ||
* is team-chat/team-labels shared | * is team-chat/team-labels shared | ||
| − | + | =Victory handling= | |
* add a "share victory" button | * add a "share victory" button | ||
* a side is victorious when all remaining sides share victory with him | * a side is victorious when all remaining sides share victory with him | ||
| − | + | =Open questions= | |
* do we see what the other give us ? | * do we see what the other give us ? | ||
* victory : how do we handle some sides winning before others | * victory : how do we handle some sides winning before others | ||
| Line 29: | Line 48: | ||
* do we enable it in MP ? make it an option ? | * do we enable it in MP ? make it an option ? | ||
* handling of backstab (helping against an ally) | * handling of backstab (helping against an ally) | ||
| + | |||
| + | =Whom to ask about this= | ||
| + | Ask Boucman on #wesnoth-dev | ||
Latest revision as of 22:55, 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
New Alliance system
Page for the idea: SoC_Ideas_New_Alliance_System
Wesnoth currently has a very simple alliance system, players are either allied, neutral, or enemies. The idea is to replace this with a system of privilege granting. Each player can grant privileges to other players but can't force other to grant the corresponding privilege. Thus it's only through diplomacy and trust that you can build an alliance.
There are 4 submitted student proposals for this idea
Endercoaster-New Alliance System
I plan to develop an expanded alliance system for Wesnoth, providing greater granularity and asymmetry in setting permissions. The first major step in this will be refactoring the array enemies_ which stores booleans with an array alliances_, which will store a vector of permissions (Probably stored as booleans, possibly stored as various implementations of an interface that will wrap either booleans or enums).
See GSoC: Endercoaster for more information.
Sannya - New Alliance System
I propose a new Alliance System, expanding from the basic Ally/Enemy/Neutral system as current. These settings in the proposed system are either automatically set or user-choice set. The default status is "Neutral", the Enemy status will be set after a series of unfriendly actions, or can be set by user. The "Ally" status can only be set with mutual agreement among players. Request to be an ally will be treat as an yes/no confirmation, with time-out and other constraints applied.
See Sannya GSoC for more information.
Aranair - Summer of Code Proposal
gna.org : aranair
irc : aranair (will pop by real soon)
I am interested in a new implementation of the alliance system where I will introduce the list of parameters that was listed out in the original post in the list of ideas (with modification). My take to this is that they should not be simply set to true or false but rather with more intricate levels to increase the dynamics through simple means...
Discussed this in more details in my wiki page. Or if you wish to view a pdf version at:
PDF Version of my Idea
See SummerofCode Aranair for more information.
Greywhind - New Alliance System
I plan to implement a system for configurable privileges and protections between players in Battle for Wesnoth, in order to create a more flexible and more extensible alliance system. I plan to implement the suggested settings, and also to provide unintrusive tooltip notifications when an action is permitted or denied by an alliance setting. As someone who enjoys the board game Diplomacy, I know how an interesting alliance system can really make for an engaging game. Therefore, additionally, I would like to consider putting in place a system whereby these settings can be secret or public, and whereby public or private written treaties (in text form, and unenforced by code) can be proposed and accepted or rejected.
See SummerOfCodeGreywhind for more information.
WML Handling
To allow UMC to work with the alliance parameters, each of them
- should be setable by WML
- should be lockable/unlockable by WML
- unlocked parameters can be set by player via a table.
- There should be an easy way to emmulate the old alliance system in MP game (a way for the game-creator to set and lock the parameters before the game)
List of parameters
- can unit attack this side
- do we take village from that side
- can this side use our healers
- can this side use our leaders
- do we give this side our shroud information
- do we give this side our fog information
- can this side use our villages to teleport
- is this side affected by our ZOCs
- is team-chat/team-labels shared
Victory handling
- add a "share victory" button
- a side is victorious when all remaining sides share victory with him
Open questions
- do we see what the other give us ?
- victory : how do we handle some sides winning before others
- defeat : i'm not sure if we need special handling for that, what would be the point of sharing defeat (unless forced by WML, in which case it's better to do it with events)
- do we enable it in MP ? make it an option ?
- handling of backstab (helping against an ally)
Whom to ask about this
Ask Boucman on #wesnoth-dev