DEV Community: Dominik Ágh

Chess Engine Journey Ch. 0: Let's build a Chess AI!

Dominik Ágh — Sun, 26 Sep 2021 20:43:16 +0000

So at the end of last year, I started getting more interested in chess.

I began playing online, studying puzzles, watching videos, and generally getting engaged in the chess space. Because of this, my recommendations on YouTube started to feature quite a lot of chess related content. That’s how I stumbled upon a video by Sebastian Lague, in which he tries to make a “Chess AI” to play against.

I thought that it looked like a fun thing to try, and since I was looking for a coding side-project for a while now, I decided to give it a shot. And while I was at it, I also decided to document my journey!

Surveying the Landscape

Right, so we want to build a chess engine. But how does one actually go about doing it?

I began by searching for resources that already exist on the topic of chess programs. Early on, I found the Chess Programming Wiki which proved to be a great source of information, as it covered all the important principal topics, a lot of the different ways of optimizing Chess algorithms, as well as provided a great Getting Started jump-off point for anyone hoping to dive into chess programming. It also has a very extensive Recommended Reading section, which saved me a lot of time during this phase.

Chess Program vs. Chess Engine

The first practical hurdle I faced was when deciding how to go about actually implementing the program itself. My first naive approach was that I had to obviously make the whole thing from scratch as a standalone program. I contemplated what game engine or framework would be best, but I was a bit unsatisfied since none of the better maintained frameworks and engines supported any of the languages close to my heart, like Go, or at least Python.

Wanting to develop in my preferred language of choice, I came to the idea of decoupling the graphical interface and the engine which would be calculating the best moves, essentially splitting the single program into frontend and backend. I would write the interface in something like Unity (I still might do that in the future as a separate project) and the engine in Go.

Luckily (and probably obviously) I wasn’t the first person to come up with this idea.

Protocols & Interfaces

So turns out, people (as is more often than not the case) have already dealt with a similar issue and found a solution. There are already numerous options when it comes to Chess programs (or GUIs for our purposes) which support custom chess engines. (A nice list can be found on the wiki) They do so by utilizing a couple of standardized protocols to communicate with the engine code.

The two most commonly used protocols I found were Chess Engine Communication Protocol (CECP), often simply dubbed xboard after the program which introduced it, and the Universal Chess Interface (UCI).

Conclusion

After some time pondering this topic, I finally decided to only implement a chess engine for now, as opposed to a complete chess program (Which gives me the opportunity for a second project in the future maybe…), as it will likely be faster and will allow me to further my coding skills with my language of choice, Go.

I also decided to go with UCI as the communication protocol for this project, as it seemed like the more straight-forward to implement (smaller number of individual commands, using stdin and stdout as its communication channels), as well as the better supported by a wider number of graphical interfaces (CECP slightly lacking in this regard).

Next Steps

So, after getting all of this “boring” pre-production out of the way, I feel confident getting to work on this project. By the time I will write up another chapter in this series, I would like to have the following done:

Think of a name for the engine
Setup a repository for the project
Prepare (at least stub) handlers for all the UCI commands
Implement the Board Representation part of the chess engine

Seems like I have my work cut out for me, and I can’t wait to roll up my sleeves and getting my hands dirty by actually starting to implement this project. Hopefully I’ll have something worth sharing again soon.

In the meantime, thank you for reading the first part in this series! I hope that you enjoyed it, or that it at least gave you a brief look into the problem space of chess programs and provided you with enough information and further reading to be able to start a similar project of your own!

Until the next chapter, thank you again for your time and take care!

Dealing with Burnout, or How I found motivation once again.

Dominik Ágh — Thu, 08 Oct 2020 18:00:00 +0000

(this turned out a bit long - TL;DR at the end.)

During these last few months (Summer/Fall 2020), I found myself in an emotional, (and motivational) slump.
Considering the state the world is in, it probably comes as no surprise, but combined with a few developments at work,
it resulted in me having next to no drive to solve issues and feeling more and more depressed about the whole situation.

In this post I'd like to go through to the things which helped me get out of said slump, got me into a better mind-set
about the whole thing and enjoying coding again. Hopefully, if you find yourself in a similar situation, you'll be able to
find something in here to help you, or at least avoid the same pitfalls I've fallen into.

You are NOT alone

With the whole COVID-19 and lock-down, we, as I suspect many others, have transitioned to working exclusively from home.
This had one rather unpleasant side-effect, which only became apparent to me after a few months. Even though I didn't really
miss human contact, as many people, getting to communicate with teammates almost exclusively via Zoom meetings regarding projects
and daily syncs meant loosing the casual office banter and the option to just turn to your colleague and talk through a problem
or ask for help. This led to me feeling isolated and as if I had to deal with every problem on my own.

Luckily, it turned out that I was not the only one in our company feeling that way. A couple of colleagues have felt the same way,
and have started a few initiatives to help with these problems. We started weekly sessions, where we talk about things we are unhappy
about, or which we'd like to change, and discuss ways we could make them better. We also started a few Slack channels where people can
talk about their issues and get feedback and help from other, as well as one where we share cool or interesting articles regarding
Software Development.

This is a long way of saying that even though we might feel isolated, or that we have to deal with our problems alone, that's rarely
the case. Even if you don't work for a company, or don't have any immediate friends interested in Software Development, there are some
amazing developer communities out there, including (but not limited to) dev.to, StackOverflow, HackerNews
and countless of other groups, forums, and sub-reddits where you can ask for help or feedback and where other people share their cool
projects, talk about development or share their programming experience. Hell, if you have somehow stumbled upon this article, I think
you already are in the right place.

