Is it cheating to use a game engine?

There's a common view held by many developers that using a third-party game engine to make games is a kind of cheating; that it's like using a calculator in a mental arithmetic exam. This view is most strongly and openly expressed by students and newcomers to the industry, but it can also be found in subtler and implied forms by very experienced developers too, in both what they say and do. My purpose here is to examine the root cause underlying this view, and to see what may be said in response. In doing this, my purpose isn't to reach a definitive answer that'll satisfy everybody, but to list some compelling reasons against the view. It's my hope that I'll offer reassurance to those who genuinely feel they may be cheating, just because they use a game engine. Before proceeding, I'll clarify what I mean by 'Game Engine'. Specifically, I'm referring to any third-party software or service intended to make development easier by abstracting from lower-level APIs and tools, to offer a more user-friendly experience with mouse-driven GUI interfaces, visual-scripting editors, animation editors, drag-and-drop functionality, and other level-editing features. In addition, such engines often include pre-coded script files from which users derive and build new features without even needing to fully understand what the original code base does. Among this group of programs I include tools already popular in the industry today, in no particular order: Unity, UDK, CryEngine, Torque, Shiva, Godot, Flash, GameMaker Studio, RPG Maker, Multimedia Fusion, Construct2, Stencyl, Blender Game Engine, GameSalad, and others.

The engine itself is not the main issue, however. It's how the engine makes you feel and the regard that using it has among peers. The point is: there are some tools available for game development whose use many regard as just cheating, plain and simple. The idea, I believe, is that when using those tools, you're not doing proper development; you're simply engaging in unprofessional pretence. True, you may make a professional looking game with the tools, and you may even fool gamers into thinking you're a bonafide developer. But, in the last analysis, you won't fool other developers, because they'll somehow know you really cheated by using an engine for your game, avoiding the real and hard work.

Now, in much of this, there's a preoccupation with self-identity; with how other people think of you. This arises perhaps from insecurity about whether you're being regarded as a full member of the games industry. You worry that, by choosing an engine, other developers won't really take you as seriously as you think you should be taken. But, putting aside these external judgements, there are also developers who are uncomfortable with themselves, because they can't shake off the intuition that a game engine is really just a means of cheating- a kind of laziness keeping them removed from true game development work. For them, the question arises not because of identity so much as a desire for truth, to know once and for all: is this cheating?

It's not difficult today to find expressions of this concern on the internet, and beyond. Sometimes you'll hear it directly in online forums through user questions or advice: “Don't bother learning any engine. Just learn real game programming technologies, like C++, OpenGL and DirectX!”. Other times it's expressed more subtly, for example: “We took the most professional approach a studio could take: we built an engine and tools from the ground up”. These expressions, and others like them, produce a feeling that engine use mitigates your achievements, making you a cheater. This flows from a belief that engine use is just piggy-backing on a substantial foundation of work created earlier by somebody else- namely, the engine developer. Such work includes: render systems, light-mapping systems, baking functionality, and physics calculations as well as others. When using the engine, the so-called game developer may apply some, or all, these features to make games they claim as their own, and yet have no deeper understanding about the code at the foundation. The feeling is that this reliance on others to do your work amounts to cheating. So what can be said in reply? I think there are five main arguments to be offered that counter the accusation. I'll list them individually, giving each a name. It also seems that each follows from the previous, connected by a chain of reasoning, perhaps in some imprecise way. It may be that none of the arguments alone are entirely persuasive. Yet, taken together, something compelling emerges.

#1. The “Who cares, anyway?” Argument

This isn't so much a reason or argument as merely an avoidance tactic, refusing to acknowledge the issue at all. This response says “Hey. Maybe using an engine is cheating, after all. I don't know. But I don't care. I just want to make games and get on with it”. This approach may be emotionally compelling, but it doesn't appeal to reason or to anybody interested in reasons. Consequently, it's the kind of sermon appealing only to the converted. Either you feel this way, or you don't. And if you don't, the feeling of cheating won't go away, no matter how often you say 'Who cares?'

#2. The 'No Rules' Argument

