DEV Community: GuardingPearSoftware

GuardingPearSoftware Obfuscator vs Obfuz

GuardingPearSoftware — Sat, 22 Aug 2026 11:20:24 +0000

Compiled Unity code is not a secret by default. Open the player with a .NET or IL2CPP dump tool and you can still read class names, walk through game systems, and copy strings.

When searching for Unity obfuscation tools, you might come across: Obfuz (an open-source Unity obfuscator from the HybridCLR / Code Philosophy circle) and also GuardingPearSoftware Obfuscator (a dedicated Unity asset with a Free tier and paid seats).

Both tools are built for Unity. They are not the same product. Obfuz is made mostly for teams that already live in HybridCLR or xLua hot update. GuardingPearSoftware Obfuscator is made for a normal player build, enterprise type-level renaming, and hardening and a vendor behind the package.

This comparison breaks down how both tools work, where their features differ, and which one fits your game development workflow.

Short answer

GuardingPearSoftware Obfuscator Pro costs $79.99 (one-time purchase). It includes symbol renaming, string obfuscation, fake code injection, method control flow, watermarks, and anti-tamper checks. It runs directly inside your Unity build pipeline and patches your game assets when it renames MonoBehaviour classes and other serialized types.

Obfuz is a free MIT plugin. HybridCLR docs point to it when hot-update code needs protection. The public list is long: symbols, constants, strings, control flow, call and expression obfuscation, a random encryption VM, polymorphic DLLs and watermarks. It is made to work with little config, but it does not rename MonoBehaviour type names. That is a Unity-safe default, and wanted.

In simple words:

Choose GuardingPearSoftware Obfuscator if you want plug and play, Unity type renaming with asset updates, and a publisher behind the asset.
Choose Obfuz if you need HybridCLR or xLua hot update, you want the source for free, and you are fine configuring a code-first plugin.

Many teams can use one or the other. A few high-risk hot-update games may later study both layers. Start with one pipeline.

Quick comparison

Topic	GuardingPearSoftware Obfuscator	Obfuz
Vendor	GuardingPearSoftware	Open-Source
Based in	Germany	China
License	Paid Asset Store seat (Free tier exists)	MIT, free
Price	$79.99 Pro	$0
Setup	Plug and play	Plug and play
MonoBehaviour class names	Renames and patches assets	Not supported
Hot update	General Unity builds	First-class HybridCLR and xLua
DOTS	Yes	Yes
Addressables	Yes	No
Control flow	Yes	Yes
Encryption VM	Not supported	Supported
Watermarks	Yes	Yes
Support	Phone, Email, Discord	GitHub, Discord, QQ, Email
Best fit	From Indie to Enterprise Studio	Teams that already use HybridCLR or want OSS

The table is simple on purpose. Obfuz wins on hardening techniques and hot-update depth. GuardingPearSoftware Obfuscator wins on Unity integration because of the obfuscated asset patching (what most unity scripts are).

What GuardingPearSoftware Obfuscator does

GuardingPearSoftware Obfuscator is a Unity cybersecurity asset. After you enable it, protection runs when you press Build. You do not export a DLL, open a second Windows GUI, then copy files back. The same hooks fire for a custom BuildPipeline.BuildPlayer script and for cloud builders that run a normal Unity player build.

The package can rename namespaces, classes, methods, fields, properties, and events. And also rename the Unity types that most tools skip: MonoBehaviour, ScriptableObject, and Playable classes. After the rename pass, it updates scenes, prefabs, and other assets that still store those names.

Unity stores a lot of meaning as text. A button in the Inspector may keep the method name it should call. An animation event may keep a string. A serialized field on a component keeps its field name. Addressable bundles can keep script references too. Obfuscator has compatibility settings for those cases: Inspector values, UnityEvents, animation events, reflection and coroutines, UI Toolkit, and Addressables.

It also hides strings, adds random fake code, and can suppress simple ILDasm inspection. Mono builds can get control flow and assembly signing. Standalone builds can get integrity checks. Watermarks are included to proof ownership. Mapping files stay available so crash logs are still readable after release. A Free tier exists if you want to test the pipeline first. MonoBehaviour and namespace renaming are Obfuscator Pro features.

The tool stays local. You do not send the game to a cloud protector. Because it runs inside Unity and Tuanjie, it works on any platform where those editors run, including Windows, macOS, and Linux build machines.

What Obfuz does

Obfuz is a Unity package, not a generic .NET GUI. HybridCLR's own docs say that among current open-source tools, only Obfuz is deeply tied to Unity and fully supports HybridCLR.

You install the package, mark assemblies, and generate secret key and VM files. That is simple for programmers. It is not the same as a one-click Asset Store product. HybridCLR workflows also need the obfuz4hybridclr extension, because the default HybridCLR generate steps do not expect obfuscated names.

Its public feature list is long:

Symbol obfuscation with rules and incremental builds
Constant, string, and array obfuscation
Evaluation-stack, expression, and call obfuscation
Control-flow flattening
A randomized encryption virtual machine
Static and dynamic decryption
Polymorphic / structurally random DLLs
Garbage code
Code watermarks
Unity 2019+, Tuanjie, Mono, and IL2CPP

Roadmap items they have stated in public docs include anti-dump, anti-debug, and fuller code virtualization.

The published feature list is closer to a commercial protector than to a rename-only tool. Free means you own the maintenance risk. There is no Asset Store seat and no publisher SLA.

Obfuz keeps MonoBehaviour type names because Unity looks those types up when it loads scenes and prefabs. It still obfuscates the code inside the class. That is a safe default. It also leaves the type name attackers search for first.

The biggest difference

Obfuz competes on hardening techniques and hot-update support. GuardingPearSoftware Obfuscator competes on Unity product workflow and type-level renaming.

If your live game loads HybridCLR DLLs after install, those DLLs are as readable as a Mono build. That is why Obfuz exists, and why HybridCLR recommends it.

If your game is a normal Unity player build (mobile, console, standalone) and you care about prefab-safe renaming plus a support channel, GuardingPearSoftware Obfuscator is the shorter path.

A virtualized or encrypted method is hard to read. A class that still says PlayerHealth on the prefab is still easy to find. GuardingPearSoftware Obfuscator attacks that second problem by renaming the type and updating the asset. Obfuz attacks the first problem and leaves the type name stable.

You can invent a two-layer pipeline. You also get two ways to break the build. Start with one tool. Add a second layer only if you have a clear extra threat, such as hot-update DLLs plus a store build.

Why Unity-aware renaming matters

Unity does not only compile C#. It also saves type names and member names inside assets. That is how the Inspector, scenes, and prefabs keep working after you close the Editor.

public class PlayerHealth : MonoBehaviour
{
    [SerializeField]
    private int maxHealth = 100;

    public void TakeDamage(int amount)
    {
        maxHealth -= amount;
    }
}

If a generic protector renames PlayerHealth or maxHealth, the prefab can lose the script or reset the value. If it leaves those names alone so the prefab stays valid, attackers still search for PlayerHealth and find the class.

Obfuz chooses the second path for type names and still hides the method body. GuardingPearSoftware Obfuscator is built for the first path. It can rename the class and the serialized field, then update the related assets so the GameObject still points at the new names.

Both answers are Unity-aware. They solve different parts of the same tradeoff.

Which one should you pick?

Pick GuardingPearSoftware Obfuscator if you want:

An Asset Store product with an enterprise vendor behind it
MonoBehaviour and ScriptableObject renaming with asset updates
Less time writing obfuscation rules
Regular updates
A normal player build, not a HybridCLR-first game

Pick Obfuz if you want:

Zero license cost
HybridCLR or xLua as a first-class target
A wide OSS protection set, including an encryption VM
Full source under MIT from day one

Final thoughts

Obfuz is the open-source Unity obfuscator to take seriously in 2026, especially if HybridCLR is already in the project.

GuardingPearSoftware Obfuscator is still the better everyday product for teams that want Unity type renaming, a simple build button and a enterpise cybersecurity vendor behind it.

Read more on my blog: www.guardingpearsoftware.com!

GuardingPearSoftware Obfuscator vs Beebyte

GuardingPearSoftware — Fri, 21 Aug 2026 14:20:40 +0000

A shipped Unity player still contains readable C#. If you skip protection, a common decompiler can list your types, follow combat or shop logic, and pull string literals out of the build.

For years, Unity developers typed "Beebyte" when they needed an obfuscator. It was the Asset Store default. Two Unity tools sit in that search path today: Beebyte Obfuscator (the older Asset Store package) and also GuardingPearSoftware Obfuscator (a dedicated Unity asset that still gets 2026 updates).

Both tools hide compiled game code inside the Unity build. They are not in the same place now. Beebyte taught the store what a Unity obfuscator looks like. But GuardingPearSoftware Obfuscator is now the tool to go which is actively updated, and available for the current Unity versions.

This comparison breaks down how both tools work, where their features differ, and which one fits a new project.

Short answer

GuardingPearSoftware Obfuscator Pro costs $79.99 (one-time purchase). It includes symbol renaming, string obfuscation, fake code injection, method control flow, and anti-tamper checks. It runs directly inside your Unity build pipeline and patches your game assets when it renames MonoBehaviour classes and other serialized types. A Free tier exists if you want to test the pipeline first.

Beebyte Obfuscator costed about $80, and was the best known Unity obfuscator from about 2015 to 2024. It did renaming, string hiding, and fake methods, and it understood many Unity "do not touch this" cases. It did not offer real control flow. Public listings now mark it deprecated. Compatibility notes limit it to selected 2021.3 and 2022.3 builds, and newer Unity versions should be treated as incompatible.

In simple words:

Choose GuardingPearSoftware Obfuscator if you ship on current Unity and want an asset that is still maintained.
Choose Beebyte only if you already own it and you are stuck on an old LTS that it still accepted.

For new projects, Beebyte is no longer the safe default.

Quick comparison

Topic	GuardingPearSoftware Obfuscator	Beebyte Obfuscator
Vendor	GuardingPearSoftware	Beebyte
Based in	Germany	United Kingdom
Status in 2026	Actively updated (2026.x)	Deprecated / maintenance only
Price	$79.99 one-time (Free tier available)	About $80 one-time
Unity workflow	Native build pipeline	Inspector settings, build-time
MonoBehaviour renaming	Yes, with asset patching	Limited after Unity 2018.2
Namespaces	Yes	Yes (remove / flatten)
Strings	Yes	Yes
Fake methods	Yes	Yes
Control flow	Yes (Mono builds)	No
Anti-tamper	Yes on Mono, integrity on standalone	No serious anti-tamper story
IL2CPP	Supported as a backend	Compatible on supported old LTS versions
Best fit	Current Unity games	Legacy projects that already bought it

The table is simple on purpose. Beebyte won on history and search. GuardingPearSoftware Obfuscator wins on current support, asset patching, and extra hardening.

What GuardingPearSoftware Obfuscator does

It also hides strings, adds random fake code, and can suppress simple ILDasm inspection. Mono builds can get control flow and assembly signing. Standalone builds can get integrity checks. Mapping files stay available so crash logs are still readable after release. MonoBehaviour and namespace renaming are Obfuscator Pro features.

What Beebyte does

Beebyte obfuscates compiled assemblies, not your source files. That part is the same idea as most Unity obfuscators. You set options in the Inspector, then the package rewrites names when you build.

Its known feature set:

Rename classes, methods, parameters, fields, properties, and events
Hide string literals
Add fake methods
Respect many Unity types that must keep their names
Work with assembly definition files
Support IL2CPP on the Unity versions it still listed

It was easy. That is why it won so many searches. The protection was also thin. Reverse-engineering writeups have said for years that Beebyte is mostly renaming plus junk methods. There is no control-flow layer and no packing or virtualization.

Beebyte also struggled with MonoBehaviour renaming on newer Unity. From 2018.2 onward, that feature was limited, especially outside some standalone cases. Public copies of the listing say only LTS Release 2022.3.29 and LTS Release 2021.3.38 were valid. Other versions, including newer LTS releases, should be considered incompatible.

Search is not the same as "best tool to buy today." The name still shows up first in a lot of old threads. The listing is deprecated, and the publisher is no longer an active Unity-store default.

The biggest difference

Beebyte won on history. GuardingPearSoftware Obfuscator wins on current Unity use.

If you start a Unity 6 or a current 2022 LTS project today, Beebyte's own compatibility notes are the problem. You also get only rename-and-junk protection. That was enough when few Unity teams used any obfuscator. It is a weak plan if you want more than shorter names.

GuardingPearSoftware Obfuscator still ships 2026 updates. It can rename Unity types and patch the assets that point at them. Mono builds can get control flow and anti-tamper. Addressables work is part of the product, not a forum workaround.

Price is close. Both sit around $80. The gap is maintenance and how far the rename pass can go without breaking scenes.

Why Unity-aware renaming matters

Unity does not only compile C#. It also saves type names and member names inside assets. That is how the Inspector, scenes, and prefabs keep working after you close the Editor.

public class PlayerHealth : MonoBehaviour
{
    [SerializeField]
    private int maxHealth = 100;

    public void TakeDamage(int amount)
    {
        maxHealth -= amount;
    }
}

If a protector renames PlayerHealth or maxHealth and never updates the prefab, the GameObject can lose the script or reset the value. If it leaves those names alone so the prefab stays valid, attackers still search for PlayerHealth and find the logic.

GuardingPearSoftware Obfuscator is built for that tradeoff. It can rename the class and the serialized field, then update the related assets so the GameObject still points at the new names. Beebyte understood many Unity skip cases, but MonoBehaviour renaming was limited after 2018.2. On a current project, that often means the names attackers look for first stay readable.

Which one should you pick?

Pick GuardingPearSoftware Obfuscator if you want:

A Unity obfuscator that is still updated
MonoBehaviour and ScriptableObject renaming with asset updates
More than rename-and-junk protection
A Free tier to test the workflow
One seat price close to what Beebyte used to cost

Stay on Beebyte only if:

You already paid for it
Your project is on a Unity version it still accepted
You only need light renaming and you can live without new updates

Final thoughts

Beebyte taught the Asset Store what a Unity obfuscator looks like. For a long time it was the practical answer.

That answer aged. The listing is deprecated, newer Unity versions are a risk, and the protection stayed at renaming plus junk.

If you want the same Unity workflow with a tool you can still buy and update, start with GuardingPearSoftware Obfuscator. It fits the build you already run, it can rename the Unity types attackers look for first, and it updates the assets those types live on.

Read more on my blog: www.guardingpearsoftware.com!

SIM Swap Attacks: How They Work and How to Protect Yourself

GuardingPearSoftware — Fri, 21 Aug 2026 13:31:52 +0000

Your mobile phone number is more than a way for people to call or text you. For many people, it has become a key to their digital identity. Banks, email providers, social networks, cryptocurrency platforms, and other online services frequently use phone numbers for password recovery and multi-factor authentication (MFA).

That makes a mobile number a target for cybercriminals.

One of the most effective ways attackers exploit this is through SIM swapping, also known as SIM hijacking or SIM-swap fraud. This article examines how SIM swapping attacks work, the security risks they pose, and effective ways to prevent them. Understanding SIM swapping can help reduce the risk of identity theft, account takeover, and financial fraud.

What Is a SIM Swap Attack?

SIM swapping is a sophisticated cyberattack in which criminals hijack a victim’s mobile phone number to gain access to sensitive accounts and information.

The attacker usually deceives or manipulates a mobile carrier into transferring the victim’s number to a SIM card they control. Once the transfer is complete, the attacker can receive SMS-based two-factor authentication codes, intercept calls and messages, and reset account passwords.

The attacker does not necessarily need physical access to the victim's phone.

