DEV Community: Kevin Bjorvand

Fail-closed accounting workflows: n8n, TypeScript, and a Conta pilot

Kevin Bjorvand — Thu, 17 Sep 2026 05:45:19 +0000

A workflow can finish successfully and still have no valid accounting conclusion. That distinction drives the design of this open-source Conta intercompany balance checker.

The project combines n8n orchestration with deterministic TypeScript logic. It compares manually selected accounts for two companies and produces Norwegian HTML, CSV and JSON evidence for an accountant.

Current status: this is a pilot. Synthetic tests and local self-hosted n8n tests have passed. Validation against reports from two authorized Conta companies and execution on n8n Cloud are still outstanding. Nothing below establishes a production-ready integration or a completed reconciliation.

Separate data completeness from balance agreement

Consider two synthetic companies:

Signed NOK balance	Company A	Company B	A + B
Opening	100,000	-85,000	15,000
Period movement	150,000	-140,000	10,000
Closing	250,000	-225,000	25,000

The closing difference is NOK 25,000, but NOK 15,000 was already present at the start of the month. Reporting the entire difference as something caused this month would be misleading.

The comparison uses signed balances:

closing residual = closing balance A + closing balance B
opening residual + movement residual = closing residual

Taking absolute values before comparing would lose the distinction between a receivable and a payable.

The report exposes two separate decisions:

Data status	Balance status	Meaning
COMPLETE	BALANCES_AGREE	Required checks passed; residual is within tolerance.
COMPLETE	DIFFERENCE	Required checks passed; residual exceeds tolerance.
INCOMPLETE	null	There is insufficient evidence for a balance conclusion.

An absent account, failed request or malformed response must never become a zero balance. Even COMPLETE plus BALANCES_AGREE does not prove that all transactions were recorded or that an accountant approved the reconciliation.

Keep orchestration and accounting logic separate

n8n handles requests, branching, bounded retries and scheduling. TypeScript handles scope validation, response adaptation, exact arithmetic, candidate suggestions and report rendering.

The TypeScript modules are bundled into JavaScript Code nodes. The shipped workflows require no runtime npm imports or separate backend.

For each run, the request sequence is:

Retrieve each company's account list and initial trial balance.
Retrieve ledger details for every selected account on both sides.
Retrieve both trial balances again.
Check each account's opening + movement = closing, detail sum = movement, and unchanged selected totals across the two retrievals.

The final retrieval catches some changes during collection. It is not an atomic snapshot: offsetting edits that leave totals unchanged can still escape that check.

Account ownership is an explicit configuration boundary. An accountant must approve dedicated accounts for the relationship. The workflow does not infer counterparties from amounts or descriptions.

Preserve precision before calculating anything

The local n8n HTTP-node tests exposed a transport issue: text response mode parsed JSON internally and rounded a 64-bit source ID. Converting that rounded value to a string later cannot restore the missing digits.

The tested configuration therefore receives the response as a file, then decodes its raw bytes inside a Code node:

const raw = await this.helpers.getBinaryDataBuffer(0, 'raw');
const text = raw.toString('utf8');
// Pass this text to the token-preserving parser before mapping values.

The project's parser preserves numeric JSON tokens as strings for authoritative decoding. Its implementation and limits are visible in transport.ts.

Money is converted from validated decimal strings to integer øre with BigInt; one NOK is 100 øre. Values cross JSON boundaries as decimal strings. Exponent notation and amounts with more than two fractional digits are rejected instead of silently rounded.

const closingA = 25_000_000n;   // NOK 250,000.00
const closingB = -22_500_000n;  // NOK -225,000.00
const residual = closingA + closingB;
// 2_500_000n øre = NOK 25,000.00

The runtime also exposed a bundling constraint: the hardened n8n runner rejected export helpers using Object.defineProperty. The build now emits a plain bundled object, and a regression test exercises that restriction.

Treat failure paths as report behavior

The request loop allows at most three attempts per request. It honors Retry-After seconds and HTTP dates. An excessive wait stops the run instead of retrying earlier than the server requested. Authentication failures and redirects do not retry.

All Conta requests are GET-only and restricted to the configured Conta gateway and endpoint paths. Credentials stay in n8n credentials. This restriction does not make the API key itself read-only: Conta keys inherit their user's privileges.

An INCOMPLETE report can be the output of a successful n8n execution. Operators must inspect both the execution status and the report status. A missing report after a host or runner failure is also not a valid result.

Ledger candidates are conservative. Suggestions require an explicitly confirmed shared invoice reference, uniqueness on each side, opposite equal amounts and dates within the configured window. Local voucher IDs are not shared matching keys. Duplicates, split settlements, reversals and corrections remain review items.

What has actually been tested

As of September 17, 2026:

53 deterministic accounting/workflow tests passed.
17 scenarios passed through actual self-hosted n8n 2.39.6 execution on Windows with Node 24.13.1, synthetic credentials and a loopback fixture server.
Those scenarios covered both credential branches, multiple accounts, Retry-After seconds/date, exhausted retries, three real 30-second timeouts, 401/403 responses, malformed and empty bodies, missing accounts, inconsistent movements, changing balances, large IDs and redirects.
A real local Schedule Trigger generated a saved synthetic report; HTML, CSV and JSON were read back from execution storage.
n8n's automatic pruning removed a disposable copy of that execution and its inline reports. This did not test Cloud retention, external binary stores, backups or physical secure erasure.

The runtime record includes workflow hashes and separates execution success from report completeness.

These tests establish the behavior of the tested implementation and fixtures. They do not establish Conta's live date, omission or correction semantics. Those checks remain explicit release gates.

Reproduce the synthetic example

