From UBC Wiki

Project Link


Myron, Nelson, Robert

What is the problem?

We want to play Connect 4.

We've decided we want to build it using SWI-Prolog, but we're unaware of how capable (or incapable) Prolog is as a programming language to implement this. We're aware that we must forgo our traditional programming paradigms to accomplish this (i.e. no OOP, procedural, or imperative programming styles).

What is the something extra?

We will create a basic AI for users to play against. Our AI will have multiple levels of difficulty (ie. easy, hard).

We will also have a fully functional text based user interface for displaying the game board and other relevant information.

What did we learn from doing this?


Much like our Project 1, we needed a few key features:

- user keyboard input

- console printout

Luckily, prolog includes these. Hence we're able to progress and create our game.


There are already quite a few past attempts at a Prolog Checkers game. This includes:

- a past Project2 attempt:

- another project attempt:

By further assessing these attempts, we realize that we can further build upon these attempts and offer more features. The past Project2 attempt only has one AI difficulty level and the version also doesn't support player vs player. We decided to draw from its AI implementation as a starting point.


Most programmers would say that it's probably easier to write code for this game in another language. They may have a point; traditional OOP, functional, procedural, and imperative paradigms seem to heavily differ from Prolog's programming paradigm.


Unit Testing in Prolog is also just as easy as it is in Haskell, mainly due to the submit-query-getresponse format of swi-prolog.

It was especially handy in Connect Four; we can test proper win/draw condition handling by directly submitting various game board states, as opposed to waiting and playing for the win conditions. For example, no waiting for 6x7 turns to test for a tie game, or waiting for the AI to win.


During the project we reinforced our knowledge with list manipulation, as we had to extract data from a list of columns, which in turn were a list of player pieces. Additionally, we learned more about the process of building larger programs in Prolog. For this project especially, it was very top-down and it was hard to work in parallel as everything was dependent on each other. We also learned that Prolog can mitigate type errors up until a certain point, where some of our functions were requiring the pieces themselves rather than the player team. This could be an issue with semantics and how we could have specified things, but Prolog does not completely avoid these issues on its own.

There are also prolog graphics and GUI frameworks available, such as XPCE. But for the limited resources we have for this project, we chose not to integrate it.


There is a vast plethora of tech combinations to support a more impressive Connect 4 game, including cloud hosting and accompanied frameworks, graphics resources, and more. However, the spot testing capabilities in both Prolog and Haskell do offer some merit in long-term maintainability.


Building Connect 4 in Prolog, operated on a sole machine, is still quite doable and we can still recreate the same Connect 4 experience on a laptop running Prolog. With other available technologies considered, and with more resources available, other tech combinations can be used to produce the same game experience at potentially a fraction of the effort or a far more enhanced experience.

On the other hand, programmers can further expand Connect 4 projects in Prolog if there are modern technologies compatible with it, such as cloud services supporting Prolog (to enable browser-based gaming) or graphics frameworks designed to work with Prolog (improved UI graphics overall).

Links to code etc