Instead, they may obtain enough personal information to convince a carrier representative that they are the account holder. The FBI says criminals have used social engineering, phishing, and, in some cases, insider assistance to carry out SIM swaps.

Once the number is transferred, the attacker can receive calls and SMS messages intended for the victim. That is very dangerous when SMS messages are used as a second authentication factor.

How SIM Swapping Works

A typical attack can unfold in several stages.

1. The attacker gathers information

The first step is often reconnaissance.

Attackers may collect information about a target from social media, data breaches, phishing campaigns, leaked databases, and other sources. They may look for the victim's name, phone number, email address, date of birth, address, carrier, and other information that could help them impersonate the victim.

Publicly available information can sometimes make social engineering easier.

2. The attacker targets the mobile carrier

The criminal then contacts the victim's mobile carrier, either through customer support, an online process, or a physical retail location.

The attacker may claim that the victim lost their phone, damaged their SIM card, or purchased a new device.

The objective is to persuade the carrier to move the victim's number to an attacker-controlled SIM or eSIM.

3. The phone suddenly loses service

If the fraudulent transfer succeeds, the victim's SIM is usually disconnected from the cellular network.

The victim may suddenly see:

No cellular service
No ability to make or receive calls
No incoming SMS messages
Unexpected carrier notifications
An unexplained loss of mobile data

A sudden and unexplained loss of cellular connectivity can therefore be an important warning sign.

4. The attacker receives SMS codes

After taking control of the number, the attacker can receive SMS messages and voice calls that were intended for the victim. This is where the attack can escalate quickly.

Suppose an attacker already knows your email address and password. If your email provider sends a login verification code to your phone number, the attacker may now receive that code.

The attacker can use the same technique against banking, cryptocurrency, social media, and other accounts.

5. Accounts are taken over

The attacker may attempt password resets, account recovery procedures, or new-device logins.

If the victim's phone number is the primary recovery mechanism, the attacker may be able to change passwords and other security settings.

How to Protect Yourself

As the threat of SIM swapping continues to grow, businesses and individuals should adopt these security measures to reduce their exposure and protect themselves.

Move away from SMS-Based MFA

Multi-factor authentication is still one of the most important defenses against account takeover. However, not all MFA methods provide the same level of protection.

The weakness of SMS-based MFA is that the authentication code is delivered through the phone network. If an attacker controls the victim's phone number, the attacker may receive the same code that was supposed to protect the account.

That does not mean you should disable MFA if SMS is your only available option. SMS MFA is generally better than having no second factor at all. But where stronger options are available, they should be preferred.

Use an Authenticator App

One alternative is an authenticator application that generates one-time codes directly on your device.

Instead of receiving the code through SMS, the application generates it locally using a previously established secret.

This means an attacker who merely takes control of your mobile number does not automatically receive the authentication codes. Authenticator apps are therefore generally more resistant to SIM-swap attacks than SMS-based verification.

However, users should still protect the device and account containing the authenticator carefully and maintain appropriate recovery options.

Use Passkeys or Security Keys

For your most important accounts, consider moving beyond SMS and one-time passwords.

Security keys and passkeys can provide phishing-resistant authentication because they rely on cryptographic credentials rather than simply sending a code that a user can enter into a website.

Mobile Carrier Providers Should Do More

Mobile carriers should strengthen identity verification procedures before activating replacement SIM cards or transferring customers’ phone numbers. They should also provide training for customer service staff to recognize suspicious requests and stop fraudulent SIM-swapping attempts before they succeed.

Reduce the Amount of Personal Information You Publish

Attackers do not necessarily need sophisticated malware to perform a SIM swap. Social engineering can be enough. Every publicly available piece of information can make impersonation easier.

Avoid unnecessarily sharing sensitive personal information online, including your full date of birth, personal phone number, home address, detailed information about family members, financial information, or details about valuable assets. You do not need to disappear from social media altogether; instead, limit the amount of personal information available publicly so attackers have fewer identity-verification clues to exploit.

Protect Your Email Account First

Your primary email account deserves special attention because it can often be used to reset passwords for other services.

If an attacker gains access to your email, they may be able to intercept password-reset messages, change account credentials, and lock you out.

Where possible, protect your email account with a passkey, security key, or another phishing-resistant authentication method. You should also regularly review your recovery email addresses, recovery phone numbers, logged-in devices, active sessions, email forwarding rules, account-recovery settings, and recent login activity. If an attacker gains access to your email account, they may attempt to maintain persistent access by changing recovery information, adding their own devices, or creating forwarding rules that secretly redirect your messages.

Training

Increasing awareness of SIM swapping and its associated risks is important for both individuals and organizations. Employees and users should be educated about how these attacks work, the warning signs to watch for, and the steps they can take to protect themselves. Regular cybersecurity training and ongoing reminders about security best practices can help reduce the likelihood of falling victim to SIM-swapping attacks.

Conclusion

SIM-swapping scams are part of social engineering and account takeover attacks. Attackers rarely rely on a single technique. Instead, they may combine phishing, doxing, and SIM swapping to create a chain of compromises that enables them to gain access to sensitive accounts and information.

The growing adoption of eSIM technology adds another layer of complexity. Although eSIMs eliminate the need for a physical SIM card, they rely on digital processes for activating and transferring mobile numbers. If these processes are not adequately secured, attackers could potentially exploit them to carry out fraudulent transfers.

For organizations, SIM-swap fraud shows the fact that the attack surface extends beyond networks, applications, and devices. Human error, weak identity-verification procedures, and continued reliance on vulnerable authentication methods can all provide attackers with opportunities to compromise accounts.

Read more on my blog: www.guardingpearsoftware.com!

First rule of cybersecurity: no tool alone will save you from bad habits

GuardingPearSoftware — Fri, 21 Aug 2026 07:42:56 +0000

Both companies and individuals often treat cybersecurity as something you just need to buy.

They buy an antivirus program, a password manager, a SIEM, or a shiny new firewall with a really cool dashboard. They spend money and feel good about themselves, thinking about how they invest in their safety.

My name is Erich Winkler. I have been working as a cybersecurity manager and head of IT security for years, and I want to show you why habits are what really make the difference, not tools.

Why security as a product is a problem

Let's face it, we all love the idea that security (or anything else) can be simply purchased.

It feels good. You hand over money, get the thing, and the problem is now considered "handled," without any effort or the need to change your behavior.

Just "buy a tool" sells better than "change how you work every single day."

That is not how security works. If you buy a lawnmower and do not actually use it, the grass will still be tall. If you put a lock on an open door, it is still open. Simply having a seatbelt in your car will not help you either. You get the idea.

Trust me, this problem is real, and I can imagine that maybe even you’ve experienced it yourself. And now that we know where this problem is coming from, let’s deep dive into it.

Hackers target people, not tools

Hackers, attackers, or threat actors care about results. In some sense, they are like any other business. They want to get what they want (usually money) for the least effort possible.

Like it or not, we humans and our behavior are the weakest link in many systems.

Breaking an encryption algorithm is much harder (often impossible) than convincing someone to click a link that promises them one extra week of vacation a year.

And I know, maybe you think you are too smart to fall for these scams. The statistics say you are not.

Picture it yourself. A normal Tuesday evening. You are tired, half watching something, phone in hand. A message pops up: "Your package could not be delivered, confirm your address here." You tap it without thinking, because you actually are waiting for a package.

That is the whole attack. No firewall was defeated. No password was cracked. You just did not pay attention for a second, and that was enough.

If you want to know more about why smart people fall for dumb scams, read The psychology of hacking.

Remember: You do not get hacked because you are important. You get hacked because you were easy that day.

Top 5 security habits that anyone should do

Okay, that was enough general lessons that maybe sound interesting, but do not help you at all.

I want to tell you about five personal habits that have the biggest impact on the security of your identity, your accounts, and your digital life.

And the good news is, it is easier than you think.

Use unique passwords

Never reuse your password. Each account deserves its own unique password.

Why? Because breaches happen all the time, and you will never find out about all of them. When one site leaks, every other account that shares that password is suddenly open.

Turn on two-factor authentication

Even a strong, unique password is not enough anymore. Credentials can be stolen, and the second layer of protection is exactly what separates you from an easy target.

Attackers go for easy. Make your accounts a little less easy.

Pause before you tap

This is probably the hardest one to implement. It takes time, but it can really save you the trouble.

Before you click that link, check the sender. Think about it for two seconds. If something starts feeling off, verify it first.

Protect your email first

Your email account is your digital passport. If someone gets access to your email, they can get access to nearly all of your other accounts.

So if there is one account you really should protect, it is this one. Unique password. Two-factor authentication. No exceptions.

Audit your app permissions

Once in a while, check the app permissions on your phone. You will be surprised.

A flashlight app with access to your gallery. Why? Remove everything that is not essential, and be extra careful about location, camera, and microphone access.

Tools help. They do not replace the habit

Let me be clear before we finish. I am not saying tools are useless. I use plenty of them every single day, and so should you.

A good antivirus, a password manager, a solid backup. These things genuinely help. But they help the way a good pair of running shoes helps. They make it easier to run. They do not run for you.

That is the whole point. Tools are here to support your goals, not to replace your effort. They remove the friction so the smart choice becomes the easy choice.

Example 1: unique passwords and MFA

Use unique passwords and MFA. Both become much more convenient when you use a good, secure password manager.

Piece	What it is
The goal	Secure my accounts
The habit	Use unique passwords and MFA
The tool	A password manager

If you skip the habit and jump directly to a tool, you will have a password vault full of weak reused passwords. Your accounts will still be vulnerable.

Example 2: pause before you tap

Pause before you tap, and support that habit with a SecureDNS service.

Piece	What it is
The goal	Avoid clicking malicious links
The habit	Pause before you click
The tool	SecureDNS

The tool can stop you if you click a malicious link, but it has limits. If you just turn on SecureDNS and click on everything you see, you will be scammed sooner or later.

The moment you expect the tool to do the thinking for you, you are back to the lock on the open door.

So buy the tools. Use the tools. But establish the goals and build the habits first, because the habits are the part that actually protects you.

And here is the best part. Tools cost money. Habits are free, and the most important ones often do not require a significant effort.

About the author

I am Erich Winkler, a cybersecurity manager and the creator of Decoded Security, a newsletter and learning platform that helps people understand complex cybersecurity topics and build a career in cybersecurity.

If you want to protect your digital identity, your privacy, or build a career in cybersecurity, feel free to reach out to me and our community.

Read more on my blog: www.guardingpearsoftware.com!

Game monetization benchmarks 2026: skin, battle pass, and IAP prices

GuardingPearSoftware — Wed, 19 Aug 2026 12:05:38 +0000

You are planning a shop. Maybe the game is still in Early Access. Maybe it already has players and you are trying to guess what a skin, a coint pack, or a season pass should cost. And how many of your players will buy it, and what does that mean per person?

Here is what you will learn in this article:

How to tell buy rate, ARPPU, and ARPU apart
What skins, currency, loot, and battle passes actually cost in 2026
How many of your players will buy in your shop
First-year planning tables by genre, plus three worked examples

The genre tables later in this piece are conservative first-year, per-title estimates.

Newzoo put the global games market at $201.6 billion in 2025, up 9.1%, and past $200 billion for the first time. That is consumer spend on games and services, not hardware. On PC, microtransactions were 47% of PC revenue and grew 9.1% year over year. Console in-game spending went the other way, down 4.6% to $13.3 billion. Sensor Tower counted $81.75 billion in mobile game in-app purchases in 2025, up only 1.3%.

MIDiA Research found in its Q1 2024 consumer survey that cosmetic items now account for the majority of in-game spending, and that share is still rising. Players buy identity, not only power.

How to read every number in this article

Three metrics get mixed together in industry posts. If you mix them, your forecast is wrong.

Metric	Formula	What it answers
Buy rate / conversion	Paying players / reachable players	How many people open their wallet
ARPPU	Revenue / paying players	How much a buyer spends
ARPU	Revenue / all players	How much an average player is worth

The identity you must keep in your head:

ARPU = buy rate x ARPPU

Example: 4% of players buy skins, and those buyers spend $50 a year.

ARPPU = $50
ARPU = 0.04 x $50 = $2.00 per player

If you have 20,000 reachable players, first-year skin revenue is about $40,000, not 20,000 x $50.

A second trap is worse.

Kind of "buy rate"	What it measures	Can you use it as a per-game forecast?
Lifetime ever-bought	Share of all players who have ever bought this in any game	No. Upper bound only.
Per-title conversion of actives	Share of your players who buy your shop in a year	Yes. This is the planning number.

The Entertainment Software Association's 2026 Essential Facts report says 27% of US players aged 8+ have ever bought skins. That is not "27% of your Steam page will buy your $12 jacket." That is "more than a quarter of US players have bought a cosmetic somewhere, at some point."

For a new title, use the 1 to 5% one-off IAP and 8 to 20% battle pass bands from live-ops catalogs, then adjust by genre.

Takeaway: Do not plan as if 27% of your players will buy a skin. For a new game, expect about 1 to 5% to buy a one-off item, and about 8 to 20% to buy a battle pass.

The 2025 to 2026 market

Platform revenue

Segment	2025 figure	Year-over-year	Source
Global games market	$201.6B	+9.1%	Newzoo, Global Games Market Report, 2025 full year (2026 update)
Mobile	$113.3B	+10.7%	Newzoo
Console	$44.7B	+2.8%	Newzoo
PC	$43.6B	+12.0%	Newzoo
Console in-game spending	$13.3B	-4.6%	Newzoo
Console DLC	$2.1B	-23.4%	Newzoo
Mobile game IAP (store-tracked)	$81.75B	+1.3%	Sensor Tower, State of Mobile 2026
Mobile game downloads	50.41B	-7.2%	Sensor Tower
Hours played in mobile games	444.63B	+0.9%	Sensor Tower
Share of mobile IAP from top 1% of publishers	92.5%	n/a	Sensor Tower

Newzoo's $113.3B mobile number and Sensor Tower's $81.75B IAP number measure different things. Sensor Tower is App Store plus Google Play in-app purchases. Newzoo is a wider consumer-spend view. Do not average them.

Newzoo credited PC microtransaction growth in part to Counter-Strike 2 and Roblox. It blamed the console in-game drop on weaker engagement in Fortnite and Call of Duty. Full-game spending still grew 25% across PC and console.

Takeaway: These billions are industry totals, not your forecast. Use them for context, then plan from the players who will actually find and try your game.

Who is buying

Fact	Figure	Source
US players 8+ who have ever bought in-game content	58%	ESA 2026 Essential Facts, YouGov, n=13,545, 11 to 25 Feb 2026
Gen Z / Millennial / Gen Alpha buyers, median monthly in-game spend	$20	ESA 2026
Parents who buy in-game content for their children	54%	ESA 2026
Of those parents, who require approval	93%	ESA 2026
PC microtransaction buyers who spend on cosmetics	52%	WorldMetrics 2026 (secondary recap)
Mobile players who have made at least one microtransaction	68%	WorldMetrics 2026 (secondary recap)

Older players have more cash. ESA and a Cubix 2026 recap both note that the 44 to 59 group and the 50+ audience spend more per purchase and churn less. If your game is "for teens only," your ARPU will sit below these medians.

Takeaway: A teen-only audience will sit below these medians. If parents must approve a purchase, expect fewer impulse buys and a lower ARPU.

What players actually buy

ESA asked US players which types of in-game content they had ever purchased. Multiple answers were allowed, so rows overlap.

