2. And so you are using .NET for the game? Yes, it’s quite a popular platform at the moment; there is Unity3D that uses mono, we use an engine quite similar to it called Duality and it’s on .Net.



Werner: Your talk here was about F#, so you don’t use C#, you use F#.



Well actually we use both, the engine is in C#, we found a lot of productivity in games by using F# in certain areas of the game. When we started using it about, maybe a year ago, maybe a little bit less and we slowly began finding spots where it’s very effective.

3. You discovered functional programming I guess a year ago, and so what were the biggest gains that you got from adopting F#, is it less code, is it more stable code? Well it’s both of those. F# it’s a very concise language when you compare it with C#, like type definitions, pattern matching, just really helps when it comes to writing code and writing less code. You can also get the advantage of less bugs because it’s a smarter compiler and it really comes across.

4. When you say smarter compiler, how is it smarter? Well it just highlights the bad stuff in your code a little bit better; if there are errors in your logic, it picks it up quicker. So it's a stronger typed language than C#. When you start learning you are wondering “Why did this error happen?”, but very soon you get used to the fact that you have that help and that means you can focus on what you are trying to solve rather than “I forgot to check all these things that are probably wrong”, so that’s very nice.

5. You’ve mentioned pattern matching, is it not just fancy ifs? Well not really, but yes, yes but no, it’s one of those horrible yes-no questions. It is because you could decompile that pattern matching code and it will look probably like an if, but at the same time you are able to, because you are matching expressions, you can do a lot of very, very smart things with it, and you can then move on not only to just expressions, you can do Active Patterns as well and that allows you to separate what you are trying to decide from what you are actually doing with it, so it’s very, very helpful.

6. What are Active Patterns? Active Patterns are a way, well actually it’s exactly what I’ve just said, it’s like it allows you to give a name to some sort of logic condition that you have and then use that in a pattern match and in an expression of pattern match. And there is probably better definition out there but that’s what I’m using them for.

7. You said you use both C# and F#, where do you use F# more, is it more in the business logic or where you prefer it? We use F# for scripting and that means, if you think of the architecture of an engine from bottom up, scripting will be at the very top, so what that means is that you can allow code that is slightly not as performant as stuff that it is at the bottom. When you are doing C# at the bottom you try not to use LINQ, to be very smart about how you deal with collections and stuff like that. You can also do that in F# but we just haven’t done it. So when using F# people tell you generally they are kind of worried about that, you generate a lot of garbage because you have all these objects that you are generating and then throwing them around, but you are scripting so that’s ok. If you were lower, you would have to do it differently.

8. It’s mostly high level code basically? Yes, and that’s when we are talking about the code for the game. I found that a really good way to get F# into your process of running code is on the side. You start with tests, you start with build scripts and anything like that that is on the side and that allows you to kind of start getting good about thinking from an F# point of view.

9. In a future game or a future project, do you think at some point you would have a 100 % F# project or is that not something that you want to do? There are some interesting thoughts around that, there are two lines of research I’d like to follow, one comes from trying to do Event Sourcing, Reactive/Event Sourcing-type engine where you have data structures that help you to get that done, and the other way would be to have a slightly more pragmatic approach where you do all of the non-game engine, so everything game play, from up there all F# or even Clojure. I’m talking about this because of this other project called Arcadia where they used ClojureCLR(in Unity 3D) and that’s also kind of fun, it’s like if you are going to talk about things you like to do, you might as well talk about all of them.

10. Clojure is on the other side of the static dynamic divide, so what’s your opinion on dynamic versus static functional languages? You want to put me on the spot. I think they are tools and I think when you are doing dynamic typing you can generally move faster but you also can make mistakes faster. I think it’s a lot about preference. I tend to side with static typing a lot but I can see that advantages of dynamic and it can be very, very fun, I enjoy writing code in those languages, so I wouldn’t be surprised if one day we'll talk again and I say: “Clojure, it’s great” because we are developers, we need to know what these different languages can give us.

