Difference between revisions of "SoC2014 RiftWalker Unify SP MP"

From The Battle for Wesnoth Wiki
(Description)
(Project)
 
(64 intermediate revisions by the same user not shown)
Line 8: Line 8:
 
The purpose of this project is to ensure that all user-made content works across game modes by
 
The purpose of this project is to ensure that all user-made content works across game modes by
 
unifying and extending the code paths that handle configs for single- and multi-player games.
 
unifying and extending the code paths that handle configs for single- and multi-player games.
 +
This will be achieved by making SP a special case of MP as described by Zaroth.
  
*Merging the code paths, ultimately, will result in a unified campaign experience encompassing single and multi-player game modes.
+
*To begin with, I will implement the current single player campaign creation through the multiplayer code path, changing as little as possible.
*All campaigns with more than one human-playable side, including those previously classified as single-player, will have the option to play with others.
+
*Once I've sorted out all the problems that may arise from this, the door will be open to a host of potential new features and improvements which I will implement according to demand from the community.
*Users will have the option of selecting combinations of humans and AI's to play with on a per-scenario basis.
 
*Campaigns previously classified as multi-player will be playable by a single player, by filling any open sides with AI's.
 
*It may be possible to 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.
 
*If time permits, it may also be possible to add experimental functionality that will allow for converting single-player campaigns into co-op multi-player campaigns by adding sides.
 
*Both of the above ideas may introduce balance issues which would need to be sorted out.
 
  
 
==Details==
 
==Details==
Line 22: Line 17:
 
*Unification will be accomplished by having all campaigns use the current MP code path.
 
*Unification will be accomplished by having all campaigns use the current MP code path.
 
**This path already contains the add-on functionality which is missing from the SP code.
 
**This path already contains the add-on functionality which is missing from the SP code.
*The conversion of SP campaigns to this is simple:
+
*The conversion of SP campaigns to this is (conceptually) simple:
 
**The game will load as if it were a local MP game.
 
**The game will load as if it were a local MP game.
 
**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
*MP games, then, will work in a similar way.
+
 
*#Assign humans to select sides
+
==Tasks==
*#Fill the rest with AI.
+
 
 +
===Critical Priority===
 +
These tasks are critical to the project and will receive the most attention.
 +
 
 +
====Avoid namespace collision and improve config loading====
 +
*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.
 +
** This would probably be more difficult to implement
 +
** Might be good to include other metadata in the tag.
 +
 
 +
 
 +
*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 campaign define is read in from the config object in game_controller::new_campaign().
 +
**More defines for mp and era could be added to game_classification.
 +
***It seems that the mp equivalent of new_campaign() is play_multiplayer() (also play_multiplayer_commandline()). We'll read in the define= attribute here.
 +
**Still need to figure out where to load defines for eras/mods.
 +
**Still need to figure out where to add_preproc_define and reload config.
 +
 
 +
====Minimize the impact of running SP code through MP====
 +
*The first step is to make the SP game creation dialog initialize SP campaigns as MP campaigns.
 +
**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.
 +
*There will likely be many design considerations and issues with running SP campaigns as MP.
 +
**Which io_type should we use?
 +
***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.
 +
****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.
 +
 
 +
===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.
 +
 
 +
====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.
 +
*May introduce balance issues.
 +
 
 +
====Allow for converting single-player campaigns into co-op multi-player campaigns by adding sides.====
 +
*Extra castle added adjacent to ally?
 +
*May introduce serious balance issues
 +
**Adjust gold?
 +
 
 +
====Implement options for handling off-turn unit advancement====
 +
*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.
 +
*In all cases, units are advanced randomly if they level during another human player's turn.
 +
*There seem to be three viable options for handling this:
 +
*#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==
  
 +
{| border="1"
 +
| + ||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.
 +
|-
 +
| 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. 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 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.
 +
|-
 +
| - || 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 27 || Mid-Term evaluation deadline.
 +
|-
 +
| - || 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.
 +
|-
 +
| - || August 11 || "Pencils Down" date. Take a week to scrub code, write tests, improve documentation, etc.
 +
|-
 +
| - || Afterwards || Continue to maintain and improve on my code, and implement some ideas that may branch from my summer work. <br/>
 +
|}
  
 
==IRC==
 
