bencope.land (Page 2)

bencope.land

game development

Preferring Immutability in Godot

Game engine development tends to rely on mutability, such as keeping up with an object's position on-screen. Typically, the game object is represented by a single class with a "position" property, and as the object moves around that property mutates to reflect its new value. This is fine because these

game development

Exporting Godot Variables in F#

In Godot, it's convenient to export variables so that they can be updated via the Inspector tab. Doing so in C# looks like this: using Godot; public class Player : Area2D { [Export] public float Speed = 2f; public override void _Ready() {} public override void _Process(float delta) {} } Here the Speed variable is

lambda calculus

Argument Selection Function

The argument selection function λfirst.λsecond.first accepts a function as an argument and returns a function which, when given an argument, returns the first argument. // λfirst.λsecond.first const selectFirst = x => y => x const double = a => a * 2 const triple = a => a * 3 const applyDouble = selectFirst(double) const applyTriple

functional programming

Semantic Focus

In his book Stylish F#, Kit Eason describes a few unstylish pitfalls that developers may fall into. One of these pitfalls he calls lack of semantic focus. I'll describe the kind of code that isn't readable with minimum context as having poor semantic focus. In other words, relevant meaning isn't

functional programming

Functional Reactive Programming

There's something about FRP specifically that makes programming an absolute pleasure. Designing an elegant reactive application is a great feeling and opens you're mind to just how rewarding it can be to focus on decoupling. Thinking in reactive (message driven) streams has clear benefits between multiple applications, but even within

game development

Godot and F#

Over the weekend I got a game started with Godot Mono and F#. It works out pretty well, although it relies on using C# to extend types defined in F#. Out of the gate I've taken up a convention of defining a namespace just for defining a type (class) that

lambda calculus

Application Function

Function application function is represented by the term λf.λx.f x. It accepts a function as an argument and applies it to the argument of the function it returns. // λf.λx.f x let apply f x = f x let addOne c = c + 1 let applyAddOne = addOne |> apply |> (fun

lambda calculus

Self Application Function

The function λx.x x is the self application function. It applies its argument to its argument. // λx.x x const sa = x => x(x) Like the identity function, it doesn't seem helpful at first glance but it has some interesting applications. Consider the twice function λf.λx.f (f

lambda calculus

Identity Function

Identity function is the simplest of the lambda calculus functions, represented by λa.a. It simply returns the argument that it was given. // F# fun a -> a // JS a => a # Python lambda a: a While it is a simple function, it still has significance in composing functions in that

functional programming

Pipes Again

Python's PyMonad library provides some neat utilities for functional programming. Here's a Python pipe function from a previous post. pipe = lambda *fns: lambda x: reduce(lambda y, f: f(y), list(fns), x) g = lambda n: n + 1 f = lambda n: n * 2 h = pipe(g, f) h(20) #42

game development

Invisible

Just completed a prototype for Weekly Game Jam #147. The theme was "invisible". What we came up with was a space adventure where you must reach a base, but the base is cloaked until a certain objective is met. We had lofty goals and only produced a subset of features

game development

Game Jams

Game jams are a nice way to develop a game under a set of constraints so that you don't get bogged down with too many details, or end up with an eternal side project. I'd like to do a few this year hopefully with some friends and colleagues, trying out

functional programming

Pipes

Inspired by the following Tweet from Eric Elliot in which he uses a reducer to make a pipe function, I thought I'd do something similar in Python and F#. const pipe = (...fns) => x => fns.reduce((y, f) => f(y), x); const g = n => n + 1; const f = n => n * 2;

Deno, Node and TypeScript

JavaScript is considered decent language for functional programming, particularly because its weak, dynamic typing combined with arrow functions make for succinct code. After using F# more though I've really come to appreciate type-driven development. Strong types and functional programming go so well together, I've essentially completely abandoned regular JavaScript, even

design patterns

Demystifying Design Patterns

Often times I find it beneficial to look outside of one's own industry for inspiration. There is often a lot of practical wisdom to be gained from areas that seem unrelated to our own domain, and possibly even similar problems that have already been solved. This has proven valuable to

game development

Throwaway Code

Sometimes we write code that we know will be thrown away - especially in the discovery phase of a feature or product. The problem is, often circumstances cause this sort of code to be shipped. I imagine a fair amount of cursing under one's breath the previous developer who worked

Style Guide, not Coding Standards

In Stylish F#, Kit Eason suggests that we create Style Guides rather than Coding Standards to assist developers. A style guide "suggests" or guides rather than mandates, and better encourages creativity and originality while still producing code that is understandable by one's peers. He suggests that a programming language is