DEV Community: Kevin Bjorvand

Automatically Generate Third-Party Notices in Unity

Kevin Bjorvand — Tue, 10 Mar 2026 14:54:41 +0000

# Automatically Generate Third-Party Notices in Unity

A simple way to stay compliant when shipping games

If you ship games using Unity, you are almost certainly using third-party software.

This might include:

Asset Store packages
open-source libraries
plugins or SDKs
copied utility scripts
packages from GitHub

Each of these may come with license requirements.

Many licenses require that you include a Third-Party Notices file or credit the authors somewhere in your build.

The problem is that this step is often overlooked.

Not because developers want to ignore licenses, but because tracking every dependency manually becomes difficult as projects grow.

Why third-party notices matter

Many open-source licenses require attribution.

Common licenses such as MIT, BSD, and Apache typically require that the license text and copyright notice are included when distributing software.

In practice this usually means adding a file such as:

THIRD_PARTY_NOTICES.txt

or including license credits somewhere accessible in your application.

If those notices are missing, your distribution may technically violate the license terms.

For most indie developers this is not intentional. It simply happens because dependencies accumulate over time.

The hidden complexity of Unity projects

Unity projects often pull in dependencies from several sources.

A typical project may include:

Asset Store packages
UPM packages
plugins bundled with assets
third-party SDKs
custom scripts copied from repositories

Each of these may contain its own licenses.

Because many assets include their dependencies internally, developers may not even realize which libraries are being used.

By the time a game is ready to ship, the project might contain dozens of different licenses.

Trying to manually audit these files can take hours.

A common late-stage problem

Many teams only think about licenses right before release.

At that point the questions start appearing:

What open-source libraries are included in this project?
Which licenses require attribution?
Where should the notices file be generated?
Did we miss anything?

Unfortunately this usually happens during the final release phase, when developers are already dealing with builds, store submissions, and bug fixes.

Compliance work becomes another unexpected task at the worst possible moment.

Introducing Third-Party Notices Generator

To simplify this process I built a small Unity editor tool called Third-Party Notices Generator.

The idea is straightforward.

Instead of manually searching through packages and asset folders, the tool scans your project and generates a structured notices file automatically.

This provides a clear overview of third-party licenses used in the project.

How the workflow works

The process is intentionally simple.

You open the tool inside the Unity editor and run a project scan.

The tool looks through project dependencies and identifies license information where available.

It then generates output files that can be included directly in your project.

Typical outputs include files such as:

THIRD_PARTY_NOTICES.txt
CREDITS.md
structured manifests for documentation

These files provide a clear list of dependencies and their associated license information.

Because the files are deterministic, they can also be tracked in version control.

Why automated license tracking helps

Automating license notices has several benefits.

First, it reduces the chance that dependencies will be forgotten during release.

Second, it makes compliance work faster. Instead of manually reading every license file, developers can generate a structured list automatically.

Third, it makes updates easier. When new packages are added to the project, the notices file can simply be regenerated.

This keeps the project documentation accurate over time.

When developers should think about license compliance

License compliance is usually not the most exciting part of development.

But it becomes important when projects reach the stage where they are distributed publicly.

This includes:

Steam releases
mobile store submissions
web builds
open-source project distribution

At that point it is useful to have a clear record of which third-party components are included in the project.

Having that information organized early can prevent unnecessary stress close to release.

Final thoughts

Modern game development relies heavily on shared tools, libraries, and open-source software.

That ecosystem allows developers to build games faster than ever before.

But it also means that projects often contain many different licenses.

Keeping track of those dependencies manually can become tedious.

Automating the process with tools like Third-Party Notices Generator makes it easier to stay organized and compliant when shipping games.

Sometimes the most useful tools are the ones that quietly take care of the small but important details behind the scenes.

Stop Unity Build Size Regressions Before They Ship

Kevin Bjorvand — Wed, 18 Feb 2026 20:52:03 +0000

Unity build size rarely explodes overnight. It grows slowly:

A few new 4K textures
An uncompressed audio file
A plugin update
An Addressables change
A scene pulling unintended dependencies

Then one day your APK, AAB, or build folder is 120 MB larger and no one knows why.

The real problem is not build size.

It is lack of regression control.

The Question You Should Be Asking

Most developers ask:

“What is my build size right now?”

The correct question is:

“What changed compared to my last good build?”

You cannot answer that without structured snapshots and deterministic diffs.

A Practical System for Controlling Unity Build Size

To prevent regressions, you need three things:

1️⃣ Automatic Build Snapshots

Every successful build should record:

Build target (Android, iOS, Windows)
Total build size
Contributor breakdown
Category grouping (textures, audio, meshes, shaders, plugins)

Store this as JSON so it works with version control and CI artifacts.

No snapshot = no baseline.

No baseline = no regression detection.

2️⃣ Deterministic Snapshot Comparison

When a build grows, you need:

Total delta in bytes and percent
Top increases
Top decreases
New assets
Removed assets
Category distribution shifts

This gives you immediate root cause visibility instead of guesswork.

Example output:

+42 MB textures
+18 MB new Addressables bundle
+9 MB plugin update
+6 MB scene dependency pull

Now you are debugging facts.

3️⃣ Enforced Size Budgets

Visibility is not enough.

You should define:

Maximum total build size per platform
Maximum allowed regression vs baseline
Optional category budgets

If violated:

Local builds warn or fail
CI exits non-zero
A clear report explains what exceeded and by how much

This turns build size into a hard constraint instead of a suggestion.

Why CI Enforcement Matters

Manual review fails at scale.

In real projects:

Multiple branches ship in parallel
Different team members commit large assets
Nightly builds accumulate silent growth

A proper batchmode workflow should:

Load a baseline snapshot
Compare against current
Evaluate budgets
Print a human-readable summary
Output JSON for automation
Return a non-zero exit code on failure

That is how you prevent accidental regressions from reaching production.

Introducing Build Size Guard

I built Build Size Guard specifically for regression control, not just reporting.

It:

Automatically records build size snapshots
Compares any two builds
Highlights top increases and new contributors
Groups by folder and category
Enforces size budgets locally and in CI
Generates JSON and Markdown reports
Has zero runtime footprint

It is designed for serious Unity developers shipping on Android, iOS, and Windows.

If You Care About

APK size
AAB size
IPA size
Patch size
Store limits
Preventing last-minute build surprises

This workflow solves that problem.

Available Now

🎮 Itch.io

https://kevindevelopment.itch.io/buildsizeguard

🧰 Unity Asset Store

https://assetstore.unity.com/packages/slug/361332

If you treat build size as a tracked metric instead of an afterthought, regressions become predictable and preventable.

How to generate THIRD_PARTY_NOTICES.txt and CREDITS.md in Unity (Game Compliance Pack quickstart)

Kevin Bjorvand — Tue, 10 Feb 2026 11:01:22 +0000

Shipping a Unity game often means shipping third-party software too: Unity Package Manager (UPM) dependencies, Asset Store plugins, embedded DLLs, native plugins, copied utilities, and random folders someone dragged into Assets/.

At release time, this turns into the same panic checklist:

What third-party did we ship?
What are the license obligations?
Where is our third-party notices file?
Did we forget something?

This post shows a practical workflow using Third-Party Notices & Credits: License Compliance for Unity (Game Compliance Pack) to generate release-ready compliance artifacts directly from your Unity project.

Tool link (copy/paste):
https://kevindevelopment.itch.io/compliance

What the tool generates (release-ready outputs)

From your Unity project, it can export:

THIRD_PARTY_NOTICES.txt (full attributions plus license text when available)
CREDITS.md (short, human-friendly credits block)
compliance-manifest.json (machine-readable source of truth for diffs and repeatable builds)

The key design goal is deterministic outputs you can commit to version control so diffs stay meaningful.

The workflow (scan, review UNKNOWN, export)

1) Import the package into your Unity project

Purchase and download the Unity package
Import it into the project (like any other .unitypackage)
Reopen the project if Unity does not immediately compile editor scripts

2) Run a scan for third-party components

In the tool window, run the scan. The scanner is designed to pick up the most common sources of third-party software in Unity projects:

UPM dependencies (direct and transitive)
Asset Store imports
Embedded folders (common “ThirdParty” style locations)
Native plugins and binaries (DLLs and platform libs)

After the scan, you should see a component list with evidence for where each item came from.

3) Treat UNKNOWN as a feature, not a bug

If a license cannot be identified with high confidence, the tool marks it UNKNOWN instead of guessing.

This is exactly what you want for real compliance work: unknowns become visible, reviewable tasks, not silent risk.

Practical rule: do not export and ship until your UNKNOWN items are handled.

4) Resolve UNKNOWN items using overrides (the real work)

UNKNOWNs are expected. The fast path is to resolve them once and store the decisions in source control so everyone on the team shares the same results.

Typical resolution steps per UNKNOWN component:

Confirm what the component is (where it lives in the project, what it is used for)
Locate license evidence (LICENSE, NOTICE, COPYING, vendor docs, repo metadata)
Fill in attribution fields (name, author/publisher, URL if applicable)
Set the license identifier and include license text when required

