What is a game engine?
Nowadays, the underlying source code of a video game is rarely developed from scratch. Modern video games usually rely on middleware. Game engines are such middleware pieces.
A game engine can be defined as a platform and framework for game development. In the realm of software development, the notion of a “platform” was touched upon by the US Supreme Court in its famous decision from 2021 that put an end to the legal battle between Google and Oracle. In particular, the Supreme Court likened the concept of a platform to a factory floor where workers come, use the available tools and work on their creations.
In exactly the same way, a game engine can be described as a development environment and a suite of tools that game developers can use in the process of creating a computer game. With a certain risk of oversimplification, an engine can be likened to a computer program that you can use in order to build computer games. Or if you prefer a more dynamic metaphor, the game engine is like a basic auto chassis that is shared by many different car models and car manufacturers.
Back in the 1970s and early 1980s, every new computer game had to be developed from scratch. In the following decades, in order to save time and effort and optimize efficiency, the functionality presented by a game engine gradually started to gain relevance. What a game engine was able to provide was a significant logistical shortcut. In particular, portions of the code responsible for certain general functions did not need to be written every single time when a new game was to be constructed but could be simply reused.
Quite prominent during the 1990s and early 2000s were the game engines behind the then popular first person shooter games such as Quake and Doom (id Tech engine), Unreal Tournament (Unreal engine) and Half-Life (Source engine). Some of those frameworks are still relevant nowadays and continue to have strong market presence in their respective current versions – Unreal Engine 5 and id Tech 7.
The core functionality that a game engine realizes is data transmission and transformation. Put simply, it takes existing external data input, then transforms it so that it can be visualized on the computer screen and further interacted with in a user-friendly manner. This external data can include video files, image files, audio files, etc. which come in certain digital formats that are supported by the game engine so that they can be read and the data processed. This allows the game developers to actually import all these external assets into the game world and then use them in order to shape the specific gameplay, game environment and user experience.
Another useful function that game engines as a framework provide is “platform abstraction”. This denotes a principle where all platform specific details can be abstracted away so that game developers are able to focus on writing code that is generalized for all platforms. This makes it a lot easier to apply the necessary tweaks later for the game to be ported out to other platforms (for example, from PC to various game consoles or mobile devices) without having to re-write the entire source code of the game.
It has to be noted that some game engines are used by game companies strictly as internal proprietary tools and they are never brought to the market or shared with competitors. It is needless to say that in such a scenario the code of the engine would be strictly protected as a highly valuable trade secret. At the same time, other engines are commercialized and licensed as COTS (commercial off-the-shelf) products so that other companies, even competitors, can also build games using the same engine in exchange for a license fee or under a subscription model. This business model based on royalties has proven to be quite profitable for the licensors.
What are the key components of a game engine?
A game engine typically includes multiple modules and functionalities such as a graphics (rendering) engine, audio engine, physics engine, AI, networking, input, etc.
The graphics engine is responsible for the rendering of 2D images into 3D visual models, the display of textures, animations and all assets that are used to create the characters, the in-game objects and the entire visual game environment. It is exactly the graphical appearance that is often the most important factor that determines the success of a video game.
In turn, the audio engine takes care of what audio and sound effects are played and when exactly they are played during the interaction of the player with the in-game environment. It is also responsible for the incorporation of music into the video game as many games even end up having their own soundtracks.
The physics engine recreates the natural laws of physics from the real word into the game environment – for example – gravity, collision dynamics, light reflection, diffusion, etc.
Game engines also come with networking frameworks that allow for the realization of multiplayer and online social gaming. In particular, it is ensured that the same game state is retained by all players involved despite them running different hardware and using internet connections with different characteristics.
AI and scripting also play a key role in game engines. They are very useful when it comes to the automation of the behavior of NPCs (non-player characters) and enemies in the game.
Finally, input functionalities take care of the capturing of input events from a keyboard, a mouse, a joystick controller or a touch screen. Then, they trigger corresponding game actions such as running, crouching or jumping that are tied to a specific button on a keyboard or a controller.
Copyright protection of a game engine
At its core, a game engine is a piece of computer code. As such, it naturally attracts IP protection under the copyright regime. The only applicable requirement for protection under copyright would be the originality of the code, which in reality is not a high threshold.
Under the EU legal regime, the source code, the object code and the preparatory design materials of a game engine will all be protected expressions of the software work. This is intuitive for source code which is expressed in human readable programming language and could be equated to a literary work.
When it comes to object code, it has to be mentioned that it is compiled from source code and can also be decompiled back into source code. Both appearances of the program – human-readable in source code and machine-readable in object code – are given equal legal protection. We can see this explicitly postulated by the TRIPS Agreement (Agreement on Trade-Related Aspects of Intellectual Property Rights). Article 10, paragraph 1, TRIPS reads that “computer programs, whether in source or object code, shall be protected as literary works under the Berne Convention (1971)”. Finally, under the EU Software Directive (Directive 2009/24/EC), preparatory design materials are also included in the scope of copyright protection to the extent that the nature of those works is such that a piece of software can result from them at a later stage.
In the above scenario, source code and object code can be classified as literal expressions of the game engine. In addition to those literal expressions, a game engine might also present certain non-literal expressions such as the overall structure, sequence and organization of the code. The internal architecture of the software work might reflect the separate modules, their hierarchy and their interactions. It is important to note that such non-literal expressions of a game engine could also be protected under copyright.
Interesting guidance in view of the question of copyright protection for non-literal expressions of a computer program was provided by the U.S. Court of Appeals for the Second Circuit in the case Computer Associates International, Inc. v. Altai, Inc., 982 F.2d (2d Cir. 1992). Such guidance may also be applicable for a game engine as it is also at its core a piece of code. In this case, the court clarified that the structure of a computer program contains non-literal components such as general flow charts, inter-modular relationships, parameter lists and macros. Therefore, if these non-literal components of an original program are substantially similar in a second program, a case for copyright infringement may arise in the form of non-literal copying.
The legal battle between Silicon Knights and Epic Games
Inevitably, all video games that use the same engine will share a certain portion of their source code. This may create a risk of copyright infringements depending on the specifics of the licensing arrangements between licensors and licensees and the particular game development practices involved. One such case was the contractual relationship and the ensuing lawsuit involving Silicon Knights and Epic Games before the U.S. District Court for the Eastern District of North Carolina.
Silicon Knights (SK) and Epic Games (Epic) were both involved in the business of game development. In 2007 Silicon Knights initiated a lawsuit against Epic Games alleging breach of contract and fraud in relation to a licensing agreement between the parties for the Unreal Engine 3 owned by Epic. In particular, SK was alleging that Epic failed in the provision of a properly working game engine and also did not offer reasonable support to SK. In turn, Epic filed a counterclaim alleging that SK used Unreal Engine 3 in violation of the license agreement and also purported copyright infringement and misappropriation of trade secrets.
Silicon Knights argued that Epic made false oral representations about the functionality of the Unreal Engine 3, which SK licensed from Epic for the development of the game Too Human. However, the first instance court postulated that the parties entered into a written license agreement that explicitly disclaimed any warranty that the functions performed by the Unreal Engine 3 will meet the requirements of Silicone Knights. The provision in question also further disclaimed any and all other warranties, conditions or representations in view of the game engine or any part of it. Additionally, the court asserted that SK was aware that Unreal Engine was still a work in progress when the purported representations were made.
In its counterclaim Epic alleged that SK made unauthorized use of the game engine and infringed Epic’s IP rights by incorporating code from Unreal Engine 3 into its own game engine. Additionally, Epic purported that SK breached the licensing agreement when it used this derivative work in 2 computer games. In its defense SK argued that the copying was de minimis. However, it was established that over 20% of the code from Unreal Engine 3 was actually copied by SK. Further, it was postulated by the court that SK copied code from Unreal Engine 3 when it began development of the game The Box and this was a use which was not authorized under the licensing agreement between the parties.
Epic Games was ultimately successful in the legal battle between the parties and it won its counterclaim for 4.45 million dollars. Subsequently, the awarded amount doubled due to attorney’s fees, prejudgment interest and costs of the proceedings. Judge James Dever III stated in the judgement that Silicon Knights “deliberately and repeatedly copied thousands of lines of Epic Games’ copyrighted code, and then attempted to conceal its wrongdoing by removing Epic Games’ copyright notices and by disguising Epic Games’ copyrighted code as Silicon Knights’ own”. The judge stressed upon the fact that SK copied not only the functional code but also the internal comments which were left by Epic’s software engineers.
As a result of the judgement, SK was directed by the court to destroy all the code that was taken from Unreal Engine 3 and to ensure access to its servers to Epic so that it could verify the actual removal of the items in questions. Additionally, SK was also ordered to recall and destroy all copies of games which it built using Unreal Engine 3. In 2014, shortly after the judgement of the district court was affirmed on appeal, Silicon Knights filed for bankruptcy.
The ruling in this case highlights the importance of the scope of warranty provisions in software licensing agreements. As demonstrated, such clauses can have far-reaching consequences and shall never be overlooked during contract drafting or contract negotiations. In particular, when vendors are licensing a software product that is not yet fully complete, it is advisable for them to curtail the scope of the warranty provision so that it does result in unreasonable risk exposure.
You must be logged in to post a comment.