Network Multiplayer (Multi-human players)
Posted: 22 Mar 2013, 15:00
uhlersoth wrote: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: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.
- 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();
}
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.
myk wrote:@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.
uhlersoth wrote: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.
myk wrote: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.: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.
- write a design document, detailing the proposed changes and outlining the archicture and data structures
- 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.
- implement network logic for lobby, including communications architecture (peer-to-peer? server-based?)
- 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)
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 : )