Haskell meets Entity Systems – Part 1: Introduction

I was given an assignment – to wrote small project of my choice using functional programming. Having known only OCaml and Haskell from those languages and one programming interest since I was 10 – games, it was not hard to decide. Tetris written in Haskell (compare its syntax to OCaml’s if you are willing to know why). Of course, writing such a simple game in C without any thought on design is no challenge at all, but it’s also no fun at all. To make it more interesting (and after reading this fantastic articles series) I decided to try Entity Systems approach to designing game engines.

At first I was planning to use “Crash test” phrase in the title, but I couldn’t make anything short and interesting with it, so it is as it is. But why “Crash test” you may ask? Well, besides two unfinished attempts at using ES (Entity Systems) in my games, I haven’t done anything with it. I also haven’t found any mention about using functional programming for it. Moreover, apart from course at my university where we were learning theory and doing some impractical exercises, I have never seen (or done) any serious application’s code written in Haskell. If that’s not enough, I almost completely erased functional programming from my memory, stuffed my brain with Java/C++ and learned to think without any effort in terms of OOP. So there are many possible causes of my  failure, or to be more optimistic, questions to which I’m going to find answers:

  1. Is Haskell for me?
  2. Can I stop thinking in terms of objects and classes?
  3. Are ES a perfect solution for game design problems?
  4. Can functional programming be combined with ES and give satisfactory results?

For readers not familiar with functional programming, it’s a paradigm where function is the main building block of a program. In OOP we make objects, that composed together form an application. Here, objects don’t even exist! What we have is data, and functions that manipulate it. And manipulate it in a pure sense – take arguments, return results, no side effects! Of course I’m generalizing, and Wikipedia is much better source of information than I am, but…

What is ES? It’s a big bag of components that carry data and have no methods, and systems that manipulate that data. Entity is an ID representing game thing to which components are associated. By combining different components we can create different kinds of objects, that behave differently. For more, read Adam’s blog mentioned in the opening paragraph.

Let’s go back to that unfinished “but…”. I’m sure you noticed the pattern and so did I. What’s more, one way to correctly design ES is to forget totally about OOP.  Why not make it easier – choose language that prohibits OOP (because it expresses another programming paradigm), and that let’s us easily define systems (functions) and components (data). That’s my theory. How will it work, we’ll see.


I’m not experienced functional programmer. I am learning it the same time I’m writing these articles. The same goes with Entity Systems. If you have any objections to what I said, any thoughts, that could expand my post, any errors spotted in my code, bad design, etc, I will appreciate any feedback. I want to know more after I finish this series than I know now and I want to be a better programmer (I also want to know English better). So don’t hesitate and show me in some constructive way how badly I suck at what I’m writing about. Then I will run to my mum crying and she will deal with you.


One thought on “Haskell meets Entity Systems – Part 1: Introduction

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s