Collectible Card Game Headquarters

The problem with cheating would still be present in that each player's local Forge instance would have the contents of their library in memory.

Regardless, I agree with the casual sentiment that's been expressed here -- if it's easier to get a first version together that doesn't work to prevent this (i.e. one instance of Forge acts as the 'server' and the other instance connects to it) that would still be a great improvement to the software. Then eventually adding server capabilities (e.g. a headless mode of Forge that would centrally handle hidden information) could be an amazing future improvement.

I'm probably only ever going to play with my friends but I do agree that a separate social component would probably be the least controversial and also least 'threatening' to Wizards option. So say if you have a site or board with several constant chat rooms (commander, modern, casual, etc) where people can post the relevant information when looking for games:

Lugaru here! Looking for 3 opponents to test a commander deck! Connect to 12345231 password letsplay.

Also by divorcing it from forge you can use any social tools your web design skills allow, personally I suck but through joomla I've been able to set up free forums, chats, user profiles and such. That if somehow we end up with the only healthy community on the internet (joking, kinda) you can have players give each other ratings, scores, comments, trade decks, etc.

drdev wrote:Since Forge's game logic isn't currently built in such a way that individual actions could be serialized and sent,

That was the actual objective of introducing those PlayerControllers.

drdev wrote:I'm thinking instead that every time a player passes priority, we'd simply serialize the entire game state and send it to the server. The other player's machine would then just ping the server on an interval, and if it detects that an updated game state is available, it would retrieve that state, deserialize it, then call the necessary client logic to apply it on the UI side, just as as we already do after the AI takes actions.

The thing I always adviced against.

drdev wrote:With such a strategy, the only tricky part is creating an optimal serialization method for the game state. The good news is, if we can do this, it would also allow us to add support for saving and loading games, which would be a nice enhancement.

Grab some library (Protobuf or counterparts), there's a huge amount of them. In my mind a manual serialization of those Card objects would be a worst nightmare.

drdev wrote:How does this plan sound to everyone?

Bad, yet it's better than nothing.

Max, I know you're not working on the project anymore, but could you maybe outline what your plan was for using the PlayerController classes to support a network player? My suggestion was just the simplest implementation I could think of and I'm quite aware it's not the optimal one. If you could advise us on a better way, I think we'd all be open to trying to implement it that way instead.

You're right, I didn't make it. Don't even well understand why I lost interest.
And it looks like no disater is happenening.

