SoC2014 RiftWalker Unify SP MP - Revision history

RiftWalker: /* Project */

2014-04-04T03:39:52Z

Project

← Older revision		Revision as of 03:39, 4 April 2014
Line 263:		Line 263:
	'''Why did you choose this project?'''		'''Why did you choose this project?'''

	I chose this project in particular because it ~~seems~~ like a ~~good opportunity~~ to ~~contribute to the project and community. I like~~ the ~~idea of making things run more smoothly. Also~~, ~~I believe that this project will provide~~ a good challenge for me without being outside my skill set.		I chose this project in particular because it seemed like a way for me to make a noticable positive impact on the game, which would be a good challenge for me without being outside my skill set.

	'''Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".'''		'''Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".'''
Line 279:		Line 279:
	'''What would make you stay in the Wesnoth community after the conclusion of SOC?'''		'''What would make you stay in the Wesnoth community after the conclusion of SOC?'''

	I intend to keep developing Wesnoth after the summer ends.		I intend to keep developing Wesnoth after the summer ends. I'm interested in eventually working with the AI as well as porting to iOS and Android.

	===Practical considerations===		===Practical considerations===

RiftWalker: /* Timeline */

2014-04-04T03:35:40Z

Timeline

← Older revision		Revision as of 03:35, 4 April 2014
Line 104:		Line 104:
	\| now \|\| Apr 8 - Apr 20 \|\| Continue to learn about the codebase. Start working on a solution to the namespace problem.		\| now \|\| Apr 8 - Apr 20 \|\| Continue to learn about the codebase. Start working on a solution to the namespace problem.
	\|-		\|-
	\| - \|\| Apr 21 \|\| "Community Bonding Period" begins. ~~Finalize~~ plans for the summer. Study the differences between SP and MP code and try to find any issues in merging them. Finish up with the namespace solution if not done yet.		\| - \|\| Apr 21 \|\| "Community Bonding Period" begins. Discuss the project with my mentor and solidify plans for the summer. Study the differences between SP and MP code and try to find any issues in merging them. Finish up with the namespace solution if not done yet.
	\|-		\|-
	\| - \|\| May 3\|\| Fly home for the summer. Begin coding in earnest. Work on ironing out any kinks between SP and MP.		\| - \|\| May 3\|\| Fly home for the summer. Begin coding in earnest. Work on ironing out any kinks between SP and MP.

RiftWalker: /* Timeline */

2014-04-04T03:34:26Z

Timeline