11. One topic I’m interested in is, so you mentioned already generating a lot of garbage, so what’s your experience with .NET or maybe F# with the garbage collector, is it fighting the garbage collector, yes, no, is it not a problem? For this game, Onikira it hasn’t be a problem so far, we haven’t had to do a lot of performance tweaking, you have a cycle of some sort of development then you, to perform some analyses, fix that, wash and repeat. On our previous game build, in P-3 Biotic we did have to be a little bit smart about how we dealt with garbage. I we'll get to that point, however so far we are running on PC, so it’s not, I’m sure we will have a very different opinion when we get to go to consoles. At the same time we are on next gen and we do have quite a lot more memory than before, so maybe we'll be ok(it was a slightly ironic ok but doesn’t come across).



Werner: I guess it would be a worse problem on mobile.



Yes, absolutely, and thankfully that’s not a platform we're targeting for this game.

12. Let’s get on to some tools that you use, I think in your talk you mentioned a tool called FsCheck, which is a property based testing tool? Property based testing exactly, so the idea of any of these tools is basically that you define properties that are of functions and where you define the behavior of your system that way, so the nice thing about it is that you have rules for your system rather than very, very fixed scenarios and that’s really nice. In games you have a lot of fluidity on how your systems behave and you want to tie them down as little as possible and this helps because you can say “I just want this to be bigger than this or this to be true”, but you don’t need to say “It needs to be four” and that makes the difference to us.

13. FsCheck or property based testing is basically generating procedural tests essentially? Instead of writing your tests, you are generating them, so it means you write fewer tests, because you are thinking about the rules of your system. I mean I’m sure when you look at TDD particularly, you go like: “If this is null do this, when it's three do this stuff or maybe not that” I’m being a bit flippant, but it’s very case by case, you can do maybe multiple test cases but you have to define them exactly and precisely and that ties you down and thinking about properties actually helps you think about the problem you are trying to solve and that really helps.

14. Makes you think about what you're actually doing? Yes, I found that in TDD you have this problem where you go iteratively incrementally very, very small steps and at some point you actually, you get to the fifth or sixth test and you actually need to step back and solve the problem and most people go like: “Do the simplest thing that works”, that’s the thing. But sometimes that's just not enough, how about you think about it better, it works then you refactor, people sometimes don't refactor, it’s not built into the system that you reason and why wouldn’t you, you know?

15. Are all your tests using FsCheck or just a certain subset? We have some tests that are [using FsCheck]. So you need to use the right tool for the job. I’d like to have more property based tests. In games also how you test is different because you are testing your systems, you don’t test game play so there will be a big part of the code that won’t be under test, and we are ok with that.

16. Do you see any specific sort of logic that lends itself better to property based testing? I think by its own nature anything that is kind of, I don’t know if there is a word to define this, but if you're testing something like a data structure or if you are testing something that has a kind of boolean type logic. Yes, those are better. At the same time you can use it in a slightly more naive way. The way I’m trying to show and you can get a lot of value out of that because you are not thinking(about those scenarios); if you have anything with a string it will generate all the craziest strings for you and you get a lot of that because you never think about it, you know?



Werner: So that is a big value add, so FsCheck made your life easier, I guess.



I mean honestly for me what made me realize this is something I should check is that you get this NuGet package, and I go like “Ok let's see what I can do” and I was working on the scripting plugin and the first thing I did was: “Ok, what if I pass this as a value as one of my references” but it failed, but it didn’t fail like I thought, it failed because it had the forward slash or backslash, so suddenly it was thinking of paths that weren’t there and I just didn’t cover that case at all, so one test, three bugs, I mean that’s a lot of bang for your buck.

17. What are some of the other F# tools that you want our audience to look into? Well there is more (that I can probably mention) and for our type of projects you should check out Paket is really good for dealing with dependencies. Basically Paket is something that works on top of NuGet and it makes dependency management a little bit easier. I only started using like maybe a week or two ago, I’ve been hearing a lot of good stuff about it but I include it on our video player and, it’s like: “I don’t have to worry about this anymore, this is nice” and because we are using FAKE(F# Make) as well they work pretty well together, you can integrate them into the build projects, it’s not that NuGet was a pain but it was more pain than it is now and with FAKE it’s just beautiful, FAKE means that we have some slightly tricky build things that we need to do, like we need to have local builds that are x86 and 64 bits and you want to be able to do that and just have one and be able to copy and use it and test it and if works on Steam and it works with particular C++ libraries and it doesn’t work with others ones and thats the way it should be, and with FAKE we can do that quickly, so we really like that. Also when you need something really weird that nobody has done before, you can just write a little bit more F# and there it is, so I really like that.