Introduction

I have been putting off really diving into F# for a while. Lots of small toy programs and exploring the language in my head but there is nothing quiet like using a language to test your knowledge and understanding.

So I have decided it is time to start a new roguelike and see where is takes me. I like building roguelike engines for a few reasons

• Complexity: There can be a mountain of complexity hidden behind the sparse ASCII graphics.
• Simple graphics: I am no artist. I like code, data and its movement and transformation.
• Wide scope: There is no limit on setting, story or style.

I plan to set up a github repo for the code and run a developer blog that outlines the issues I hit, my solutions and how I solve them. Normally I start with the engine and layer the visuals on later but I will try to mix things up so you can see it in action.

If you want to follow on with the code you will need the following:

• Visual Studio 2017: Community edition is fine and also free. Install all the F# options.
• Open mind: If you are from an OO background you will need to leave that baggage behind you. F# is a functional first language and I will embrace that.
• Patience: This will be done in my spare time so there might be times where progress slows.

The next block of the article is a quick primer on some of the key issues doing this in a functional language brings. At the end is a competition/call for help.

Immutability

Functional Programming means immutable state throughout, everything from the game world to the render engine. If you are from an OO background that might be hard to imagine. The cost of building new state for every change might appear too high but immutability include certain optimizations with it.

• As it is not possible to change data it means you can pass it to other parts of your system without fear, no need to project it into transfer objects and the like.
• When building new state you can reuse anything you have not changed so you get huge data reuse.
• There is no need for any locking in a threaded environment, the data can't change so there is nothing to lock. There are also no race conditions.
• Functional languages normally have nice syntax for building new immutable state.

The downside is that you have to REALLY think about your data structure, the manipulations that will be performed and the changes that will be applied. This is a trade off between read performance vs update costs, you need to group the data to balance this out as you will see when I dive into starting the design.

Purity

Functional programming is about managing side effects, pushing them to the edges of you code so you get control over them.

It makes your core code more honest about what functions take in and return. Functions read what they are passed and for a given input will always return the same result. This means in reality any "pure" function could actually be replaced with a lookup table.

Side effects are easy to spot in a function. Just look for any of the following

• void input with many possible output values.
• void result
• read or write global state, this includes class member variables
• read or write IO, including logging.
• generate a random number! Think about this one a bit and look at the first point, it should click.

Ouch, that sounds bad.

It is not as bad as it sounds, if you have ever worked on a large product, 10s or 100s of thousands of lines in size, then you have no doubt had to trace bugs where something has changed something it shouldn't. This removes that type of problem, you can reuse and plug functions together knowing they do not depend on anything else. A great trade off in my eyes.

Call for help

I am looking for setting, basic story and name for this roguelike.

Please comment with all or any of these and also vote on ideas you like. I will pick the best setting, basic story and name and then split any SBD 4 ways. 1/4 myself, 1/4 for each person that supplies the related bit of the game backstory or name. Get all three and you get 3/4 :)

I look forward to your ideas

Woz