re: Publisher Denied My Game Because of Custom C++ Engine VIEW POST


It might be worth building an "engine inside an engine" for other projects if this is a risk, for example a highly customized system within Unreal where C++ can drop right in.

Instead of writing for Vulcan, OpenGL, or DirectX, why not target Unreal (C++) or Unity (C#)? It's an extra layer of abstraction, sure, but as you point out, it does provide a sort of insurance when shopping it to publishers who are risk averse. Porting to iOS and Metal, for example, may not be an easy task, or it might be a breeze, but the fact that it could get ugly is going to give publishers pause for concern.

As an indie developer you could license your engine for other developers to build on as well through things like the asset store, perhaps creating an additional revenue source. Based on the types of things in the store and their popularity, I wouldn't be surprised if some developers make enough money building tools for other devs they don't even need to build games of their own.


I'll answer this for the OP as someone that has worked on game engines for over a decade. One reason is that Unreal and Unity are awful engines. Bad code, bad performance, bad workflows, bad design. Having worked with both, and needed to customize/modify both heavily, it's amazing how bad code can get if the provider of the code isn't dogfooding their own stuff. Unity doesn't ship a game at all, and if you rely on an Unreal feature that isn't needed by Fortnite, good luck.


As much as all that may be true by various definitions of "bad" it's still a lot easier to trust Unreal or Unity, which thousands of people have shipped games with, than some homebrew engine that nobody's heard of.

You need to pick your poison. Are you going to battle Unreal quirks and bugs but at least get portability, or are you going to battle OpenGL, Vulcan, Metal and DirectX directly? These are pretty "bad", too, because their implementations vary so much from one OS to another, even one version of one OS to another. Then you need to deal with audio, game input, and dozens of other things that are equally quirky and broken.

I've known a number of people that have shipped with Unity, Unreal and Game Maker Studio. Most people that embark on building their own engine never ship a game because it's a very deep rabbit hole to fall into and one with no bottom.

It's really a matter of how "indie" you want to be. Overgrowth managed to ship with a custom engine despite the odds, but wow, was that ever an undertaking.

I've been pretty involved in just about every layer of the stack. I cut my teeth on graphics (and still do graphics) but I've had to deal with networking, input, audio, and gameplay/scripting code as well.

Platform support is likely the most expensive to do right, but I would argue supporting say 2*n engineers per platform is actually cheaper than needing to rewrite huge chunks of Unreal or Unity. I can honestly say with confidence that no AAA game has shipped on Unreal without needing substantial rewrite of various internals. I've consulted on several Unity projects, and it's an actual dumpster fire :/. I've heard that Unity's valuation is driven by cloud service offerings and the ad network they've spun up. It shows in the quality of the code and the investment. That said, frameworks like SDL2 have come a long way in democratizing the platform-dependent bits of code that used to be insanely hard to get right.

I really do believe a better option "should" exist for developers that want to make the game and not the engine, but I sort of lean towards building an engine (leveraging open source frameworks wherever possible) for more "serious" studios that need to maintain their game for several iterations.

It's "Vulkan" btw :) Also grats on shipping!


This is definitely an option, and I am remaining open to the idea of using a commercial engine for my adventure should that be the only option remaining, but I thoroughly believe I am doing the right thing, for me, by writing my own tech. I enjoy the path, and while this is a business, and costly to make my own tech, it is an interest of mine - need to remain interested in the long-term.

One issue nobody really talks about when using dependencies is the fact that you now depend on that technology. Sometimes this is truly fine, and adds no cost. And sometimes it could be that choices of other entities that destroy everything because of that dependency. It obviously comes with benefits too, so weigh your options.


There's certainly a craft in building something like this, but there's also two kinds of "tech" here: The kind that makes your game/engine unique, and the kind that does the same thing everyone else does like put triangles on the screen, take input, and play noises.

It's important to be able to focus on the first without getting mired in the second. Hope you've been able to strike a good balance there.

code of conduct - report abuse