Collectible Card Game Headquarters

I still have lots more work to do on the MCTS AI but while browsing through the forum and reddit posts I have noticed that there are lots of complaints about server performance/disconnects. So I would like to start thinking about a server redesign.

I think the most beneficial task right now would be to update the IO framework. A while back I switched from RMI to Jboss Remoting but it appears that JBoss Remoting is not getting much attention anymore. I don't see any major updates to the package in several years. http://jbossremoting.jboss.org/downloads

I've done a bit of research and found that a good alternative might be netty.io. It uses java.nio which should provide some performance benefits.

If anyone else has some other ideas/suggestions I would like to hear them.

BetaSteward

You're right, currently a very weak part of XMage.
I recently talked with Noth about this problem. Here's the topic with the conversation.

http://www.slightlymagic.net/forum/viewtopic.php?f=116&t=16722

I now remember reading that thread a while back but I had forgotten about it. Maybe that's where I got the idea for netty.io

I see that North had suggested that we also overhaul the inner workings of the server. I completely agree with that. I think that updating the io framework can be done relatively quickly and will hopefully provide some relief from disconnects. A second round of redesign could tackle the problems with the server code.

BetaSteward wrote:I still have lots more work to do on the MCTS AI

You noticed the missing Turn.getValue() method of your last AI commit?
I intend to release soon a new XMage version and I would like to have a working AI code for that.
Did not check yet what the missing method should do (replaced it by a simple dummy until now).

Sorry about that. I was playing around with ThreadLocal StringBuilder. I will check in the code since it does provide a small performance benefit and could be applied to other frequently used StringBuilders.

I had this migration to Netty on hold for a little while. The main reason was because I wanted to write a proof of concept for a game engine that has the same requirements as MAGE.

In my mind, the game (rules + state) were supposed to be fully non-blocking. This means the client always sees some kind of state + actions that are available. When I say actions it can be something like play a card, play an ability, choose a color and so on - anything that requires the user input. In this way, the game will always be in a stable non-blocking state. This kind of design helps in a lot of areas. I think the drawback will be higher complexity. I can't say for sure until I'll have implemented a proof of concept.

I don't think we'll have it like that in MAGE. What we can have is implement the communication layer using Netty and implement some kind of delegation. I think this is how it is at the moment. the replacement shouldn't be too painful.

I think that moving XMage to a non-blocking paradigm is a good idea. There aren't very many long running calls so the amount of time spent blocked is small. As you indicated, waiting for user responses is probably the major blocker.

Converting the io framework to Netty should make most of the calls non-blocking if we use the NioServerSocketChannel. It might even fix the user response blocking. I haven't gotten too deep into Netty yet but I did implement a basic chat application to get familiar with the fundamentals.

I have created a new branch Network_Upgrade and have committed my first update. At the moment only the chat pane on the table pane is functional. But this does cover a lot of the client server communications including connecting, logging in and transferring objects back and forth.

There is an issue right now with timeouts. I suspect that it should be an easy fix but I wanted to give everyone a look at how the network upgrade is structured.

I will be committing changes frequently as more functionality is updated.

BetaSteward