SoC2014 RiftWalker Unify SP MP

From The Battle for Wesnoth Wiki
Revision as of 22:32, 27 March 2014 by RiftWalker (talk | contribs) (→‎Medium Priority)


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 improv 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.
    • It may be possible to:
      1. Use the same define. This would rule out isolating parts of scenarios within campaigns
      2. Define another define alongside it, and work with it similarly.
    • 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.
      • Same goes for eras. We need to find the best place to implement these things.
    • 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:
      1. Load the define= value from config into game_classification
      2. 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
  • 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.

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

Once we've got basic functionality working as described above, It's time to implement some of the features that motivated these changes and stem from them:

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

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.
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.
  • Allow for converting single-player campaigns into co-op multi-player campaigns by adding sides.
    • Both of the above ideas might introduce balance issues which would need to be sorted out.
  • 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 that 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.

Timeline

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.
- Apr 1 - Apr 7 Work on a solution to the namespace collision / content loading problem.
- Apr 8 - Apr 20 Continue to learn and work on problems that arise. Keep working on namespace problem if not solved yet.
- Apr 21 "Community Bonding Period" begins. Finalize plans for the summer. Work on getting add-ons fully functional within SP.
- May 3 Fly home for the summer. Begin coding in earnest.
- 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.
- June 9 GUI's should be basically functional. Begin working on server selection/switching.
- June 23 Mid-Term evaluations begin. By now, GUI's are fully working with dynamic side assignment between scenarios.
- June 27 Mid-Term evaluation deadline.
- June 28 - July 14 Work on some of the 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 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.

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.

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.

Retrieved from "https://wiki.wesnoth.org/index.php?title=SoC2014_RiftWalker_Unify_SP_MP&oldid=54269"