Don't try to change the whole world

Another issue keeping me down I ran into, both with the global situation and the situation at work, was the fact that I saw too many
things which desperately needed addressing, and problems which seemed couldn't be fixed by any other way than by starting from scratch with
a completely new solution, which we couldn't afford. (Which is a completely valid reason not to do something. The company has a limited
amount of resources and must use them in the most efficient way possible.)

It's easy (for me at least) to see a challenge or an obstacle from birdseye view, see all the things which would need to change, all the ways
it can fail, get overwhelmed by this feeling, and believe the problem to be unsolvable. The same could probably also be said for the state the
world is currently in. But as a wise man once said "Rome wasn't built in a day". We shouldn't expect it from ourselves to rework the whole app
or feature, redesign the entire process, or change everything about ourselves in one Big Bang change. Sooner or later you'd probably hit a
brick wall, get swamped by all the possible issues, lose your motivation, and quit.

Here it's probably best to borrow a bit from the Stoic philosophy - don't get discouraged by the things which are out of your control, accept
them for what they are, and move on. Focus, instead, on the things which you CAN change or influence. You most likely won't be able to rewrite
the entire service from scratch, but there most likely is that one small issue, that has been driving you nuts for couple of weeks or months
already. So go and fix it! Find these low-hanging fruits, these small victories, these incremental improvements.

This is very much in line wit the japanese concept of Kaizen - the process of continuous improvement via small changes (something I will likely
write about more in the future.) The point I'm trying to get at is that you should try and improve - wether it's the software you are working on,
your management processes in your, or yourself - little by little and not all at once. Start with small, but steady steps and you'll be surprised
how quickly they will accumulate and you will hopefully start feeling the impact they're having.

People are making amazing things!

I have already touched on this briefly in the first section, but one of the few things that really helped me get my
motivation levels up, was to get back into reading articles, blog posts and watching videos about cool projects or tools people were building or
ingenious solutions to some irritating problem they came up with. This reminded me how amazing and fun software development can be!

Here's just a few posts that caught my eye and which might be a good starting point for you as well:

Building a simple Chat application with Websockets in Go and Vue.js by Jeroen de Kok
How to estimate your work like you know what you are doing by Vitor Paladini
Stop Over-Engineering by Greg Young (video)

Rediscovering the Joy of Coding

Feeling once again motivated by all these incredible articles, I decided to start my first personal project in months! And it did wonders for me!
I realise that this is most likely a more personal thing, but since at work I was stuck mostly just fixing bugs and making small tweaks to existing
functionality, the blank slate that a new Git repository offered was a much needed breath of fresh air for me. Dusting off the basics I haven't used
in ages by building the foundation for the project, but also utilizing the experience I've gathered while maintaining a rather large piece of software
at work.

After a very long time, I've felt empowered, and much better prepared than the first time I've started developing something. It helped me realise how much
I've grown since then, but also brought with itself the nostalgia of the struggle of getting my first ever project to work. I remembered how magical the
feeling of making a small script which automated something was, and it reminded me why I wanted to pursue this career in the first place, how much I actually
enjoy coding.

Writing about it

Last, but certainly not least, the process of writing this article has helped me greatly. It allowed me to properly formulate the emotions I was feeling,
come to terms with them, and put them behind me, for the time being. It also forced me to dwell on each aspect of the problem I was dealing with and properly
analyze it, so that I could write about my solution to said problem.

And here I would, once again, like to repeat that by no means is this article meant to be a "silver bullet" to dealing with burnout. To be honest, I'm not
convinced such a thing could ever exist, as burnout is often caused by very personal reasons and might be brought about by completely opposite reasons
for two different people. Everyone's life experience is unique and regarding emotional and psychological issues there rarely is a one-size-fits-all solution.

In Summary - TL;DR

To summarize (and offer a TL;DR for those who saw a wall of text and got scared), I'll briefly go over the things which helped me deal with burnout:

Even if you feel like you are all alone and that no one can help you with your problems, this is rarely the case. If you reach out to your colleagues, or engage with online developer communities (like dev.to or StackOverflow), you will most likely find someone willing to help you out.
Don't try and solve all the issues at once. If you are under a lot of pressure at work, this might be hard, but try and divide your work into manageable portions and tackle them one at a time. Strive for small, but continuous improvements.
Read articles and posts by people who make awesome stuff, or struggle with similar issues as you to see, how they approached them! Get inspired to try things out, learn new skills or just distract yourself from the daily routine.
If your time allows, find a small personal project to work on in your spare time. For me, this was a pet coding project which reminded me why I enjoy coding, but it can be anything for you. The main point is to find something which you will enjoy and which will pull you out of the worries you might be facing throughout the day.
Putting things on paper (or at least into a written form). This allowed me to verbalize what I was dealing with, get a clearer picture of the reasons for it, which in turn helped me find solutions for those specific reasons.

Well, this turned out longer than I initially expected, but this being my first article, it's probably no surprise, as I've yet to develop an eye for these
things. Hopefully you found something this article which might be helpful to you, or at the very least found it a bit interesting. In the future, I'll probably try and keep things shorter, and more to the point.

If you've read this far, first of all thank you, but I'd also like to hear from you! As I mentioned, I'm just starting out, so any feedback is welcome!