==IRC==
Line 98: Line 191:
  
 
'''Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.'''
 
'''Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.'''
 +
 
No.
 
No.
  
Line 165: Line 259:
 
'''If you have invented your own project, please describe the project and the scope.'''
 
'''If you have invented your own project, please describe the project and the scope.'''
  
See [[Description]].
+
See [[SoC2014_RiftWalker_Unify_SP_MP#Description|Description]].
  
 
'''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".'''
See [[Timeline]].
+
 
 +
See [[SoC2014_RiftWalker_Unify_SP_MP#Timeline|Timeline]].
  
 
'''Include as much technical detail about your implementation as you can'''
 
'''Include as much technical detail about your implementation as you can'''
See [[Details]].
+
 
 +
See [[SoC2014_RiftWalker_Unify_SP_MP#Details|Details]].
  
 
'''What do you expect to gain from this project?'''
 
'''What do you expect to gain from this project?'''
Line 183: 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?'''
  
As long as there's more
+
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===

Latest revision as of 03:39, 4 April 2014


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



This is a Summer of Code 2014 student page


Description

RiftWalker - Game Engine: Unify SP and MP

Currently, certain add-on content works only in single- or multi-player games. The purpose of this project is to ensure that all user-made content works across game modes by unifying and extending the code paths that handle configs for single- and multi-player games. This will be achieved by making SP a special case of MP as described by Zaroth.

  • To begin with, I will implement the current single player campaign creation through the multiplayer code path, changing as little as possible.
  • Once I've sorted out all the problems that may arise from this, the door will be open to a host of potential new features and improvements which I will implement according to demand from the community.

Details

  • Unification will be accomplished by having all campaigns use the current MP code path.
    • This path already contains the add-on functionality which is missing from the SP code.
  • The conversion of SP campaigns to this is (conceptually) simple:
    • The game will load as if it were a local MP game.
    • 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

Critical Priority

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

Avoid namespace collision and improve config loading

  • 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.
    • This would probably be more difficult to implement
    • Might be good to include other metadata in the tag.


  • 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 campaign define is read in from the config object in game_controller::new_campaign().
    • More defines for mp and era could be added to game_classification.
      • It seems that the mp equivalent of new_campaign() is play_multiplayer() (also play_multiplayer_commandline()). We'll read in the define= attribute here.
    • Still need to figure out where to load defines for eras/mods.
    • Still need to figure out where to add_preproc_define and reload config.

Minimize the impact of running SP code through MP

  • The first step is to make the SP game creation dialog initialize SP campaigns as MP campaigns.
    • 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.
  • There will likely be many design considerations and issues with running SP campaigns as MP.
    • Which io_type should we use?
      • 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.
        • 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.

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.

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.
  • May introduce balance issues.

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

  • Extra castle added adjacent to ally?
  • May introduce serious balance issues
    • Adjust gold?

Implement options for handling off-turn unit advancement

  • 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.
  • In all cases, units are advanced randomly if they level during another human player's turn.
  • There seem to be three viable options for handling this:
    1. Make all off-turn advancements random, including the host, in networked games; keep local games as they are now.
    2. 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).
    3. 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

+ 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.
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. 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 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.
- 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 27 Mid-Term evaluation deadline.
- 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.
- August 11 "Pencils Down" date. Take a week to scrub code, write tests, improve documentation, etc.
- Afterwards Continue to maintain and improve on my code, and implement some ideas that may branch from my summer work.

IRC

RiftWalker

Questionnaire

Basics

Write a small introduction to yourself.

My name is Nathan Walker. I'm an undergraduate Computer Science major at Vanderbilt University.

State your preferred email address.

nathan.b.walker@vanderbilt.edu

If you have chosen a nick for IRC and Wesnoth forums, what is it?

RiftWalker

Why do you want to participate in summer of code?

My primary motivation is that I wan to gain experience working on a large project, especially one that I'm interested in. I decided a while ago that I wanted to spend my summer contributing to an open source project. When I recently learned about GSoC, it seemed perfect. I can earn a little money and reputation doing what I was planning to do for free.

What are you studying, subject, level and school?

I am a Junior studying Computer Science at Vanderbilt University.

What country are you from, at what time are you most likely to be able to join IRC?

I am from the United States. I will most likely be online from noon to midnight CST.

Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.

I have no other plans or commitments.

Experience

What programs/software have you worked on before? I have worked on various projects for classes. Programming classes I have taken or am currently taking include:

  • CS 101 - Intro to Programming and Problem Solving
    • Basic Java
  • CS 201 - Program Design and Data Structures
    • C++, pointers, recursion, data structures, object-oriented programming
  • CS 231 - Computer Organization
    • MIPS assembly
  • CS 251 - Intermediate Software Design
    • STL iterators, algorithms, containers, and allocators. Exception safety.
    • Software design patterns. Implementing templatized vector, list, and a pattern-based expression tree.
  • CS 270 - Programming Languages
    • Writing Sudoku solvers in C++, Lisp, Prolog, Ruby, and F#.
    • Programming language paradigms and design considerations
  • CS 281 - Operating Systems
    • Linux C API's: POSIX message queues, semaphores, shared memory, threads, pthreads
    • More design patterns - wrapping ugly C API's into nice C++ classes
  • CS 292 - Big Data
    • SQL, NoSQL: MariaDB, Cassandra, HBase, BigTable

Have you developed software in a team environment before? (As opposed to hacking on something on your own)

No.

Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?

No.

Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.

No.

Gaming experience - Are you a gamer?

Yes.

What type of gamer are you?

I can be casual or competitive, depending on the game and mood.

What type of games?

My favorite types of games are RTS, MOBA, and RPG, but I also enjoy some turn-based strategy and FPS.

What type of opponents do you prefer?

I prefer human opponents, ideally who are sportsmanlike.

Are you more interested in story or gameplay?

I am more interested in the gameplay.

Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer. We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.

I have not played Wesnoth. I just finished the tutorial. I'll most likely pick it up pretty hard though, once I have more free time.

If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so.

I do not have commit access, but I've submitted one pull request here: https://github.com/wesnoth/wesnoth/pull/122

Communication skills

Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.

English is my primary language. I write it rather well.

What spoken languages are you fluent in?

I'm fluent only in English.

Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.

I've gotten used to interacting with players who can be less than polite. If they're being obnoxious, I prefer to mute them.

Do you give constructive advice?

I try to give constructive advice where I can.

Do you receive advice well?

I strive to be as open as possible.

Are you good at sorting useful criticisms from useless ones?

Unless someone knows more about something than I do, I trust my own judgement first. That being said, I'm always open to the possibility that I'm wrong.

How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project wants?

Having tried both approaches, I think that if you're going to spend any significant amount of time on something, it's better to win people over to your idea first. For smaller changes, I think it's less of an issue.

Project

Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?

I chose to unify and extend single-player and multi-player code paths so that user made content will work across game modes.

If you have invented your own project, please describe the project and the scope.

See Description.

Why did you choose this project?

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".

See Timeline.

Include as much technical detail about your implementation as you can

See Details.

What do you expect to gain from this project?

Mostly experience, and of course some money from Google.

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'm interested in eventually working with the AI as well as porting to iOS and Android.

Practical considerations

Are you familiar with any of the following tools or languages?

  • Git (used for all commits)

Yes, and much more so now that I've gone through the process of submitting my first pull request.

  • C++ (language used for all the normal source code)

Fluent. The majority of my programming courses have been taught in C++.

  • STL, Boost, Sdl (C++ libraries used by Wesnoth)

I know the STL fluently, Boost not as well, and I have no experience with Sdl.

  • Python (optional, mainly used for tools)

I'm not very familiar with python. Most scripting I've done has been in Bash.

  • build environments (eg cmake/scons)

I'm familiar with cmake.

  • WML (the wesnoth specific scenario language)

No experience.

  • Lua (used in combination with WML to create scenarios)

No experience.

Which tools do you normally use for development? Why do you use them?

For small projects I use vim, gcc, and git. I like vim because I've gotten used to it and it's intuitive for me. For something as large as Wesnoth, I've been using Code::Blocks so far, and It's worked out well. I may switch back to vim once I figure out a good way to manage large numbers of files.

What programming languages are you fluent in?

C++, C, Lisp, and Java.

Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail.

I don't mind talking on the phone.

This page was last edited on 4 April 2014, at 03:39.