Taylor

Taylor Monthly - July 2026

Sat, 01 Aug 2026 00:00:00 +0000

	Count
Releases	0
Commits	6
Contributors	2
Pull requests merged	2
Issues closed	1

At a Glance

My Mental Health Life is currently difficult
Windows Issues Fixing the console issue on Windows
Path Issues Working on fixing the current working directory feature
Taylor v0.5.0 Progress Where the new release is at

My Mental Health

If you follow my personal blog you will have seen that things have been pretty hard for me. This has meant pulling back on the amount of serious work I can do, including working on Taylor.

The plan was to have v0.5.0 released already but I haven’t been able to commit many hours to the last couple of tough challenges I want to get done before releasing.

I’m not sure how much longer the current stressors are going to be affecting me but I am prioritising myself and getting through this situation. I will still try to fit in some Taylor development as I really want v0.5.0 released but I will not sacrifice my health to do so.

This means I will put no deadlines or promises for a release date.

I appreciate your understanding on this.

Windows Issues

Pull request

While I was preparing for Taylor’s v0.5.0 release I started building up a proper checklist to make sure things weren’t broken or there were no regressions. This has already payed off as it discovered that Taylor’s development experience was broken on Windows and has been since v0.4.0.

This came about due to unknown changes but it was related to how I wanted to package Taylor as both a CLI tool and GUI which it seems Windows has issues with.

A new config option was added for toggling the behaviour of showing a console on Windows. This is set to true for Taylor CLI but should probably be set to false (the default value) when you export your games. You shouldn’t have to change anything about your config to get this fix, just upgrade to v0.5.0 when it releases.

Path Issues

I discovered this issue when testing on Windows but it seems it applies to all systems. This is some functionality I added during the v0.4.0 development but I now think is an anti-feature.

When running your game internally we would Dir.chdir to the location of the executable. I thought this was helpful because it means you don’t need to think about the current working directory when loading in your assets but has caused issues when you want to do something like ../taylor to launch your project or game. This causes it to not respect your actual current working directory and makes it unable to find game.rb.

On Linux and OSX I didn’t notice this because I always just put taylor somewhere in my $PATH and it resolves correctly. On Windows though it was changing the directory to where the actual executable was still, even though on Linux and OSX it stayed in the current directory.

This is still a work in progress.

Taylor v0.5.0 Progress

I think this is reasonably close. The last issue I’m aware of is the path issue described above.

There may be more issues that come out of the release checklist and I’m trying to delay this release to include as many positive changes as possible. I want to make v0.5.0 a release that brings Taylor up to the standards I expect. I feel there has been some slips in quality since v0.4.0 but that was somewhat expected with how massive that release was.

If you’re interested if following the release, see the pull request.

Taylor Monthly - June 2026

Wed, 01 Jul 2026 00:00:00 +0000

	Count
Releases	0
Commits	10
Contributors	2
Pull requests merged	7
Issues closed	1

At a Glance

Emscripten Upgrade 4.0.13 -> v6.0.0
ARGV Rework for the CLI You can now use -- to split args from the CLI to your game
Improved Developer Experience You should be able to use Docker from within Docker now
Updated Documentation for Development How to properly set up your machine for developing Taylor
Block Stacker Example Game I start in earnest on the block stacker example game
Taylor v0.5.0 Progress Where the new release is at

Emscripten Upgrade

Pull Request

Emscripten has been upgraded two major versions from 4.0.13 all the way to 6.0.0. Thankfully it just boiled down to including emscripten.h in a few more places.

ARGV Rework for the CLI

Pull Request

The Taylor CLI was missing some a pretty useful bit of functionality that makes it a lot clearer which arguments are for Taylor and which are for your game.

Given the following script:

# args.rb
puts "Arguments: #{ARGV}"

When you run taylor args.rb -- --version what would you expect? I bet it’s not:

$ taylor args.rb -- --version
trace (most recent call last):
        [3] /app/taylor/output.rb:569
        [2] /app/taylor/output.rb:320:in call
        [1] /app/taylor/output.rb:326:in initialize