The tool supports JSON overrides and manual components so the final attribution data reflects what you actually ship.

Example override shape (illustrative, check the tool docs for exact fields):


json
{
  "overrides": [
    {
      "key": "com.vendor.component",
      "licenseId": "MIT",
      "attribution": "Component Name by Vendor Name",
      "url": "https://example.com",
      "licenseText": "..."
    }
  ]
}

How to Escape Tutorial Hell (As a Beginner Game Dev) Without Becoming a “Framework Collector"

Kevin Bjorvand — Tue, 30 Dec 2025 18:21:31 +0000

If you’ve ever done the classic move where you finish a tutorial, feel productive, then open your own project and instantly forget what to do… welcome. You’re not broken. You just haven’t trained the part of the brain that generates solutions.

dev.to has a lot of smart people, but beginners still get stuck in the same trap: passive learning feels like progress.

This is a practical, engine-agnostic post (Unity/Godot/Unreal all fine) on how to escape tutorial hell with a loop you can repeat forever.

The real issue: you’re optimizing for “recognition”, not “creation”

Tutorials train recognition:

“Yeah, I’ve seen this before”
“I remember that menu”
“I know that line of code”

But building games requires creation:

“What do I do next?”
“Why did this break?”
“How do I simplify this?”

So your learning method has to force creation.

The system: Struggle → Build → Repeat

This is the loop:

1) Struggle: try without help (short and controlled)
2) Build: implement the smallest version that works
3) Repeat: rebuild from memory + change one thing

The goal is not to “finish the tutorial”. The goal is to build the skill of moving forward without a guide.

Step 1: Struggle (but don’t cosplay as a genius)

Rule: You must attempt for 15 minutes before searching.

Why?
Because the struggle creates a map of what you don’t know. Without that map, searching becomes random doomscrolling.

What to do during those 15 minutes (simple routine)

Open a scratch note and write:

Goal: “Player can jump”
My guess: “I need gravity + input + velocity”
Try: implement your best attempt
Result: what happened?
Next guess: one adjustment

This turns confusion into a process.

If you still fail after 15 minutes

Good. Now you earn the right to search, but with a constraint:

Search for one missing piece, not the whole solution.

Bad search:

“how to make a platformer movement system”

Good search:

“how to detect grounded in 2d”
“difference between AddForce and setting velocity”
“how to clamp camera movement”

Step 2: Build the smallest working version (embarrassingly small)

Beginners try to build “a real game” too early. That creates complexity and kills momentum.

You want minimum playable mechanics, not minimum viable product.

Example: “Top-down movement”

Smallest version:

WASD moves a square
no animations
no fancy camera
no sprint, no stamina, no diagonals handling beyond normalization

Then you ship the learning.

A constraint that helps

One mechanic at a time. One file if possible.

If your “movement” requires 9 scripts and a state machine, you are building a cathedral, not learning.

Step 3: Repeat (this is where the learning actually locks in)

This is the most important step and the one almost nobody does.

Once you get the thing working, do this:

Repeat Protocol

1) Delete it (or start a new empty project)
2) Rebuild it from memory
3) Only after you rebuild it, compare with a reference
4) Then change one variable and rebuild again

This is how you move from “I watched it” to “I own it”.

Practical mini-projects that kill tutorial hell (pick one)

These are designed to be:

small enough to finish
easy to debug
easy to repeat with variations

1) Dodge Arena (2 hours)

Goal: survive 30 seconds

Mechanics:

player moves
enemies (or hazards) move toward player
collisions reset the timer

Variations for repeats:

add invincibility frames
add dash cooldown
add random spawn waves

2) One-Button Jump Game (2 to 4 hours)

Goal: jump over obstacles and score points

Mechanics:

jump
obstacles spawn
game over on hit

Variations:

variable jump height
speed increases over time
“perfect jump” bonus

3) Collect + Return (3 to 6 hours)

Goal: collect 3 items then return to exit

Mechanics:

player movement
pickups
UI counter
exit unlock

Variations:

add a timer
add a “wrong pickup” penalty
add fog of war

4) Simple Horror Loop (3 to 6 hours)

Goal: find key, escape, avoid enemy

Mechanics:

flashlight cone (fake is fine)
key pickup
enemy patrol/chase (basic)
win/lose state

Variations:

sound lure mechanic
hiding spot
random key location

If you finish any of these, you are already ahead of 90% of beginners.

How to use tutorials without getting trapped (rules that actually work)

Tutorials are not evil. Your usage pattern is.

The “30/70 rule”

