Hey there! We’re looking for an experienced Engineer to join our Wayward Tide team. 🙂

The role will suit a programmer who is looking to increase their skills in game development or functional programming.

Your main responsibility will be developing tools which will be used by our designers. You may also be involved in puzzle design, engine development in Haskell, or algorithm design for procedural generation. You are encouraged to contribute in other ways as your skills allow.

We are looking for someone who feels passionate about delivering software, and has a love of making (and playing!) games. A strong ability to work with others is imperative, as is an ability to communicate effectively.

Requirements:

– at least 3 years experience in software development and delivery

– knowledge of functional programming patterns

– expertise in one or more of the following: Haskell, Erlang, Scala, F#, functional JavaScript

– knowledge of graphic, audio, and video formats, and experience integrating these into applications

Please email your CV together with any code samples and or games you have made – we would love to see what you’ve been working on!

E-mail : business@chucklefish.org

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)!