Introduction

It's been about a month since I learned Scala by myself, so I made an Othello game using socket communication as a practice. Below is a summary of what I learned. The implementation period is about 2 weeks. (Excluding learning of Scala alone)

[Source code] https://github.com/yuto226/Oselo

What is Scala Scala is recognized as a relative of Java. What you can do with Scala can basically be done with Java.

What I felt most different from Java was that it had a small amount of code, and it was possible to do functional programming instead of rugged object-oriented programming.

The function called trait seems to be useful, but I couldn't use it for capacity over this time, so I would like to improve it in the future.

environment

Mac OS X Sierra 10.12.6 InteliJ IDEA Scala 2.12.7 jdk-9

I will omit the story of environment construction.

What i made

Recently, I was lazy in technology, so I thought I would make a game with the meaning of moving my hands anyway, so I made Othello. By the way, socket communication is also implemented as a review of network processing. I used Scala because there was a high possibility that I would use Java for work in the future, so when I was looking for something similar, I found something close to it, so I started with interest. Since I did it with such motivation, I think that I have not reached the implementation that makes full use of the goodness of Scala. (I was aiming to move anyway) However, Scala itself was quite used and it was easy to write and interesting, so I think I will study hard in the future.

Simple design (flow)

Since it is socket communication, it is a client server format. The server side is in charge of Othello's black, and the client connects and it is white. Through the socket, we will exchange the coordinates of where the piece was placed with a message and proceed with the game. At the design stage, I thought that the GUI drawing process would be troublesome, but it was troublesome later (laughs).

Implementation

Since it's been a while since I've been programming socket communication, the first barrier was to connect sockets and exchange messages. Furthermore, since this is a game, screen drawing processing for the GUI will be included. When running a program with one thread, the limit is inevitably reached, so I introduced multithreading. In the sub thread, the message reception is made to wait in an infinite loop, and the victory judgment and screen drawing are done in this thread. Multithreading is essential when waiting indefinitely for I / O processing that you do not know when it will come. (At first, I made this thread wait indefinitely, but of course the process stopped working at all.)

 override def run(): Unit ={
     createServer
     receiveMsg
   }

The receiveMsg function is infinitely waiting. The createServer function initializes BufferedReader etc. by default. Inherit Java Thread class and call it from this thread with start method. Basically, if you let the client and the server wait in the same way, and alternate order control, victory judgment, message transmission, etc., it will be a game.

The screen drawing itself was done with scalafx (javafx), but scalafx allows you to design a GUI with a GUI using a tool called Scene Builder. (Like making an iPhone app screen with X Code)

There is no such thing in swing, and it seems that the implementation will be a mixture of UI code and data processing code, so I think it is an advantage of scalafx (javafx).

Blocking / non-blocking

Ultimately, if you make it multi-threaded during implementation, you can solve message reception and screen drawing! I found out, but while I was wandering around, the word blocking / non-blocking came up and I was quite at a loss. (I remember hearing the words in a university lecture)

In conclusion, the idea of blocking / non-blocking is to use non-blocking when there is a risk of multiple clients accessing the server. ... apparently ... (Please tell me if it is different ...) From the viewpoint of computer resources, it is obvious that if thread processes are assigned to multiple clients, they will be exhausted, so put in a process to "monitor" and connect if it is a new connection. It seems that it is ideal to implement it by processing when a message flies. I think I'll study again when I'm calm around here.

Learning and summarizing

It is summarized in the following bullet points. -Use multithreading for infinite waiting I / O processing. -In multi-thread, be careful when performing screen drawing processing in sub-thread. -For one-to-one communication like this time, blocking processing is okay. When multiple clients come, insert a non-blocking monitoring process. ・ Othello's reversal algorithm is very difficult. (Over 500 lines of code for this class.) ・ I wish I could use more Scala.

I will leave the code for drawing the screen with multithreading because it seems to be confusing. It was solved by passing the target function to Platform # runLater.

Platform.runLater(() -> hogehoge())

I wanted to study Scala in the future, so if you read the code, this is the place to go! If you can comment on that, it will be a source of study. Thanking you in advance.

The story of making a communication type Othello game using Scala.