Type of in-game content	Share of US players aged 8+	Source
In-game currency	34%	ESA 2026 Essential Facts
Skins or customization items	27%	ESA 2026
Expansion packs	26%	ESA 2026
Season pass / battle pass	26%	ESA 2026
Additional maps or levels	19%	ESA 2026
Randomized content packs	15%	ESA 2026

Currency sits first because it is the payment method for everything else. In Fortnite and Call of Duty, buying V-Bucks or COD Points and buying the pass are often the same transaction. If you add both a currency pack and a battle pass to a forecast, do not add 34% + 26%.

Loot sits last. That matches the regulatory and trust story: EU odds rules, UK and Australian scrutiny, and player fatigue. If you still want chests, price them honestly and show the odds.

Game content (expansions, maps, story packs) is still a real line. It is not dead because battle passes exist. It is just a higher ticket and a lower purchase frequency. Game Developer covered the same US spend picture through Circana and ESA.

Takeaway: Do not add currency buyers and pass buyers together. They are often the same purchase. Sell skins and a pass first. Treat loot as optional. Expansions still work if the price matches the game.

What things actually cost

Cosmetics, currency, and loot

Item	Typical price	Notes	Source
Global average cosmetic purchase	$8.17 in 2025	Up from $4.52 in 2020	MarketIntelo, In-Game Apparel Market
Basic cosmetic	$0.99	Entry SKU	MarketIntelo 2025
Common psychological price points	$4.99, $9.99, $19.99	Convert better than round numbers	MarketIntelo 2025
Premium / legendary cosmetic	$30 to $50+	Brand collabs and ultra tiers	MarketIntelo 2025
Premium character skin (industry average)	about $15	Directional	WorldMetrics 2026 (secondary recap)
Limited-time cosmetic premium vs permanent	+20 to 50%	Scarcity pricing	MarketIntelo 2025
Regional discount vs US list	40 to 60% in developing markets	Purchasing-power pricing	MarketIntelo 2025
Currency packs	$4.99 / $9.99 / $19.99 / $49.99 / $99.99	Larger packs have a better rate	Publisher store listings, 2025 to 2026
Loot / chest ticket	$5 to $10 typical	Lowest ESA ever-bought share	ESA 2026 plus common store SKUs
Game content / expansion	$10 to $20 indie; $20 to $40 AAA DLC	Fewer purchases per year	Circana / ESA content mix, 2025 to 2026

Live-service cosmetic SKUs players already know

Game	SKU	Price	Source
Valorant	Select Edition weapon skin	875 VP, about $10	Riot support / community conversion, 2026
Valorant	Deluxe Edition	1,275 VP, about $16	Riot, 2026
Valorant	Premium Edition	1,775 VP, about $23	Riot, 2026
Valorant	Exclusive / Ultra	about $26 to $30+ per gun	Dexerto bundle guide; Riot "varies"
League of Legends	Standard / Epic skin	975 to 1,350 RP, about $11	Riot Points chart, 2026
League of Legends	Legendary	1,820 RP, about $22	Riot, 2026
League of Legends	Ultimate	3,250 RP, about $35	Riot, 2026
Fortnite	Individual skins	typically $8 to $20	Epic item shop, 2025 to 2026

These are AAA reference prices, not indie targets. Your first shop should sit near the $5 to $12 band unless the item is a full bundle or a story expansion. MarketIntelo's $8.17 average is the cleanest single number for "what does a cosmetic checkout look like in 2025."

Valorant Points in the US run about $0.0105 per VP on the smallest pack and $0.0091 on the largest. Players who buy the $99.99 pack get about 13% more points per dollar. If your economy only works when people buy the whale pack, the economy is wrong.

Takeaway: Price your first cosmetic between $5 and $12, and make it obvious in one screenshot. Valorant and League prices are AAA reference points, not indie targets.

Battle pass prices in 2026

The market converged on ten dollars. MWM's May 2026 catalog of US battle and season-pass products makes that obvious.

Benchmark	Figure	Source
Apps running a battle / season pass	754 (73% are games)	MWM, State of May 2026
Game pass items in catalog	977	MWM
Median game battle pass	$9.99	MWM
25th percentile (entry)	$5.99	MWM
Premium tail (top 10%)	$29.99	MWM
Typical standard pass	$5 to $10 / season	MWM
Premium / deluxe pass	$15 to $25	MWM
Tier-skip bundle	$5 to $15	MWM
Annual / subscription pass	$30 to $60 / year	MWM, emerging
Typical season length	4 to 12 weeks	MWM
Pass adoption in top live-service titles	about 85%	Cubix / Kevuru 2026 recaps
Pass adoption in top online multiplayer (2025)	about 73%	Dataintelo
Pass share of those titles' revenue	22 to 35%	Dataintelo
Enrolled consumer spend per season (pass + extras)	about $31.50	Dataintelo

2026 live-service list prices

These are premium-currency prices, not always a clean dollar tag.

Game	Premium pass	Season checked	Source
Fortnite	800 V-Bucks ($8.99 cheapest pack after 19 Mar 2026)	From 19 Mar 2026	Epic Games
Apex Legends	950 Apex Coins	Season 30, from 4 Aug 2026	EA / Respawn
Marvel Rivals	990 Lattice	Season 9, Jul 2026	NetEase
Valorant	1,000 VP (about $9.99)	2026 Act 2, from 18 Mar 2026	Riot
Overwatch	1,000 Overwatch Coins (about $10)	Season window Apr to Jun 2026	Blizzard
Call of Duty: Black Ops 7	1,100 COD Points	Season 05, from 23 Jul 2026	Activision

Epic cut the Fortnite pass from 1,000 to 800 V-Bucks in March 2026, and cut the $8.99 pack from 1,000 to 800 V-Bucks on the same day. The dollar price did not fall. Completing the pass now returns 800 V-Bucks, enough for the next pass and no surplus. If you copy Fortnite's "the pass pays for itself" loop, budget that as retention, not extra revenue.

Deluxe bundles sit above the pass. Activision's Battle Pass Bundle with 20 tier skips is 2,400 COD Points. Blizzard's premium plus 20 skips is 2,200 coins. Apex sells Ultimate tiers for real money.

Casual and smaller games should start at $5.99, not $9.99. That is MWM's 25th percentile, and it is where puzzle, idle, and light seasonal games actually sit.

Takeaway: Price a full live-service pass at $9.99. Start at $5.99 if the game is casual or small. If the pass pays for the next pass, count that as retention, not extra revenue.

How many players pay

Industry bands

Shop	Per-title conversion of actives	Lifetime ever-bought (US, any game)	Source
One-off IAP (a single skin, pack, or currency bundle)	1 to 5%	Skins 27%, currency 34%, loot 15%	MWM 2026; ESA 2026
First purchase after install (mobile)	2 to 5% typical; 8 to 12% top mid-core	n/a	AppFollow 2026, compiling AppsFlyer / Sensor Tower / Newzoo
Battle pass	8 to 20% of actives	26%	MWM 2026; ESA 2026
Well-timed battle pass in a top title	15 to 20%	n/a	Cubix / Kevuru 2026 (secondary recaps)
Mobile multi-pass	8 to 12%	n/a	Recited (secondary)
Console single-pass	25 to 35%	n/a	Recited (secondary)

Mobile IAP conversion by genre (US / Canada, 2026)

Genre band	IAP conversion	Source
Hyper-casual	0.5 to 2%	RewardingHub 2026
Casual	2 to 4%	RewardingHub 2026
Mid-core	3 to 6%	RewardingHub 2026
RPG	4 to 8%	RewardingHub 2026
Casino (first purchase in 30 days)	4.95%	AppsFlyer, App Monetization 2026

A battle pass converts better than a single skin because the pitch is "buy once, unlock the season by playing." MWM's catalog says pass holders also log in 30 to 60% more often. Cubix and Kevuru report pass owners are about 3x more likely to still be around after six months, and they make about 25% more secondary micro-purchases.

That last point is a warning. Deconstructor of Fun (2022) showed that a generous pass steals a la carte shop spend. If the pass already contains the only skins people wanted, your shop ARPU falls. In planning, if you run a pass and a shop, cut shop revenue by about 15%.

Takeaway: More players will buy a pass than a single skin. If you sell both, cut your shop forecast by about 15%, because the pass often includes the skins people wanted.

Revenue per person

These numbers are not all measuring the same window. Read the period column.

Metric	Period	Figure	Source
Casual IAP ARPPU	Day 90	$7.26	AppsFlyer 2026
Mid-core IAP ARPPU	Day 90	$9.80	AppsFlyer 2026
Casino IAP ARPPU	Day 90	$11.40	AppsFlyer 2026
Casual IAP ARPU	Day 90	$1.34	AppsFlyer 2026
Mid-core IAP ARPU	Day 90	$2.13	AppsFlyer 2026
Casino IAP ARPU	Day 90	$2.43	AppsFlyer 2026
Casual monthly ARPPU	Month	$10 to $30	AppFollow 2026 compile
Mid-core monthly ARPPU	Month	$50 to $100	AppFollow 2026 compile
Gacha / hardcore monthly ARPPU	Month	often $100+	AppFollow 2026
Mobile ARPPU	Month	about $12.30	WorldMetrics 2026 (directional, secondary)
Free-to-play ARPU	Month	$7.20	WorldMetrics 2026 (secondary)
US mobile player microtransaction spend	Month	$15.60	WorldMetrics 2026 (secondary)
ESA buyer median in-game spend	Month	$20	ESA 2026, younger generations
Top RPG / strategy paying user	Unspecified, tier-1 markets	$45+	Cubix 2026 (secondary)
Mobile shooter annual ARPPU	Year	$45 to $120	Dataintelo, Mobile Shooter, 2025
Broader mobile annual ARPPU band	Year	$30 to $65	Dataintelo 2025
Console single-pass ARPPU	Season	$12 to $18	Recited (secondary)
Mobile multi-pass ARPPU	Season	about $47	Recited (secondary)
Pass + supplemental cosmetics	Season	about $31.50	Dataintelo 2025

Day-90 ARPPU of $8 to $11 looks small next to "$50 to $100 a month." Both can be true. AppsFlyer is a short window across a huge install base. AppFollow's monthly band is what a healthy live mid-core title sees among payers in rich markets. For an indie PC forecast, annual ARPPU of $20 to $60 among shop buyers is the honest middle. $100+ a month is gacha and 4X, not a $12 Steam shooter skin.

Dataintelo's $31.50 per season is spend by people who already bought the pass, including extra cosmetics and skips. If your model already has a separate skins line, do not add $31.50 on top. Use pass price times paid seasons for the pass, and a smaller shop ARPPU for extras.

Takeaway: Do not mix Day-90 numbers with monthly or yearly numbers. For an indie PC shop, plan about $20 to $60 per year from each buyer, not $50 to $100 a month.

What each genre actually sells

Industry recaps in 2026 agree on the shape, even when they disagree on the exact dollar.

Genre	Primary live-ops motion	What to sell first	Source
Shooter / Action	Battle pass + cosmetics	Season pass, then weapon / operator skins	Cubix 2026; MWM 2026
MOBA	Cosmetics and seasonal content	Skins, then a pass	Cubix 2026
RPG	Collection + cosmetics	Characters, skins, currency; pass is secondary	Cubix / Kevuru 2026
Strategy	Premium currency	Time / resource packs, then a mid-core pass	Cubix 2026; Sensor Tower 2026
Sports	Seasonal leagues + packs	Currency, player packs, kits, a season pass	WorldMetrics sports MTX; ESA content mix
Casual / puzzle	Ads + cheap IAP	$5 to $6 cosmetics, $5.99 pass, rewarded ads	RewardingHub; Cubix
Adventure / story	Premium + DLC	Game content first, light cosmetics	Newzoo PC / console 2026 (sandbox vs story split)
Hyper-casual	Ads	Do not plan a $10 pass	Cubix 2026 (about 90% ads)

Sensor Tower's 2026 State of Gaming note: strategy and puzzle led mobile growth in 2025. Strategy IAP was up 20%, puzzle up 14%. Strategy was the only mobile genre that grew revenue, downloads, and time together. On PC, action premium revenue on Steam was up 32%.

That does not mean every strategy indie prints money. It means the category is where spend is moving.

Takeaway: Match the shop to the genre. Action games sell a pass and skins. Adventure games sell DLC. Hyper-casual games should not plan a $10 pass.

Planning tables by genre

The tables below are first-year, per-title planning defaults for a reachable PC audience. They sit inside the research bands above. They are not Fortnite, Genshin, or Call of Duty Mobile.

How to use a row:

Take your reachable players (the people who will actually find and try the game).
Multiply by buy rate. That is your buyers.
Multiply buyers by price x purchases per year. That is first-year revenue for that shop.

ARPU = buy rate x price x purchases per year

Purchases per year is how often a buyer comes back. A $10 pass bought 3.5 times is not $10 of revenue. It is $35 from that buyer.

Battle pass

Genre	Default price	Buy rate	Paid seasons / year	ARPPU	ARPU
Action	$9.99	16%	3.5	$35.0	$5.59
Adventure	$9.99	9%	2.5	$25.0	$2.25
Casual	$5.99	10%	3.5	$21.0	$2.10
Racing	$9.99	12%	3.0	$30.0	$3.60
Role Playing	$9.99	12%	3.0	$30.0	$3.60
Simulation	$7.99	10%	2.8	$22.4	$2.24
Sports	$9.99	14%	3.5	$35.0	$4.90
Strategy	$9.99	11%	3.0	$30.0	$3.30
Other	$9.99	12%	3.0	$30.0	$3.60

Paid seasons are lower than calendar seasons. A game can run five seasons and still only collect 3.5 purchases from the average pass buyer. People skip a season.

Skins

Genre	Default SKU	Buy rate	Purchases / year	ARPPU	ARPU
Action	$12	3.2%	2.5	$30.0	$0.96
Adventure	$8	1.8%	2.0	$16.0	$0.29
Casual	$6	2.0%	2.2	$13.2	$0.26
Racing	$10	2.8%	2.4	$24.0	$0.67
Role Playing	$10	4.2%	2.8	$28.0	$1.18
Simulation	$8	2.5%	2.3	$18.4	$0.46
Sports	$12	3.5%	2.6	$31.2	$1.09
Strategy	$8	2.2%	2.2	$17.6	$0.39
Other	$8	2.5%	2.4	$19.2	$0.48

Currency

Genre	Default pack	Buy rate	Purchases / year	ARPPU	ARPU
Action	$9.99	3.5%	3.5	$35.0	$1.22
Adventure	$9.99	2.0%	2.5	$25.0	$0.50
Casual	$4.99	2.5%	3.0	$15.0	$0.37
Racing	$9.99	2.5%	3.0	$30.0	$0.75
Role Playing	$9.99	4.5%	3.8	$38.0	$1.71
Simulation	$7.99	2.8%	3.0	$24.0	$0.67
Sports	$9.99	4.0%	3.5	$35.0	$1.40
Strategy	$9.99	4.0%	4.0	$40.0	$1.60
Other	$9.99	3.0%	3.2	$32.0	$0.96

Currency converts a little more often than skins because it is the wallet, not the item. Strategy and RPG sit highest. That matches Cubix: strategy lives on premium currency.

Loot packs

Genre	Default ticket	Buy rate	Purchases / year	ARPPU	ARPU
Action	$7.99	1.5%	2.5	$20.0	$0.30
Adventure	$6.99	1.0%	2.0	$14.0	$0.14
Casual	$4.99	1.0%	2.2	$11.0	$0.11
Racing	$6.99	1.2%	2.2	$15.4	$0.18
Role Playing	$9.99	2.5%	3.0	$30.0	$0.75
Simulation	$5.99	1.2%	2.0	$12.0	$0.14
Sports	$7.99	2.0%	2.8	$22.4	$0.45
Strategy	$6.99	1.5%	2.4	$16.8	$0.25
Other	$6.99	1.2%	2.2	$15.4	$0.18

