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

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)

スクリーンショット 2018-12-10 16.17.29.png

[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

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.

Recommended Posts

The story of making a communication type Othello game using Scala.
The story of making ordinary Othello in Java
The story of making a game launcher with automatic loading function [Java]
The story of making a reverse proxy with ProxyServlet
How to operate IGV using socket communication, and the story of making a Ruby Gem using that method
The story of making Dr. Oakid using LINE BOT
The story of making the existing Dockerfile GPU compatible
The story of introducing Ajax communication to ruby
A story about making a Builder that inherits the Builder
[Jackson] A story about converting the return value of BigDecimal type with a custom serializer.
The story of making dto, dao-like with java, sqlite
A story about making catkin_make of rosjava compatible offline
[Ruby] Get in the habit of using the dup method when making a copy of a string variable
Story of making a task management application with swing, java
A story packed with the basics of Spring Boot (solved)
The story of pushing Java to Heroku using the BitBucket pipeline
[Apache Tomcat] The story of using Apache OpenWebBeans to enable CDI
The story of making a binding for libui, a GUI library for Ruby that is easy to install
The basics of the process of making a call with an Android app
The story of the first Rails app refactored with a self-made helper
A story about hitting the League Of Legends API with JAVA
A story about making a calculator to calculate the shell mound rate
A story that struggled with the introduction of Web Apple Pay
A story that confirmed the profile of Yasuko Sawaguchi 36 years ago
[Java version] The story of serialization
The story of @ViewScoped consuming memory
A memorandum of the FizzBuzz problem
Write a null case using the Optional type without using an if statement
A story I was addicted to when testing the API using MockMVC
[Java] How to get to the front of a specific string using the String class