30%: watching/reading
70%: building/testing/changing

If you are doing the reverse, you are training comfort, not skill.

Never follow a tutorial twice

If you need it twice, you did not learn it. You consumed it.

Instead:

rebuild from memory
then look up the one missing piece

Force a change immediately

When you do use a tutorial, you must change one thing before you close it:

different control scheme
different movement speed curve
different enemy behavior
different UI layout

No change = no learning.

Debugging mindset for beginners (so you stop rage-quitting)

When something breaks, beginners think:

“I’m bad at this”

Better thought:

“My mental model is missing one piece”

Use this micro checklist:

1) What did I expect to happen?
2) What actually happened?
3) What is one possible cause?
4) What is the smallest test I can run?

Your goal is not to “fix it fast”. Your goal is to tighten the loop.

A simple weekly plan for busy beginners (realistic)

If you only have 30 to 60 minutes a day, do this:

Week 1

Day 1: pick one mini-project + define win condition
Day 2: build core movement
Day 3: add one obstacle/enemy
Day 4: add win/lose state
Day 5: rebuild from memory (Repeat Protocol)
Day 6: variation #1
Day 7: variation #2

This looks small because it is small. That’s the point. Finishing tiny things builds the identity: “I finish games”.

If you want a structured path (engine agnostic)

If you want more content like this (and the full channel + program behind it), I’ve put everything here:

👉 https://smartindie.dev

It’s focused on helping beginner solo devs stop bouncing between tutorials and unfinished projects, and actually finish and release a first game with simple systems.

Understanding the sizeof Operator in C++: A Comprehensive Guide

Kevin Bjorvand — Tue, 09 Jul 2024 17:45:39 +0000

Wassup guys!

I recently published a YouTube tutorial on the sizeof operator in C++, and I wanted to share some insights and gems from the video here. You can watch the full tutorial here

What is the sizeof Operator?
The sizeof operator in C++ is a compile-time operator that returns the size of a variable or data type in bytes. This can be incredibly useful for understanding how much memory your variables and structures are consuming.

Key Points Covered in the Tutorial:
Basic Usage:

`int a;
std::cout << "Size of int: " << sizeof(a) << " bytes" << std::endl;
This prints the size of an integer variable.`

Using sizeof with Data Types:

`std::cout << "Size of double: " << sizeof(double) << " bytes" << std::endl;
You can directly use sizeof with data types to get their size.`

Arrays and sizeof:

`int arr[10];
std::cout << "Size of array: " << sizeof(arr) << " bytes" << std::endl;
This returns the total size of the array (number of elements multiplied by the size of each element).`

Pointers vs. Arrays:

`int* ptr;
std::cout << "Size of pointer: " << sizeof(ptr) << " bytes" << std::endl;
It's crucial to understand the difference in size between pointers and the arrays they may point to.`

Best Practices:
Using sizeof with Structs and Classes:

`struct MyStruct {
    int a;
    double b;
    char c;
};
std::cout << "Size of MyStruct: " << sizeof(MyStruct) << " bytes" << std::endl;`

This helps you understand the memory layout of your custom data types, which is critical for performance tuning and debugging.

Alignment and Padding:
The sizeof operator reveals the effects of alignment and padding on the size of structs and classes. Understanding this can help optimize memory usage.

`struct MyPackedStruct {
    char a;
    int b;
} __attribute__((packed));
std::cout << "Size of MyPackedStruct: " << sizeof(MyPackedStruct) << " bytes" << std::endl;`

Using sizeof with Dynamic Memory:
Be cautious when using sizeof with dynamically allocated memory, as it only returns the size of the pointer, not the allocated memory.

`int* dynamicArray = new int[10];
std::cout << "Size of dynamicArray pointer: " << sizeof(dynamicArray) << " bytes" << std::endl;`

Common Pitfalls:
Misunderstanding sizeof with Functions:

`void func(int arr[10]) {
    std::cout << "Size of arr inside function: " << sizeof(arr) << " bytes" << std::endl;
}`

Inside functions, arrays decay to pointers, so sizeof will not return the size of the original array.

Using sizeof with Expressions:

std::cout << "Size of expression: " << sizeof(1 + 2.0) << " bytes" << std::endl;

This will return the size of the resulting type of the expression.

Conclusion
Understanding the sizeof operator is fundamental for mastering C++. It not only helps in efficient memory management but also deepens your understanding of how C++ manages data. For a detailed explanation and more examples, check out my YouTube tutorial.

Feel free to leave comments and questions below. Happy coding!

Check out my full video here: https://www.youtube.com/watch?v=DuiCjk2ksfc&t=4s