RPG and sports are the only genres where loot still looks like a real line (gacha, card packs, Ultimate Team). Everywhere else, keep it small or skip it. ESA's 15% lifetime ever-bought rate is the ceiling, not the plan.

Game content (DLC, expansions, maps, story packs)

Genre	Default price	Buy rate	Purchases / year	ARPPU	ARPU
Action	$14.99	2.0%	1.2	$18.0	$0.36
Adventure	$19.99	3.0%	1.3	$26.0	$0.78
Casual	$9.99	1.0%	1.1	$11.0	$0.11
Racing	$12.99	1.8%	1.2	$15.6	$0.28
Role Playing	$19.99	3.5%	1.4	$28.0	$0.98
Simulation	$14.99	2.2%	1.2	$18.0	$0.40
Sports	$14.99	2.5%	1.3	$19.5	$0.49
Strategy	$14.99	2.0%	1.2	$18.0	$0.36
Other	$14.99	2.0%	1.2	$18.0	$0.36

Adventure and RPG pay for expansions. Casual barely does. Do not put a $20 story pack behind a $5.99 hyper-casual loop.

Takeaway: Find your genre row. First-year revenue is reachable players times buy rate times (price times purchases per year). That is your shop, not Fortnite.

Three worked examples

Example A. Free-to-play multiplayer action game

Assume 50,000 reachable players in year one. You ship a $9.99 pass, $12 skins, and $9.99 currency. No loot.

Shop	Buyers	Spend per buyer	Revenue	ARPU
Battle pass	8,000 (16%)	$35.0	$279,720	$5.59
Skins	1,600 (3.2%)	$30.0	$48,000	$0.96
Currency	1,750 (3.5%)	$35.0	$61,163	$1.22
Shop after 15% pass overlap	n/a	n/a	$92,788	$1.86
Total live-ops	n/a	n/a	$372,508	$7.45

Store fees are not in this table. Steam still takes its cut. So does the platform owner on console.

If the same game is single-player only, cut live-ops by about 30%. Identity cosmetics convert worse when nobody else can see them. Multiplayer can justify about a 15% lift.

Example B. Premium $25 adventure game plus DLC

The box price does the heavy lifting. Add a $19.99 expansion and a light $8 skin line.

On 20,000 reachable players:

Line	Buy rate	Revenue
Game ($25, using your store conversion, not these live-ops rates)	your catalog model	catalog revenue
Game content	3.0% x $19.99 x 1.3	about $15,600
Skins	1.8% x $8 x 2.0	about $5,760

Live-ops here is a bonus, not the business.

Example C. Casual game, $5.99 pass only

On 100,000 reachable players:

Buyers: 10,000
Spend: $5.99 x 3.5 = $20.97
Revenue: about $209,700
ARPU: $2.10

That is why casual studios still run passes. The ticket is small. The conversion is not.

Takeaway: In a free-to-play action game, the pass is most of the live-ops money. In a $25 adventure game, live-ops is a bonus. The box price is still the business.

Design notes that change the math

Price the pass at a visible discount. MarketIntelo says a $9.99 to $19.99 pass often looks like 30 to 40% off the a la carte value of the items inside. If the pass is not obviously cheaper than buying two skins, people will not convert at 8 to 20%.

Keep a free track. The free track fills lobbies and teaches the loop. The paid track is the product.

Keep seasons between 4 and 12 weeks. Shorter than four weeks feels like a chore. Longer than twelve loses the deadline. Most action games land near five seasons a year. Casual can run more, cheaper.

Do not put progression power in the shop if you sell a competitive game. Cosmetics are the majority of in-game spend because they do not break the match. Pay-to-win still prints money in 4X and some RPGs. It also prints reviews you cannot undo.

Loot is optional and politically expensive. ESA puts randomized packs last. If you ship them, disclose odds, cap child spend, and do not make the only good skin a chest exclusive.

A pass can eat your shop. Watch ARPPU after the first season. If high spenders drop, the pass is too generous. Deconstructor of Fun called this out in 2022. It is still true.

Currency is not content. A coin pack with nothing worth buying is a dead SKU. Currency ARPU only shows up if skins, passes, or content exist to sink it.

Takeaway: Make the pass look cheaper than two skins, keep a free track, and keep seasons between 4 and 12 weeks. Do not put power in a competitive shop.

Your takeaway

If you are shipping a live game in 2026, start with three prices:

A $6 to $12 cosmetic people can understand in one screenshot.
A $5.99 or $9.99 pass with a free track and a season short enough to finish.
A currency pack only if something on that list is worth buying.

Then forecast with buy rate times spend per buyer. Do not use ESA's 27% as your conversion. That number is "have they ever bought a skin in any game." Your number is "will they buy your shop this year."

Here is the short version to keep:

Split the metrics. Buy rate is how many players pay. ARPPU is how much a buyer spends. ARPU is those two multiplied. Never apply ARPPU to every player.
Use 1 to 5% for a single item and 8 to 20% for a pass. Adjust down if the game is new or single-player.
Price a cosmetic at $5 to $12. Price a pass at $5.99 (casual or small) or $9.99 (live action). Add coins only if there is something worth buying.
If you run a pass and a shop, cut shop revenue by about 15%. The pass often includes the skins people wanted.
Sell what the genre already buys. Action: pass and skins. Adventure: DLC. Casual: a cheap pass. Hyper-casual: ads, not a $10 pass.

If you want a first look at the potential for your game, put the genre, platform, and game type into the Market Insights calculator. It estimates where the game sits in the market and what audience that implies. Then come back to the tables above and run buy rate times spend per buyer on that audience.

Sources

Entertainment Software Association, 2026 Essential Facts About the U.S. Video Game Industry. YouGov survey of 13,545 US respondents, 11 to 25 February 2026.
ESA press release, 3 June 2026.
Game Developer / Circana coverage of ESA 2026 spend.
Newzoo, Year in review: 2025. Global Games Market Report quarterly update, June 2026, covering full-year 2025.
Sensor Tower, State of Mobile 2026 and State of Gaming 2026. Mobile game IAP $81.75B; strategy / puzzle growth.
MWM, Battle Pass: How It Works, 2026 Pricing Benchmarks and Design. State of May 2026 catalog.
MarketIntelo, In-Game Apparel Market Research Report 2034. 2025 pricing section: $8.17 average cosmetic.
MIDiA Research, The "why" and "what" behind in-game spending. August 2024. Q1 2024 survey in US, UK, Australia, Canada, Germany, France, Poland, Turkey, South Africa.
AppsFlyer, The State of App Monetization, 2026 Edition. D90 IAP ARPU / ARPPU and conversion.
AppFollow, Mobile Game KPIs: The 2026 Guide to Gaming Metrics.
RewardingHub, Mobile Game Monetization Benchmarks by Genre 2026.
Dataintelo, Online Microtransaction Market. Pass adoption, $31.50 per season, shooter ARPPU $45 to $120.
Recited, Battle Passes and Season Passes. Mobile vs console conversion and ARPPU. Secondary playbook.
Deconstructor of Fun, Battle Passes: Everything You Ought to Know and Then Some. 4 June 2022.
WorldMetrics, Microtransactions In Video Games Statistics, 2026 Edition. 12 Feb 2026, verified 11 Jul 2026. Secondary recap.
Epic Games, Fortnite V-Bucks Price Increase. 10 March 2026, effective 19 March 2026.
Riot Games. Valorant skin tiers and Riot Points / VP pack prices, 2026. Publisher listings, no single stable public support URL.
Cubix, Game Monetization Statistics 2026. 8 July 2026. Secondary recap, not a primary survey.
Kevuru Games, Game Monetization Statistics: Data and Insights. Secondary recap of the 15 to 20% pass band.
Xiao, Zhang, Mao. What Makes Loyalty Programme Work: The Effectiveness of the Battle Pass System in Chinese MOBA Game. Advances in Economics, Management and Political Sciences 172 (published 8 May 2025). Academic pass and loyalty framing, not Western ARPU.

Read more on my blog: www.guardingpearsoftware.com!

The Growing Threat of Vishing and AI Voice Cloning

GuardingPearSoftware — Fri, 14 Aug 2026 14:18:09 +0000

Voice has long been one of the most trusted forms of communication, allowing people to recognize colleagues, family members, customers, and business partners simply by hearing them. But advances in generative artificial intelligence are challenging that assumption. With AI voice-cloning technology capable of producing remarkably realistic speech, cybercriminals can now impersonate trusted individuals and organizations.

According to Google Mandiant, while exploits remained the most common initial infection vector in 2026, highly interactive voice phishing has surged, accounting for 11% of observed incidents and becoming the second-most common initial access vector.

What is voice phishing?

Voice phishing, or vishing, is a form of social engineering in which cybercriminals use phone calls, voice messages, or other voice-based communications to impersonate trusted individuals or organizations and manipulate victims into revealing sensitive information or taking actions that compromise their security.

AI voice cloning

AI voice cloning is a technology that uses artificial intelligence to create a synthetic version of a person’s voice based on recordings of their speech. AI models can generate highly realistic speech that sounds like the original speaker by analyzing characteristics such as tone, pitch, pronunciation, rhythm, and speaking patterns. While the technology has applications in areas such as accessibility, entertainment, and content creation, it can also be abused by cybercriminals to impersonate trusted individuals.

The problem is particularly serious when the attacker knows something about the victim.

A cloned voice alone may not be enough to convince someone. But a convincing voice combined with knowledge of a person's name, job title, colleagues, current projects, or organizational structure can make the interaction much more credible.

How Vishing Scams Work

Attackers typically move through several stages, gradually building trust before attempting to achieve their objective.

Reconnaissance

The attack usually begins with reconnaissance, during which the attacker collects as much information as possible about the intended victim. This information can come from social media profiles, company websites, professional networking platforms, public records, data breaches, leaked credentials, or previously compromised accounts. Attackers may look for an employee's job title, manager, colleagues, responsibilities, phone number, email address, and even information about ongoing projects. The more details an attacker has, the easier it becomes to construct a believable story and make the subsequent phone conversation appear legitimate.

Identity Preparation

After gathering information, the attacker develops a convincing identity and determines whom they will impersonate. In corporate attacks, this could be an IT administrator, help-desk employee, manager, executive, business partner, or security representative. Attackers may also impersonate a trusted service provider, bank, telecommunications company, or government agency. The objective is to select an identity that the victim would have a legitimate reason to trust, and that can plausibly make the request the attacker intends to deliver.

Initial Contact

The attacker then establishes contact with the victim, typically through a phone call, although modern campaigns can combine voice calls with email, text messages, messaging applications, or collaboration platforms. The initial communication is often designed to appear routine rather than immediately suspicious. For example, the caller may claim to be following up on an account problem, security alert, password issue, payment, or technical-support request. Attackers may also use caller-ID spoofing or other techniques to make the incoming call appear to originate from a legitimate organization or familiar number.

Voice Impersonation

AI voice cloning can make this stage more convincing by allowing attackers to generate speech that resembles a real person. A criminal may use publicly available recordings or other audio samples to create a synthetic voice that imitates an executive, colleague, family member, customer-service representative, or other trusted individual. During a live conversation, the attacker can use the cloned voice to reinforce the impersonation and make it more difficult for the victim to recognize that they are communicating with a criminal.

Social Engineering

Once communication has been established, the attacker uses social-engineering techniques to manipulate the victim into taking the desired action. A common tactic is to create a sense of urgency by claiming that an account has been compromised, a payment needs immediate approval, an employee must complete a security verification, or access will be suspended unless action is taken. Attackers may deliberately limit the victim's opportunity to think or independently verify the request. They combine urgency with authority, familiarity, and information gathered during reconnaissance, to make the fraudulent request appear both legitimate and time-sensitive.

Credential and Information Theft

After gaining the victim's trust, the attacker attempts to obtain something valuable. This could include usernames, passwords, one-time authentication codes, recovery codes, financial information, or other sensitive data. In some cases, the caller may direct the victim to a fraudulent website that resembles a legitimate login portal. The victim may be instructed to enter their credentials or authentication information while remaining on the phone with the attacker. This allows the criminal to capture the information in real time and use it before the victim realizes that the interaction was fraudulent.

Lateral Movement

A compromised account may be only the beginning of the attack. After gaining an initial foothold, criminals can search for additional accounts, applications, documents, credentials, and systems that can provide greater access. They may use the compromised identity to impersonate the victim and target colleagues, access sensitive business information, or obtain higher privileges.

Types of Vishing Scams

Family Emergency Scams

Family emergency scams use AI-generated voices to impersonate a relative who supposedly needs immediate assistance. The attacker may claim that the relative has been involved in an accident, arrested, hospitalized, or stranded and urgently needs money. The caller may then instruct the victim to transfer funds or provide financial information. These attacks are particularly effective because they exploit emotional responses rather than relying solely on technical deception. When someone believes that a loved one is in immediate danger, fear and urgency can override normal skepticism.

Bank and Financial Institution Impersonation

In bank impersonation scams, criminals use AI-generated voices to pose as representatives of banks or other financial institutions. The caller may claim that suspicious activity has been detected on the victim's account, that a transaction needs to be reversed, or that the customer's identity must be verified. The victim may then be asked to provide account information, passwords, one-time passcodes, or other authentication details. Attackers often combine the voice call with spoofed text messages or emails to reinforce the legitimacy of the story. They may also possess partial information about the victim obtained from previous data breaches, leaked databases, or compromised accounts, making the conversation appear more credible and convincing.

IT Help-Desk Scams

InnIT help-desk scams, attackers can use a cloned voice to pose as an internal IT employee or support technician. The supposed technician may claim that the employee's account has experienced a security problem and that immediate action is required. The victim could then be asked to reset a password, approve an MFA request, disclose an authentication code, or install remote-access software. Once the attacker gains access, the compromised account can be used to reach corporate applications, internal systems, and sensitive information.

Customer-Service and Technical-Support Impersonation

Attackers can also clone the voices of customer-service representatives or technical-support personnel and contact individuals claiming to help resolve an account or device problem. The caller may create a sense of urgency by claiming that the victim's account is compromised or that immediate verification is required to prevent unauthorized activity. The victim may subsequently be directed to a fraudulent website, asked to reveal authentication information, or persuaded to grant remote access to a device.

Government and Law-Enforcement Impersonation

Another use of AI voice cloning involves impersonating government officials, law-enforcement personnel, tax authorities, or other public institutions. The attacker may claim that the victim is under investigation, has an outstanding payment, or must provide information to resolve an alleged legal or administrative issue. Threats of penalties, arrest, or other consequences are used to create fear and discourage the victim from questioning the request.

CEO Fraud

CEO fraud is one of the most financially damaging forms of AI-powered voice impersonation targeting organizations. In these attacks, criminals use a cloned voice to impersonate a CEO, senior executive, or other authority figure and contact employees, often those in finance or accounting, with an urgent request to transfer funds or approve a payment.

Attackers may deliberately make the request outside normal working hours or claim that the transaction is confidential, reducing the chances that the employee will independently verify it with the executive.

How organizations can defend against AI-powered vishing

Establish independent verification

Employees should verify unexpected requests through a separate, trusted channel. If an executive calls asking for a sensitive action, the employee should not verify the request by calling the same number back. Instead, they should use a previously established corporate contact method.

Create strict help-desk procedures

Account recovery and authentication resets should require strong verification. Help-desk personnel should not be able to override established identity controls merely because a caller sounds convincing or knows internal information.

Train employees for AI impersonation