The MIT-licensed repository contains the modules, fixtures, tests and inactive workflow exports.

With Node 22.18 or newer, run the local deterministic checks:

git clone https://github.com/KevinBjorv/conta-intercompany-checker.git
cd conta-intercompany-checker
npm ci
npm run check

To try the n8n demo, import workflows/conta-synthetic-demo.json, run Manual demo, and download the three files from Private reports. That workflow makes no network requests and needs no credentials.

The fixed example contains 20 lines, a NOK 25,000 closing residual, nine candidate pairs and two unresolved lines. You can inspect the Norwegian sample report or the 90-second silent Norwegian demonstration.

The separate live template stays inactive and reports INCOMPLETE until its operator has documented the required report validation. Balance agreement remains evidence for review, never automatic accountant approval.

AI disclosure: This article was written by an AI assistant from the project's source code and recorded test evidence. All company examples are synthetic. The checker itself uses deterministic accounting logic, not an LLM.

Checking Xero supplier statements with n8n and deterministic TypeScript

Kevin Bjorvand — Wed, 16 Sep 2026 13:23:33 +0000

A reference match is not the same thing as a safe amount comparison. A supplier statement might show the invoice's original total, the remaining balance after a payment, or an unclear amount column. Treating all three as the same value can produce a convincing report with the wrong conclusion.

The open-source Xero Supplier Statement Checker uses n8n for orchestration and TypeScript for deterministic checking. This article explains three choices behind it: explicit amount meanings, complete retrieval and evidence-preserving operator review.

The project is a preview. Synthetic tests and local n8n runs have passed; live Xero and n8n Cloud verification are still pending. All examples here are fictional.

1. Separate references from amounts

The operator selects a supplier from the configured Xero organization's contacts. The checker only considers bills within that supplier and currency. It normalizes references using Unicode NFC, outer-whitespace trimming and ASCII case changes. It preserves punctuation, internal spaces and leading zeros.

It does not use amounts, dates or fuzzy similarity to establish a match. Xero's purchase-bill InvoiceNumber is the primary reference; the separate Reference field is supporting evidence. Multiple candidates stay visible for review.

Only after one eligible reference candidate exists can the checker compare tax-inclusive original totals. The checked-in fixture includes these two cases:

Reference	Statement	Xero	Result
INV-101	Original 250.00 GBP	Original 245.00 GBP	Amount difference: 5.00 GBP
INV-107	Outstanding 45.00 GBP, no original total	Reference candidate found	Review required; no automatic comparison

Public contracts keep monetary values as decimal strings. Calculations use integer minor units, based on a checked-in currency table. Excess non-zero fractional digits are flagged instead of silently rounded. Xero JSON is parsed losslessly before converting its numeric values.

Credits, partial payments, duplicate statement references and unsafe bill statuses also require review. A fully paid bill can still match its original total; the report displays its current paid status separately.

2. A later failed page invalidates the retrieval

"Not found" is a statement about the searched data. If page one succeeds and page two fails, there is no sound basis for declaring an invoice absent.

The workflow uses HTTP Request nodes outside the Code nodes, sequential pages and explicit page sizes. It records requested pages, returned IDs, counts and the retrieval interval. The checking interface validates that evidence rather than trusting a caller's success: true flag.

Repeated pages, duplicate IDs, inconsistent counts, missing pages, malformed responses or exhausted retries stop the check. Rate limits use the provider's Retry-After delay within a bounded retry policy. There is no date lookback or outstanding-balance filter that quietly omits old or paid bills.

The interrupted-retrieval fixture fails on page two with a 401. Its report has zero matches, zero amount differences and zero not-found conclusions. Available statement rows remain review-required, and no follow-up draft is produced.

3. Let AI extract; keep the operator and rules in control

CSV uses no AI. The operator maps columns and explicitly identifies original totals and outstanding balances. Invoice references stay strings, including leading zeros, and quoted multiline fields retain their source record numbers.

For optional text-PDF extraction, n8n extracts pages separately. The code assigns page numbers and verifies page coverage. OpenAI receives page-labelled text with a strict output schema, no tools and store: false. Returned evidence excerpts must exist in the supplied page text. Xero bill data is not included in that request.

The review form shows extracted rows, source references and warnings. Operators can correct a canonical CSV representation and must confirm supplier, currency, amount meanings and statement coverage. Initial extraction and corrections stay in the evidence. The AI never chooses a supplier or decides a match.

This does not eliminate extraction risk. Scanned, encrypted or partly unreadable PDFs are rejected, and the operator must check the original document for omitted rows. Provider retention is separate from the store: false setting.

Try the synthetic example

With Node.js 24 or later:

git clone https://github.com/KevinBjorv/xero-supplier-statement-checker.git
cd xero-supplier-statement-checker
npm ci
npm run demo
npm run check

Open output/demo/report.html. The ten-line fixture produces two matched rows, one amount difference, one not found and six requiring review. No credentials are needed. The repository also includes an importable n8n synthetic form workflow.

The downloadable ZIP contains HTML, CSV and JSON, plus an optional unsent draft. HTML is escaped; CSV formula-like values are protected; exact originals remain in JSON. Limits stop processing at 10 MiB, 50 PDF pages or 1,000 rows rather than truncating data.

The checker supports statement review. It does not reconcile supplier balances, convert currencies, post accounting entries or send email. A current Xero fetch is not a historical or atomic snapshot at the statement date.

Source and implementation

MIT source, fixtures, tests and verification status

See the sample report and implementation options at Bjorvand AI

Disclosure: this is a Bjorvand AI project. The workflow is free; installation and customization are separate paid services. This article was prepared with AI assistance and checked against the source and synthetic fixture results.

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