Siren Devlog #0 - It Begins

This is it - the first Siren Devlog! I've had this project on my mind for a long time, so I'm excited to finally share it with everyone. Before this devlog starts getting technical, I just wanted to talk a bit about what Siren is and where I want to go with this project.

So what is it?

Siren is a handcrafted game engine for programmers.

Siren is being designed with a focus on simplicity and performance. Performant software is scarce these days. But when you're dealing with games, performance is not an option, it's a requirement. A bottleneck in someone's project should be the fault of the project, not the engine.

Every line of code is written by a human (me... until it becomes open source.) There is no generative AI assistance used. That also goes for everything I write on this site and any assets that will go towards future projects made in Siren. I detest what's happening right now with generative AI and I want nothing to do with it.

I'm also trying to keep third-party libraries to a minimum. It can't be completely avoided, but any added dependencies should serve an important purpose and be chosen carefully. I won't be pulling in entire packages when I only need a few functions. This will aid in overall simplicity, transparency, and performance.

It's an engine for programmers. It's not a drag-and-drop game creation tool. There are plenty of tools out there for that. While some of them are pretty slick, that's just not how I want to make games. I build software every day by writing code and I view the games I want to develop the same way. After all, games are just software, so why would I develop them any differently?

My hope is that programmers of any discipline will be able to use Siren to apply their existing skills towards developing games. Every feature and API is designed with the mentality that the end user is another programmer. This means building APIs that are simple, but robust. Setting up Siren and integrating it with other projects should be trivial. Developers should be free to work with their own development pipeline, rather than Siren dictating that for them.

Why make a game engine? Just use Unreal or Unity!

No. I'd rather make my own.

In game dev circles, you'll often hear people say, "If you want to make a game, don't make an engine." I completely understand that sentiment, and for most people looking to make a game, it's solid advice. But I don't want to just make games; I want to make games with my own code on the backend! But maybe I'm crazy - after all, I did have to take a break from Siren to create my own CMS before I could start this site. Now I'm not knocking those existing tools. Obviously, they're used to create incredible things (way beyond what I'll be able to do, admittedly.) It's just not how I want to build things.

Building my own engine will also offer me absolute freedom. I won't rely on someone else to implement a feature I need. I won't have to worry about an update suddenly breaking my game. There won't be any licensing issues and fees to worry about. I'm free from all of that, at the expense of having to write a lot of code.

Let's say I scrap Siren and decide to make a game in Unirealty. I'll need to implement a specific feature, and since I'd be working with a mostly black box, I'll end up turning to google for answers. This will result in multiple conflicting solutions on how to do the thing. I try one and end up with a cryptic error. I try something else and find that it only works on an older version of the tool. Eventually, I get something that works, but then it mysteriously breaks one day after an update. No thanks. I'd rather be in a position where I can just code my way to whatever solution I need. Games are complicated and I'd much rather have full control and understanding of what all is happening under the hood.

Technical Goals

As I said, I don't want to just make an engine, I want to make games with my engine. I'm not ready to announce what any of those will be (far from it.) But I'm using those games/ideas to drive the features needed for a 1.0 release. I can look at those projects and know when/if I'll need specific high level features like tilemaps, parallax scrolling, or simple physics. There's an infinite number of features and systems that could be implemented in an engine. Without a subset of features in mind, this whole project could easily spiral out of control.

There's a lot of thinking in code happening while I iron out a solid architecture. With each feature of the engine, there's a lot to consider. Since my target audience is other programmers, I need to keep in mind the cleanliness and ease-of-use for every API. But I need to balance that with keeping everything flexible enough that a developer can make any kind of game they want. This results in a lot of temporary code while I figure out an ideal workflow. I'm not comfortable sharing the project in this state, hence not releasing the source yet.

Now let's talk about portability. At the bare minimum, I'm targeting Windows, Mac, and Linux. I'm planning to also support mobile, but it's just not a high priority. Eventually porting to consoles would be a dream. But I'm nowhere near being in a position to tackle that right now. I don't intend to target the web, but it's a possibility, so we'll see.

To achieve portability, including for the platforms I'm not supporting yet, I'm trying to maintain a thin platform layer. Any OS-specific code belongs in that layer and nowhere else. Then the engine can communicate with that layer through an API and not really have to know anything about platform-specific details. This is pretty straightforward when dealing with Windows, Mac, and Linux. Mobile will be a little more work just by nature of how you interact with the device. But it should be feasible.

Where do we go from here?

I've got my work cut out for me. Building an engine is no easy task, and Siren's not even my only project (more on that later.) But as I make progress, I'll be keeping this updated. In my next post, I'll be discussing some high-level architecture and design patterns. We're gonna start getting technical and I hope you'll stick around for it!