Lights and Shadows of the "Stop Killing Games" Initiative

The Stop Killing Games initiative is a consumer movement launched in 2024 by YouTuber Ross Scott, known for his channel Accursed Farms, in response to the shutdown of the servers for The Crew, a Ubisoft video game that became unplayable due to its constant internet connection requirement, even in single-player mode. This sparked outrage, as the game, despite having multiplayer components, also included a single-player mode that did not inherently need an online connection. The initiative raises a crucial debate about digital ownership in an era where games are increasingly expensive (with prices reaching 80-100 euros) and rely on servers that can be shut down.

The Stop Killing Games Logo

Ross Scott released a video introducing the initiative and created a website (stopkillinggames.com) to collect signatures and promote government petitions in countries such as France, the UK, Canada, Australia, and the European Union.

In response to cases like this, the initiative demands the preservation of video games after their official support ends, protecting consumer rights and preventing purchased games from becoming inaccessible due to publishers' decisions. Its argument is rooted in opposing publishers selling games as temporary licenses rather than permanent products. It defends players' rights to enjoy what they paid for without time restrictions. Additionally, it claims video games as cultural heritage, comparing them to films or books that do not vanish after commercialization.

To this end, the initiative seeks legal protections for players against sudden server shutdowns that render games unplayable. It demands that games always include an offline mode, with single-player campaigns, so they do not rely on active servers, or that games allow users to create private servers to keep them alive when companies cease support.Since its launch, the initiative has garnered support from over 1.4 million signatories, media outlets, and content creators like PewDiePie, MoistCr1TiKaL, and Jacksepticeye. Even one of the European Parliament’s vice-presidents, Nicolae "Nicu" Ştefănuță, publicly endorsed the initiative and added his signature. While not decisive, given the size of the European Parliament, this support signals a growing trend to curb certain abusive practices.

Nicolae "Nicu" Ştefănuță, a vice-president of the European Parliament, publicly supported the initiative.

On the other side, major game developers, represented by the Video Games Europe lobby (including companies like EA, Ubisoft, and Activision), argue that the initiative’s proposals would make game development "prohibitively expensive" and maintain that players own revocable licenses, not the games themselves. Other voices in the gaming industry, such as streamer Pirate Software (Jason Thor Hall), have also criticized the initiative, claiming it is not viable for all games and could harm developers, leading to a public clash with Scott.

While publishers naturally defend their interests, some of their arguments have merit and deserve consideration to ensure well-intentioned initiatives do not harm indie studios or negatively impact the dynamic video game market.

For starters, the initiative oversimplifies by treating all video games the same, despite their diversity. A key distinction exists between games designed to run entirely on local resources (e.g., Half-Life: Alyx) and those reliant on online servers to manage game logic and player progress (e.g., Fortnite or World of Warcraft).

The initiative seems to overlook that redesigning a game built for online servers to work offline or on private servers is not always feasible. Online games often incorporate licensed elements on the server side (e.g., physics engines, matchmaking frameworks) that developers do not own and cannot redistribute without violating license terms. This is even clearer with audiovisual content, such as music licensed for use in Fortnite’s lobbies. If such content were redistributed to local game copies, the risk of uncontrolled distribution would skyrocket, prompting artists’ publishers to renegotiate rights. Alternatively, games could be distributed without licensed content, but this would contradict the initiative’s goal of preserving everything players paid for. Removing licensed functional elements could even render games inoperable. Additionally, computational power is a factor: maintaining the state and progression of an MMORPG requires significant processing, storage, and robust data networks, often relying on entire data centers. Replicating this in a user’s home is practically impossible.

Many online games run on complex data centers, impossible to replicate at home.

Then there’s the issue of time. Unlike films, which only require a compatible player, server-dependent games need ongoing, expert maintenance beyond the average person’s skills. Expecting users to maintain complex game servers at home is highly unrealistic.

Maintaining such complex infrastructure is beyond the average citizen’s capabilities.

While the initiative’s motivation is understandable, it overlooks practical challenges widely discussed in game development forums. However, this debate is healthy and may lead to a balanced solution. Some propose labeling games to warn consumers about external server dependency, enabling informed purchasing decisions.

Labeling as a Possible Solution

Others suggest a voluntary framework for developers, committing to design games with long-term preservation guarantees. For example, a first category could include games with limited offline modes using bots, specific maps, or local multiplayer; a second could involve partnerships with nonprofits to preserve games with security measures; a third could allow players to host local servers. Like labeling, these categories would be disclosed at purchase, letting buyers assess risks.

Voluntary Categorization as a Solution

While the initiative’s proposed regulations aim to protect consumers, they must be carefully crafted to avoid stifling the creativity and economic vitality of the video game industry. Conditions feasible for large studios could be prohibitive for small or indie developers, increasing costs and legal risks. Protecting consumers without harming small studios or limiting new game production is key. Legislators tackling this issue will need to navigate a delicate balance, requiring deep understanding of the complex and ever-changing video game market.

This initiative demands highly delicate legislative work.

Resources in Godot and the Risk of Sharing Them

In Godot, Resources are a type of object used to store and manage reusable data within a project. They are modular components that can be created, saved, loaded, and shared among different nodes or scenes within the engine. Resources are essential for organizing and structuring projects efficiently.

They are designed to store specific information, such as configurations, properties, or custom data, which can be accessed or modified by nodes or other systems. Resources can be saved as files (usually with the .tres extension for textual resources or .res for binary ones) and loaded into the project using ResourceLoader. This allows resources to be shared across scenes or even projects, as they are not tied to a specific scene and can be referenced by any node or script.

