Network Multiplayer (Multi-human players)

[Chris H.]

I'm trying to implement a custom FControl, for the purpose of creating a custom home screen. This is doable, but requires a small change to the existing code. Could you please consider the following feature request?

1. Create a frame controller interface (possibly named IFrameController). This interface should have the following methods:

Code: Select all

public interface IFrameController {
    public Player getPlayer();
   
    public void setPlayer(Player localHuman);
   
    public Lobby getLobby();
   
    public int getState();
   
    public void changeState(final int i0);
   
    public void initialize();
   
    public SoundSystem getSoundSystem();
   
    public List<Shortcut> getShortcuts();
}


2. Change FControl to implement this interface. This shouldn't require a code change other than to add the "implements IFrameController" to the class definition, since FControl already has all of these methods.

3. Change Singletons such that the member control is defined as an IFrameController instead of as an FControl.

4. Change Singletons such that the set/getControl methods use an IFrameController instead of an FControl.

5. Change the 20 or so references throughout the code from FControl.SINGLETON_INSTANCE to Singletons().getControl() but leave the one in Main alone.

This feature would be awesome for a geek like me who loves Forge and tinkering with Java code, and would make Forge slightly more componentized.

 

@uhlersoth: We could make that kind of change fairly easily, but could you explain the purpose a little more? If you want to make a custom home screen, isn't this something you'd have to maintain in a local branch anyway? Also, what kind of customizations would you like to do? Would they benefit other users if they were just integrated into the main codebase? We do have this issue currently open in our bug tracking system, and getting it addressed would be welcome.

 

I'm trying to extend Forge so as to allow for multiplayer. Forge has hands-down the most robust card/rules management system I've seen, and my fellow local MtG players already use it to test their decks. The AI isn't always that smart (no offense! like I said I'm a Forge fanboi), so adding multiplayer capability using the Forge framework would be ideal.

To do this, my idea is to begin by swapping out the standard home screen with a simple lobby (online players in a JTree, with the option to invite them to games, etc) that you would expect to see in any server program. All the multiplayer work would need to be maintained separately, yes, but I'm not asking y'all to take on that job. If my efforts pan out I would send the code your way and you could do with it whatever you want - throw it away, integrate it, whatever.

 

This is a pretty big change for Forge, though I think it would be a welcome one. I don't think the "integrate in one go" method would work very well, though. The code changes quickly and long-term branches are difficult to maintain. Is there a way to break this up into smaller sub-projects that can be individually useful and merged incrementally? e.g.:

1. write a design document, detailing the proposed changes and outlining the archicture and data structures
2. prepare UI to be more "lobby-centric", including settable user preferences that will only turn on network play capabilities for those who want them (label them experimental, off by default). ensure AI players can be added easily, as that will still be the norm for the majority of players.
3. implement network logic for lobby, including communications architecture (peer-to-peer? server-based?)
4. implement network logic for match (may need to split this up into many smaller tasks, such as first allowing actions to be performed manually on the local side on behalf of a network user, and then automating them one by one)

I highly recommend you try a hack-job prototype for that last item before you even begin anything else, just to get a taste of what will be required to manage game actions and input dependencies across a network. Multiplayer has come up several times in the past, and I'm sure the other devs will have more advice/warnings for you too.

Frankly, though, I think this is too large for a first-time contribution. You will be touching nearly all subsystems in this, and each have their own little quirks and histories. It might be wise to make some smaller contributions first, just to get some familiarity with the codebase. It will also give the devs a chance to become familiar with you and get a feel for how likely you are to destabilize currently working code : )

 

[Chris H.]

I agree completely regarding your "integrate in one go" comment - not gonna happen. But that's actually why I'm hoping to use this dev model - determine some hookpoint that leverages multiplayer, which can be opened up without any impact on the existing dev stream. The last thing I would want to do is have any of your current resources redirected toward a side project like this. Given a choice, I would much rather see Forge stay up to date with all the latest rules changes than to see multiplayer added.

