I haven’t talked about SiloRider in two years, and even then it was the only time I mentioned it on this blog since I announced it eight years ago! I’m obviously not good at advertising or project management. But I’m decent at coding, and if you looked at the repository, I’ve been slowly maintaining SiloRider all this time. After all, I’m using it daily with this blog, which crossposts to my social media.

It’s been long enough that I need to re-introduce SiloRider: it’s a Python command-line utility that parses your blog’s homepage for microformat markup, and cross-posts your content to social media platforms. Basically, it’s how I post here on my blog, and everything then shows up on my Bluesky and Mastodon accounts.

Anyway, I was way overdue for a new release! SiloRider 0.3.0 is now available on Pypi, in case anybody out there wants to try it out. But watch out, this is very much a “works on my machine” kind of project, so you need a bit of technical know-how to get it running. I would happily welcome contributions to make it more user-friendly.

Notable new features since 0.2 include:

• Posting to Bluesky. This includes support for rich text, such as hyperlinks in your skeets.
• Posting to Facebook Pages. Posting to personal accounts isn’t supported, since Zuckerberg shut that down a few years ago to try and keep you inside his silo. But Pages, used by brands and businesses and so on, do support automated content.
• Automatic resizing of pictures in a micropost, for silos with file size limits.
• Generation of “social cards” for links in your posts, for silos like Bluesky who don’t do it themselves.
• Converting GIFs to MP4, for silos like Bluesky who only support “proper” videos.

And of course, a whole bunch of bug fixes. So many bug fixes, especially around the finicky ways of determining character counts for those silos with character limits.

I’ll try to post more regular updates about SiloRider going forward, but most of it will be bug fixes, unless something notable happens in the social media landscape on par with the exodus from Twitter.

I hinted at it last time I talked about my camera system for Unreal Engine: it might come back.

Well, now it sort-of has, and if you have some use for it, you can help by sponsoring its development and getting technical support for it! All the information can be found at my company’s website. And yes, my company is called “Brutal Baguette”¹.

Obviously, if you were following my Gameplay Cameras articles here, you might want to start following the Brutal Baguette blog from now on. It will be fairly low frequency.

1. Bonus points if you catch the reference. ↩︎

So I figured I would post an update that is part of the actual developer diary I had on the UE5 Gameplay Cameras, in case someone out there only followed that category of posts: I was part of the mass layoffs that saw Epic Games get rid of almost a quarter of their employees this week. I had only posted a small status update so far.

What’s Next for UE5 Gameplay Cameras

I don’t know what’s next for GPC. I was the one who started that plugin, and I was the only developer on it — and only part time at that (the other half of my time was spent on Sequencer). It is possible that someone else picks it up but it’s unclear at this point. GPC is powering the Verse camera system for UE6’s “metaverse” tech, but it’s only doing so “under the hood”. That is: you’re supposed to “just write Verse code” and not assemble your cameras using the graph editors I built. In fact, UE6 currently plans to have as few “custom editors” like these as possible, preferring doing everything directly in Verse.

As a result, I assume that the people working on UE6 will only address runtime issues and won’t have the time or desire to work on the “data-driven” aspect of GPC, its editor workflows, UIs, integration with Actors and Blueprints, and so on. If you need some clarity on that, I would strongly recommend that you contact the UE team by asking that question on UDN (now called EPS).

When people asked me, a year ago, “what the plan is” for GPC, I was indeed planning to support it for as long as possible. Sadly, “as long as possible” wasn’t quite as long as I thought.

Some Personal Thoughts

When I started working on the first draft of this camera system more than 10 years ago, in a different engine, I had set myself the goal to bring gameplay cameras through the same sort of data-driven evolution we saw in the early-2000s for shaders, animation, audio, and more. I wrote about it in detail in “A Modernization of Camera Systems”.