/app/taylor/output.rb:387:in setup_options: unknown option: , version (RuntimeError)

In v0.5.0 you can run taylor args.rb -- --version to disambiguate who the arguments are for. Anything before the -- is for the taylor command and everything after is for args.rb. For example:

$ taylor-dev args.rb -- --version
Arguments: ["--version"]

Thanks to azimux for implementing this feature! It’s still so amazing to me that there are people out there interested in Taylor.

Improved Developer Experience

Pull Request

Having someone else work on Taylor made me take the developer experience a lot more seriously. I’d kind of neglected the development Docker setup since I don’t use it much myself.

I’ve now got the full CI suite able to run locally inside of Docker to make getting a full development environment set up a lot easier. This means that you can do development on OSX as well, and maybe even Windows if you set up Docker Desktop or WSL.

There’s definitely still some issues. I’ve noticed on Fedora sometimes it’ll stop having permission to access /var/run/docker.sock. I’m not sure what’s happening there and may investigate later if other people have issues.

Updated Documentation for Development

Pull Request

Given the big push to make local development easier for people I decided it was time to rewrite the documentation and split them out from the README.md.

I also decided to remove the documentation around setting up a local build environment. This was done in favour of pushing people to the easier to maintain Docker environment. If people are still keen though, they can look into Dockerfile.dev and figure out what they need. It’s honestly not very hard to get set up on Linux but would be very difficult on Windows or OSX.

Block Stacker Example Game

I’ve finally started in earnest on a new example game, this time the focus will be on stacking blocks and clearing lines!

I’m very excited about this project as I’ve wanted to build this sort of game for a while but have felt intimidated I might not structure it well enough for the crazy shenanigans I plan on doing with it. If I let that sort of thing hold me back though Taylor would never exist, so I bit the bullet and started work. It’s early days but I’m already pretty happy with it.

If your browser doesn't support the video tag, you can download the video.

An orange 'L' piece is shown spinning around and moving over a light gray grid. There is debug information on the left hand side of the screen.

Taylor v0.5.0 Progress

I spoke about this in my last monthly update but it’s still not live. It turned out there was more I wanted to get into this release. Also with the discovery of some missed test migrations that meant I had broken important functions after the mruby upgrade I decided to take it a bit slower.

One of the big things I want to do is come up with a release checklist. I’ve been thinking on it a bit more the past few days because I want to start the release process as I do believe it’s ready. I’ve been using the prerelease locally for a while and haven’t hit any unexpected issues.

If you’re interested if following the release, see the pull request.

Taylor Monthly - May 2026

Mon, 01 Jun 2026 00:00:00 +0000

	Count
Releases	2
Commits	19
Contributors	1
Pull requests merged	3
Issues closed	3

At a Glance

Taylor v0.4.2 and v0.4.3 Released I put out two small releases to fix some bugs
mruby 4.0.0 Upgrade A hard fought battle to upgrade mruby
Raylib 6.0 Upgrade A much simpler upgrade
Taylor Squasher Progress Finally just sat down and built a prototype

Taylor v0.4.2 and v0.4.3 Released

Taylor v0.4.2 and Taylor v0.4.3 have been released. These contain a handful of small fixes.

Changelogs

Taylor v0.4.2
- Lock the MRuby version used in the export docker image
- Refactor talyor-config.json handling
- Update the Dockerfile.dev for Debian 13
- Fix OSX exports
Taylor v0.4.3
- Properly use Taylor::Config through the entire export process

mruby 4.0.0 Upgrade

This was a hard fought battle but I managed to conquer mruby and bring it up to 4.0.0. There are three main reasons for this.

1. mruby 4.0.0 Loads mGems in a Different Order

The ordering of mgems has changed in the build config. Now custom mgems are loaded before internal core mgems. This broke the following two mgems for very different reasons.

2. mruby-require

mruby-require is an extremely powerful mgem that lets you use require and properly structure your project into many neatly organised files. It actually also allows you to compile other mgems into .so or .dll files so you can programmatically require them after mruby is built. That’s the functionality that broke.