The second argument takes a logical step 'forwards'. It reasons: Cheating is about breaking rules. This means cheating depends on their being established rules to break. But, it turns out that, in game development, there are no such rules. And so there can't be cheating. In consequence, engine-use can't be cheating either. Now, I doubt this argument will persuade many, though its logic seems infallible. There's something too abstract and formal about it. Its strength seems to rest in word-juggling and rationalization. There might be something true at its core, struggling to come through. But its abstractness fails to impress.

#3. The 'Consequences Matter' Argument

More compellingly, the third argument focuses on the consequences of engine use in game development, using that as a justification for the means. This argument encourages us to behold the variety of games on offer today, seeing the many gamers enjoying them who are totally untroubled by whether a third-party engine was used in their development. It reminds us that a crucial motivation for making games is to produce fun and entertaining experiences, and that it's this that gamers really value. For gamers, the question is whether the game will be enjoyable, and not whether an engine was involved. A game made with or without a third-party engine may be fun in either case. So if engine-use doesn't bother gamers, and if games can be made fun in any case, then it doesn't matter whether you use a third-party engine. It's not about cheating. It's about making enjoyable games.

#4. The 'Absurd Consequences' Argument

This argument starts with a thought-experiment and encourages us to think about consistency. Let's say, for argument sake, that we stop using engines because they really are cheating. Now, if we do this and want to be consistent in our lives, we should apply such logic everywhere else too. But impractical absurdity results from this. The argument continues 'So engines are cheating, eh? They make our lives easier. They do a lot of hard work for us. And that's cheating? OK. Let's stop using engines then! But, we must also stop using cars. They too make our lives easier and rest on the work of others. Oh, and let's stop using calculators, and clothes, and computers, and televisions, and radios, and trains and aeroplanes, and everything else useful, and for the same reasons'. This argument is powerful in many respects, not least because it reminds us of the heavy reliance we have on the work of others everywhere in our daily lives. It helps us see the connectivity in all things, as well as our dependence on foundations laid by others who came before. This argument shows us that, if engine use really is cheating, it can't simply be because our work would depend on others. For if that were true, then everything would be cheating. And if everything were cheating, there'd be no point in calling anything cheating.

#5. The 'Infinite Regression' Argument

The final argument is connected and allied to the previous. Both begin by accepting engines as cheating and then demand we follow that acceptance wherever it leads. But whereas the previous argument found the idea leading to absurdity, this argument sees it leading to nowhere. For argument’s sake it says: OK, let's abandon engine use as cheating just because it would depend on foundations laid by others. Thus, to be entitled to use an engine without the charge of cheating, then, we must first take a step back and become an engine developer ourselves, capable of understanding all technical considerations attendant to engines. Only then may we become a legitimate engine user. But, the argument continues, we must understand that even an engine developer will be a cheater, if they've not first been a computer scientist with mastery over low-machine code and binary systems on which all engines are inevitably founded. And the computer scientist will also be a cheater, if they've not formerly been a hardware specialist intimately familiar with electrical impulses and micro-chip internals. And the hardware specialist too shall be a cheater if he's not already gotten to grips with Quantum Mechanics and the laws of the universe making electrical interactions possible at all. And so this argument repeats infinitely, leading us into nowhere, it seems. And in this nowhere place there's the inclination to shrug our shoulders. We've been humbled before the expansiveness of the universe, left wondering whether there's really anybody out there who isn't a cheater. This argument helps remind us that if using an engine needs any justification at all, it can't be by simply appealing to antecedent knowledge in this way. It tells us that, if we're to be game developers, the journey has to start somewhere with a foundation that's taken as given and is not itself questioned or interrogated.

Together these five arguments provide impetus to move us in one of two possible directions, both of which permit third-party engine use for game development. Either we move further from the idea that engines are cheating, or else we widen the scope of cheating, if we follow the consequences where they lead. Either engine use is not cheating, or nearly everything is cheating, and so it cannot matter anyway. But in both cases, all the arguments seem to lead emotionally back to the first argument, which appeared initially to be the weakest of all.