Accidentally making a language, for an engine, for a game

You say that like it is a bad thing. By (nearly) all accounts Braid and The Witness are lovingly and expertly crafted, unconventional, and brilliant games. He's not making the annual Madden or Call of Battlefield here.

> Casey Muratori, who started handmade hero almost 8 years ago, and is nowhere even close to a game

Be fair to Casey, Handmade Hero is primarily an educational project and he only devotes a few hours to it each week. Though admittedly he has allowed the scope to creep quite a bit from the original goals.

> The post we're commenting on here is entitled "Accidentally Making a Language, for an Engine, for a Game". If your take away from those things is that "you'll spend more time fighting the engine" then I don't really know what else to say.

My point is more that I'm kind of sick of people being so down on the concept of building your own engine even for relatively simple 2D games. Yes, I agree that it takes time, but so does learning the ins and outs of an existing engine and the time you invest in the latter nets you less generalizable skills than the former and leaves you with less control over the end product. It is a tradeoff, and like all tradeoffs there are good reasons to go one way or another.

But as a practical matter, using Unreal turns every decision you make from "what behavior do I want" into "what behavior do I want and is it worth fighting Unreal on this", so Unreal games are a lot more Unreal-y than they otherwise would be. (This is especially true on PC, where things like "how are the game assets organized on disk" are visible to end-users.)

Particularly on the 2D hobbyist stuff that I do, writing my own engine is less work than becoming an expert in an engine I don't really like so I can change most of it.

I don't agree with this at all - Unreal gives you defaults that can be easily replaced. The decision is "do I use what unreal gives me or do I write my own" for most systems, compared to "do I write my own or do without" if you're starting from scratch.

> so theoretically if you use Unreal your game could be any legal C++ program.

That's a bit reductionist, and not really fair. All of the "behavioural" parts of the engine are exposed in very customisable ways. As an example if you're not happy with the collision detection behaviour/triggers, they are designed to be modified and changed around. If you're not happy with character movement, you provide your own character movement definitions.

> (This is especially true on PC, where things like "how are the game assets organized on disk" are visible to end-users

If your definition of end user experience of a game is file layout on disk, then so be it. Knowing that something is made with unreal engine doesn't immediately turn it into another copycat unreal engine project. Besides looking at the disk layout, you could also just see the splash screen that you're legally required to use when licensing the engine. Also, you have source code to the engine, to the automation process, and the pak tools. If you want a different layout on disk, go ahead and change it.

> Particularly on the 2D hobbyist stuff that I do

If you want to do hobbyist engine development work, _that's_ a great reason to write game engines. Not "liking" an engine and wanting things done differently isn't the same as wanting something that's incompatible with a game engine's design and architecture. If you want a lock step multiplayer game with rollback then sure, you're probably not going to find it. But if you want "less floaty" character physics, or a different camera perspective, a different startup flow/implemention, you can _definitely make that within the bounds of Unity and Unreal

> writing my own engine is less work than becoming an expert in an engine I don't really like so I can change most of it.

You definitely don't _need_ to be an expert in an engine to use it, any more than you need to be an expert in python to start writing some scripts. Also, how can you know how much of the engine you need to throw out before you actually know how to use it?

Which is to say: sometimes, if you build a low-level library/infrastructure service and release it, someone else will take advantage of it to write the high-level thing you were originally aiming to create.

I'm speaking from experience — my company's DBaaS is built on the premise of just building a really good database domain-model to hold a certain type of large, public-available datasets, for efficient, flexible querying of them; loading those datasets into it; and then giving people access to it (through SQL or various use-case-shaped APIs.) It's a really thorough yak-shave of the DB+ETL layer of what was originally planned to be a higher-level B2C product.

But it turns out I have a pretty unique view of what should be considered "fun", because my yak-shave was everyone else's schlep. Everyone turned out to be dying to get their hands on this thing, because they wanted to spend all their time on a product, rather than getting good data to feed their product. Once we realized that, we stopped trying to build a B2C product at all, and just started selling the yak wool directly.

I'm glad he's having fun, too :)