I ended up having to fork the mgem and remove that functionality. This has the bonus of making the code for the mgem much more maintainable as that was causing the build to be complicated.

3. Neospec

neospec is my gem/mgem. It’s a testing framework that helps me keep Taylor working correctly as I develop it.

I forgot that I rely on the core mgem mruby-env and that meant it was built in the wrong order. This meant when Taylor loaded up the code tries to use ENV before it’s available. Thankfully a pretty easy fix once I figured out what was going on.

Raylib 6.0 Upgrade

This has gone a lot easier than the mruby upgrade. This brings extremely minimal changes to your experience using Taylor. What’s interesting is that this opens up a lot more possibilities on the backend for porting to different systems.

Taylor Squasher Progress

I sat down one night and decided to do something a little silly to get myself unstuck on this project. I kept worrying about “how to do it perfectly” and overthinking every step. So I sat down with my laptop, put a chill video on in the background, and just gave myself permission to write bad code to achieve the simplest possible result.

This is something I can get a little hung up on when developing something open source. I get in my head that every commit has to be a perfect example of great code instead of reality. There’s every chance I’ll re-write the git history before opening it up but history has often shown I’m too lazy for that, so you’ll probably be able to dig and see what I did.

I am happy to report that I did get a basic prototype working with the Jumpy Alien example project!

The interesting thing to note is that it includes every .rb file that’s in your load_path according to the taylor-config.json file. So you’ll see in the playground that it also includes the files from under test/ even though they aren’t used.

Obviously this is just a prototype and weird things like this are to be expected for now. I’m not entirely sure how I want to handle things like that. I’m not convinced I’d be able to implement a tree shaking algorithm or anything fancy like that. But maybe just a simple export-ignore option?

Taylor v0.4.3 Released

Sun, 31 May 2026 00:00:00 +0000

This is another minor release that fixes a bug in the export process that caused assets not being exported correctly.

You may see some warnings when you run taylor export letting you know that you’re using a deprecated key in your taylor-config.json. The old values will continue to be supported for the foreseeable future but may be removed in a future release.

The following keys are deprecated:

export-directory
export-targets
load-paths
copy-paths

In favour of:

export_directory
export_targets
load_paths
copy_paths

Download Taylor v0.4.3 now!

Changelog

Properly use Taylor::Config through the entire export process

Taylor v0.4.2 Released

Wed, 27 May 2026 00:00:00 +0000

This is a very minor release that fixes a couple of bugs and tweaks some of the development experience.

Download Taylor v0.4.2 now!

Changelog

Lock the MRuby version used in the export docker image
Refactor talyor-config.json handling
Update the Dockerfile.dev for Debian 13
Fix OSX exports

Taylor Monthly - April 2026

Fri, 01 May 2026 00:00:00 +0000

	Count
Releases	0
Commits	9
Contributors	1
Pull requests merged	0
Issues closed	0

At a Glance

Taylor's Five Year Anniversary It's been five whole years since I started Taylor
Refactored Taylor's Config handling Noticed this area was really bad and cleaned it up
Taylor Export Woes Found an issue with my exports
Taylor Squasher Brainstorming around implemntation
Taylor Has a Community Site It finally happened!

Taylor’s Five Year Anniversary

I wrote a whole blog post so go check it out!

I’m just so blown away at how far I’ve come with Taylor. It even lead to me getting my current job!

Refactored Taylor’s Config handling

An issue was raised because I have a discrepancy between the documentation and the code. In the code taylor-config.json is the file used for configuring all your Taylor needs. In the documentation I call it taylor_config.json. An easy fix right? Just rename the documentation? Well yes, that did fix it.

I looked closer at the code though because I briefly considered supporting both as a politeness. I did not end up doing that but I did notice how awful the configuration handling is inside Taylor. So I took some time and completely refactored the configuration handling and created the Taylor::Config class to help out. This has reduced the amount of magic strings across the codebase and now lets developers easily use this configuration for themselves if they wanted.

Taylor Export Woes