← Older revision		Revision as of 03:34, 4 April 2014
Line 98:		Line 98:

	{\| border="1"		{\| border="1"
	\| ~~now~~ \|\|Mar 23 - Mar 31 \|\| Develop a solid understanding of the current state of things: study the current code; study the wiki; familiarize myself with WML preprocesser tags and their relevant code. Continue to flesh out my proposal.		\| + \|\|Mar 23 - Mar 31 \|\| Develop a solid understanding of the current state of things: study the current code; study the wiki; familiarize myself with WML preprocesser tags and their relevant code. Continue to flesh out my proposal.
	\|-		\|-
	\| - \|\| Apr 1 - Apr 7 \|\| Code some basic things as examples.		\| - \|\| Apr 1 - Apr 7 \|\| Code some basic things as examples.
	\|-		\|-
	\| - \|\| Apr 8 - Apr 20 \|\| Continue to learn about the codebase. Start working on a solution to the namespace problem.		\| now \|\| Apr 8 - Apr 20 \|\| Continue to learn about the codebase. Start working on a solution to the namespace problem.
	\|-		\|-
	\| - \|\| Apr 21 \|\| "Community Bonding Period" begins. Finalize plans for the summer. Study the differences between SP and MP code and try to find any issues in merging them. Finish up with the namespace solution if not done yet.		\| - \|\| Apr 21 \|\| "Community Bonding Period" begins. Finalize plans for the summer. Study the differences between SP and MP code and try to find any issues in merging them. Finish up with the namespace solution if not done yet.

RiftWalker: /* Minimize the impact of running SP code through MP */

2014-04-04T03:29:39Z

Minimize the impact of running SP code through MP

← Older revision		Revision as of 03:29, 4 April 2014
Line 51:		Line 51:
	***The solution here will probably be a modified IO_SERVER code path.		***The solution here will probably be a modified IO_SERVER code path.
	***For each difference that we want to keep between SP and MP, we can use either an if statement or some other method such as strategy pattern to branch depending on the campaign type.		***For each difference that we want to keep between SP and MP, we can use either an if statement or some other method such as strategy pattern to branch depending on the campaign type.
	****Campaign type is stored in game_classification
	****It is very important that we get a definitive list of where the two code paths differ from a user's perspective.		****It is very important that we get a definitive list of where the two code paths differ from a user's perspective.
	*There may be many unforseen challenges in this area, which will need to be accounted for.		*There may be many unforseen challenges in this area, which will need to be accounted for.

RiftWalker: /* Minimize the impact of running SP code through MP */

2014-04-04T03:28:47Z

Minimize the impact of running SP code through MP

← Older revision		Revision as of 03:28, 4 April 2014
Line 42:		Line 42:

	====Minimize the impact of running SP code through MP====		====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:~~		*The first step is to make the SP game creation dialog initialize SP campaigns as MP campaigns.
	**~~Using game_classification~~ to ~~store and read~~ SP/MP ~~status~~		**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 be set to appropriate values.
	**~~Choosing controller type based on number of human players~~		*There will likely be many design considerations and issues with running SP campaigns as MP.
	**~~Coming up~~ with an ~~object-oriented~~ solution such as strategy pattern.		**Which io_type should we use?
	***~~Note:~~ It ~~seems~~ the ~~strategy pattern may be very useful in making this project work nicely~~.		***playcampaign::play_game uses io_type to decide whether to run a local SP game, MP game as host, or MP game as client.
			***IO_NONE is used to run current SP code such as playsingle_controller, so it would be guaranteed to work as we expect.
			***IO_SERVER is used in MP games, and would probably be necessary for things like observers, or joining a campaign in progress. With this option, play_game follows the MP code path, including playmp_controller, so games launched with this option will behave like an MP game.
			***The solution here will probably be a modified IO_SERVER code path.
			***For each difference that we want to keep between SP and MP, we can use either an if statement or some other method such as strategy pattern to branch depending on the campaign type.
			****Campaign type is stored in game_classification
			****It is very important that we get a definitive list of where the two code paths differ from a user's perspective.
	*There may be many unforseen challenges in this area, which will need to be accounted for.		*There may be many unforseen challenges in this area, which will need to be accounted for.

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

	*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===		===High Priority===

RiftWalker: /* Avoid namespace collision and improve config loading */

2014-04-04T02:34:07Z

Avoid namespace collision and improve config loading

← Older revision		Revision as of 02:34, 4 April 2014
Line 35:		Line 35:
	*Implementation notes;		*Implementation notes;
	**The current [campaign] define= is stored as a string campaign_define in game_classification, which typically exists as a member of game_state.		**The current [campaign] define= is stored as a string campaign_define in game_classification, which typically exists as a member of game_state.
	**~~It may be possible to~~:		**The campaign define is read in from the config object in game_controller::new_campaign().
	**#Use the same define. ~~This would rule out isolating parts of scenarios within campaigns~~		**More defines for mp and era could be added to game_classification.
	**~~#Define another define alongside it,~~ and ~~work with it similarly.~~		***It seems that the mp equivalent of new_campaign() is play_multiplayer() (also play_multiplayer_commandline()). We'll read in the define= attribute here.
	**Note: This works for campaigns, but multiplayer may be ~~handled differently. We need~~ to ~~ensure that this is even the right place to define such a thing~~.		**Still need to figure out where to load defines for eras/mods.
	***~~Same goes for eras~~. We ~~need to find~~ the ~~best place to implement these things~~.		**Still need to figure out where to add_preproc_define and reload config.
	**~~Alternatively, it may be possible, in the process of trying~~ to ~~implement this,~~ to ~~make the whole system more modular~~.
	***Maybe it already is modular, and I just can't see it yet.

	*Currently, here is my plan going forward:
	**Study how define= is used in the campaign code.
	**Compare the multiplayer/scenario code to ~~find similarities~~
	**Find the best place to:
	**# Load the define= value from config into game_classification
	**# add_preproc_define and reload config ~~for game.~~
	***Either or both of these could be different for era, multiplayer, and scenario.

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

RiftWalker: /* Timeline */

2014-03-28T02:28:52Z

Timeline

← Older revision		Revision as of 02:28, 28 March 2014
Line 125:		Line 125:
	\| - \|\| May 30 \|\| Should have completed all critical tasks by now. Begin working on add-on functionality and associated GUI.		\| - \|\| May 30 \|\| Should have completed all critical tasks by now. Begin working on add-on functionality and associated GUI.
	\|-		\|-
	\| - \|\| June 23 \|\| Mid-Term evaluations begin. By now SP add-ons and the SP Advanced ~~settings~~ gui should be fully functional.		\| - \|\| June 23 \|\| Mid-Term evaluations begin. By now SP add-ons and the SP Advanced Settings gui should be fully functional.
	\|-		\|-
	\| - \|\| June 27 \|\| Mid-Term evaluation deadline.		\| - \|\| June 27 \|\| Mid-Term evaluation deadline.

RiftWalker: /* Timeline */

2014-03-28T02:28:31Z

Timeline

← Older revision		Revision as of 02:28, 28 March 2014
Line 111:		Line 111:

	{\| border="1"		{\| border="1"
	\| now \|\|Mar 23 - Mar 31 \|\| Develop a solid understanding of the current state of things: study the current code; study the wiki; familiarize myself with WML preprocesser tags and their relevant code.		\| now \|\|Mar 23 - Mar 31 \|\| Develop a solid understanding of the current state of things: study the current code; study the wiki; familiarize myself with WML preprocesser tags and their relevant code. Continue to flesh out my proposal.
	\|-		\|-
	\| - \|\| Apr 1 - Apr 7 \|\| ~~Work on a solution to the namespace collision / content loading problem~~.		\| - \|\| Apr 1 - Apr 7 \|\| Code some basic things as examples.
	\|-		\|-
	\| - \|\| Apr 8 - Apr 20 \|\| Continue to learn ~~and work on problems that arise~~. ~~Keep~~ working on namespace problem ~~if not solved yet~~.		\| - \|\| Apr 8 - Apr 20 \|\| Continue to learn about the codebase. Start working on a solution to the namespace problem.
	\|-		\|-
	\| - \|\| Apr 21 \|\| "Community Bonding Period" begins. Finalize plans for the summer. ~~Work on getting add-ons fully functional within~~ SP.		\| - \|\| Apr 21 \|\| "Community Bonding Period" begins. Finalize plans for the summer. Study the differences between SP and MP code and try to find any issues in merging them. Finish up with the namespace solution if not done yet.
	\|-		\|-
	\| - \|\| May 3\|\| Fly home for the summer. Begin coding in earnest.		\| - \|\| May 3\|\| Fly home for the summer. Begin coding in earnest. Work on ironing out any kinks between SP and MP.
	\|-		\|-
	\| - \|\| May 19\|\| Google "Begin Coding" date. By now I should have SP campaigns basically working within MP code~~, as well as MP campaigns working as solo with AI~~. ~~Begin testing and working~~ on GUI.		\| - \|\| May 19\|\| Google "Begin Coding" date. By now I should have SP campaigns basically working within MP code. Work on getting the new SP campaign code to work with the old GUI. Continue to iron out kinks.
	\|-		\|-
	\| - \|\| ~~June~~ 9 \|\| ~~GUI's should be basically functional~~. Begin working on ~~server selection/switching~~.		\| - \|\| May 30 \|\| Should have completed all critical tasks by now. Begin working on add-on functionality and associated GUI.
	\|-		\|-
	\| - \|\| June 23 \|\| Mid-Term evaluations begin. By now~~, GUI's are~~ fully ~~working with dynamic side assignment between scenarios~~.		\| - \|\| June 23 \|\| Mid-Term evaluations begin. By now SP add-ons and the SP Advanced settings gui should be fully functional.
	\|-		\|-
	\| - \|\| June 27 \|\| Mid-Term evaluation deadline.		\| - \|\| June 27 \|\| Mid-Term evaluation deadline.
	\|-		\|-
	\| - \|\| June 28 - July 14 \|\| Work on some of the lower priority tasks. Test and receive feedback.		\| - \|\| June 28 - July 14 \|\| Work on some of the medium and lower priority tasks. Test and receive feedback.
	\|-		\|-
	\| - \|\| July 15 - August 10 \|\| Continue testing and improving. Fix things that are broken. If everything works, work on more lower priority tasks.		\| - \|\| July 15 - August 10 \|\| Continue testing and improving. Fix things that are broken. If everything works, work on more lower priority tasks.

RiftWalker: /* Critical Priority: */

2014-03-27T22:45:36Z

Critical Priority:

← Older revision		Revision as of 22:45, 27 March 2014
Line 23:		Line 23:
	==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.

RiftWalker: /* Avoid namespace collision and improv config loading */

2014-03-27T22:45:21Z

Avoid namespace collision and improv config loading

← Older revision		Revision as of 22:45, 27 March 2014
Line 26:		Line 26:
	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.

	====Avoid namespace collision and ~~improv~~ 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.