Organizations should implement structured, role-based cybersecurity awareness training that specifically covers the risks posed by AI-powered voice-cloning scams. Training should teach employees how to recognize common social-engineering tactics, follow established identity-verification procedures, and respond appropriately to urgent or suspicious requests without allowing pressure or perceived authority to influence their decisions.

Report Suspected AI Voice-Cloning Scams

Individuals who encounter suspected AI voice-cloning scams should report them to the appropriate authorities and organizations. Organizations should additionally notify their internal security teams so that other employees can be warned about similar attempts. Early reporting can help authorities identify recurring campaigns, connect related incidents, and alert other potential victims before attackers can reuse the same impersonation techniques.

The future

The next generation of AI voice attacks is likely to be even more sophisticated. Attackers may use AI voice cloning to respond to verification questions. Combining deepfake video with cloned voices could also make live video calls with fake identities difficult to distinguish from genuine interactions.

At the same time, defensive technologies are advancing. Researchers are developing watermarking techniques that embed identifiers into synthetic speech, although widespread adoption remains limited.

Legal and regulatory frameworks are evolving as well. Courts and compliance teams will need to determine how voice recordings should be treated as evidence as voice cloning becomes more prevalent and the authenticity of audio becomes harder to establish.

Read more on my blog: www.guardingpearsoftware.com!

Hoop Dynasty - The Continue button is the hardest part of a living sports simulation

GuardingPearSoftware — Thu, 13 Aug 2026 05:59:55 +0000

When I started building Hoop Dynasty: Rise of a Legend, the interface was rough and the project was still searching for its final identity. The real work was happening underneath.

I am Giulio Caruso, the solo developer behind the game. Hoop Dynasty is a single-player basketball career simulator. You do not watch a legend from a distance. You build your own.

Create a young prospect, choose your role, shape your skills and mentality, then live an entire basketball career in an original world that evolves season after season. You can begin in College, enter International basketball, or face the pressure of the Pro world from day one. Every path carries different opportunities, risks, and expectations.

Performances, consistency, form, injuries, and decisions determine your minutes, development, and reputation. A prospect can become a star, or follow a path no one expected.

That living world is the part that took years to make honest.

The work happened in long simulations

I spent years simulating careers through repeated, sometimes almost endless cycles. I wanted to understand what happened to rosters after several seasons, how injuries affected development, how contracts changed the balance between teams, and how a player's career could remain believable over time.

Many of the most important corrections came from these long simulations.

A roster could become unbalanced. An injury could have too much or too little impact. A player could develop in a way that looked mathematically valid but felt completely wrong from a basketball perspective.

That forced me to create a QA system capable of generating alerts around the mathematical model behind the game. It had to identify unusual roster situations, unexpected progression, injury patterns, broken career paths, and inconsistencies that were almost impossible to see during a short manual test.

Pressing Continue starts a chain of events

The most difficult part, however, was creating the living world.

In Hoop Dynasty, pressing Continue does not simply move the calendar forward. It activates a large chain of events and validations. Matches are processed, player conditions change, rosters evolve, injuries are evaluated, contracts and decisions move forward, national team selections can appear, rivalries develop, and the world records the consequences.

Every new feature has to find a place inside that chain without breaking something that already works.

The Services layer that powers this system has grown to roughly 100,000 lines of engine code. I do not see that number as a badge of honour. I see it as a reminder of how much interconnected logic a sports simulation can contain.

Whenever I had a new idea, I could not simply add it in isolation. I had to understand where it belonged, what it affected, and how it would behave after several seasons. The goal was not just to make the feature work once. It had to remain coherent inside a world that keeps moving.

The bugs that only appear after many seasons

There were also plenty of absurd moments. I remember situations where a player was called up to the national team and then never returned to the club. Other bugs were less obvious but even more dangerous, because the simulation continued while quietly becoming inconsistent.

That is why the QA system became such an important part of development. It allowed me to observe the world over long periods, catch problems earlier, and measure whether the mathematical model still produced believable outcomes.

Hoop Dynasty is still not perfectly coherent. That is one of the main areas I am working on before the demo. The ambition is not to pretend that a complex simulation is flawless. The ambition is to make the remaining inconsistencies visible, understandable, and progressively easier to correct.

Ten years, nights, and Visual Studio

I have been working on this project for more than ten years. I develop it after my regular job and family time, often late at night, with little more than Visual Studio, a cigarette, and another season to investigate.

The project has changed enormously since the first prototypes. The UX became more deliberate, the systems became deeper, and the world became much more ambitious.

But the central question remained the same:

Can this world continue to live when the player is not looking?

Where AI fits, and where it does not

That question is also where I use AI today. I write the code and design the systems myself, then use AI to challenge the implementation, search for weaknesses, and expose blind spots. I do not delegate the game's logic or its design identity to AI. Some promotional assets were also created with AI, but the final creative direction and selection remain mine.

I still do not know exactly where Hoop Dynasty will take me. I do know that it now has an identity of its own. After so many years, that is what gives me the confidence to keep pushing it forward.

Every season is another test.
Every Continue button is another chance to find out whether the world is still alive.

Build an arena the world will remember

Hoop Dynasty needs places with an identity. Until 16 August 2026 at 23:59 CEST, the first HD Foundry community challenge is open: imagine the next arena in this universe and turn it into a proposal ready for editorial selection.

Give it an original name, a fictional city or region, an architectural identity, an atmosphere the crowd would recognize with their eyes closed, and one ritual or detail that could become part of its legend. No real teams, leagues, brands, venues, or copied identities. Build something that could only belong to the Hoop Dynasty universe.

Every entry goes through editorial and originality review. Selected ideas may be adapted for the game world and credited in the Community Credits. Submission does not guarantee inclusion. The strongest ideas are the ones that feel ready to live inside the game.

Enter the arena challenge

Links

Read more on my blog: www.guardingpearsoftware.com!

What MonoMod is and how Unity developers can detect it

GuardingPearSoftware — Wed, 12 Aug 2026 19:38:57 +0000

If you have read about BepInEx, MelonLoader, or HarmonyX, you have probably also seen MonoMod mentioned underneath them. MonoMod is not a player facing mod manager. It is a lower level .NET modding toolkit. Loaders and libraries use MonoMod pieces to hook and rewrite methods at runtime.

You will learn what MonoMod is, how frameworks use it, what it does inside a Unity process, and how to spot its traces.

What MonoMod is

MonoMod is a general purpose .NET modding "basework." That word is intentional. It is a set of base tools and libraries, not one single app.

Depending on which package is involved, it can help with runtime method detours, IL rewriting, hook helper generation, and patching support across Mono and related runtimes.

In Unity modding and cheating talks, people usually mean the runtime pieces, especially MonoMod.RuntimeDetour. Those let foreign code redirect your methods while the game is running.

A useful way to place it in the stack:

BepInEx or MelonLoader get into the process and load mods.
The mod or plugin is the actual cheat or feature code.
HarmonyX is often the friendly patch API the mod calls.
MonoMod is one of the deeper engines that carries out detours and IL work.

Players rarely install "MonoMod" as the main product. They install a loader, and MonoMod arrives with that toolchain.

How mod loaders and frameworks use MonoMod

Mod frameworks need a way to change compiled methods without shipping a cracked game build. MonoMod helps with that.

HarmonyX is the API many plugin authors write against. Underneath, HarmonyX is built on MonoMod.RuntimeDetour. BepInEx docs list both as runtime patching options, and patches from both can coexist.

Some ecosystems also use MonoMod directly. RuntimeDetour attaches hooks and builds detour chains. HookGen can generate helper assemblies so hooks feel like C# events, for example On.SomeType.SomeMethod += MyHook;.

When a Unity PC game runs with BepInEx or MelonLoader, you will often find MonoMod assemblies loaded with the loader core. The usual flow looks like this:

The loader boots into the Unity process.
It loads plugin DLLs plus support libraries such as MonoMod.RuntimeDetour.
A plugin creates a Hook, an ILHook, or goes through HarmonyX.
The hook redirects the target method into a detour chain.
From that moment, selected game methods run through the hooked path.

For legitimate mods, that might mean better UI or content hooks. For cheats, that might mean free purchases, skipped cooldowns, or rewritten damage and inventory logic.

How MonoMod works technically

MonoMod's runtime model is easiest to understand as layered detours.

At the bottom, a detour redirects execution from one method entry point to another. Higher level hooks accept delegates and pass a trampoline so your code can call the next handler or the original method. That detour can change arguments, skip the original behavior, call through, or change the return value.

MonoMod can also work at the IL level through ILHook. An IL hook receives the method body as instructions and rewrites them. This is similar in spirit to a Harmony transpiler.

HookGen does not turn your game assembly into a cracked copy for distribution. It generates a helper DLL, often named like MMHOOK_Assembly-CSharp.dll, with events that use RuntimeDetour behind the scenes. The game EXE may still match Steam. The change happens live in memory.

Unity gameplay code is full of normal methods: take damage, spend currency, unlock item, check entitlement, start cooldown. If those methods exist on the client and the client decides the result, MonoMod gives a mod a clean way to intercept them. On Mono games this is especially direct. On IL2CPP games, loaders add interop so many mods can still reach equivalent targets.

A cheat does not need MonoMod's full toolkit. It only needs one reliable hook on a valuable method.

MonoMod vs HarmonyX

These two are related, but they are different tools.

HarmonyX is the higher level patch API. Authors write prefixes, postfixes, and transpilers. MonoMod is the lower level detour and IL toolkit. It can be used directly, and HarmonyX can use it underneath. BepInEx and MelonLoader often ship both.

Think of it this way: the loader is the workshop, the mod is the worker, HarmonyX is the standard wrench, and MonoMod is part of the machine shop that makes those wrenches work.

Many Unity cheat plugins stay on Harmony attributes and never mention MonoMod by name, even when MonoMod assemblies are present.

A tiny example

using MonoMod.RuntimeDetour;
using System.Reflection;

// Skip SpendCoins completely
var spendCoins = typeof(PlayerWallet).GetMethod(nameof(PlayerWallet.SpendCoins));
var hook = new Hook(spendCoins, (Action<PlayerWallet, int> orig, PlayerWallet self, int amount) =>
{
    // Do not call orig. The wallet never spends.
});

In a real cheat, that kind of hook can stop coin spending or force free unlocks. Many cheats never write this MonoMod code by hand. They write a HarmonyX prefix instead, and MonoMod still ends up in the process underneath.

The important part for developers is the model: once MonoMod style hooking is active, your methods are no longer guaranteed to run as compiled.

Why Unity developers should care

If you develop a single player game, you will mostly not care about mods or cheats. Maybe you even appreciate the extra content. A user bought the game and can modify it. No one gets hurt.

But what if someone does get hurt? That usually means financial loss for you, or a broken experience for other players. No one wants a wallhacking opponent in multiplayer. And no one wants a player on top of a competitive leaderboard without earning it.

Financially, that can mean skipping licence checks, skipping ads, or unlocking items they should not have. The attacker only needs the right method name and a host that can apply the hook.

So how can you protect your game? Let's look at the clues MonoMod leaves.

Traces MonoMod leaves

MonoMod is quieter than a full mod loader tree. Its fingerprints are the toolkit itself. Useful MonoMod specific clues include:

Assemblies such as MonoMod.RuntimeDetour, MonoMod.Utils, and often MonoMod.Core
HookGen helpers named MMHOOK_..., commonly MMHOOK_Assembly-CSharp
RuntimeDetour types such as Hook, ILHook, and DetourConfig
HookGen namespaces such as On. and IL. generated against your game types
MonoMod or MMHOOK_*.dll files on disk that are not part of your shipped build
Method entry points rewritten by RuntimeDetour after JIT

Those signals point at MonoMod style hooking even when the cheat author only writes Harmony attributes on top.

Detecting MonoMod traces

You can check for these signals in your game and then warn, restrict online features, or block startup.

MonoMod assemblies loaded into the process

A normal Unity player does not ship MonoMod. When RuntimeDetour is active, you usually see several MonoMod assemblies in the current AppDomain. Newer stacks often include MonoMod.Core under RuntimeDetour.

void Awake()
{
    bool monoModLoaded = AppDomain.CurrentDomain.GetAssemblies()
        .Any(a =>
        {
            string name = a.GetName().Name;
            return name == "MonoMod.RuntimeDetour"
                || name == "MonoMod.Utils"
                || name == "MonoMod.Core"
                || name == "MonoMod.RuntimeDetour.HookGen";
        });

    if (monoModLoaded)
    {
        Debug.Log("MonoMod assembly detected. Blocking game from starting.");
    }
}

HookGen helpers and RuntimeDetour types

HookGen generates a helper DLL whose name starts with MMHOOK_. That helper does not contain your original game code. It exposes event style hooks under namespaces like On.YourNamespace and IL.YourNamespace. An MMHOOK_ assembly in your process is a strong MonoMod signal.

Inside MonoMod.RuntimeDetour, mods construct Hook for delegate based detours and ILHook for IL rewrites. Finding those types means the MonoMod hooking API is available.

void Awake()
{
    var assemblies = AppDomain.CurrentDomain.GetAssemblies();

    bool mmhookLoaded = assemblies.Any(a => a.GetName().Name.StartsWith("MMHOOK_"));

    string[] markers =
    {
        "MonoMod.RuntimeDetour.Hook",
        "MonoMod.RuntimeDetour.ILHook",
        "MonoMod.RuntimeDetour.DetourConfig"
    };

    var typeNames = assemblies
        .SelectMany(a =>
        {
            try { return a.GetTypes(); }
            catch { return Type.EmptyTypes; }
        })
        .Select(t => t.FullName);

    bool runtimeDetourApi = markers.Any(marker => typeNames.Contains(marker));

    if (mmhookLoaded || runtimeDetourApi)
    {
        Debug.Log("MonoMod HookGen or RuntimeDetour API detected.");
    }
}

MonoMod files on disk

MonoMod often leaves files under the install tree. Typical names include MonoMod.RuntimeDetour.dll, MonoMod.Utils.dll, MonoMod.Core.dll, and MMHOOK_*.dll helpers. Scan next to your executable for those names.

void Awake()
{
    string[] monoModFiles =
    {
        "MonoMod.RuntimeDetour.dll",
        "MonoMod.Utils.dll",
        "MonoMod.Core.dll",
        "MMHOOK_Assembly-CSharp.dll"
    };

    bool found = Directory.EnumerateFiles(".", "*.dll", SearchOption.AllDirectories)
        .Select(Path.GetFileName)
        .Any(name =>
            monoModFiles.Contains(name)
            || name.StartsWith("MMHOOK_", StringComparison.OrdinalIgnoreCase));

    if (found)
    {
        Debug.Log("MonoMod files found on disk.");
    }
}

Method entry points rewritten by RuntimeDetour

MonoMod does not need to permanently rewrite your shipped DLLs on disk. A file hash can still match. What RuntimeDetour changes is the compiled method itself. After Unity has JIT compiled a method, MonoMod's native detour layer can overwrite the entry point so every call jumps into the detour chain.

A simple approach is to force a method to compile, read the first bytes of its entry point, and keep that as a baseline early at startup. Later, read those bytes again. If they changed, a detour library rewrote the method.

using System.Runtime.CompilerServices;

void Awake()
{
    MethodInfo method = typeof(PlayerWallet).GetMethod(nameof(PlayerWallet.SpendCoins));
    RuntimeHelpers.PrepareMethod(method.MethodHandle); // force JIT compile
    IntPtr entry = method.MethodHandle.GetFunctionPointer();

    // Read the first bytes at 'entry' and compare them
    // with a clean baseline taken at startup.
}

