"Democratization of game development", this is probably going to be one major milestone in the history of game development. One notable aspect of this phenomenon is how it shaped people's thinking of engine development. Two decades ago, developing a game implicitly meant building it all from the ground up. The concept of "game engine" didn't even exist in most people's heads. A little later and deciding a game project involved mostly picking an existing game's codebase to reuse. But it was not too long after when a wide range of options became available. I don't know if many remember names like Gamebryo, RenderWare, Torque, Ogre3D, GameMaker and 4A. But surely many more know about Quake3, The Source, Unreal and Frostbite. <rant>I claim that these engines became very prominent mostly because of the success of the games they powered and shipped. I also claim that this success lent other devs to believe that using the tech behind it will lock their own games for success too. After all, you will have access to all those buzz word features that get people excited, right?</rant>

But returning to the present day and gamedev democratization, for many, the process nowadays is pretty much pick Unity or Unreal and start rolling, and with hopefully not a lot of effort one can publish the game on all platforms those engines support. This leaves the urging question: do we just forget about engine development and leave it up to Unity Technologies and Epic?

I'll use the smartest answer in history: it depends!

Seriously, there is no answer that fits all. You'll need to hear people's stories and understand their context and their resources then reflect on that and see what makes sense for you. And I really encourage you to read more than just one, like here and here, and... the rest of this article 😊

INFramez Story

INFramez is a tiny studio of experienced and highly technical gamedevs that identifies its mentality with a 2-bullet moto:

• Don't take things for granted. Just because all people do the job a certain way doesn't mean we have to follow and do the same.
• Be practical and to the point. Tech must help us build our games effectively - not bend our games to fit the tech, nor build tech for the sake of building tech.

With that off the way, lets walk through the major reasons that drove our decision, hoping this would be of inspiration and help to your case.

A learning opportunity

I personally learned game programming by developing and evolving my own engine. I started 18 years ago and I still recommend this as the best way to become a good game programmer. That engine is what we are using until now in our projects. It is fascinating to see how it evolved from a basic DirectX3 sprite engine to a modern cross-platform 3D engine with a strong data processing pipeline and editing tools scalable for the most recent generations of gaming machines.

Knowledge is freedom

Having the knowledge to build tech by yourself unleashes you to do everything you can imagine. Or better said: "Dude it's code! We can do anything!"

You are not confined to the technical decisions of another team. Imagine having to bend an engine built for an FPS shooter to make a car racing game. For us this is key, as our projects never revolve around a single kind. We did 2D platformers, 3D RTS, FPS walkthroughs, and a 3D tube shooter game. We need to have the flexibility to easily shape the code to serve the game rather than retrofit a game to fit the engine.

On a similar wavelength, we also tend to do quite some R&D of new techniques, and having our own engine makes testing these ideas and employing them easier.

Workflow

Every team has its own way of working. With time, we have established a set of workflows and tools that maximize our efficiency. The last thing we need is an engine imposing certain pipeline decisions or software on us. For example, we use Autodesk Softimage and the dotXSI format to export everything we need to the engine. This includes lights, camera setups, NURBS curves, particle systems, animations, render trees plus any custom stuff we figure out for a project.

In other words, an in-house engine allows you to build the game the way you want rather than building it the way another team wants. <rant>Need I say how many despise Unreal3's binary package format for storing assets in the editor?</rant>

Identity

Only a few studios around the world nowdays own their tech. For us it is a source of pride to be able to build our games without being limited by the vision and production mechanisms of another third-party.

Often I read gamers' comments such as:

It's just another ******* Unity game.

This isn't fair, as there are great games made with Unity. But that's one of the costs of democratizing game dev. And this price is paid not just by the maker of that Unity game himself, but also by many other devs that get lost in the sea of daily game releases. To the point that one of the biggest challenges to a gamedev nowadays is getting visibility. <rant>Hence silly games surfacing just because they draw public attention even if in a negative way like [insert whatever Thing Simulator game name here.]</rant>

Software Quality

One thing I hate is to see code wasting CPU cycles or allocating memory at things that don't matter to my game. Our latest game Hyper Void ran with all of its bells and whistles on PS3 at 60FPS with 2xMSAA at full HD. Did that come easy? Of course not. The code was so focused to not waste a single cycle outside of real game work. All data structures were bulk serialized and emplaced in memory. And no editor-specific code executing at all. Such results could not be achieved without dedication, something no other team but you can do for your game.

Deep knowledge of the engine's code translates to less risk and faster bug fixes too. This is especially important if you are console-focused (like us) and once your game goes to 1st party submission; as these guys will report to you all bugs they find whether they are in your game's domain or the engine's domain.

Conclusion

I hope this has given you enough context of our case and how that led to our decision to use our own in-house engine rather than a 3rd-party solution. It surely has a bill to pay, but for us we see it mostly to our benefit. Use this as food for thought and to assure yourself of whichever decision you go with. And I wish you happy game programming.