[Proposal] Unity3D Recreation of XMage

[analytic-bias]

I would like to make something like MTGA with the codebase of XMage. The goal is to make it have the pros of both two games: friendly interface and good new-player experience (so that we can convert people to MTG, which is important) from MTGA and 10000+ cards and freedom (open sourced, no colletible function, no money invovled) from XMage.

Ideally, what I would expect is that it will be compatible with XMage codebase for all future versions (i.e. all future cards can be wrote once in Java and then usable to both XMage and the Unity3D recreation).

Here's some questions for the community:

• Is there already a project similar to my proposal?
• Is what I'm proposing allowed by you the developers?
• How is the current XMage codebase in terms of compliace with the comprehensive rulebook?
• Is there anyone wanting to join me developing this?

[analytic-bias]

Possible techstack: Unity3D, IKVM

[JayDi85]

Is there already a project similar to my proposal?

1. Nope, but you can find more details in #5373

Is what I'm proposing allowed by you the developers?

2. Yes, you can do anything you want. It's a MIT license.

How is the current XMage codebase in terms of compliace with the comprehensive rulebook?

3. It support full rules with some exceptions like mutate cards or offline mechanics for un-sets. XMage uses server side logic and cards processing, client sends only commands and feedback from users.

Is there anyone wanting to join me developing this?

4. There are a "littile" problem -- xmage uses JBoss network engine (binary protocol with java objects). It's incompatible with any third party clients (even JVM must be same major version for both client and server). So that engine must be reworked and replaced with text base protocol like json or another. Search issues for graphql for more details, discussions and examples.

[theelk801]

Unity uses C#, right? would that present an issue?

[analytic-bias]

@theelk801 I don't think so. There's something called IKVM that allows such interoperation, and I'm going through the codes under Mage folder and it seems it's rather well-designed and decoupled.

[analytic-bias]

Hi developers.

If it's not too bothering, could you please write and publish a short document on the API of XMage codebase like "invoke this to setup a deck, that for starting the game, that to play a card, that to tap" etc.

[JayDi85]

• Player interactions in game: Player.java. Search implements Player for different implementation (empty/stub implementation, unit test, HumanPlayer, ComputerPlayer). Also can be usefull third party/console client implementation try from #4575.
• Client-server interaction (non-game): SessionHandler.java. I recommends to search for LoadPlayer from LoadTest -- it's the simpler client realization for server connection and game start.

[allentiak]

@zhangyutong926

You might be interested in give Matag a look. (Disclaimer: I have done almost trivial contributions to it.)

MaTaG has a great UI (see below). Whereas its backend is quite limited, I think it could be possible to modify it to work as an XMage client. Just be aware that MaTaG's license is AGPL, so if it gets integrated into the XMage client, its license should be switched to AGPL...

[JayDi85]

Intergating project/service (bridge between xmage server/client and third party app) can be made at any license.

[allentiak]

It always depends on the definition of "integrating".

• If two separate modules interact (e.g., the client and the server), each one can have its own license.
• In order to combine AGPL code (in this case, MaTag's) with MIT code (in this case, XMage's) into an integrated module (let's call it "Mage Client NG, with MaTaG UI"), the resulting combination should be AGPL.

The advantage I see in such a licensing choice is that this would prevent any attempt to "privatize" the code by any third-party. This is the case for Magarena (GPL3), Forge (GPL3), and MaTaG (AGPL3-or-later). Whereas the current XMage licensing choice (MIT) does not protect against this potential problem, its license is fortunately compatible with the others I mentioned. This is, XMage's code can be integrated into the other projects'.

[JayDi85]

It's not a code interaction. It's a separate apps.

I was working on this issue (integration with third party clients). And I came to the conclusion about the following architecture:

1. XMage basic distribution must contains special library/service like "xmage api app" -- it's a simple client-server app on java, but with REST end points (or other open protocol);
2. REST end point gives access to all basic xmage client features like connect to server, create new games, play it, etc;
3. Third party clients can implements that api.

So no needs to rewrite network engine, no needs to change any licenses, all code compatible with any xmage servers. All must works from the box:

• xmage distribution (current version + api lib);
• third party client (any language, any license);
• third party connector to xmage api app (any language, any license);

[allentiak]

@JayDi85 Both are aspects of the same thing. There is no contradiction between what you said and what I said. Please, read carefully what I wrote :-)

[allentiak]

@JayDi85 BTW: I updated my earlier comments. You may want to read them again :-)

[JayDi85]

@allentiak can you explain potential problems with MIT license for XMage (by example)?

[allentiak]

Sure, @JayDi85 :-)

(Disclaimer: I am not a lawyer, and this is not legal advise - only my opinion.)

The main potential problem I see for XMage is simple: Loss of freedom by its users.

• Anyone (including WoTC/Hasbro) can "privatize" XMage from its users. This is, they can integrate its code into their own product (this is, to take advantage of the huge collective work made by the XMage community) and prevent whoever uses that modified version from sharing those benefits back with the rest of the XMage community.

• On the contrary, no one can "privatize" MaTaG (AGPL-licensed). Anyone who interacts with it (even a subscriber via a network) has the right to benefit from any improvements made to the program by whoever provides access to it, and to share them back upstream

• In the case of the other projects I mentioned (Forge and Magarena), their license (GPL) does not fully protect them when using a client/server model (such as XMage's). People need direct access to the binaries to gain the right to benefit from any improvements made to the version they are using.

For a pragmatic rationale on how to choose a (libre software) license, I recommend this excellent article by Bruce Perens about Libre Software Licensing. It is the one I used when recommending the use of AGPL to the developer of MaTaG. (Yes, it was me :)

As a final reflection, it is clear to me that using the "open source" term helps preventing people from realizing these potential problems.

--Leandro

[allentiak]

@zhangyutong926 Still interested in implementing this?

[allentiak]

@cute-sayako Still interested in implementing this?