This works well on Mono desktop builds. A changed entry point proves a detour, not the name "MonoMod" by itself. Pair it with the assembly and type checks above when you want the signal to stay MonoMod specific.

You do not want to create all those checks by yourself? There are tools that can help you. Check out my Anti-Cheat solution that can help you detect MonoMod based hooking stacks and other cheating or modding tools. Plus a tone of more features to help you with your anti-cheat needs.

There is still one problem

Do you remember the example from earlier?

var spendCoins = typeof(PlayerWallet).GetMethod(nameof(PlayerWallet.SpendCoins));
var hook = new Hook(spendCoins, (Action<PlayerWallet, int> orig, PlayerWallet self, int amount) =>
{
    // Do not call orig. The wallet never spends.
});

Especially the nameof(PlayerWallet.SpendCoins) part?

All those checks you implemented to detect MonoMod are useless if an attacker can bypass them. An attacker could look for something like My.Amazing.MonoMod.Detector.Detect and hook the body of the Detect method.

There are two main ways to address this:

Outsource critical code to an external source

You can move part of your important code to an external source, such as your server, and load it at runtime. This makes it much harder for attackers to analyze your code in advance. Your detection logic can live in this external code and run before attackers have a chance to patch it.

However, this approach can be quite complicated to implement and maintain.

Use an obfuscation solution

Obfuscation can make your source code much harder to understand. That makes it harder for attackers to find and patch your detection logic. For example, a name like My.Amazing.MonoMod.Detector.Detect would become something like IUQWEWQ.XACBSCA. That is still possible to reverse, but it takes more effort.

You might consider using my Obfuscator to obfuscate your source code. It is a powerful build-time tool that can make your code much harder to understand and analyze.

Your takeaway

MonoMod is a low level .NET modding toolkit, not a loader. BepInEx and MelonLoader bring it in so mods can detour methods and rewrite IL at runtime. HarmonyX is often the friendlier API above it. Once a hook is applied, your method no longer runs as compiled. That is fine in many single player games, but it becomes a real problem when cheats hurt your revenue or other players.

The good news is that MonoMod leaves its own traces: RuntimeDetour and Core assemblies, HookGen MMHOOK_ helpers, known Hook / ILHook types, toolkit DLLs on disk, and method entry points that suddenly jump into a detour chain. You can check for those signals yourself, or use existing tools to help you.

Read more on my blog: www.guardingpearsoftware.com!

Replacing a Live MMORPG Client Without Replacing the World

GuardingPearSoftware — Mon, 10 Aug 2026 12:00:26 +0000

Fantasy Online 2 is a massively multiplayer online role-playing game you can play in a web browser or on Windows through Steam. It is a huge little pixel-art world of quests, crafting, rare loot, character builds, and adventures with other players Built around social progression and discovery. Players invest in one character across equipment, skills, factions, achievements, and cosmetics, then carry that adventure between supported platforms.

That persistent world is also what made replacing the client hard.

Replacing a game client sounds straightforward when the game is still a prototype. You can change the renderer, rebuild the interface, rewrite the input layer, and reset whatever data no longer fits. Fantasy Online 2 was already live when I began. Players had accounts, characters, inventories, quests, skills, guilds, market listings, achievements, and years of expectations about how the game behaved. The server and database had to stay online. The world could not be reset just because I wanted a better foundation for the client.

That changed the job from an engine rewrite into a live-system migration.

The first important decision was defining what would not change. The server remained authoritative. Existing accounts, character data, game content, and network messages were treated as contracts. PxEngine, the new TypeScript and WebGL2 client, had to understand the same world rather than invent a replacement for it.

That boundary reduced the risk considerably. I was not rewriting the game server, moving the database, and replacing the client at the same time. I was rebuilding the presentation, input, rendering, audio, and interface layers around a backend that players already depended on.

Parity came before improvement

The most tempting mistake during a migration is redesigning every system while porting it. A new interface makes old choices look dated, and a new renderer makes it easy to imagine larger structural changes. Doing both at once makes failures much harder to diagnose.

I made feature parity the first target. Login, character selection, zone loading, movement, combat, inventory, equipment, skills, quests, dialogue, shops, crafting, parties, guilds, banking, trading, settings, reconnect behavior, and error states all needed to survive the move.

A system was not complete just because its main screen rendered. Inventory also had to handle pending operations, full bags, drag cancellation, server rejection, and updates arriving while another window was open. Skills had to cover casting from the book, hotbar assignment, cooldowns, targeting, and failure conditions. Mobile input had to block touches where desktop mouse input was already blocked. Those edge cases are where a port that looks finished begins to feel unreliable.

The production game became the specification. Old behavior, server responses, player reports, and real content were more useful than a clean theoretical design document.

Building for the actual workload

PxEngine is a custom TypeScript and WebGL2 client built around Fantasy Online 2's real requirements. It renders tile maps, animated sprites, effects, particles, interface windows, and GPU text while handling mouse, keyboard, controller, and touch input.

The engine uses retained buffers, pooling, and preallocated working storage wherever the game would otherwise create garbage every frame. Browser garbage collection is not automatically a problem, but repeated per-frame allocation can turn into visible pauses during movement or combat. Avoiding those allocations also makes performance more predictable across a wide range of devices.

That does not mean every subsystem was generalized into a giant reusable framework. The useful approach was to build the smallest solid primitive that solved a production need, then expand it when another real feature required more. The tile renderer, sprite batching, text system, GUI batching, pathfinding, particles, and input stack all grew from scenes the game actually had to run.

Keeping the server authoritative helped here too. The client could focus on responsive presentation and clear feedback while the server remained the source of truth for movement, combat, inventory, quests, and progression. That gave the migration a stable center even while the visual and interaction layers were changing quickly.

Ship the migration in slices

A live migration needs checkpoints that players can actually exercise. Waiting until every old feature has been recreated produces one enormous, difficult-to-debug launch.

I brought the new client to the official website and CrazyGames first. That exposed the browser build to real accounts, real network conditions, and the full production data set. Android followed after the touch controls, storage behavior, layout constraints, and platform wrapper were ready for broader use. Steam has its own migration and testing path; it is not treated as a simple copy of the browser release.

The core client stays shared, while platform-specific code remains around the edges. Authentication, local storage, storefront behavior, and wrappers differ, but movement, rendering, combat, interface systems, and game content do not need separate implementations for every platform.

This staged rollout also made bug reports more useful. A setting that appeared correct in the browser could still fail when a platform supplied a different storage service. A window that blocked mouse input could still allow a mobile touch to pass through. A reconnect path could work during local testing and fail after a real network interruption. Shipping smaller slices made those boundaries visible.

The mistakes were usually at the seams

The hardest bugs were rarely in a single isolated renderer function. They appeared where systems met.

A feature might display correctly but lose its state after a new session. A touch event might reach the world through an open interface window. A remote actor could receive the right server update while showing the wrong transient effect. A UI port finished too quickly could preserve the happy path but miss drag cancellation, selection state, or server rejection.

The lesson was to test each feature as a state machine rather than as a screenshot. What happens before the action, while it is pending, after success, after rejection, after reconnecting, and after changing platforms? That checklist catches far more than asking whether a button works.

It also helped to keep the distribution wrappers thin. The more game logic that moves into platform-specific code, the harder it becomes to know whether a bug belongs to the game, the engine, the wrapper, authentication, or storage.

What made the migration possible

The migration worked because it had a stable boundary. The server protocol, persistent data, and game rules remained the center of the system. PxEngine could replace the client one subsystem at a time without asking players to abandon their characters or asking the backend to become a different game simultaneously.

For another small team considering the same kind of move, my main recommendations are:

Decide which contracts must remain stable before writing the replacement.
Build a complete parity checklist that includes failure and persistence states.
Separate platform wrappers from shared game logic.
Test against real production content as early as possible.
Ship in controlled slices with a rollback path.
Treat player reports as evidence about system boundaries, not just isolated bugs.
Delay unrelated redesigns until the replacement is trustworthy.

The successful moment is not when the new renderer draws its first map. It is when a returning player logs in, sees the same character and world, and continues playing without needing to understand how much changed underneath.

Play Fantasy Online 2

Fantasy Online 2 can be played here: fantasyonline2.com

About the author

Jeromy Stroh is the solo developer of Fantasy Online 2 and the founder of Pixel Games LLC. He works primarily in TypeScript, WebGL2, Java, and MySQL while building and operating the game's custom client, persistent world, server, and player tools.

Read more on my blog: www.guardingpearsoftware.com!

What HarmonyX is and how Unity developers can detect it

GuardingPearSoftware — Sun, 09 Aug 2026 17:46:31 +0000

If you have read about BepInEx or MelonLoader, you have probably also seen HarmonyX mentioned right next to them. HarmonyX is not another mod loader. It is the patching library that many mods use after a loader has already put their code into your game.

You will learn what HarmonyX is, how mod loaders and frameworks use it, and what it technically does inside a Unity process.

What HarmonyX is

HarmonyX is a runtime method patching library for .NET code. In the Unity world, that usually means it can change how your C# methods behave while the game is already running.

It is a BepInEx maintained fork of the original Harmony project (often called Lib.Harmony). Most Unity modding docs simply say "Harmony," but BepInEx and MelonLoader commonly ship HarmonyX specifically.

A useful way to place it in the stack:

BepInEx or MelonLoader are the frameworks and loaders. They get into the process and load mods.
The mod or plugin is the actual cheat or feature code.
HarmonyX is the library that mod uses to rewrite game methods.

So HarmonyX is a tool used by frameworks and by the mods those frameworks load. It is not the host that starts the modding session.

How mod loaders and frameworks use HarmonyX

Tools like BepInEx and MelonLoader include HarmonyX, so plugin authors do not have to ship their own patcher.

The usual flow for a mod using HarmonyX looks like this:

The loader boots into the Unity process.
The loader finds and loads plugin or mod DLLs.
A plugin creates a Harmony instance, often with a unique ID.
The plugin calls something like PatchAll() to apply its patch classes.
From that moment, selected game methods run through the patched path.

That is why people sometimes think HarmonyX "is BepInEx." BepInEx makes HarmonyX easy to use, but HarmonyX can also work outside BepInEx if some other host loads the assembly first.

In practice, a mod uses HarmonyX when it wants to do things like:

Run code before a method starts
Run code after a method finishes
Change parameters or return values
Skip the original method completely
Rewrite parts of the method's IL for more advanced changes

For legitimate mods, that might mean better UI, accessibility options, or content hooks. For cheats, that might mean forcing return true on a purchase check, skipping cooldowns, or rewriting damage and inventory logic.

How HarmonyX works technically

HarmonyX does not edit your source code and it does not need to permanently rewrite your shipped DLLs on disk. It patches methods at runtime.

At a high level, HarmonyX:

Finds the target method through reflection.
Collects your prefix, postfix, transpiler, or finalizer patches.
Builds a new combined method that includes those patches.
Redirects the original method to that new implementation.

After that redirect, every call to the original method goes through the patched version instead.

Prefixes

A prefix runs before the original method. It can inspect or change inputs. It can also return false to skip the original method body. That is one of the simplest cheat patterns: patch a validation method with a prefix that returns early and pretends everything is valid.

Postfixes

A postfix runs after the original method. It can read or replace the result. A common pattern is "let the game calculate the value, then overwrite the return with something better for the cheater."

Transpilers

A transpiler edits the Intermediate Language (IL) of the method before the patched version is created. This is more advanced. Instead of only wrapping the method, the mod can change individual instructions inside it.

Why this is powerful in Unity

Unity gameplay code is full of normal methods: take damage, spend currency, unlock item, check entitlement, start cooldown, submit score. If those methods exist on the client and the client is allowed to decide the result, HarmonyX gives a mod a clean way to intercept them.

On Mono games, this is especially direct because the managed methods are easier to target. On IL2CPP games, the loader and interop layer still let many mods reach equivalent method targets, so HarmonyX style patching remains relevant there too.

A tiny example

[HarmonyPatch(typeof(PlayerWallet), nameof(PlayerWallet.SpendCoins))]
class SpendCoinsPatch
{
    // Runs before SpendCoins
    static bool Prefix(int amount)
    {
        // Skip the original method completely
        return false;
    }
}

In a real cheat, that kind of patch can stop coin spending, force free unlocks, or combine with a postfix that changes balances. The important part for developers is not this exact sample. The important part is the model: once HarmonyX is active, your methods are no longer guaranteed to run as compiled.

Why Unity developers should care

If you develop a single player game, you will mostly not care about mods or cheats. Maybe you even appreciate the extra content and longer lifecycle other players create. A user bought the game or app and can modify it to their advantage. No one gets hurt.

But what if someone does get hurt? That usually means financial loss for you as the developer, or a broken experience for your players. No one wants a speeding or wallhacking opponent in a multiplayer game. And no one wants a player sitting on top of a competitive leaderboard without actually being the best.

Financially, that can mean skipping licence checks, skipping ads, or unlocking items and features they should not have.

The attacker does not need to reverse every system. They only need the right method name and a loader that can host the patch.

So how can you protect your game? Let's start by looking at the clues HarmonyX leaves.

Traces HarmonyX leaves

HarmonyX is quieter than a full mod loader tree, but it still leaves clues:

Managed assemblies such as HarmonyX or 0Harmony loaded into the process
Known Harmony types and patch registries present at runtime
Methods that suddenly have detours or wrappers they did not have at build time
Loader folders nearby, because HarmonyX patches usually arrive through BepInEx or MelonLoader

In Unity games, HarmonyX plus an unofficial loader is a very common modding and cheating pattern. It is a pattern that can be detected and blocked.

Detecting HarmonyX traces

The traces from the prior chapter are a good starting point. You can check for them in your game and decide what to do next: warn, restrict online features, or block startup.

Loader folders nearby, because HarmonyX patches usually arrive through BepInEx or MelonLoader.

HarmonyX rarely shows up alone. It usually arrives with a loader, and that loader leaves folders and files next to your game install.

BepInEx often looks like this:

BepInEx/
BepInEx/core/
BepInEx/plugins/
BepInEx/config/
BepInEx/patchers/
doorstop_config.ini

MelonLoader is a bit more mixed, and can include things like:

MelonLoader/
Mods/
Plugins/
UserData/
UserLibs/
version.dll, winhttp.dll, or dobby.dll

A simple first check is to look for those loader folders when your game starts. If they are present, you can treat that as a strong signal and block the session.

void Awake()
{
    if (Directory.Exists("BepInEx") || Directory.Exists("MelonLoader"))
    {
        Debug.Log("Mod loader detected. Blocking game from starting.");
    }
}

Managed assemblies such as `HarmonyX` or `0Harmony` loaded into the process

HarmonyX is loaded into the process as a managed assembly. The common assembly names are 0Harmony and sometimes HarmonyX. That is the DLL name, not a C# type name. You can detect it by scanning the assemblies already loaded into the current AppDomain.

void Awake()
{
    bool harmonyLoaded = AppDomain.CurrentDomain.GetAssemblies()
        .Any(a =>
        {
            string name = a.GetName().Name;
            return name == "0Harmony" || name == "HarmonyX";
        });

    if (harmonyLoaded)
    {
        Debug.Log("HarmonyX detected. Blocking game from starting.");
    }
}

Known Harmony types and patch registries present at runtime

Inside that assembly, Harmony exposes types in the HarmonyLib namespace. Useful signals include HarmonyLib.Harmony, HarmonyLib.PatchProcessor, and related patch metadata types. Once patches are applied, Harmony also keeps a runtime registry of patched methods. You can look for the known types first, then ask that registry if anything was patched.

