Wayward Tide : Technical Info

Game development is not some black art; there are tools, tutorials and libraries freely available for anyone to get started. So why have we decided to move away from that and write Wayward Tide in Haskell? Just how are we developing this game?

WARNING: this is about development, not about the game. Please adjust your expectations accordingly!

A Bit Of Detail

We’ve split the development of Wayward Tide into two streams; asset and game content is independent from engine development. This split is really helping to keep the game data-driven, a decision we made to make it easier to mod the game or procedurally generate content for it. Today we’re only talking about the engine (known internally as Cove).

We’re building it on top of SDL2, which is a highly portable and stable library. It’s this portability that let’s us say we will definitely be supporting Windows and Mac. There’s a good chance we’ll support Linux too, but we can’t promise that yet.

Palf's desk

Think I can get a third on there?

The application code is written in Haskell, using the low-level bindings to SDL. The code itself is heavily influenced by Helm – we realised that Helm’s focus on 2D rendering wasn’t going to work for us long term, so we started from scratch using a similar design philosophy.

We’re using Elerea to provide an FRP interface to the SDL event stream. This allows us to composite logic as a series of transformations of a stream, removing a lot of the boilerplate code usually required to handle input and output. A mature example of using FRP for games is Elm, which inspires both Helm and Cove.

It’s difficult switching to a language that doesn’t have as rich a history in the gaming domain, but it’s less of a risk, more of a trade-off. Haskell allows you to express program flow declaratively, which is an accelerant to development; I’ve already been surprised when code has just clicked together. If there’s a killer feature in some other language that we need, there’s always the foreign function interface to drop back on.

Working Practices

The development process is quite flexible. I’m an old-school evangelist of behaviour-driven development, so all specified game behaviour is covered by some level of automated testing. I do cut corners and will skip automating tests if I think the code in question is trivial, which will undoubtedly come back to bite me in a few months time.

We’re using Trello as our task management system. A task goes through the usual planning stage, but we don’t bother with estimation – there’s no pressure to deliver features by a deadline; instead we’ve adopted a “when it’s ready” approach (thanks, Blizzard!). It’s also likely that estimates made now would quickly become worthless – the team roster is not finalised, the developers (well, me) are still learning the ropes – but this is something we may revisit.

To keep us honest, we also do internal weekly demos to the entire company. It doesn’t matter if we’ve managed to take three steps back (this has happened) and the the game won’t even run – we demo anyway. Sometimes you have to own your failure! We plan to film these demos and release them as part of our monthly update, and if interest is high enough we’ll go to a weekly schedule.

These demos are not marketing material – they provide insight to the development process and solicit feedback that goes into the next week’s iteration. This is why we think it’s important to open these demos to a wider audience – after all, it’s your input we’re interested in. We’re going to take a few trial runs at filming; as soon as the video looks good we’ll start sharing them.

Open Source

When you buy Wayward Tide, you’re buying into the content, modding tooling and ecosystem. Much of what makes the game unique will be in the game package, not the engine. Our puzzle design, for example, is considered to be ‘content’. The ability to have puzzles in-game is a result of engine features (like collision and criterion satisfaction detection), so aspiring game devs can make their own puzzle games with it.

Being open source, the Cove engine will hopefully support Haskell game development, which in turn will cause a greater investment in Haskell from the gamedev community. If you’re looking to contribute, keep an eye on the blog – we’ll announce when Cove is available on here and Twitter. You can also find me on GitHub pretty easily.

Any further questions? Leave a comment or follow up on Twitter (@waywardtide)!

13 comments

  1. Haskell, that’s interesting. Would be great to have another blog post when it’s all done with thoughts and observations.

    Also, c’mon, support Linux, you know you want to. 😉

  2. Enjoyed the update. Curious about your Trello boards and tasks. We are using it for a software project as well and I can’t decide if I like how we are building our Cards and Boards.

    Would you be open to sharing an example or write a short blog entry on how you plan a task?

    1. If and when we expand the team, we’ll have to adapt the process to match working practices of the new team. That transition might be a good topic for a blog post, thanks for the inspiration!

  3. As a long time Haskeller who has toyed with game programming in it, I’m quite interested to see what happens with your project. I look forward to the influence that a commercial game will have on the library ecosystem. I think you’ll have some frustrations and be faced with far more low-level programming than you may be used to (to establish support libraries and make API bindings), but you’ll walk away from this project with tools/libraries that allow everyone to more easily make games in Haskell.

    Carry on! 🙂

  4. This is incredible news! Just a few weeks ago, I started the /r/haskellgamedev subreddit — not because I’m any sort of qualified, but because its absence had started feeling notable. Even so, I haven’t yet abandoned Unity for my own projects. But I can’t wait to get my hands on Cove!

      1. Okay, I can’t resist a few prying questions, feel free to ignore any or all…

        While there’s probably a limit to how “noob-friendly” a Haskell tool can be, it’s still a nice goal. Haskell on Windows tends to be extra nasty when it comes to library dependencies. SDL isn’t the worst offender, but still not exactly plug-and-play. Will there be other dependencies?

        Coming at the same topic from a different angle, are you planning to create a self-contained distribution, or will Cove be dressed up as just another Cabal package?

        Most prying of all: do you have a ballpark order of magnitude for public access — days, weeks, months? I’m debating whether to start something else, or wait for this. 🙂

  5. Great! I have just started working on a Haskell game. I’d love to start hacking on Cove when I can (why reinvent the wheel?). Helm’s dependencies on cairo meant it wouldn’t install on OSX for me. I tried to use Elm, but Javascript just wasn’t cutting it (I need 60fps!)

    What do you use to edit code? I have been looking for something with good autocomplete and hackage documentation built in. Emacs seems the best at the moment.

    Why use Elerea over Netwire or one of the other reactive programming libraries?

    1. Open-sourcing Cove is my number one priority right now, but in the meantime maybe the Cairo-free version of Helm can tide you over (sdl_render branch on GitHub).

      I haven’t found an amazing Haskell editor yet, so I stick with Vim and Sublime Text. Leksah is pretty cool though.

      Elerea is something we inherited from Helm; I’m ensuring that library access in code is gated, so if we need to switch libraries later it will hopefully be in a limited scope.

  6. Hi, what are you using to make haskell available on android? just plain jhc or did you make your own?

    is there any suggestion for one who want to start develop haskell game apps or normal apps on android?

Leave a Reply