Even when game is over, it is possible to continue playing in the GUI.

There needs to be an opotion to load pre-packaged mods, both in the client and in the server.

Mods can be written in different languages and we are expecting a "native" packaging method, this concretely means that a Java mod should be packaged in a JAR file, and a Lua mod should be packaged in a ZIP file.

It would be good to add in the README how to use TCG.
Doing so could draw more interested coders to the project.
Without a good description at the front, it's hard to feel compelled to dig into the code to find out.

I know it's a young project. It's normal that it's in a flux and probably even fundamental things can change, which could make it difficult to write a proper overview. But at least a brief summary of the core ideas to spark interest in visitors would be good, and definitely better than nothing.

Travis is still running on Java 8u5, we should force it to update to the most recent version, https://github.com/skiwi2/JavaLuaInteropTest/ has the code for that task somewhere.

During play testing, it was discovered that it is currently too easy to accidentally scrap a card. It would be better if Scrapping had an explicit button, or if a confirm dialog is shown so that the scrapping has to be confirmed.

The game designed was intended so that if a 4/5 attacks a 2/1, 3 damage (4 - 1) should go through and hit the player.

Currently the used package name is com.cardshifter.server, this should be com.cardshifter.api.

Make it possible to run a specific script (game) using command-line arguments

We should look into supporting parallel building using Maven, especially now that the FindBugs checks have been added.

For game play balancing please add a scrap value property that can be set for each card.

We need to have the ability to choose cards from the starting hand on the first turn, shuffle them back into the deck, and draw new cards to replace them (with no penalty)

Add support for more game types on the server, and make it possible to choose one when playing.

Because of #11, it is possible to get into a situation where you can't play any cards and you also do not draw any new cards. Possibly ending up in stalemate.

One possibility for a fix is that you can Discard up to 3 or so cards, and draw some new ones.
Another alternative is to avoid this from ever occurring, by having more cards that can always be used.

When playing a local game client, it would be nice to have a menu (using the Menu class) where it could be possible to change the AI, among other things.

Our core will be able to generate a lot of events, all of which need to be actable upon.
We are talking about events like this:

• Turn Start
• On Action (right before a card gets played)
• Turn End

There needs to be a system such that cards can add and remove event listeners on certain events.
You could have a real powerful card that has a chance to make you discard your whole hand when your turn starts. Upon activating that card, you need to be able to add that listener to the Turn Start method. When the card is deactivated, the listener needs to be removed.

We need a list of all possible events, generated by the core, on which can be acted upon.

Right now the client is not alerted when the other player leaves the game. When one player "clicks the X" to close the client window, nothing happens at all. If you Force Quit out of the program, the server reports this:

[2014-09-24 06:27:06,772] INFO ClientSocketHandler [ Conn-0](ClientSocketHandler.java: 61) - Socket Communication no more bytes to read for com.cardshifter.server.clients.ClientSocketHandler@72579bdc
[2014-09-24 06:27:06,775] INFO ClientSocketHandler [ Conn-0](ClientSocketHandler.java: 78) - End of run method for com.cardshifter.server.clients.ClientSocketHandler@72579bdc

Possible solutions would be for the server to send a message to the remaining client when it produces the above messages. Another solution might be to have the Client send a message to the server indicating that the window has closed. This might require a new type of Message to be created.

Currently the EntityRemovedMessage only sends id. Somehow though it needs to be able to tell if the zone for that entity was a deck. Perhaps a good option would be to send a list of all ids that exist in a zone in the ZoneMessage.

Currently the console game controller resides in the core module, this should not be the case and the console version of the game should be in its own module.

When a test fails in the server module it does not cause the test to fail, it only prints the stack trace.
It should let the test fail.

If the player has a full hand, when they draw a card that card should be destroyed.

The JavaFX windows keeps running, but you can no longer advance turns. Here is the error message:
(This is Lua) Turn Start! {Player 'Player1'}
(This is Lua) Deck is empty!
Exception in thread "JavaFX Application Thread" java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
(followed by a stack trace)

Please add the following attributes for cards:

• An actual ID field
• Card name
• Card description

I will leave the naming of those fields to developers' discretion.

The Travis build number should be added in the MANIFEST.MF file of every generated jar that went through Travis, this seems to be a suitable plugin: http://mojo.codehaus.org/buildnumber-maven-plugin/usage.html

This can be useful when debugging a specific version, such that the always know to what build and to what commit it was linked.

Special care should be taken to ensure that builds to not crash locally (without the Travis environment).

When closing the JavaFX client window, the process is still running. All threads needs to be closed. The thread created on new Thread(this::listen).start(); is not interrupted when window is closed.

FindBugs identified the following issue:

The line: https://github.com/Cardshifter/Cardshifter/blame/master/cardshifter-api/src/main/java/com/cardshifter/server/messages/MessageTypeIdResolver.java#L85 dereferences msg, but, the code here: https://github.com/Cardshifter/Cardshifter/blame/master/cardshifter-api/src/main/java/com/cardshifter/server/messages/MessageTypeIdResolver.java#L74 calls that method with a null value...

Thus, you have a guaranteed null-pointer dereference.

We want to have alpha version 0.1 as upcoming release, therefore I think we need to define the scope of it. I think the scope would be a working server and client, capable of playing a game.

We can use this to determine in what phase of the project we are, if work still needs to be done to get the game playable, then we will hold of the first release. If our scope is established and finished, then we could use some days to polish it some more.

The cardshifter-fx module depends on cardshifter-console, which is not allowed.
It is not allowed because the cardshifter-console is considered an end product which will be published as a fat JAR and thus should not be depended upon, instead cardshifter-fx should depend on the neccessary cardshifter libraries directly.

Client needs to be able to handle InviteRequest and InviteResponse.

Client A sends StartGameRequest with userId for Client B
Server sends InviteRequest to Client B, with the information that it is Client A who wants to play
Client B sends InviteResponse to the Server, with a boolean flag for if to accept or decline the invite.

The cardshifter-fx module needs some refactoring to reduce code duplication and improve flexibility. This mainly applies to the client that connects to the server as that client is more important, but the stand-alone GUI can be refactored as well.

One missing test is for the client/server connection to make sure the client and server can communicate properly.

The luajava table should be made inaccessible in the Lua code, as you can execute any Java code and this is a security issue.

Would it be possible to export a list of all current cards in Excel or CSV format? The purpose for this is so that I can work with Jay to start giving cards names and descriptions.

Each branch should have the option to opt-in for travis support, most likely via a small configuration file.
This should be by default enabled on the master branch.

There needs to be a hand limit of 7 - 10 (adjustable) for gameplay reasons

The main class is missing in the pom files, leading to an IDE suggesting the main class when running the project.
It does work correctly on the compiled versions, as the main class is actually set in the maven compiler plugin.

Make a command line argument, probably --random or --seed that can specify the random seed when creating a game. If left out, a random seed is generated.

A new version of Jackson has been released, we should consider upgrading to it.

Before you start a game, you should be able to for example choose/modify your deck, pick your opponent (when there are multiple AIs to choose from), and possibly some other settings (allowed cards, special features, etc.)

When having more than 8 creatures on the field, the battlefield size is not enough. Battlefield size should either be limited (just like hand size has max 10), or a scrollbar should be added.

As a temporary fix to make the JavaFX client playable, the Lua scripts has been copied to that Maven module. Another solution should preferably be used to solve that, there are at least two maven plugins available that may help in solving this issue. See http://blog.sonatype.com/2008/04/how-to-share-resources-across-projects-in-maven/#.VA3sFmN_SsY

The setup of a game needs to change slightly. It needs to be possible to create a game using a specific random seed. This is also related to #30 and #44

All methods of at least the core and the api should be documented via javadoc, to make them easy to use in other modules.

https://travis-ci.org/Cardshifter/Cardshifter/builds/37007190 and https://travis-ci.org/Cardshifter/Cardshifter/builds/37008087 failed because of some concurrency issues.

In the test it is possible for the AI to end turn at the same time as the human checks for what possible actions there are - which calls getCurrentPhase, which makes it possible for the LinkedList of upcomingPhases to be empty.

There are also some issues about wrong type of message received in the testUserOnlineOffline method

Currently the JavaFX application has two entry points. One for playing a local game and one for playing on the server. It would be better if there was only one. All that's really required is to add a button to the existing network launcher that starts a local game, with the FXMLGameController.

The current AI is quite stupid, a new and improved AI should be added, but possibility should still exist to play against the stupid AI.

Should be added in both the stand-alone client and on the server. I'm imagining that on the Server there should be a sort of 'lobby' where you can choose an AI to play against, manage your deck - see #30 - and chat/challenge specific other players (or simply get paired with a random player).

It would be nice to have a 'Lobby' when connecting to the server, where you can see all other players that are online right now and invite a specific player to play against.

For example if Bazola, Skiwi, Phrancis and I are all online at the same time, then Bazola can send invite to Skiwi (skiwi can accept or reject invite). If/when Skiwi accepts, they leave the lobby and enter the game view (as it is today).

Phrancis perhaps sends an invite to AI Medium, and they start a game together. (All AIs automatically accepts any invite).

Meanwhile, Zomis stays in the lobby awaiting for other players to connect, or perhaps also starts a game against AI Medium.

At the moment, I don't think there is a limit of time for a player to play his turn. It could be a good idea to add one. It could had a "difficulty" to the game, it would also prevent from players to "pause" a game indefinitely.

It could have a different value based on a type of a game (I'm not sure that concept exist yet) or if there is a single "campaign" based on the difficulty.

It could help prevent a situation that a game would be frozen by this issue : #32