I shipped a few games with this idea, and last I checked, that first system is still shipping more games. UE5 was a better and bigger engine to prove my idea, and I’m happy it seemed to be on the right path, judging from the many emails and Discord messages I received over the last few months. I’m very grateful for all the feedback y’all sent me — everybody was very nice, enthusiastic, critical, and supportive. I would typically get some encouragements, a couple of bug reports, ideas for improving workflows, and a drink offer, all in the same email. This is the sort of gamedev community I like to see! Good job everyone! 😄

What’s Next

I’m currently of course looking for a new job, and chatting with a couple of game studios to that effect. If you’re interested in someone with a lot of experience in cinematics, cameras, animation, tools, and pipelines, hit me up via email. I recently setup a business so I’m also available for freelance contracting work, which might be better in some cases given the state of the industry.

That’s it for UE5 Gameplay Cameras from me for now. I’m OK being part of the layoffs (I was internally quite vocally against UE6’s technical direction) but I am quite sad to abandon all the people who contacted me about building their game using GPC. Leaving these people behind is the hardest part of this. Good luck to everyone who had camera-related chats with me over the past year!

In the meantime, if you want some camera goodness, please check out my friends at Black Eye Technologies, along with cool folks like Evelyn Schwab.

This is another article in my developer diary for the Unreal Engine camera system.

The Gameplay Cameras (GPC) plugin currently still has the “experimental” status, but the plan is to upgrade it to “beta” for UE 5.8. This means I have to clean up a few mistakes I made with some of the early designs. The first big mistake was how and where the camera system activates from and runs… let’s dive in!

Oh hey, look at the time! Another post in my developer diary for the Unreal Engine camera system, and a whole release went by that I haven’t posted anything about. Oh well, let’s see if I can pick the pace back up later. In the meantime, here are some notes and highlights for the Gameplay Cameras (“GPC”) plugin in the Unreal Engine 5.7 release that just went out.

Once again, while the GPC plugin is flagged “experimental” and, therefore, we don’t guarantee any backwards compatibility for it, I made a reasonable effort to keep most things working. Still, there are a couple of breakages we’ll talk about here. Also, if everything goes according to plan, the plugin will graduate to “beta” in 5.8, so fingers crossed!

This is the eighth post in my developer diary for the Unreal Engine camera system. Since the UE 5.6 release has just gone out, I figured I would write a little bit about what to expect if you’re using the early UE 5.5 Gameplay Cameras experimental plugin.

While the GPC plugin is still flagged “experimental” and, therefore, we don’t guarantee any backwards compatibility for it, I made a reasonable effort to keep most things working. There are however a couple of breaking changes to prevent having to maintain cumbersome code in such an early stage of development. This article is most about that.

This is the seventh post in my developer diary for the Unreal Engine camera system. Since the last post was a super high level view of what the system is supposed to be, I figured I would just go down one step for this article and share some notes about the general design. This might be particularly useful since the official Unreal Engine documentation doesn’t usually cover “experimental” plugins, and we’re probably one release away from upgrading GPC to “beta”.

This is the sixth article in my UE Gameplay Cameras developer (GPC) diary. Last week I wrote about one of the first decisions I had to make when I started this work, but I realized I could write about the very first decision I had to make: the decision to start making a camera system in the first place, and in particular making one this way! So, why am I doing this?

This is the fifth article in my GPC developer diary. Gameplay Cameras (GPC) is a camera system for UE5 that started shipping with the engine as part of version 5.5, but is still in its “experimental” phase. We plan to have it in “beta” with 5.6, and “production ready” with 5.7 or 5.8 depending on how things go.

There was no article last week since it was Family Day here in British Columbia, but this week I’ll go back to one of the very first decisions I had to make, which was the basic design for camera nodes.

This is the fourth post in my developer diary about the Gameplay Cameras (GPC) plugin for Unreal Engine. I skipped last week because I was too busy! This week let’s pick up on something I alluded to last time, which is “parameter pre-blending”. As always, everything I’m showing here is work-in-progress, scheduled to ship in UE 5.6. You can grab the code from Github and play with it early if you want.