Web-based front end for mage

[braden]

I'm a web dev experienced in building rich client apps and am also a huge magic fan. I've always wanted to build a web-based mtg client, and I think that using all the hard work that the mage devs have put in would be amazing. I've got a lot of experience writing realtime apps in React.js, and thought that me and a couple friends could build something pretty cool.

What do you guys think? I feel like difficult parts of doing this are:

* How do we share the card logic between client and server (Possibly compile the common modules to javascript, so that we can write the card logic once...Maybe use one of the java to javascript compilers out there (GWT?)
* I understand that mage uses jboss remoting which would have to also support accepting websocket connections and messages so that the client may send and receive updates from the mage server...what do the mage data contracts look like?

PS. really appreciate the work you guys/girls have done making such a great project.

Sorry for no urls for react and some Java -> Js compilers....post looks too spammy apparently

[LevelX]

Hi braden,

sorry for the late response (I was a bit busy with the XMage update over the weekend).
Nice to hear that you want to contribute the the XMage project.

I talked lately with North about the replacement of JBoss Remoting with another communication layer.
The cause of this was the high amount of disconnects that happen on the server currently. Here is what he wrote - just as basic information. I hope he stays involved and getting the communication layer updated to some modern tool would be a great thing.
Maybe also a good point to settle the needs of a new client.

I gave it a bit of thought. I'm thinking that maybe switching to a NIO communication layer can alleviate some problems related to disconnects. What this allows is a smaller thread pool that handles the connections. As such far less context switching. I'm looking at Netty as a replacement for Jboss remoting. The API isn't exactly friendly but it is well built. As far as I know Play framework was using it so that does give it some credit.

I also see currently some more leverage point to fix the connect problems (see here: https://github.com/magefree/mage/issues/662). Before changing the communication layer I will try to fix other problems (e.g. garbage collection problems) because it would be very disappointing to do all the work to change the communication layer and the same problems would happen because they are caused from other parts of the project.

To create a new client is IMHO a very big task and needs a lot of work and of course a lot of endurance. I've seen over the time some projects in the past to create a JavaFX client but the work to do was probably too much, so the projects died after some time.

I also have to say that network communication is not the area I'm familiar with and beside the bug fixing and implementation of new cards and features for XMage I hardly can see that I have the time to go into this and support the creation of a new client a lot at the moment.

* How do we share the card logic between client and server (Possibly compile the common modules to javascript, so that we can write the card logic once...Maybe use one of the java to javascript compilers out there (GWT?)

In my opinion there should be none or very less card logic be on the client. Or maybe I'm not sure what you mean with "card logic".
All the relevant actions have to happen on the server to prevent any kind of cheating. Maybe you can explain a bit in detail what you intend to do?

* I understand that mage uses jboss remoting which would have to also support accepting websocket connections and messages so that the client may send and receive updates from the mage server...what do the mage data contracts look like?

As already said that's not my area. You have to look into the project source and find out.

Sorry for no urls for react and some Java -> Js compilers....post looks too spammy apparently

You have to habe 5 posts, than this blockade is removed.

We should use this thread to exchange out opinions about the possibility of the creation of a new client and the exchange of the communication layer. So it's also very welcome if others with knowlege in this area post their opinions and ideas.

Thanks a lot for your dedication to the XMage project.

Regards
LevelX

[North]

As it happens I have experience in both client side (javascript) and backend development.

XMage is based on RMI (remote method invocation) for communication. Seeing as how all communication passes through a restricted set of interfaces, this is where the replacement shall take place. I can't promise anything but I'll keep in mind the possibility of using a JS client.

What you need to understand about how XMage works is that card data is not required in the client. At some point all the logic was a dependency for the client but got removed. Now only card data can be found in the client (can be serialized to JSON for example). This ensures the client doesn't have to be rebuilt every time a new card gets added. In case of the web client, this data could be stored in either LocalStorage or a client side database. I would choose the later if the different browsers have finally come to a consensus regarding this. If I'm at it I would also like to add that it would be a good setting to save in local storage the location to the card images so that if the user has the downloaded they can be used from his PC.

If you don't have the logic in the client you may ask yourself how are the rules enforced. Here are the kind of messages the client exchanges with the server:

• Information messages - this are basically a type of messages you "observe" and respond to them with some kind of UI update. For example you receive a message from the system or from somebody else. You can see this as notifications.
• Question messages - this is when the game expects you to make a decision, for example to pick a color. I'll need to look to see how the response is sent to the server.
• Command messages - this is when you send a command to the server. Here are some examples: create a game, send a chat message, play an ability and so on.

When it comes to writing such a client it is mostly about sending the command messages, "observing" information messaging and responding to question messages.

Here are the steps to build a client for XMage:

• Connection to server. This is the very first step and is essential. As you have guessed, there is a need for a bidirectional connection and as far as client side goes the only solution is either web sockets or a flash client only responsible to communication.
• Create the lobby. Here you can see all different users, chat with them and later on create games and join games.
• Create a game.
• Join a game.
• Play a game. Here comes the most difficult part of them all and probably the one part you are excited on working on. Works the same way as the basic chat client but you have more logic behind (more kind of messages supported).

PS: Because of internet connection issues I couldn't research the replacement solution in detail this past weeks. I expect to be on a decent internet connection two weeks from now. Until then all I can do is look through the code a bit and familiarize myself with the communication layer.

[braden]

Hey! Thanks for the great replies! It's good to see that mage has some dedicated developers.

In my opinion there should be none or very less card logic be on the client. Or maybe I'm not sure what you mean with "card logic".
All the relevant actions have to happen on the server to prevent any kind of cheating. Maybe you can explain a bit in detail what you intend to do?

I've built some realtime apps in the past, and the best implementations had this architecture:

1) Client and server each have a database for their state (client's may be localstorage or something).
2) Client and server both have a shared set of code for the business logic of the app. The client has this so that when the user performs some action we get to process it immediately and then the server runs the same stuff and sends back the verified changes to the state that the client should perform. Basically you get instant feedback, without compromising anything since the source of truth is still the server. This could be a little harder to do in mage since the server is Java (though we should be able to find a way to have that java code compile to JS to be used in browser) than in my other projects where we used Node.

We could do this without sharing any code (like the current mage does), however it makes the app feel sluggish at times if the user has any latency issues.

If you don't have the logic in the client you may ask yourself how are the rules enforced. Here are the kind of messages the client exchanges with the server:
Information messages - this are basically a type of messages you "observe" and respond to them with some kind of UI update. For example you receive a message from the system or from somebody else. You can see this as notifications.
Question messages - this is when the game expects you to make a decision, for example to pick a color. I'll need to look to see how the response is sent to the server.
Command messages - this is when you send a command to the server. Here are some examples: create a game, send a chat message, play an ability and so on.

Thanks for this! Since it's using RMI, this could be a little more tricky to implement a websocket based approach...would be interested to have an IM with someone about this to bounce ideas around how it should look for a web version. I've been looking through the code, and have a fairly decent grasp of it (Looks like good code BTW ). I may try implementing a quick prototype of what a new websocket based communication layer would look like.

Thanks for the replies!