The build for my previous config change broke on the web test suite. I thought this was really strange and was able to reproduce it locally. It just boots up, runs the C++ code portion of Taylor, then does nothing, and exits.

This took a decent chunk of debugging, lots of puts statements, and even going back commits. But the strangest thing was the mrb state didn’t claim to have an exception when running the mrb_load_irep method to load the test suite.

Interestingly going back to earlier commits didn’t fix this and it started happening on my Linux builds too. This made me realise the actual cause. It was because I was using the master branch of MRuby in the export Docker image but I was locking it to the 3.4.0 tag when I compile libmruby.a. So the most recent commits to MRuby seem to have changed how the bytecode is generated and loaded. This meant the older 3.4.0 version of MRuby couldn’t load and run it.

The fix isn’t that interesting, it’s mostly just me locking the MRuby version so this doesn’t happen again.

Taylor Squasher

I’ve decided to pick this project back up and give it a serious attempt. I do believe there’s some huge value to be had here. Right now I’ve mostly just sat down and thought about what I want to tackle and how I want to tackle it.

I think I have some decent ideas that’ll let me implement require_relative too, but that’ll take a little experimenting before I’m confident.

Taylor Has a Community Site

You read that right, Taylor officially has a community site! I did the big announcement over on this blog post if you want the details, or you can just go check it out!

Taylor has a Community Site!

Wed, 15 Apr 2026 00:00:00 +0000

At a Glance

Intro
What Does this Mean
How do I Participate
Outro

Intro

After much hinting, faffing about, and being worried about having to be a community manager a golden opportunity fell into my lap! Javier reached out to me to discuss bringing the Taylor community to the Ruby User Forum. I was weary initially because this is a ridiculously kind gesture, but after a bit of digging and a video call this actually is just an incredibly kind offer.

You can see the announcement on the forum too! There’s quite a few FOSS Ruby projects that agreed to this and I think it’s going to be great.

What Does this Mean

You now have a place to discuss Taylor, ask me questions, get help, show off your cool projects, etc. I’ll be an active member there and I will be posting the fun projects I’m working on. If I’m looking for feedback on a proposed feature I’ll be posting there too. Basically, anything Taylor is fair game.

How Do I Participate

That’s an excellent question! It’s really easy, all you need to do is:

Head on over to the forum and sign up
When you create a topic, be sure to tag it taylor
Add the relevant category too

That’s it! It’s just that easy. If you want, you can also tag @Sean as that’s me on the forum.

Outro

This is a huge deal for me, someone across the world took notice of Taylor and reached out to me to offer this amazing joint venture. This also means I don’t have to be a community manager as the thought of that scares me a lot.

I look forward to seeing you there and am extremely excited to see the projects people have been working on!

So please, head on over to the forum, all you need is an email or a GitHub account and the community as already welcoming and friendly.

Taylor's Five Year Anniversary

Thu, 09 Apr 2026 00:00:00 +0000

Intro

This is going to be a long rambling post about the past five years of Taylor. Be prepared for it not to be well edited and for my thoughts to jump around a bit. I thought about making this a video but life has not been kind recently so this is what I have the energy for. So please sit back and enjoy my ravings.

At a Glance

Five Years ago Today Where it all started
Major Refactor Mistakes What I did wrong with the refactor
Taylor Squash Changes to how Taylor concatenates your project into one file
Exporting Options to overhaul exporting
Dependency Management Thoughts on how to use gems with Taylor
Future Plans What's to come
Outro Cheers 🍻

Five Years ago Today

commit 0d9def80e734eb3df48469d4a4a4a8ebb964f42c
Author: Sean Earle <sean.r.earle@gmail.com>
Date:   Fri Apr 9 22:02:11 2021 +0930
▎
▎   Initial commit
▎
▎   Got basic mruby integration but terrible structure and not very DRY

This was the first ever commit to the Taylor repository so I treat it as the birthday for Taylor. I figure I’d cover some of my gripes, lessons learnt, and future plans.

As a fun fact, this is the list of implemented Ruby methods in the very first commit:

init_window
set_target_fps
window_should_close?
begin_drawing
end_drawing
draw_fps
clear_background
draw_rectangle
get_frame_time
Colour.new
Colour#red
Colour#red=
Colour#green
Colour#green=
Colour#blue
Colour#blue=
Colour#alpha
Colour#alpha=

Major Refactor Mistakes

The major refactor took about 2.5 years and the way I went about it was (in my opinion) all wrong. Sadly I only realised that about 2 years into the process!

After working on Taylor for a while, I finally decided to give all the methods a refactor to be my vision of what Taylor should be like to use, instead of just being a one to one copy of Raylib. This meant that it was going to be a much more “Ruby like” experience with classes and keyword arguments. This was also raised as the issue Top-level namespace is overloaded.

I did sit down and write out a version of the example.rb you see on the front page to try and figure out how I wanted this to look. After a little bit of back and forth with a trusted friend I had made up my mind about how I wanted to structure everything.

The mistake came when I decided to just start rewriting all the C++ code into the new shape. I realised I could have taken a much shorter path of adding a layer of Ruby on top to obfuscate the lower C++ code and slowly chip away at rewriting the C++ code later. This would have let me get the release out a lot earlier and have people using it and able to give me feedback.

In terms of code, my proposed refactor would have initially just looked like this:

class Window
  def self.open(width: 800, height: 480, title: "Taylor Game")
    init_window(width, height, title)
  end
end

Other than that though, I’m happy with how it all turned out. I think the new design is significantly better and helped me find quite a few nasty bugs hiding in the C++ layer thanks to my usage of pointers and my understanding of memory management.

Taylor Squash

I wrote about this in the first Taylor Monthly but to summarise. Currently when you run taylor squash what it does is concatenate all the ruby files in the order they’re required. This can lead to a variables scope being a lot larger than in development.

I’d like to replace it with something a lot smarter that uses lambdas to keep the scopes from polluting each other. It still won’t be perfect but I think it’ll be good enough to not affect most games and applications. I also believe it could be useful for “compiling” standard Ruby applications for easy distribution.

If you know anything about me it’s that I think way too much about how to distribute the things I develop. It’s one of the reasons I love web development so much and also a major reason Taylor exists. I could rant about this all day but will instead leave it there.

You can see a prototype of my proposed squash redesign in your browser.

Exporting

Right now if you run taylor export it’ll actually run a bunch of Docker commands. If you run taylor export --dry-run in a standard Taylor project you’ll see these commands.

docker run --mount type=bind,source=/home/sean/Syncthing/code/taylor-org/examples/jumpy_alien,target=/app/game --mount type=bind,source=/home/sean/Syncthing/code/taylor-org/examples/jumpy_alien/exports,target=/app/game/exports --env USER_ID=$(id -u ${USER}) --env GROUP_ID=$(id -g ${USER}) hellrok/taylor:linux-v0.4.1
docker run --mount type=bind,source=/home/sean/Syncthing/code/taylor-org/examples/jumpy_alien,target=/app/game --mount type=bind,source=/home/sean/Syncthing/code/taylor-org/examples/jumpy_alien/exports,target=/app/game/exports --env USER_ID=$(id -u ${USER}) --env GROUP_ID=$(id -g ${USER}) hellrok/taylor:windows-v0.4.1
docker run --mount type=bind,source=/home/sean/Syncthing/code/taylor-org/examples/jumpy_alien,target=/app/game --mount type=bind,source=/home/sean/Syncthing/code/taylor-org/examples/jumpy_alien/exports,target=/app/game/exports --env USER_ID=$(id -u ${USER}) --env GROUP_ID=$(id -g ${USER}) --env EXPORT=osx/intel hellrok/taylor:osx-v0.4.1
docker run --mount type=bind,source=/home/sean/Syncthing/code/taylor-org/examples/jumpy_alien,target=/app/game --mount type=bind,source=/home/sean/Syncthing/code/taylor-org/examples/jumpy_alien/exports,target=/app/game/exports --env USER_ID=$(id -u ${USER}) --env GROUP_ID=$(id -g ${USER}) --env EXPORT=osx/apple hellrok/taylor:osx-v0.4.1
docker run --mount type=bind,source=/home/sean/Syncthing/code/taylor-org/examples/jumpy_alien,target=/app/game --mount type=bind,source=/home/sean/Syncthing/code/taylor-org/examples/jumpy_alien/exports,target=/app/game/exports --env USER_ID=$(id -u ${USER}) --env GROUP_ID=$(id -g ${USER}) hellrok/taylor:web-v0.4.1

