If you intend to sell and make money by making games, you know that writing your own engine will take a lot of time. However you may not be aware that writing your own technologies can also cost opportunities and partnerships. You will need to keep that in mind as well. This is my story on how I learned that lesson the hard way:
Note: I went into the publisher search just checking out what opportunities may exist as my game development stream viewers were pushing me to try.
The Pitch
In September 2019 I prepared Turbo Boom! to be pitched to several publishers. After spending many days polishing and tweaking that content, I sent 25-30 emails. The publishers that received this email were chosen based on their interest in racing games, or action based games that are similar enough to Turbo Boom! Throughout October the responses came back, most of which included, “unfortunately not a fit at this time” along with enough information to show they took my pitch seriously.
One publisher even asked more questions about targeting mobile platforms after initial desktop launch. I knew discussing how my custom C++ engine did not support mobile at this moment would be a ding. So I let the publisher know that mobile wasn’t supported and included a realistic estimation of how long it would take to add that support. I was very confident in this estimate as my engine has been partially working on iOS for some time.
They took that answer well enough, and went to review it with the rest of their team for a week or two. Unfortunately the next response was them letting off the hook with a not so subtle hint to the reason being my custom engine and the risk it added.
It makes sense.
A custom engine has a lot more unknowns, especially to publishers who are not typically developers. Based on the response had a major engine (Unity, Unreal) been used, “that just works” in the eyes of non-developers, my game may have had a publisher. But that is okay, I like doing things my way. It is just a lesson learned that the custom engine can also cost opportunities based on the perceived, and actual, additional risk that is increased with custom technologies.
As an indie developer taking a look at things from a business perspective is important and I already knew custom engine development was time consuming, costly and adding risk. It wasn’t until this response that I became aware that risk extends to opportunities and partnerships. Others pursuing similar paths should be aware of this.
Top comments (15)
I was thinking that maybe creating your own engine makes it difficult for other developers to keep the work later? Since it will probably not be (only) you who will maintain the code, this may be something they will consider before decide to publish your game.
The company also asked about a mobile version, and after watching a video on your site, i agree with them. This game would be great on mobile as well. Of course, this require expanding the engine to mobile platforms, and this will require a lot of time,effort, trial & error, bugs,etc..
Wish you luck in this journey!
Yea I've been aware the game is looking like a great fit for mobile and am very open to it. The porting wouldn't take ages but it also wouldn't be done next week.
Licensing is one thing I never considered. Nor did I get far enough in discussions to start considering it. I was/am assuming that as long as I retain IP I also retain code licenses, which is certainly a desire of mine, though I could see a publisher wanting some of that pie as well... making it super complicated. I have to assume they could be licensed that specific edition while I retain rights to the engine for future projects, but ... yikes, never considered that either!
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.
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.
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.
Custom game engines are a turn off to a lot of publishers because of a simple reason: broadening the target market is way more expensive.
Publishers often have deals with porting companies to quickly port a game to a different platform. If the engine is not known to these companies, the publisher will have to pay you to do the porting.
Porting to extremely closed platforms, like consoles, is even more expensive when you can’t use a company that already has the DEV license, gear and skills. Skills includes getting through certification.
There are also people/companies out there who are skilled in porting custom engines. But these are not the cheapest available to publishers. In the end for a lot of publishers it is just the decision on how little they want to invest in earning money. These publishers mostly skip on the next big hit, because they think it’s too risky, and rather play it safe.
But there are publishers out there who are not just looking at making a quick buck.
Either way, creating your own game engine, especially if you also avoid frameworks like SDL, is something you should only do when you want to create a game engine. There is a lot of time and risk involved when you just want to create a game.
This is exactly what I was going for, I did do an extremely poor job of explaining the various risks and "why it made sense" from the business standpoint, something I have since learned and hope future articles will include the why a little bit better. Well explained, though I disagree about the final comment that creating a engine should be done only to create an engine... Doing so definitely adds time, is more risky and has potential impact on partnerships - which is what I was trying to share.
Probably poorly worded. I did not mean to imply that you should only create a game engine when your only result would be the game engine, and not a game. You should only create a game engine, when you actually want to create an engine, and not "just" a game. Note sure if that makes it any more clear :)
10+ years ago you did not have a lot of choice when you wanted to create a game, and did not have a lot of money to buy an full fledged game engine. But these days there are really good F(L)OSS and cheap game engines to get you started in game development.
So unless you want to take the hurdles, and experience what it takes to create a game engine, you probably want to get something off the shelf.
But if you want to take the challenge, I recommend to use SDL as much as possible as it takes care of a lot of mundane and finicky low-level platform parts. That way you can focus on the engine technology, and not crack your head on trying to process input from keyboards or controllers (for example).
Uhm, its 2019....
Why do you need a publisher?
If this is a pc game you pay 100.00 to release it on steam and they take 30% of your sales done... they handle credit cards and all that other stuff...
That 30% is more then just their cut.
You still need to submit to itunes if it's a mac game..
If you do release on android you can submit it to the play store.
Besides that you can release on itch.io....
But honestly do you want to make a game or a game engine cause you aren't going to do both..
The only reason you could need a publisher is because you're trying to get them to pay for you to sit around making a game...and in this case a game engine too, in which case you probably aren't going to give them a cut if it becomes the next torque3d... sure they can take some tribes money but anyone with a brain knows they are funding both the game and engine development.
I don't NEED one, but it can make sense for the right fit. Publishers have contacts they can leverage, make it easier to get press, better at marketing and promoting and find players. I am great as a developer, but I am not great at these things. I also understand that a piece of a large pie is better than all of a tiny pie. Selling a game involves more than paying $100 to steam or making an itch.io page, it involves bringing in players.
And I am doing both, you can do both it is more time consuming, and as discussed in the article- has potential impact on partnerships.
The problem is the custom engine make it hard to update because you are the only person who can troubleshoot it.
Big companies can do this because they have big staffs behind, so the 1 person fixer is not a problem.
This is great for applying to a job and putting in your resume.
Indeed that is a valid part of the risk they are assessing among many other factors.
Yaps you find everything on dev.to, thanks for writing this up!