void Awake()
{
    Type harmonyType = AppDomain.CurrentDomain.GetAssemblies()
        .SelectMany(a =>
        {
            try { return a.GetTypes(); }
            catch { return Type.EmptyTypes; }
        })
        .FirstOrDefault(t => t.FullName == "HarmonyLib.Harmony");

    if (harmonyType == null)
        return;

    Debug.Log("Harmony type detected.");

    MethodInfo getAllPatchedMethods = harmonyType.GetMethod(
        "GetAllPatchedMethods",
        BindingFlags.Public | BindingFlags.Static);

    if (getAllPatchedMethods == null)
        return;

    var patchedMethods = getAllPatchedMethods.Invoke(null, null) as IEnumerable;
    if (patchedMethods != null && patchedMethods.Cast<object>().Any())
    {
        Debug.Log("Harmony patch registry has active patches.");
    }
}

Methods that suddenly have detours or wrappers they did not have at build time

This topic is a bit more complex, and detection is not as simple as with the other traces. HarmonyX does not change your DLL on disk, nor does it rewrite the managed IL sitting in memory. If you hash the loaded assembly and compare it with the file next to your game, both will look the same.

What does change is the compiled method itself. After Unity has JIT compiled a method, Harmony can overwrite the entry point so every call jumps into a patched version. That jump is the signal you can check for.

using System.Runtime.CompilerServices;

void Awake()
{
    MethodInfo method = typeof(PlayerWallet).GetMethod(nameof(PlayerWallet.SpendCoins));
    RuntimeHelpers.PrepareMethod(method.MethodHandle); // force JIT compile
    IntPtr entry = method.MethodHandle.GetFunctionPointer();

    // Read the first bytes at 'entry' and compare them
    // with a clean baseline taken at startup.
}

One thing to keep in mind: this works well on Mono desktop builds, and a changed entry point proves a hook, not HarmonyX by name. For cheat detection that is usually fine, because any detour library that rewrites your methods leaves the same kind of fingerprint.

You do not want to create all those checks by yourself? There are tools that can help you. Check out my Anti-Cheat solution that can help you detect HarmonyX and other cheating or modding tools. Plus a tone of more features to help you with your anti-cheat needs.

There is still one problem

Do you remember the example from the beginning of this article?

[HarmonyPatch(typeof(PlayerWallet), nameof(PlayerWallet.SpendCoins))]
class SpendCoinsPatch
{
    // Runs before SpendCoins
    static bool Prefix(int amount)
    {
        // Skip the original method completely
        return false;
    }
}

Especially the nameof(PlayerWallet.SpendCoins) part?

All those fancy checks you implemented to detect HarmonyX are useless if an attacker can simply bypass them. An attacker could look for something like My.Amazing.HarmonyX.Detector.Detect and patch the body of the Detect method.

There are two main ways to address this:

Outsource critical code to an external source

You can move part of your important code to an external source, such as your server, and load it at runtime. This makes it much harder for attackers to analyze your code in advance. Your detection logic can reside in this external code and execute before attackers have a chance to patch it. As a result, they won't see exactly what happens or know what to patch.

However, this approach can be quite complicated to implement and maintain.

Use an obfuscation solution

Obfuscation can make your source code very difficult to understand and analyze. This makes it much harder for attackers to find and patch your detection logic. For example, a name like My.Amazing.HarmonyX.Detector.Detect would become something like IUQWEWQ.XACBSCA, making it significantly more difficult to locate and modify. While not impossible, it greatly increases the level of effort required.

You might consider using my Obfuscator to obfuscate your source code. It is a powerful build-time tool that can make your code much harder to understand and analyze.

Your takeaway

HarmonyX is a runtime patching library, not a loader. BepInEx and MelonLoader bring it in so mods can rewrite Unity methods. Once a patch is applied, your method no longer runs as compiled. That is fine in many single player games, but it becomes a real problem when cheats or hacks hurt your revenue or other players.

The good news is that HarmonyX leaves traces: loader folders, assemblies, known types and method entry points that suddenly jump somewhere else. You can check for those signals yourself, or use existing tools to help you.

Read more on my blog: www.guardingpearsoftware.com!

Snake: Gridbreaker - What changed when player occupied twenty cells!

GuardingPearSoftware — Sat, 08 Aug 2026 18:21:13 +0000

A position is one of the first concepts we learn when programming a game.

The player is at (10, 12).
An enemy is at (4, 8).
A portal moves the player from one position to another.

Classic Snake already breaks this simple model. The head has a position, but so does every segment behind it. Together, those positions form the player.

I understood that before starting Snake: Gridbreaker. What I missed was how many systems would eventually depend on the exact meaning of the word “player.”

Sometimes the player meant the head. Collision checks often cared about the next head position.
Sometimes it meant the complete body. Rendering, self-collision, area transitions and several build mechanics needed every segment.
In a few cases, the player was closer to a process than to an object. The head started an action, while the tail completed it several movement ticks later.

That distinction became important after the prototype grew into an action roguelite with enemies, hazards, classes, shops, mutations, secret rooms and bosses.

The initial version proved that the idea could work. The following 1,600 commits taught me what the original prototype had left unanswered.

The array was fine at first

My first representation of the snake body was an array ordered from head to tail.

Movement looked roughly like this:

func move_snake(target: Vector2i, grow: bool) -> void:
    if not grow:
        snake_body.pop_back()

    snake_body.insert(0, target)

The code is easy to read:

Remove the final element.
Insert a new head at index zero.

For a short prototype, I would probably make the same choice again.

The problem appeared gradually. insert(0, value) has to move the existing elements in the array. Other systems also used checks such as:

if position in snake_body:
    # The cell is occupied.

Those operations became part of normal movement. They also became more common as the body gained more responsibilities.

The snake was no longer only a visual trail. Its length affected builds. Hazards could interact with specific segments. Systems asked:

whether a position belonged to the body
where the tail was
how the body should be restored after loading

I eventually replaced the direct array with circular deque storage.

The current structure keeps a backing array, an index pointing to the head and the current length:

var _snake_segments: Array[Vector2i] = []
var _snake_head_index: int = 0
var _snake_length: int = 0
var _snake_occupancy: Dictionary[Vector2i, int] = {}

A normal movement step changes the head index instead of shifting the whole body:

func move_snake_to(target: Vector2i, grow: bool) -> void:
    if not grow:
        var old_tail := get_tail_position()
        _decrement_snake_occupancy(old_tail)
        _snake_length -= 1

    _ensure_snake_capacity(_snake_length + 1)
    _snake_head_index = _wrap_snake_index(_snake_head_index - 1)
    _snake_segments[_snake_head_index] = target
    _snake_length += 1

    _increment_snake_occupancy(target)
    _mark_snake_body_snapshot_dirty()

The occupancy dictionary answers membership questions without scanning the body.

I still needed compatibility with systems that expected an ordered array. Rewriting all of them at once would have made the change much riskier, so get_snake_body() creates an ordered snapshot only when something requests it after the body has changed:

func get_snake_body() -> Array[Vector2i]:
    if _snake_body_snapshot_dirty:
        _snake_body_snapshot.clear()

        for i in range(_snake_length):
            var index := _wrap_snake_index(_snake_head_index + i)
            _snake_body_snapshot.append(_snake_segments[index])

        _snake_body_snapshot_dirty = false

    return _snake_body_snapshot

This gave the storage a faster movement path while preserving the old interface during migration.

I would not start every Snake prototype with this structure.

For a snake containing five segments and a game that is still proving its basic idea, the simple array is easier to inspect and modify. The deque became worthwhile after movement became frequent, the body grew longer and many systems depended on it.

The useful question was not whether a circular buffer was theoretically better. I needed to know whether the current representation was creating work in the hottest part of the game.

By then, it was.

Rendering faster did not solve the first problem

Performance problems appeared as the board gained more content.

My first instinct was to improve the renderer. I looked at how cells and body lines were drawn, how many visual nodes existed and how often geometry was rebuilt.

Some of those areas did need work. Per-cell nodes were later replaced with MultiMesh renderers, trails were pooled and several visual systems became incremental.

The earlier mistake was broader.

The game was asking the renderer to update objects that had not changed.

The first architecture used one main notification:

signal board_changed(board)

After movement, the game emitted it:

board.move_snake_to(target_position, grow)
emit_signal("board_changed", board)

The view received a new board state and performed a broad synchronization.

That is a sensible design for a prototype. One signal means fewer update paths and fewer chances for the visual state to fall behind the logical state.

It becomes expensive when the most common event is a snake moving by one cell.

During a clean movement step, the walls remain where they were. Food usually stays in place. Hazards, items and the exit do not need to be reconstructed. The body loses a tail cell and gains a head cell.

I introduced a separate signal for that path:

signal board_changed(board)
signal snake_changed(body)

The movement code could then decide what had actually happened:

if board_visual_changed:
    emit_signal("board_changed", board)
elif snake_moved:
    emit_signal("snake_changed", board.get_snake_body())

This was the start rather than the final design. As the project continued, the broad notification split into more specific signals for terrain, pickups, hazards, enemies and interactions.

I do not have a reliable before-and-after FPS chart for the original change.

The game was evolving quickly, and several rendering changes happened around the same period. Presenting one clean percentage would imply a controlled benchmark that I did not perform.

What I do have is a set of testable invariants:

A clean movement should not emit board_changed.
It should emit snake_changed once.
A non-growing step should logically touch at most the old tail cell and the new head cell.
A growing step only needs to add the new head.

Those guarantees are less exciting than an impressive FPS number, but they protect the architecture from slowly returning to full-board work.

Here is the order in which the optimization actually developed:

Broad board refresh
Separate clean snake movement
Update individual board layers
Replace expensive per-cell presentation

I originally started near the bottom of this sequence.

Reducing the amount of work at the top produced a more useful change.

A portal became a multi-step operation

Secret rooms introduced a problem that I had not encountered with normal player characters.

Consider a snake moving into a breach:

Source board                 Destination board

[T][B][B][H] -> | BREACH |   [ entry cells ]

H is the head, B is a body segment and T is the tail.

The head reaches the breach first. Several movement ticks may pass before the tail arrives.

My first mental model was an ordinary teleport. Commit the destination board, place the player on it and hide the swap behind an animation.

That model produced an obvious visual problem.

The breach could close while most of the body was still meant to be passing through it.

Moving the complete body instantly also looked wrong. The head had entered naturally, but the tail vanished from the previous board.

The transition eventually became a release process.

After the board handoff, only part of the snake was shown as fully emerged:

Source board                 Destination board

[T][B] -> | BREACH | -> [H][B]
           still open

Each movement revealed another segment. The game tracked whether a portal release was active, how many solid segments had emerged and the emergence direction.

A simplified version of the state looks like this:

portal_release_active = true
portal_release_solid_count = 1
portal_release_direction = exit_direction

Then movement advances the release:

func advance_portal_release() -> void:
    portal_release_solid_count += 1

    if portal_release_solid_count >= get_snake_length():
        portal_release_active = false
        seal_breach_visual()

The final state is ordinary gameplay again:

Source board                 Destination board

             | SEALED |      [H][B][B][T]

The actual implementation also had to survive saving, loading and transitions back to the main board. Collision state could be authoritative before the visual aperture closed, so logical safety and visual continuity were handled separately.

The terminology helped here:

“Hide the board swap” described a presentation trick.
“Portal handoff” described a state change.
“Portal release” described the body emerging over time.

Once those operations had separate names, it became easier to decide which system owned each part.

This design is still more complicated than an instant teleport. Instant teleportation would be a valid solution if I wanted a fast flash and were willing to accept the complete body moving at once.

I kept the gradual emergence because preserving the physical continuity of the snake mattered to the feel of this particular transition.

The state machine follows from that design decision. It is not a requirement for every segmented character.

Four directions still needed an input resolver

The first controller implementation checked movement actions one after another:

if Input.is_action_just_pressed("move_up"):
    queue_direction(Vector2i.UP)

if Input.is_action_just_pressed("move_down"):
    queue_direction(Vector2i.DOWN)

if Input.is_action_just_pressed("move_left"):
    queue_direction(Vector2i.LEFT)

if Input.is_action_just_pressed("move_right"):
    queue_direction(Vector2i.RIGHT)

This worked with a keyboard.

It became less predictable when several controller sources were active. A player could hold Up on the D-pad and move the analog stick sideways. Diagonal stick input could also make more than one action cross its threshold.

Sequential checks allowed several directions to compete during the same input update.

Snake is unforgiving here. A direction selected for a fraction of a second may place the head into the body or into a wall.

The input system now resolves all controller data into one vector before adding anything to the movement queue.

The current implementation gives the D-pad priority while any D-pad button is held. Analog input uses different thresholds for activation and release:

const STICK_ACTIVATION_THRESHOLD := 0.50
const STICK_RELEASE_THRESHOLD := 0.35
const STICK_AXIS_DOMINANCE_RATIO := 1.25
const STICK_AXIS_NEAR_EQUAL_GAP := 0.05

The gap between 0.50 and 0.35 creates hysteresis.

Hysteresis means that the boundaries for entering a state and leaving it are different.

A stick must move far enough to select a direction. Once selected, a small drop in strength does not immediately release it. Without that gap, noisy input near one threshold can repeatedly switch between active and inactive.

The resolver is roughly:

func resolve_direction() -> Vector2i:
    if any_dpad_button_is_held():
        return resolve_dpad()

    var stick := read_stick_vector()

    if stick_is_below_release_threshold(stick):
        return Vector2i.ZERO

    if stick_is_near_diagonal(stick):
        return previous_resolved_direction

    return dominant_axis_direction(stick)

The exact threshold values came from this game and its movement feel. They are not universal controller constants.

The important change was resolving one intended direction before touching the queue.

Input buffering solved another issue. At high speed, a player may press Up and then Left between two movement ticks. A short queue preserves both turns, while validation rejects reversals and duplicate inputs.

Controller work later spread into menus, focus restoration, overlays, disconnected devices and versioned binding migrations. Those are separate problems, although they share one rule: the game needs an explicit owner for the current input state.

A keyboard-only prototype does not need all of this. Even a digital-only controller setup can stay much simpler.

The resolver became necessary when D-pad input, analog input and a strict four-direction movement model had to coexist.

Multi-frame effects need an escape route

Portals are one example of an operation that lasts across several frames. Animations, pauses and temporary effects create the same type of risk.

A code review found a subtle problem in a death effect.

The effect was shrinking a sprite by interpolating from its current scale every frame:

sprite.scale = sprite.scale.lerp(end_scale, progress)

The current scale already contained the result of the previous frame. Reusing it as the starting point caused the values to compound. The final size depended on how often the update ran.

The correction stored the initial scale once:

sprite.scale = initial_scale * lerpf(1.0, END_SCALE, progress)

The same sequence temporarily changed the global time scale. Under normal completion, it restored the previous value.

There was still an interruption path.

If the scene was removed while the sequence was waiting for an animation, the cleanup code on the normal completion path might never execute. The next scene could inherit a time scale of 0 or 0.25.

The fix stored the previous value on the sequence and restored it from _exit_tree() as well:

func _exit_tree() -> void:
    Engine.time_scale = previous_time_scale

This changed the way I review multi-frame code.

I look at the normal timeline first, then I interrupt it mentally:

What if the player quits?
What if the scene changes?
What if an awaited object is deleted?
What if a save is loaded in the middle?

A system that has a start and an expected finish also needs a path for cases where it never reaches that finish.

Giving AI instructions created another source of stale state

AI coding tools have helped with implementation, tests, reviews and refactors throughout the project.

They work better when the repository explains itself.

I added files describing architecture, conventions, verification commands and project-specific constraints. AGENTS.md, for example, now contains rules about commits, type annotations, deployment and the need to expose architectural compromises instead of hiding them.

