2.1 KiB
| title | author | tags | description |
|---|---|---|---|
| Frustration levels rising | nek0 | english programming | Frustration with Haskell game development |
The software projects I do in my spare time often revolve around game development and usually the language of choice is Haskell. Doing things the Haskell way demands some frustration tolerance and patience but the outcome is usually a very robust piece of software. The outcome then usually outweighs the frustration on the way there and makes programming quite an enjoyable experience.
Unfortunately this does not apply to game development in Haskell. At least for me. After years of trying the closest I ever got to a game was Tracer, which I still wish to complete, but I doubt I will ever be successful. This is due to the fact that in the current state it performs badly because of poor technical choices on my side, which I am trying to rectify. To make better informed decisions I set the game aside and started experimenting with some new and some different concepts. This includes concepts like Functional Reactive Programming (FRP) as a new paradigm, but also better tooling, like proper shader programming.
Finding resources on FRP was quite easy. I was given a good itroductory book and found a capable Haskell library implementing this concept in reactive-banana.
Finding resources for shader programming in Haskell was not as successful. There are some interesting attempts at abstracting the GLSL shader language into Haskell, so one can profit from static type checking by the compiler, but these haven't been updated for at least two years and don't work anymore. All in all the whole GPU programming part of game development in Haskell looks very bleak. To get things done one has to resort to interfacing C libraries oneself, which is an error prone and tedious task.
For now I am really frustrated by this lack of an ecosystem and by the fact, that after three years of trying I only have rotting bits and pieces of software.