But this feature request of mine follows this model. It opens a hookpoint for creating the lobby. I'll then be able to create a lobby in my own local code without impacting the existing dev stream.

I definitely want to put together a prototype first, which is really why I was reluctant to bring the multiplayer discussion up at all. What I realized, though, is that here in the very first steps of my prototype, trying to get my local friends to test it out with me will be painful without this feature. Without it, I'll have to extract the Forge code every time there's a new release, modify it with the changes I described above, build it, jar it up, and send it out to my local friends. But with this change, my local friends can continue to simply download Forge releases on their own, since the prototype I'm working on will just specify a different FControl in its own main() method.

That said. I want to simultaneously agree and disagree with your comments on the scope of the contribution. On one hand, I'm a professional Java developer of more than a decade. These days, I speak Java better than I speak English. But at the same time, my professional experience with Java makes me wary in approaching large, mature projects such as Forge, since it goes without saying it'll have a myriad of hidden quirks. I completely agree that adding multiplayer capability robustly is a project that should involve several experienced Forge developers, rather than a Forge noob such as myself. But putting together a prototype, or determining the feasibility to begin with, should be within my capabilities.

[Chris H.]

@ uhlersoth:

We have a wiki page with some basic info on how to set up a dev system on your computer, you may want to look at it.

Forge:How to Get Started Developing Forge

[Max mtg]

I don't yet know how much development it will take to start a multiplayer match. On the other hand lobby can accept network connections at this point already to let players join (as spectators - it's fair to begin with that) and recieve GameEvents posted through the GameState's event bus.

The what I am really concerned about - think how thin web clients would join the game. Since the game is about waiting for other player to react, and common HTTP does not suppose the client to recieve anything from server (by server's initaitive), the WebSockets protocol looks like an easist way to support these clients.

[myk]

does this mean you're envisioning a server-hosted multiplayer forum, not just direct connection multiplayer?

[uhlersoth]

@Chris

I already have the Forge source code extracted locally. I'm already actively developing it locally.

[uhlersoth]

What I've created so far is a server. You login with a Java client (using sockets) and can see a list of anyone else logged in. After selecting a user, you can send them a game invitation, and... that's as far as I've gotten.

I have no interest in developing a web client. My goal is to be able to play MtG against people I know in real life, not the world in general. I plan on setting up my server, giving the connection into to my local friends, such that we can login to play against one another when it's convenient.

To set this up so far, it required mod'ing the Forge code to allow for a different FControl screen. Since I can't convince the Powers That Be to abstract the FControl to an interface, it'll make my prototype work a ton harder (every time I synch my local code to the latest Forge code, I'll have to remake all these changes... and if my friends want to try it out with me, they'll have to do the same. Even less convenient for them, since they're not programmers.)

[Chris H.]

Thank you for the additional explanation of what you are planning to accomplish. These types of discussions are very helpful. As a moderator of the Forge forum I like to see people conversing about a variety of Forge related subjects.

I created this topic to give the various developers a place to discuss this highly technical subject without overwhelming the average user who visits the non-developer Forge forum.

I suspect that the experienced developers will agree to abstract the FControl to an interface. I unfortunately, do not have the experience to handle this on my own. What we are seeing at this time is an effort to communicate with you to get a better idea and understanding of your proposal.

I also suspect that if you are successful in your proposal that other people would like to see your efforts made a part of the normal forge distribution. This would allow other people to set up a small server and invite a few of our friends to play a match together. Forge attracts a diverse group of people from around the world and your proposal would allow us to play against each other.

We plan to release the next beta on Friday March 29. It might be a good idea to abstract the FControl to an interface after March 29.

Would you like to have a branch set up in our SVN for your project? This could help you to merge in the FControl code changes and other changes back into the main trunk when it is time to do so.

[uhlersoth]

