2014-03-27

‎Critical Priority:

← Older revision

Revision as of 22:45, 27 March 2014

(14 intermediate revisions by one user not shown)

Line 21:

Line 21:

 

**There is generally only one playable side. It is assigned to the single human player, and the other sides are assigned to AI's

 

**There is generally only one playable side. It is assigned to the single human player, and the other sides are assigned to AI's

 

 



=
==Tasks
=
==

+

==Tasks==

 

 



=
===Critical Priority
:=
===

+

===Critical Priority===

 

These tasks are critical to the project and will receive the most attention.

 

These tasks are critical to the project and will receive the most attention.

 

 



====
=Avoiding
namespace collision
/ improving
config loading
=
====

+

====
Avoid
namespace collision
and improve
config loading====

 

*Option 1: Add define= attributes to [multiplayer] and [era] tags.

 

*Option 1: Add define= attributes to [multiplayer] and [era] tags.

 

*Option 2: Create a new tag with a define=, which can be used anywhere to isolate content.

 

*Option 2: Create a new tag with a define=, which can be used anywhere to isolate content.

Line 51:

Line 51:

 

***Either or both of these could be different for era, multiplayer, and scenario.

 

***Either or both of these could be different for era, multiplayer, and scenario.

 

 

 

+

====Minimize the impact of running SP code through MP====

 

+

*For starters, make sure that SP games are run with playsingle_controller and not playmp_controller possible solutions include:

 

+

**Using game_classification to store and read SP/MP status

 

+

**Choosing controller type based on number of human players

 

+

**Coming up with an object-oriented solution such as strategy pattern.

 

+

***Note: It seems the strategy pattern may be very useful in making this project work nicely.

 

+

*There may be many unforseen challenges in this area, which will need to be accounted for.

 

 



====High Priority====

+

So let
's
say we've successfully implemented
SP
campaigns
in
MP, and fixed all the problems with it.



#Create new GUI
's
to pull it all together

+



#*Single campaign menu

+



#*Maintain a clean flow for those who want to play a simple
SP
campaign

+



#Implement a lobby before each scenario (
in
SP) where one might invite other players to join their campaign

+

 

 



====
Lower
Priority====

+

*Now all the sp campaigns are available through the multiplayer menu, and when we set the right settings (ai, players), they play as we expect them to.

 

+

*Now what? We aren't satisfied. We liked the old sp campaign selection. It was simple; it was great for new players. All these options are ugly.

 

+

*Solution: Make our new mp code work with the old SP campaign menu. This isn't without problems:

 

+

**TODO: Expand with details

 

+

**We need code that will allow humans to select a side if the campaign allows it, while assigning all other sides of our now-mp-code-running scenarios to AI. All other options available in mp menus would also be set to default values With this implemented correctly, we'll have all the functionality of old SP campaigns, except now they're running in mp code.

 

+

 

 

+

===
High Priority
=
==

 

+

Once we've got basic functionality working as described above, It's time to implement the features that motivated these changes to begin with:

 

+

====Implement add-on functionality in SP campaigns====

 

+

*Addons will be available as they are in MP campaigns.

 

+

*We need to add the option to choose them to the SP GUI

 

+

*Ideally, such functionality should be encapsulated. A small settings button with a gear icon, or similar, could provide access to an advanced settings dialog. This also allows us to not have to load configs for add-ons unless they're asked for.

 

+

**This dialog would likely be similar to the MP "Configure Game" dialog, except it would not be shown by default.

 

+

 

 

+

===Medium
Priority=
==

 

+

Once we have completed the major tasks, We can begin to implement some of the nice features that could stem from our changes.

 

+

====Ability to invite players to join an SP campaign if a side opens up.====

 

+

*As a quick hack, this could be implemented by allowing saved sp campaigns to be loaded in the mp dialog.

 

+

 

 

+

====Allow observers in SP campaigns====

 

+

*This could also be enabled through the "Advanced Settings" dialog mentioned above.

 

+

**This dialog would likely be similar to the MP "Configure Game" dialog, except it would not be shown by default.

 

+

 

 

+

===Lower Priority
===

 

These tasks stem from the core tasks above, and would be nice to implement if there is demand for them.

 

These tasks stem from the core tasks above, and would be nice to implement if there is demand for them.

 

 



*
Allow humans to control sides which would typically played by AI's.

+

====
Allow humans to control sides which would typically played by AI's.
====



*
*In some cases, it may be necessary for content creators to disallow human players on a particular side.

+

*In some cases, it may be necessary for content creators to disallow human players on a particular side.



*Allow for converting single-player campaigns into co-op multi-player campaigns by adding sides.

+

*
May introduce balance issues.



**
Both of the above ideas might
introduce balance issues
which would need to be sorted out.

+

 



*
Implement options for handling off-turn unit advancement

+

====
Allow for converting single-player campaigns into co-op multi-player campaigns by adding sides.
====



*
*Currently, only the game host (or AI host (MP droid)) is allowed to choose their advancement if their unit levels up during an AI turn. Other players' paths are chosen randomly.

+

*
Extra castle added adjacent to ally?



**In all cases, units are advanced randomly if they level during another human player's turn.

+

*
May
introduce
serious
balance issues



**There seem to be three viable options for handling this:

+

**
Adjust gold?



**#Make all off-turn advancements random, including the host, in networked games; keep local games as they are now.

+



**#Allow players to right-click units and set a default advancement path during their turn (or even at any time, but that may be more difficult to implement).

+



**#Prompt players over the network to choose an advancement path.

+



**#*This would probably require a timeout, e.g. 10 seconds, before a random path is chosen for them.

+

 

 



====
Challenges
====

+

====
Implement options for handling off-turn unit advancement
====



*
Avoiding namespace collision between SP and
MP

+

*
Currently, only the game host (or AI host (
MP
droid)) is allowed to choose their advancement if their unit levels up during an AI turn. Other players' paths are chosen randomly.



**
It will be necessary
to
address
this
issue
:
https://gna.org/bugs/?11503

+

*
In all cases, units are advanced randomly if they level during another human player's turn.



*
Designing a clean and user
-
friendly interface

+

*
There seem
to
be three viable options for handling
this:



*
Implementing smooth transitioning between local
and
networked
games

+

*
#Make all off
-
turn advancements random, including the host, in networked games; keep local games as they are now.

 

+

*
#Allow players to right-click units
and
set a default advancement path during their turn (or even at any time, but hat may be more difficult to implement).

 

+

*#Prompt players over the network to choose an advancement path.

 

+

*#*This would probably require a timeout, e.g. 10 seconds, before a random path is chosen for them.

 

+

*In the case that we don't handle this, nothing would be negatively affected:

 

+

**Since there is only one human player (the host) in SP campaigns, they would continue to work as they do now, with the player given a choice of advancement path.

 

+

**Multiplayer
games
would be unaffected; they would continue to be somewhat flawed as they are now.

 

 

 

==Timeline==

 

==Timeline==

Show more