As you can see that’s 5 Docker images that are very kindly hosted over on Docker Hub. In total this is about 2~GB of images per version of Taylor. This will only get larger the more platforms I support as each platform is one Docker image (more or less). I’m very skeptical of how long they’ll let me keep hosting this and transferring this much data without charging me or cutting me off.

I also don’t love that it means every developer using Taylor needs to have Docker installed and correctly configured so they can export their games. I think on modern ARM based Macs this has a fairly large performance penalty because all the Docker images are for AMD64 based CPUs. I also haven’t tried this on Windows in a long time, but I’m hoping it still works there.

The OSX Docker image is based on OSXCross and I’m so thankful this project exists or I wouldn’t support OSX at all. It is a bit of an extra maintenance headache though as the setup for OSXCross is a bit of a pain.

The story of the Android Docker image is quite similar but even dodgier as I’m pretty sure I’m not supposed to accept the EULA for ndk. I just don’t want users to have to do anything other than run taylor export when they want to export their games.

I straight up don’t support iOS because there’s no way to compile an app for it from Linux.

The theme here is walled gardens are extremely annoying for me as a developer who wants to create an easy developer experience for cross-platform deployments.

I’m sure you can tell from the above paragraphs that I don’t love this setup. I’m strongly considering refactoring the whole thing to be much simpler. The main reason for all this complexity is because when you export your game, you’re actually compiling Taylor with your game’s code instead of the Taylor CLI tooling which actually is just a Taylor application.

I’ve got a few alternatives in mind but I’m really not sure what I prefer or what I’ll seek out.

Zig

One option is to use Zig as my C++ compiler instead of GCC/Clang/OSXCross/emscripten. This is apparently able to cross compile but I’m skeptical it’ll be as magic as it would need to be to handle building Taylor. I suspect it’d get me about 80% of the way there but then require heaps of fiddly nonsense to get the last 20% and even then, it’d still require Docker (probably).

Alternatively, you could probably use mrbc and Zig to compile a library Taylor could dynamically load. I think this would be much more likely.

TinyCC

I recently remembered TinyCC and think it could be used inside Taylor via libtcc. This is very interesting but I suspect it’s not the most supported compiler and I will run into a lot of issues supporting it myself. Also I think it might not target the platforms I need like WASM or OSX.

As above it’d still require mrbc to generate game.h before compiling it.

`mrbc`

You’ve probably seen me mention this a bunch during this blog post already. This is the CLI tool that comes with MRuby that takes your Ruby file and turns it into bytecode for MRuby. Taylor uses this to convert your squashed game into a game.h file to compile into the engine. mrbc also supports outputting a game.mrb file that is basically the same as the game.h but can be loaded via require 'game' by MRuby.

Because this is built with MRuby, I believe I could include it into Taylor itself so we can keep the single binary, drop Docker, and still let you export games. The big problems I have with this approach is that your game is no longer just a single binary and your assets. You now have to ship it with the game.mrb file. I worry this will lead to much easier reverse engineering of games similar to what happens with Godot or Unity.

This also doesn’t solve the issues of having to prepare the assets for emscripten for the web export. There are absolutely workarounds I could implement but I worry they would feel second rate.

This would greatly simplify what taylor export needs to do on your local machine. Instead of needing to compile the entirety of Taylor all it would need to do would be to zip up the different platforms with your game.mrb. I believe this is similar to how Godot handles it’s exporting with pck files.

Run a Build Server

This one is quite interesting because it alleviates a lot of setup for end users. It’s super simple for new developers. Sadly, it’d cost me money, be a lot of development, and would surely be attacked as a source of free CPU/RAM.