- Care to explain the plan?
- Sure. The idea was to host a server on only one machine (a dedicated one or one of players' computer - does not really matter) and make the other one behave as client - that is request the information it is allowed to know, receive requests from server when a player associated with that connection gets priority or is expected to make another choice. Other connected people may also request public information but take no decision since they control no player (this is how they were supposed to spectate)

All of the players' actions were intended to be transmitted over the network. Imagine a new PlayerController descendant (i.e. RemotePlayerController) whose methods contain instead of return GuiDialog.chooseOne(all_our_parameters) some code that asks the same question a remote player

Code: Select all

connectedSocket.send(new ChooseOneEntityRequest(all_our_parameters));
ChooseOneEntityResponse result = connectedSocket.waitFor<ChooseOneEntityResponse>();
return result.chosenObject;


The part of code that is really missing in Forge is to transfer the read-only game state (without information the opponent is not supposed to know) to a remote player.
The presentation layer has now direct references to game object and can synchronously read any information to draw player panels, battlefield, etc.

Instead the game state could be converted into some different and more lightweight objects to be sent over network (serving as a reflection of the current game state) that for obvious reason don't have any methods to change their state (they will be deserialized on client, so that changes on client side will change nothing on server. Because to change the game state the client may only take decisions when asked by PlayerController to do so)

To start with, we could have the GUI client rely on those reflection objects while drawing battlefield (and cut its direct access to the actual game state): choose which fields are needed for each type of entity, set up an updates pipeline, write one way conversion (from game state to reflections)

After the local client starts using such objects, it should not be too hard to send those to a remote host, that could draw the game events on its display...
Phase 3 is about turning such spectator into a player - by linking an instance of PlayerController to the network connection, asking for action and waiting for their decision. Meanwhile (while thinking on a next move) the player's client should be able to request actual game state (the latest reflection, limited by the information the client is allowed to know).

That's quite complicated and requires a lot of efforts, but looks like a path to real multiplayer with a potential to host fair tournaments (or handicap matches where cheating is allowed by settings) and allow people to spectate the matches.

That sounds ideal if someone is up to the task. I'm not sure I have the time or expertise needed to do so though.

That said, if somebody wants to take this on, I can definitely do the necessary UI development to support network play.

Hello everybody, I was invited by elcnesh to help build the network multiplayer. I had pretty much the same thing in mind as Max mtg suggests in his comment above. I've never done anything on forge before so I hope You'll trust me with this. I'm still working on setting up everything, but I hope I'll be able to get started soon.

Ok, so I was thinking about this... We'd need to change a lot of code in all the controllers, and some of the views. Perhaps we should branch to implement this? I know next to nothing about SVN branches, so if someone could create one, that'd be great. I think we could then get started by converting all the direct references to game objects in the gui code (both desktop and android – Dan, if you could help out there that'd be great) to lightweight, text-based objects.

I'm not sure if that's a good idea, re-merging branches is a huge pain in the donkey. And with two branches with a lot of changes it might even be impossible. I would suggest making the required changes in a gradual way, which prevents this problem. It would also allow the changes to be tested with the main branch, which should cut down on extra testing work. You might be surprised how big the structural changes are that you can make without the user even noticing. Structural changes don't need to create a lot of bugs as most mistakes with such changes will be caught at compile time.

PeterPrins wrote:I'm not sure if that's a good idea, re-merging branches is a huge pain in the donkey. And with two branches with a lot of changes it might even be impossible. I would suggest making the required changes in a gradual way, which prevents this problem. It would also allow the changes to be tested with the main branch, which should cut down on extra testing work. You might be surprised how big the structural changes are that you can make without the user even noticing. Structural changes don't need to create a lot of bugs as most mistakes with such changes will be caught at compile time.

And this is where I'd advocate changing over to Git where branches are made easy.

I think another branch created similar to the KeywordEnchancement branch would work. As long as you pull changes from the master branch every once in a while it won't be too much to do all at the end.

And this is where I mention we already tried the switch to GIT thing and it failed pretty miserably. Branches in SVN aren't as horrible as people make them out to be, but this is something that would be touching a lot of code so would certainly require lots of tender merging to pull off properly. Active merging from the trunk, and warning everyone before you plan to merge back in can make it work just fine.

friarsol wrote:And this is where I mention we already tried the switch to GIT thing and it failed pretty miserably. Branches in SVN aren't as horrible as people make them out to be, but this is something that would be touching a lot of code so would certainly require lots of tender merging to pull off properly. Active merging from the trunk, and warning everyone before you plan to merge back in can make it work just fine.

The only real problem with branches in svn is the fact that they're entire copies of the code, so switching can get cumbersome. Any of the above solutions would certainly work fine, though.

Sound good. Maybe we can impose a code freeze on the GUI-related code? As far as I can tell, there hasn't been a lot going on there lately (except in the Android part), so if we stick to critical big fixing there that might help make merging easier. IMO this is definitely too big to be handled in a few large commits, and is also hard to do only partially.

I am no coder, but we're all aware of what happened to the most popular multiplayer open source game using the mtg card system.

I was thinking , could it be possible to do it with an external application that would manage the all-things multiplayer and that would be hooking on Forge, and not it being a part of the actual Forge code.

As if the multiplayer component wouldn't be an actual part of Forge but another application, in case it gets the c&d treatement, it would maybe not impact Forge itself ?

And in the case the external application isn't possible technically making MP as a fork of Forge (so there would be ForgeMP and Forge being separate programs) could at least lessen the chance of the base Forge (the one without MP) struck by a c&d ?

Ok, so I think I've found a way to do the GUI refactoring bit by bit!

Attached is a patch implementing a GameView, which provides access methods to a Game. In this case, it directly references a local Game, but by translating it into an interface it could equally well provide access to a network game (possibly caching some unchanging values like game variants for speed purposes).
I marked the methods that still provide direct access to Players, etc. as deprecated, as these should later on also use view objects of sorts.

Dan, could you have a look as to how this affects the Android code? I don't want to break anything but I don't know how to test it.

(PS: I haven't tested this, but it only transfers some method calls, so it shouldn't be destructive. I'll test before committing anything )