While reviewing the repository for this article, I found a useful failure in that approach.

An older guidance file still said that the project had no test framework. It also described game.gd as the owner of the authoritative grid and documented the snake as a normal array.

Those statements were accurate for an earlier version.

They had become instructions pointing toward an architecture that the project had already replaced.

An agent following them carefully could make a worse change than an agent receiving no architecture description at all. The wrong guidance would make the mistake look intentional.

I have spent plenty of time explaining that documentation helps AI understand a codebase. The missing half of that advice is maintenance.

Agent instructions behave like code-adjacent state:

They can become stale.
They can disagree with the implementation.
They deserve review after a large refactor.

This is now part of the same checklist I use for runtime systems. When ownership changes, I search for every place where the old ownership model may still exist. That includes tests, comments, plans and AI guidance files.

The repository should describe the current project rather than preserve a confident explanation of its past.

Teaching without stopping the game

The technical problems were only half of the difficulty. Snake: Gridbreaker also moves quickly, and that changes how much information the player can reasonably process.

One of the hardest design questions was how to present objectives without asking the player to stop and read. A level still needs to communicate what matters, but a long explanation competes directly with movement, combat and the risk of colliding with the snake’s own body.

Removing a traditional tutorial did not remove the need to teach. It moved teaching into progression, animation, level structure and feedback.

The first version of a system often feels clear to its developer because the developer already knows why it exists. A new player sees several unknowns at once: what the objective means, which objects are dangerous, what an enemy is preparing to do and which part of the snake is responsible for an effect.

This became more difficult as the number of possible builds increased.

Each class has its own mastery progression. Runs can also introduce abilities, mutations, items and systems that change how movement, the head, the tail, shields, power-ups or the economy behave. Showing all of that immediately would make the early game broader, but not necessarily deeper. The player would be learning terminology instead of learning through decisions.

The Anomaly System became one answer to that problem.

It acts as metaprogression, but it also controls the order in which complexity enters the game. New abilities and mechanics appear gradually, after the player has already formed a basic model of movement and survival.

That changed how I think about unlock systems. They are not only rewards. They can also be a form of information budgeting.

A new mechanic has a cost beyond implementation and balance. It consumes part of the player’s attention. Introducing several mechanics together may make each one less visible, even if every individual mechanic is explained correctly.

The same principle applies inside a level.

Enemy attacks need to be understandable while the player is moving. Telegraphing cannot rely only on a tooltip or an icon. The shape, timing, animation and sound of an attack have to communicate enough information before the attack resolves.

At low speed, a slightly unclear effect may only cause hesitation. At high speed, it can cause an immediate collision.

This means readability is not separate from difficulty. It is part of difficulty.

I want the game to be challenging, but I do not want every death to feel arbitrary. The useful question after a failed run is not only whether the player lost. It is whether the player can form a better plan for the next attempt.

A readable failure can still be severe:

The snake may move too quickly.
A wall may remove the last safe route.
An enemy may force the head toward the body.
A build may become powerful but difficult to control.

The game does not need to protect the player from those outcomes, but it should make the chain of cause and effect visible enough to learn from.

That balancing act is still ongoing.

If every threat waits too long, the game loses pressure. If every signal is subtle, the player may understand the rules only after dying several times for reasons that feel unrelated to their decisions.

I am aiming for a state in which the player can say, “I see why that happened,” even when the correct response would have been difficult.

Variation created another design problem.

A run should not feel different merely because rooms and rewards appear in another order. I wanted some discoveries to change the player’s priorities. Secret rooms and risk rooms help with that because entering them is not only a content change. It is a decision about whether the current build can afford another danger.

That kind of variation is more useful to me than randomness by itself.

A secret room can offer an opportunity that changes the direction of a run. A risk room can turn a strong build into a dangerous gamble. The important part is that the player chooses to engage with the possibility.

The broader lesson is that fast games still need space for thought, but that space does not always have to be a pause screen. It can appear in:

the order of unlocks
the shape of an arena
a short warning animation
the decision to enter an optional room
the moment after death, when the result is clear enough to suggest a different choice next time

The goal is not to remove complexity. The goal is to schedule it, signal it and connect it to decisions the player can understand.

Where I would keep the simpler version

Several solutions in this article would have been unnecessary during the first weeks of development. I would still:

begin a small Snake prototype with an array
consider one broad board update signal before creating six specialized paths
use direct digital input checks if the game only supported a keyboard
teleport the full body immediately if preserving movement through the portal did not matter visually

The later systems cost more to understand and maintain. They earn that cost by solving specific problems:

Movement repeatedly shifts or scans a growing body.
Broad notifications rebuild unchanged layers.
The body must visibly cross a boundary over time.
Several controller sources can produce conflicting directions.
Long-running effects can be interrupted.

This matters because a postmortem can make every final decision look inevitable.

It was not.

The original implementations were useful because they allowed the game to exist quickly. I replaced them after the cost became visible in the profiler, in tests or through bugs I could reproduce.

Starting with the final architecture would have delayed the prototype and required me to predict problems before I understood the game.

The questions left by those bugs

My current checklist is fairly small.

What does this system mean by “the player”?
Who owns the state it wants to change?
Which parts of the game actually need an update?
Can the operation be interrupted before its expected end?
Is an old save, test or documentation file still describing the previous model?

Each question came from a real problem in the repository:

The circular deque came from treating the body as a constantly rebuilt array.
Granular signals came from treating every movement as a new board.
The portal release came from treating the snake as one teleportable position.
The input resolver came from treating four actions as four independent intentions.
The cleanup paths came from assuming that every sequence reaches its final line.

Snake movement is still easy to explain: the head moves and the body follows.

The difficult part was deciding what “follows” meant inside every other system:

Sometimes the body followed within the same function.
Sometimes it followed on the next movement tick.
At the portal, the tail completed an operation that the head had started several ticks earlier.

That is the most useful change in how I think about the project now. The player is represented by positions, but its behaviour often unfolds as a process.

About the author

Arkadiusz Włodarczyk is a programming instructor and solo game developer from Poland. He develops Snake: Gridbreaker under GEM Games and has taught programming to more than 350,000 students.

Links

Read more on my blog: www.guardingpearsoftware.com!

Protecting Corporate Data on Personal Devices: Best Practices for Securing BYOD Workplace

GuardingPearSoftware — Fri, 07 Aug 2026 14:11:46 +0000

The boundary between personal and professional life has become increasingly blurred. Employees no longer rely solely on company-issued laptops and smartphones to perform their jobs. Instead, many use their personal devices to access corporate email, collaborate with colleagues, edit sensitive documents, and connect to cloud applications from virtually anywhere. This trend, commonly known as Bring Your Own Device (BYOD), has become a standard practice across organizations of all sizes.

This article explores the risks associated with BYOD and outlines practical strategies organizations can implement to protect corporate data without compromising employee productivity.

Benefits of BYOD

Lower Hardware Costs

BYOD can significantly reduce an organization's technology expenses by shifting some of the cost of purchasing devices to employees. Instead of buying laptops or smartphones for every staff member, organizations may only need to provide software licenses, security tools, or partial reimbursements. This reduction in capital expenditure allows businesses, particularly small and medium-sized enterprises, to allocate more resources toward strategic initiatives such as cybersecurity, innovation, employee training, or business expansion.

Greater Workplace Flexibility

Allowing employees to use their personal devices supports flexible working arrangements, including remote work and hybrid work models. Employees can securely access company resources from virtually any location without relying on organization-issued equipment. This flexibility enables businesses to maintain operations during travel, emergencies, or unexpected disruptions while supporting a modern workforce that values mobility and work-life balance.

Improved Employee Satisfaction

Many employees prefer using devices they have personally selected and customized rather than standardized corporate hardware. Familiar devices often provide a more comfortable user experience, enabling employees to work more confidently and efficiently. BYOD can increase job satisfaction by giving staff greater autonomy over how they work, which may contribute to higher employee engagement, improved morale, and better retention rates.

Faster Technology Adoption

Employees typically replace their personal devices more frequently than organizations refresh corporate hardware. As a result, businesses implementing BYOD often benefit from access to newer smartphones, tablets, and laptops with improved processing power, improved security features, and better battery life. Organizations can take advantage of modern technology without bearing the full cost of frequent hardware upgrades, helping employees work more efficiently with up-to-date devices.

Collaboration

BYOD enables employees to stay connected through communication and collaboration platforms regardless of their location. Access to messaging applications, video conferencing tools, shared documents, and cloud-based productivity suites allows teams to communicate in real time and collaborate more effectively. This continuous connectivity improves coordination across departments, speeds up decision-making, and supports collaboration among geographically dispersed teams.

The Security Risks of Personal Devices

Unlike company-issued devices, personal devices are primarily managed by their owners rather than the IT department. These behaviors create opportunities for attackers.

Malware Infections

Personal devices frequently download applications from app stores, websites, and third-party sources. Some apps may contain malware capable of stealing credentials, recording keystrokes, or accessing stored files. If an infected device connects to corporate resources, attackers may gain unauthorized access to business data.

Lost or Stolen Devices

Smartphones and laptops are easily misplaced or stolen. If a device stores corporate emails, documents, authentication tokens, or credentials without encryption, unauthorized individuals may gain access to sensitive company information.

Weak Authentication

Many users continue to rely on simple passwords or reuse credentials across multiple accounts. If attackers obtain credentials through phishing or data breaches, they may successfully log into corporate systems from compromised personal devices.

Unsecured Networks

Employees frequently use their personal devices to access corporate resources from coffee shops, airports, hotels, and other public locations where Wi-Fi networks may be open or poorly secured. These environments increase the risk of cyberattacks, including man-in-the-middle attacks, rogue Wi-Fi hotspots, session hijacking, and traffic interception, all of which can allow attackers to intercept sensitive communications or steal credentials. Without strong security measures such as encrypted connections, VPNs, and secure authentication, confidential corporate information transmitted over these networks may be exposed to unauthorized parties.

Shadow IT

Employees sometimes install unauthorized applications to improve productivity. These unofficial tools may store corporate data outside approved environments, making it difficult for IT teams to monitor or protect sensitive information.

Mixing Personal and Business Data

Personal devices often contain family photos, social media applications, entertainment software, banking apps, and work documents all on the same system. Without proper separation, corporate files may be accidentally shared, backed up to personal cloud storage, or exposed through consumer applications.

Compliance Risks

Organizations implementing BYOD programs often face greater challenges in meeting regulatory and data privacy requirements. As employees access and store business information on personal devices, organizations have less direct control over how sensitive data is protected, managed, and removed. Failure to adequately secure customer or corporate information, or to ensure that business data is completely erased from personal devices when employees leave the organization, can result in regulatory violations, financial penalties, legal consequences, and reputational damage.

Best Practices for Protecting Corporate Data

Implement a Clear BYOD Policy

Organizations should establish a comprehensive BYOD policy that clearly defines the rules governing the use of personal devices for work. The policy should specify which devices are approved, minimum operating system requirements, mandatory security controls, acceptable use guidelines, employee responsibilities, privacy expectations, and procedures for reporting lost devices or security incidents.

It should also explain what business data the organization can access on personal devices and what personal information remains private. A well-defined policy helps ensure that employees understand their responsibilities while providing a consistent framework for securing corporate data.

Use Mobile Device Management (MDM)

MDM solutions enable organizations to enforce security requirements on employee-owned devices without taking complete control of personal content. These platforms allow IT administrators to require device encryption, enforce screen locks, verify operating system versions, deploy security updates, restrict the installation of high-risk applications, and remotely remove corporate data if a device is lost, stolen, or when an employee leaves the organization. Modern Mobile Application Management (MAM) solutions provide an additional layer of protection by securing only business applications and data while leaving personal files, photos, and applications untouched, helping balance security with employee privacy.

Require Multi-Factor Authentication

Organizations should require multi-factor authentication (MFA) for all systems that contain sensitive corporate information. Passwords alone are vulnerable to phishing, credential theft, and brute-force attacks, making additional verification essential. By requiring users to provide a second form of authentication, such as an authentication app, hardware security key, or biometric verification, organizations significantly reduce the likelihood of unauthorized access. MFA is especially important for email systems, VPNs, cloud storage platforms, financial applications, human resource systems, and customer databases.

Encrypt Sensitive Data

Encryption is one of the most effective ways to protect corporate information stored on or transmitted by personal devices. Even if a device is lost or stolen, encrypted data remains unreadable without the appropriate decryption keys. Organizations should ensure that full-disk encryption is enabled on employee devices, sensitive files remain encrypted both at rest and during transmission, secure messaging platforms are used for business communications, and corporate backups are encrypted to prevent unauthorized access.

Adopt Zero Trust Principles

A Zero Trust security model assumes that no user, device, or connection should be trusted automatically, regardless of whether it originates inside or outside the corporate network. Every access request should be continuously evaluated by verifying user identity, device security posture, login location, risk level, and access permissions. Access should follow the principle of least privilege, ensuring employees can only access the systems, applications, and data required to perform their specific job responsibilities, thereby reducing the impact of compromised accounts or devices.

Keep Devices Updated

Regular software updates play a critical role in protecting BYOD environments from cyber threats. Operating system and application updates frequently contain security patches that address newly discovered vulnerabilities exploited by attackers. Organizations should require employees to use supported operating system versions and enable automatic updates whenever possible. Maintaining up-to-date devices reduces exposure to known security flaws and strengthens the overall security posture of the organization.

Educate Employees

Employee awareness is a critical component of any successful BYOD security strategy because technology alone cannot prevent every cyber threat. Organizations should provide regular security awareness training that teaches employees how to recognize phishing attacks, create strong passwords, practice safe browsing habits, secure mobile devices, connect safely to wireless networks, and promptly report suspicious activities. Well-informed employees are more likely to identify potential threats early and follow security best practices, significantly reducing organizational risk.

Transparency

A successful BYOD program depends on balancing organizational security with respect for employee privacy. Organizations should be transparent about how personal devices are managed, what business data is monitored, and what personal information remains private. Data collection should be limited to what is necessary for legitimate business and security purposes, and employees should be informed about the organization's monitoring practices and privacy protections. By fostering openness, accountability, and mutual trust, organizations can encourage greater employee cooperation and strengthen compliance with BYOD security policies.

Role-based access control (RBAC)

Not everyone needs the keys to the entire organization. RBAC limits system access to what each role requires, effectively reducing the blast radius of a security incident involving a compromised personal device.

Monitor for Threats

Continuous monitoring enables organizations to detect suspicious activity before it develops into a major security incident. Security teams should monitor unusual login behavior, impossible travel events, suspicious application activity, malware detections, device compliance status, and potential attempts to exfiltrate sensitive data. Modern Endpoint Detection and Response (EDR) and Extended Detection and Response (XDR) solutions provide comprehensive visibility across both personal and corporate endpoints, allowing organizations to rapidly identify, investigate, and respond to emerging cyber threats in BYOD environments.

The Future of BYOD Security

As organizations continue embracing hybrid work, BYOD will remain a permanent part of enterprise IT. At the same time, attackers are using artificial intelligence, credential-stealing malware, and increasingly sophisticated phishing campaigns to target personal devices.

Future BYOD security strategies will increasingly rely on AI-driven threat detection, passwordless authentication, continuous risk assessment, behavioral analytics, and Zero Trust architectures. These technologies can help identify compromised devices, unusual user behavior, and emerging threats before they result in data breaches.

Organizations that treat personal devices as integral components of their security ecosystem, not as exceptions, will be better positioned to protect sensitive information while enabling a flexible workforce.

Read more on my blog: www.guardingpearsoftware.com!