I also think people shouldn’t just trust me to not inject evil things into their executable. Obviously I would build this in a way that people could self host their own build servers but that’s a lot more work. The nice thing is it’d be built to leverage the Docker images used by taylor export so there’s still that option.

I just have very little interest in hardening a server to the point that malicious actors can’t give me a bad day and stop people from building their games.

Dependency Management

This is something I’ve spent a lot of time thinking about but have not put any energy into getting working yet. I think it’ll be the big thing that sets Taylor apart from other MRuby based game engines like DragonRuby.

SIDE NOTE: DragonRuby is a super cool project you should check out. It’s got a lot of support and a large community. It may work better for you than Taylor depending on how you like to code. I’ve chatted with Amir in the past and he’s a nice person. He’s also ported DragonRuby to cool platforms like the Nintendo Switch.

I’ve had a few thoughts about how to handle this, so I’ll lay them out below.

Build My Own Package Manager

Building my own package manager sounds like a fun project and that entices me a lot. Obviously this would be a huge amount of work and I genuinely don’t think I’d do a great job given my lack of experience in this field. Especially when there are so many options out there already doing an excellent job.

So I could just…

Use Bundler

Using bundler is an incredibly enticing option as it’s already made, has all the infrastructure, and everyone already knows how to use it. The tricky part would be figuring out what path to include into Taylor and how to wire it into the Docker image.

This is the option I’ve considered the most and the one I think would probably be the most likely to be built. The nice thing is I could build this in isolation to test it without having to modify Taylor at all. So it would be a fun side project.

Although I could just have…

User Defined MRuby Configurations

MRuby actually has it’s own package management in the way of gems defined in the build configuration. One of the main reasons I want to support this is because Taylor actually has a great base for building distributable Ruby applications that aren’t games. Things like simple CLI tools or tiny web servers. I think it would add a lot to how useful Taylor is if you could compile it without Raylib attached. This would make the binaries a lot smaller (I think) but would require a fair bit of work to make happen.

This has the issue that I’d have to distribute MRuby as a separate file alongside Taylor because it would have to be a dynamically loaded library. I’d also have to figure out how to let people compile their own MRuby configurations easily and that sounds very hard.

Especially since people can clone Taylor, edit the taylor.gembox file, and compile it themselves. They would have to build the Docker images too but that’s also not very hard, just time consuming.

I do think this could be worth pursuing as it would allow developers to write performance critical code in C/C++/Rust/etc and easily integrate it into Taylor. I don’t believe this is a functionality any other MRuby game engine provides. I know Godot does via their GDNative extensions though!

Future Plans

I’ve got plans for the future of Taylor, so here they are in the order I expect to do them.

Make Games

This is the big one! I started Taylor five years ago because I wanted to make games with Ruby and I didn’t like any of the options I found at the time. So I made the mistake of building my own game engine thinking I would be making games with it in no time!

Here we are five years later and I’ve actually produced a few small games using Taylor as I’ve been building it, but I want to build something bigger to really put Taylor through its paces and find its pain points.

v1.0.0

Once I’ve built a decent sized game I will consider that proof that Taylor is finally ready for its v1.0.0 release. The release of v0.4.0 I consider a bit of a technical preview for v1.0.0. What this means is you shouldn’t expect any major changes to what’s there now, at most there will be new additions. I’m doing my best to not introduce any breaking changes.

If I do they are documented under migrations as I feel that is essential for a serious project that respects the developers using it. I may have issues with the leadership of Rails but their upgrade process and documentation is actually amazing and the level I aspire to. When I look at picking up a major framework or library migration documentation is something I specifically check for.

3D

Yes, the third dimension! I’ve been asked about this a few times and I do plan to support 3D as Raylib will make this pretty easy. I’m not planning on doing any work for it until I’ve gotten Taylor to v1.0.0 though. I’m mostly delaying this because it will be a lot of work that will be quite mundane. I also have zero experience with 3D and worry about doing it wrong and not realising. I already feel this way about my shader implementation as I’ve never used it because I don’t know how to write shaders.

