Posts

Showing posts from January, 2017

Some older versions

Old Versions Of JCERB Here, I am posting some older versions of the engine, which might be a little version than the latest. I am trying the JCERB 7.1 after a long time, and in a couple of situations , I have found that it is playing badly.There is probably some bugs, in the evaluation or in the minmax code, so I am going to post some earlier versions here (yes, I saved the progress step by step, so I have got about 9 or 10 versions). Here is the  JCERB v7.0  , which is a bit error free, although it does not checkmate the opponent sometimes.If there are two forced mates , it does not choose the shorter one, but the one which it evaluated earlier. I will be updating this blog again later.

A basic Ping Pong

Writing in QB64 This post will not be about how to write a really good ping pong, but how I wrote it. Mine was about a mediocre strategy considering that I wrote the whole game in pen and paper without ones trying it on the computer. I would prefer using QB64 as the language for writing the first game,  as since the game will most probably be simple, QB64 is very easy to learn and code in. This was my first program of more than say 50 lines, so the code is messy and bad and I don't expect anyone to read and understand anything, I myself can't sometimes. So this will only be helpful to those who want to write some kind of game, but don't know much about programming. Overall Plan So  first let's forget about the language specifics ...  what is the most basic way of writing a ping pong. Well, the first thing that comes to mind is that the ball will be , well, a circle, with a certain radius. Secondly,  the two players will be just rectangles on wh

A playable UI

Finally The UI And Game Class The UIBoard  class is too long for me to explain, but the gist is that the UI and the Game class are entirely separated, except for a few methods, and the UI class controls the  Game  class.The methods in the UI class are pretty self-explanatory, but here are the few main points on the mechanics: a)  The pieces are shown on CustomJLabels so that they can be highlighted and the previous color and the normal color can be stored. b) For actual creation of UI, the JPanels are arranged in a GridBagLayout. c) Well...  nothing more is there. The Game class is also very small with the primary objective of acting as an interface between the UI and the AI.Only two important methods are there,  compMove()  and playerMove(), both of which returns a string pertaining to the move made.That's it. The methods other than that are mostly used for debugging , except the nextPos(), removePrevPos()  and the  numRepeats()  method which are used for

What is the board saying

Evaluating the Board The evaluation of a position is rather simple. Here , a positive value means that the computer is ahead else the player. All values are calculated in centipawns, that is 100 points is equivalent to more-or-less one pawn. First, there is a Material  class which checks the relative piece values. Secondly, there is a PiecePosVal  class, which gives each piece a certain amount of points based on its location in the board. Thirdly, there is a checking for doubled pawns, isolated pawns and passed pawns, where certain bonus points are either given or taken according to the pawn structure.This is but a rough approximation. Also , there these valueBoard class considers whether it is an  endgame  position, which is set by the Material  class. There is also a  Options  class which awards points for mobility. Although, the evaluation could have been simpler with more time for searching deeper, or could have been better, I think that this balance i