I don't really want ownership of a branch. I'm just interested in seeing if, with minimal, non-functional changes, Forge could be modified to allow for multiplayer. Sort of like a plugin. If it is possible, I'd hand over the prototype to the official Forge devs for doing whatever they want with. If not, then I'll go back to using Cockatrice or (gasp) playing in person.

If y'all can get this change added to the main trunk that would greatly help my prototype efforts; if not, I'll have to script up my own build process in Ant for this prototype for distributing it to my friends (and developing a build is usually such a chore for me ).

[Max mtg]

Web client will cover all your friends' mobile devices. AT ONCE. All that tables and phones with large enough screens have support for HTML5.
If you stick to sockets, they'll have to sit at their computers to play with you (unless someone develops a client application for that platforms).

I don't object to FControl abstraction. Have already pushed a change from branch to trunk to minimize my risks of conflicts on merge.

If, with minimal, non-functional changes, Forge could be modified to allow for multiplayer. Sort of like a plugin.

I have serious doubts about that. But anyway, you can give it a try.

[uhlersoth]

Web development makes sense. So would, say, an iPhone app, Android app, etc. Sky's the limit, and I would not be surprised, with what the Forge team has achieved so far, if y'all can do this.

However. I'm not a web developer. Nor am I an iPhone or Android app developer. I'm a hardcore Java/Swing developer. Taking the awesomeness that is Forge and cramming it into a socket server may be within my capabilities.

If you can do the web impl, I'd love to see it, and I'd playtest the heck out of it. But what I can do lies in a different direction.

[myk]

Since I can't convince the Powers That Be to abstract the FControl to an interface, it'll make my prototype work a ton harder (every time I synch my local code to the latest Forge code, I'll have to remake all these changes... and if my friends want to try it out with me, they'll have to do the same. Even less convenient for them, since they're not programmers.)

I didn't quite grok this. It's not that I'm /against/ abstraction of FControl, I just don't get the reason for it, and if we're going to add complexity, there had better be a reason for it. This is a prototype -- just check out the source code and hack! svn will merge server changes into your local changes, and mvn will build a snapshot distributable that you can give to your friends. No manual or repetitive work is required, apart from merge conflicts, but it looks like you're prepared to handle that (or just don't fetch changes at all; this is a prototype, anyway, not production code). I think we're prepared to give you a branch, too, which will make questions easier to answer and collaboration easier to manage.

[sidereal]

This actually overlaps some work I'm looking into. I want to be able run a headless game of AI vs AI, just to mess around with some deck testing. But currently the UI code is deeply integrated into the game model such that running a game without any notion of the UI is pretty far away. For example, there are calls to JOptionPane in GameNew and calls to GuiChoose sprinkled throughout the Effect classes. Similarly, running a game where one or more players are on the other end of a socket rather than at the UI is also pretty far away. I think a first step to this is to abstract away the concrete implementation of the player's interface and instead use some kind of PlayerController interface, roughly like:

Code: Select all

public interface PlayerController {
  public void sendMessage(String message);
  public <T> chooseSome(List<T> choices, int numToChoose);
...
}


Then one concrete implementation for the UI (sendMessage == JOptionPane.showMessageDialog, chooseSome == GuiChoose, etc), one concrete implementation for AIs (sendMessage == System.out.println, chooseSome == AI.choose, etc) and potentially another concrete implementation for a network client. This isolates the game model from having to know anything about the view implementation.

Another nice thing about a migration like this is that you can do it piecemeal. If half of the old calls are migrated to playerController.doWhatever and the other half still call directly to the UI, it's invisible to the user and doesn't break anything. And then at some point you've cut everything over and a headless game or network client becomes much more manageable.

[Max mtg]

@sidereal, did you mean something like this?
http://svn.slightlymagic.net/websvn/lis ... 0476c55d3a

Still, the current trunk will ocasionally throw StackOverflow exception in a match without human player.

[sidereal]

Ha! Yeah, a little something like that. Obviously for it to work with networking every player interaction would have to be plumbed through there..