Hello everyone. I'm working on a fairly large project in Java creating an online Chess game (similiar to, say, Chess.com) where mulitple people can connect and challenge others or play against an AI.

I'm creating this thread in the hopes of being able to continuously ask this wonderful community for advice on the best go about something (if I can't clearly find the answer myself) and to post what I'm doing in the hopes that someone will read it and inform me of a better way, so that I can walk away with the most from this project. So please, please post any thoughts, opinions, and especially criticizisms on anything you find in here, thanks!


What I'm planning so far: So far I'm planning on creating a multithreaded Server using sockets (since they're so simple in Java). The Server will constantly listen for incoming clients, pull up their stats and information, then stick them in a connected queue where they can view and challenge the other players. In which, the server will intialize a match between the players by creating a match thread and telling the clients' GUIs to update themselves.

Both the Server match thread and the clients will inherit from an abstract class Chess Engine which will verify for move validity and check for check(mate)s. Doing validity checks on both server and client side seemed like a standard practice thing so that's what I'm going to do; the client checks will try to alleviate server works by checking the moves until they picked a valid one and the server checks will ensure no one can cheat by hacking the client engine. The match will go on until checkmate, stalemate, or surrender.

The client will hold the GUI which is going to be created using JavaFX. It's going to allow for the user to choose personal settings for various things such as show possible moves, etc. The settings along with the user info, match info, ELO ratings etc, will either be stored in a DB, in files on the hosting computer, or in a combination of the two (I haven't figured out which is best yet, but I'm leaning towards files).

The AI will definitely be implemented using an existing API. The chess engine may also, but I haven't decided yet. I'm sure there are many chess APIs that include both, but I want to get the most learning out of this as possible and, having never used an API before, dont know how much it'll take away form the experience.


That's everything so far, I hope you will all check back often to give me your opinions and help answer my questions and I didn't scare any of you away with this large wall of text!

This post was edited by SanityWasHacked on Apr 6 2014 10:06am

One question right off the bat, since I have almost no experience using threads: Do you guys think the server should have separate threads for the part that's listening for clients logging on and the part that's listening for clients to initialize a match, or should it be done by the same thread since I don't expect any high traffic on this?

Thank you

This post was edited by SanityWasHacked on Apr 6 2014 10:06am

question. is this just a project for your own learning experience, or do you actually plan on people using it?

I can't tell. is this going to be in a browser (eg: chess.com) or a separate client (eg: FICS)?


what exactly do you think you're doing here? show me a code snippet please. i think you're confusing yourself. are you trying to get multiple threads to listen to the same port?



you realize databases are just stored files with a convenience engine, right? you seem to think DB == releational DB, which is not so. you have no-sql DBs also, eg MongoDB


You've never used an import statement in java?

This post was edited by carteblanche on Apr 6 2014 10:15am

For my own learning experience, and something to put on the resume (I need to get out there and get some real world experience)



No browser, it'll have it's own client.



There's a very good chance I'm confusing myself; I have very little experience using sockets/ports and even less experience using threads. I have no code yet, I'm working on the class/state/sequence diagrams first (which is supposed to be beneficial).
But basically you're saying that each thread will need it's own port right? So does that mean that every simultaneous match is going to need access to it's own port?



Good point, I was only considering storing the info in an online DB with SQL as a means to learn DB communication in Java since I've written to files plenty. But it seems very unnecessary and I'm already learning plenty of other things through this.



Also good point, lol.


Thank you very much for taking the time to clear up some of the areas I wasn't clear on or wasn't experienced/educated enough to understand. This is exactly why I made this thread.

This post was edited by SanityWasHacked on Apr 6 2014 10:37am

imo you're too ambitious and inexperienced for a large project. a few general things to consider:
1) make sure you use interfaces/factories to keep everything abstract.
eg: on your client, have a factory that generates a class that communicates with the server.
eg: CommunicatorFactory which can create TCP, REST, etc. and each ICommunicator would have its own implementation to requestToJoinGame, etc.
GameFactory which returns different available games (chess, checkers, tic-tac-toe).
DataFactory which returns different means of storing data (MySQL, plain text files, Mongo, etc)

2) after you do #1, it's very easy to drop the chess and use another game. say, tic tac toe. generically speaking, these games have common features you'll need to take care of. eg: sendMove, updateClient, isValidMove, determineWinner, resign, updatePlayerStats, etc. now you can build all your networking/db/etc stuff and not worry about chess. first get everything working with tic-tac-toe before making changes to use chess. each of these games should be in a separate jar, used via the factory. eg: TicTacToe.jar, Chess.jar, etc. this is to ensure you don't "cheat" yourself by sticking code in the wrong place. it should be abstract.

3) plan everything in phases.
sample schedule:
phase 1: focus entirely on the server. build the API to allow new users to register and old users to login and match up with others.
phase 2: create a client (command line or GUI) which interacts with the server. launch multiple clients on your computer and make sure they can all match up correctly.
phase 3: implement your game via strings. each client sends their move as a coordinate. server validates and returns something to both users.
phase 4: build a GUI on top of your game which converts the front-end to the strings to send to the server, then accepts the response and does something on the front end.
phase 5: add new features on top of what you have

break everything down into phases, and write down your requirements for each phase, then estimate how long you think it'll take. at the end of every phase, you should have something tangible that can be shown/used. as opposed to working on everything a little bit and it's broken until the day it's finished.

after everything is working with tic-tac-toe, you can try something more complex. maybe checkers before chess.

This post was edited by carteblanche on Apr 6 2014 11:39am

This is amazing, thank you. I'm going to do some research, get started with this, and I'll post my plan / results in (hopefully) a day or two (since I also have school work that needs to be done).

im good lets play

This OP makes me sad.

Let's start at the beginning.

1. Clients and servers need to communicate, this isn't usually done via "threads" it's done via connections (how you handle them can go any of about 10-15 ways). What is the server "Actually" doing in this case though? I would assume that the server doesn't actually need to "do" much of anything. The server could be involved and record every move, and validate it, and serve it to each client... or you could simply use the server as a matchmaking service that keeps track of all moves made (sent at the end of the game as chess notation), Winner / Loser / "ELO" ratings, etc. Why pummel a server with tons and TONS of concurrent connections? Your client should act as peer to peer and be instructed by your server, or else your infrastructure is going to be bloated as fuck and require WAY too much engineering (to load balance, instance, etc.)
2. You've mentioned using a "DB" but don't seem to know up or down about what a DB is / does. The easiest way to get started with databases is probably going to be something like MySql. You can download MySql community server with MySql WorkBench and be up and running in about 10-15 minutes. Get that running on Localhost and start passing in queries via JDBC. The easiest way to think of a Database is to think about an excel spreadsheet with table headers. It's just columns and rows of data. Put a LOT of thought into what each column and row will be before you make it. What else might you want to add down the line? What things might get in the way? How will your tables join? How can you link them together? Any SQL table is a HUGE trouble to maintain and as you get better at programming, they only grow in both size and complexity.
3. There's a lot more to chess than what you're talking about initially. As others have said, definitely start with an easier game. Chess is extremely complex, and will be one of the harder board games to implement.

If you ever find yourself lost or in need of help, Let me know and I'll do my best.