Ben Threlfall

Frog is a radio network simulation tool that can be used for comparing routing algorithms or network protocols. Frog has a CLI and GUI interface. Users create 'scenarios' which are a specific layout of radio nodes and set of simulation parameters. Scenarios can either be hand created or automatically generated from a set of scenario generators. The intention is that a user can either test the algorithms of interest in specific situations, or en-masse using generated scenarios to get a broad understanding of the algorithm performance. Individual simulation results can be viewed in detail showing the state of each radio and what messages are being broadcast at any time, and many results can be aggregated to produce useful statistics that describe overall performance.

Frog started as part of a University group project with 5 other people. The overall project was looking at the performance of various routing algorithms for ad-hoc mesh networks using LoRa radios for use in remote areas and how this could be used in combination with gateway nodes that could send messages from the LoRa network to HAM radio. I wrote a large majority of the simulator engine code while other group members focused on other parts of the project like writing routing algorithms, gateway code, doing data analysis, and physical testing.

Since the project finished I've worked more on Frog especially tidying up the UI for general use. I would like to extend it more though, I think with some more features it could be used for site planning and generally a wider range of uses cases.

Frog is created entirely with Rust, the simulation engine is created effectively from scratch, using just a few ubiquitous Rust crates. It's a discrete event simulator where events are queue (by other events) onto a binary heap, in time order, then executed.

The code that is conceptually running on the radio nodes in the simulation is a called a 'node model'. Nodes models are also written within the Rust code but they are somewhat separated out such that the code can be written as if writing real code for a single radio on top of some abstractions. This means is relatively simple for a developer to create a node model without knowing anything about the workings of the simulator or even much Rust specific coding knowledge.

The GUI is also Rust and uses macroquad (basic rendering, window and inputs) and egui (immediate mode GUI).

Dice Machine

Probability Analysis Tool

Dice machine is a statistical analysis tool built around a domain specific language. In the current language design each statement maps to a single final probability distribution. Its designed to be easily used for board game / TTRPG maths, i.e. designed around dice rolls. Rolling 5 dice with 6 sides is written as: 5d6 then on the web interface the dice are summed together and the distribution of the sum total is shown:

More complicated rolling procedures can be represented through composing distributions and functions either using standard function syntax or with then statements:

The online interface lets users view the view the outputs as different types of charts and as tables.

Dice machine is made mostly with Rust. The language is all made in Rust and the web interface uses Leptos, as Rust frontend web framework, with a basic HTML page that loads the compiled (web-assembly) Rust code. The web interface uses ChartJS for the charts and styling uses Sass.

My university dissertation was on modelling the brain of C. elegans a type of microscopic worm that is a common model organism because of the consistency and low number of its cells.

I created two main models. The first was a predictive only model that used a artificial neural network. The second was a biologically based model that consisted of a network of biological neuron models. The models were trained (parameter fit) on neuron calcium activity data gathered from live worms by Atanas & Kim et al., 2023.

The final models were evaluated against test data that was withheld from training.

I've been doing game development as a hobby for many years and game development is how I first got into computer science. Back in the day I started making games in Unity and for a while made stuff in Godot. Of course though, making a complete game, and especially anything that other people might actually want to play, is a huge under taking and as such although I've worked on something like 15 games, I've only even gotten one of them to something I would consider a finished state. That game was Barkour II (Barkour I is lost media) a simple platformer type game made in Unity which I completed when I was 15. At some point I may go back and tidy up some of my old game projects and publish them, even if they can't really be considered full games.

Untitled Wizard Game

My current game project is about a wizard (and goblins and other stuff). It's a real back-burner type long term project but I do thing this one will be, what I would consider, a real game.

For this one I wanted to (largely) make my own engine with Rust and Macroquad. Macroquad could maybe be considered a game engine but it's more of a game framework. Macroquad provides basic rendering, audio, windowing, and simple input management but on top of that I've built my own collision detection, game state / entity management, debugging tools, higher level input management (to support remapping), and so on.

The game is a 2D top down / twin stick style game where you're a wizard fighting through levels using magic. There's not a set in stone design for the game, I'm still playing around with things and trying to take it in whatever direction is fun. At the moment though the differentiating part of the game is a timestop planning mechanic where you can stop time and queue up actions while getting a live preview of the results.