Advantages of using resources include:

• Modularity: Facilitates data reuse without duplication.
• Organization: Helps keep data separate from code or scenes.
• Flexibility: You can modify a resource and the changes will be reflected in all nodes that use it.

Godot comes with many predefined resources, but you can also create your own by extending the Resource class. For example, in a project I'm developing in Godot C#, I created the following resource:

Custom Resource Example in Godot C#

As you can see, it's straightforward. You just inherit from Resource and define the fields/properties you want the resource to have. What deserves special mention are the attributes.

As in any other Godot script, the [Export] attribute makes the decorated field editable in the inspector when the resource is used.

The [GlobalClass] attribute on line 7 is needed to make your custom resource available in the editor's search tool when you want to use it.

The [Tool] attribute is only necessary if you need to access the contents of your resources from code that runs in the editor (not just in the game).

This particular resource is used to create an array of them in another node and store links to other nodes present in the scene (that link is precisely the NodePath field). I could have added methods to the resource—nothing prevents you from doing so—for example, to validate the data stored in the resource, but in my case, it wasn’t necessary.

Example of Using My Custom Resource

When you click on each resource, it expands and you can view and edit its contents.

Editing Resource Contents

If you come from the Unity world, resources are equivalent to ScriptableObjects since they also allow saving their instances as assets in the project. 

They also fill the role of Unity’s serializable classes. Although Godot C# has access to C#’s [Serializable] attribute, unlike Unity, Godot cannot display them in the inspector. Therefore, the alternative is to create a class that inherits from Resource with the fields you would have put in the serialized class in Unity. I have a Unity version of the entire example above, and there I solved it by making WeightedBehavior a serializable class.

Resources are ubiquitous in Godot—you’ll find them everywhere. For example, whenever you want to use an Area2D node to create a detection area, that node requires attaching another node of type CollisionShape2D to define the boundaries of the detection area.

An Area2D Node Uses a CollisionShape2D Node to Define Its Area

Interestingly, you can’t define the shape of the CollisionShape2D until you create a new resource in its Shape field.

A CollisionShape2D Node with an Associated RectangleShape2D Resource

This reflects Godot’s obsession with separating responsibilities. In this case, the CollisionShape2D node simply implements functionality in an area, but the shape of that area is stored in a resource (in this case, RectangleShape2D). 

If you expand the combo box, you’ll see that RectangleShape2D is not the only resource you can associate with that field.

Different Resources That Can Be Associated with the Shape Field

If you’re familiar with Unity’s ScriptableObjects, you’ll intuit the usefulness of Godot’s resources. If not, you’ll realize it as you use the engine. Ultimately, you’ll likely model resources in your mind as “little boxes of data.”

One of the uses of these “little boxes” is that multiple nodes can read data from the same box instead of duplicating that data in each node. This is an efficiency measure that Godot follows by default, transparently to the user.

Usually, this is fine, but sometimes it can cause surprises if you’re not aware of this behavior. Here’s an example I just experienced firsthand.

In my project, I developed a cone sensor. It’s essentially a vision cone. The scene that makes up the sensor includes the following nodes:

Nodes That Make Up My Sensor

The earlier screenshots of CollisionShape2D were taken from this scene. 

The general functionality is that the definition of the cone’s range and angle parameters (defined from another node) causes the BoxRangeManager node to resize the CollisionShape2D so that only objects within its area are detected. Then, a finer filtering is done by angle and distance, but the first “coarse” filtering is whether the detected object is inside the box.

An Agent in My Project with the Sensor Added

In the screenshot above, the blue box is the area of the RectangleShape2D. With just one agent, everything worked perfectly. The problem started when I added a second agent with another cone sensor.

Example of a Problem When Instantiating Scenes with Resources

To my surprise, the respective RectangleShape2D resources (note the italics) insisted on having the same size. When I changed the dimensions in one agent, both areas adopted that agent’s dimensions. When I changed them in the other agent, both areas adopted the new dimensions.

It took me a while to realize the problem. The issue was that there weren’t two independent RectangleShape2D resources. Since RectangleShape2D is a resource, all sensor instances were using and modifying the same resource. Hence the italics earlier—there weren’t “respective” RectangleShape2D resources, but a single one shared by both agents’ sensors.

How Do You Fix This? Are We Doomed to Use a Single Sensor Instance? Obviously not, but the solution isn’t immediately obvious.

The key is to go back to the CollisionShape2D node’s configuration and click on the RectangleShape2D resource to configure it internally.

Internal Configuration of the RectangleShape2D Resource

Inside that configuration, the Size field is obvious and corresponds to the resource’s dimensions. The key field is within the Resource section and is called Local To Scene. By default, it’s unchecked, meaning all instances of the current scene will share this resource. In other cases, this configuration might be beneficial, but in my case, it caused the problem I just described.

Therefore, the solution was to check the Local To Scene field. Doing so causes each scene instance to create its own copy of the resource and work with it. After checking it and saving the scene, both agents correctly displayed their respective (now truly) RectangleShape2D configurations.

Problem Solved

So be careful when using resources in your Godot scenes. Keep in mind that Godot’s default behavior is to share resources among different scene instances. Therefore, if you detect a case where instances need to customize the resource’s values, you should anticipate problems and check the Local To Scene option so that each instance has its own copy of the resource.

I hope this article helps you avoid problems like the one I had.