/developer|entrepreneur/i
Always looking for new developer talent, even those with zero experience, as you never know who's got the potential to become a great developer.
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.
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.
/developer|entrepreneur/i
Always looking for new developer talent, even those with zero experience, as you never know who's got the potential to become a great developer.
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.
/developer|entrepreneur/i
Always looking for new developer talent, even those with zero experience, as you never know who's got the potential to become a great developer.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.
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.
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.