And More

There’s plenty more I’d like to do, as alluded to above I definitely want to rework some internal systems and make developers lives easier. There’s also virtual reality support in Raylib and that could be cool to implement even if I don’t own a VR headset.

Honestly, I’m not sure where the future will take Taylor but I’m excited to find out.

Outro

That’s about all I can think to ramble about right now, I’m sure I’ll find more down the line and I’ll be sure to post about them when I do!

I am amazed at how far I have taken Taylor and am loving working on and with Taylor! I don’t see myself stopping work on Taylor any time soon as I am having too much fun and have too many plans.

Thank you for reading and thank you for being interested in my little project I started all those years ago just sitting on my couch with my secondhand Lenovo Helix Ultrabook and a couple beers.

Cheers 🍻

Taylor Monthly - March 2026

Wed, 01 Apr 2026 00:00:00 +0000

	Count
Releases	0
Commits	26
Contributors	1
Pull requests merged	0
Issues closed	0

Jumpy Alien

I spent some time this month and finished polishing off the Jumpy Alien example!

The final touches ended up being:

Hitboxes for sky and ground
Sound effects
Background music
Settings menu
Volume settings
Logo

Play the Game!

Community Site

Now that I got warden working with Hanami I’ve decided to go back to my Rails implementation of the community site. While I’ve enjoyed Hanami I’m looking to have a high velocity with this so sticking with tooling I know is going to be better. I will absolutely revisit Hanami later as I liked a lot of the decisions they’ve made and found it a great experience.

Going back to an old codebase always means I get to do one of my favourite things, upgrading libraries! I’m not even kidding, I get a lot of pleasure out of bumping gems and doing Rails upgrades. So now it’s running on Rails 8.1.

I decided to take it a step further though and rewrite the entirety of the erb templates I was using into Phlex. I find using Phlex a much nicer experience than writing erb templates.

I’ve rewritten the live updating mechanism. I was tempted to switch away from htmx but decided to stick with it in the end but needed a better architecture. The biggest issue was actually how I figured out what had updated. I was just asking each type of record I cared about if they had been updated. It kind of worked but it didn’t handle the case of things being deleted and it required quite a few different database queries to figure out.

The new architecture now has a model for all the updates in the system that I care about. When you update a post it creates an Update record that says a post was updated. When you delete a post it creates an Update record that says a post was deleted. This has cleaned up that whole code path a lot.

I’ve also finally committed to styling the page and wanted to share a sneak preview, it’s not the most exciting but I think it’s consistent with everything else I’ve been doing and think it’s easy to use.

Taylor Monthly - February 2026

Sun, 01 Mar 2026 00:00:00 +0000

	Count
Releases	0
Commits	1
Contributors	1
Pull requests merged	1
Issues closed	1

At a Glance

A Wild Email Appears
Jumpy Alien
Community Site

A Wild Email Appears

I received an email about Taylor! Someone noticed a bug on the playground and reported it. This small act by them made me feel like I’m actually making a difference with this project.

The thing that makes me chuckle about this bug report is that they’re focussing on the missing y call on the Vector2 but mention nothing about the clearly broken background drawing.

I’m very thankful for this report though, I have fixed both of these issues but I’m still not sure how to tackle keeping regressions like this from happening automatically.

Jumpy Alien

I got Jumpy Alien updated for Taylor v0.4.1. This was mostly the change around Texture2D#draw no longer defaulting the origin to the centre of the image and instead puts it back at Vector2[0, 0] to make it work like nearly every other #draw function.

I did some gameplay improvements too.

The pipes now spawn at random heights
Player gravity tweaked
Pipe movement speed tweaked
Exit button now works

If your browser doesn't support the video tag, you can download the video.

The main menu is shown before going into play the game. Once playing the player gets a score of three before crashing into a pipe and seeing the end screen showing their high score of 3.

Community Site

I decided to take it a step further though and rewrite the entirety of the erb templates I was using into Phlex. I find using Phlex a much nicer experience than writing erb templates.