It's been three and a half months since I posted Episode 1 of this blog, which I'd intended to post to far more regularly.
What happened?

At the end of Episode 1, I closed with a sentence which at the time I believed to be true. It turns out that I was still lying to myself...
"I never thought I’d say this, but now I’m on track to become an Indie game developer using Unity."

I write this post with a title about kicking an addiction, not to be taken literally, and not to belittle anyone with a genuine addiction, but because the pattern of behavior that I've exhibited has shown some similarities. It's expressive intent only. The beginning of this post is essentially self-reflection, and the later portion will explain what little progress I have actually made. If you'd prefer to follow progress only, without my meandering, feel free to skip to the heading "Where I'm at now."

The Addiction

I have been writing code professionally for (quick math) 26 years now, specializing in Delphi (Pascal), which I'd previously used as a hobby programming language for around three years. So, almost 30 years writing Pascal code, both professionally and for my own entertainment. Perhaps it has been a few years longer, given some vagueness in my memory. Prior to that, as a child I wrote code in BASIC and Assembler for various "toy" computers. Programming became a part of who I am, a component of my identity. Having done it for such a long time, I am still of the era in which every component of a software application could be, and often was, written from scratch.

I fell into the habit of taking on personal projects of ever-increasing complexity, only to be consumed by them, oblivious to the time passing by. Literally, weeks, months, or years could be swallowed by a project, and ultimately, they were always "never finished" projects. What happened between my previous Episode 1 blog post and this one, was precisely that.

After declaring that I was now going to focus on the game development, switch into Unity, and learn Blender more effectively, I instead went right back to working on my own compiler, and my own "game engine" projects. This is why I liken it to an addiction. In some ways, it is akin to one. I'm coming clean about having wasted another three and a half months of my life on efforts that I'd sworn to abandon, at least temporarily. I own up now, transparently admitting some shame.

I explained in earlier posts that not only do I want to make games, but I also want to share this passion with my young son. Getting swallowed up by my prior projects again put me back into a text console for long periods. I was not sharing the passion with anyone. I was hyper-focusing on my own pride-driven goals. I don't know if anyone is reading this blog as of yet, but if so, then I've let you readers down too.

Pride and Programming

In earlier years, there was a sort of bravado in hobbyist programming. There was a period when many developers wrote what we referred to as "Demos" for the so called "Demo Scene." The scene still exists today, as developers of the same ilk continue to write demos merely to keep it alive. The Demo Scene grew out of software piracy, because the pirates wrote demos to show off their programming prowess, after "cracking" copy protection. I won't dive too deeply into that history, but suffice to say that the Demo Scene became its own thing, in its own right. Though a small shadow of its former self, it's still alive today. Realistically the Demo Scene faded 30 years ago, but had been going strong for a decade or more before that.

In the 80's and early 90's, computer hardware was understandably far more limited than it is today. As a child I once owned a Commodore 64, an 8-bit microcomputer with a mixed purpose. It was leading-edge in terms of personal computing for its time, and also had business aspirations as demonstrated by its awkward sibling, the Commodore SX-64. The SX-64 was essentially the same machine as the Commodore 64, but packaged in a portable (laughably heavy) case, and was aimed at business users. The business computing industry faced a problem however, that there were too few programmers, and so both the SX-64 and the Commodore 64 shipped with a BASIC interpreter, manuals teaching how to code. The idea being not only that the business users be able to produce custom programs, but that children using the C64 would learn to code, and grow up to be software developers.

The Commodore 64 was named not because it had a 64-bit data bus, far from it, but because it had 64KB of RAM. Kilobytes. It ran at around 1Mhz (PAL or NTSC dependent) and could execute roughly 250 thousand instructions per second. By comparison, modern Intel CPUs approach 4 Billion instructions per second. Graphically, it could display 320x200 pixels in high-resolution black and white, or 160x200 in low-resolution color, unlocking a palette of 16 predefined colors, which also had strict limitations on how many could appear in any display region at once.

Nevertheless, I devised a special effect that appeared to add additional colors beyond what the hardware provided. I claimed in essence that I could make a machine that was limited to 16 colors display a 17th color. This is a claim that clearly deserves qualification. I didn't actually create a 17th color for the C64. Instead, I wrote a small piece of Assembler code that rapidly swapped between white and yellow, fast enough that via persistence of vision, they blended into a shimmering gold. I vaguely recall reading about the exact same effect being used in a commercial game at the time, though I never saw that game firsthand. It’s entirely plausible that multiple developers independently discovered the same trick, given that we were all trying to push hardware beyond its apparent limits.

Techniques like color palette switching were at the heart of the Demo Scene. It was a creative playground where individuals or groups tried to one-up each other on modest hardware. One famous example is the “9-sprite” trick on the C64, which allowed nine sprites on hardware designed for only eight. One of my favorite examples comes not from a Demo but from a commercial video game: Elite (1984) by David Braben and Ian Bell.

Elite was written for the BBC Micro and was essentially an open-world space flight game. Braben wanted high-resolution two color mode for crisp star fields and wire frame ships, but that would have left the game colorless. His solution was to detect the vertical scan position and switch video modes about three quarters down the screen, yielding a colorful UI while retaining high-resolution graphics above.

(Aside: David Braben is a personal programming hero of mine. Beyond Elite, he created Frontier: Elite II and, decades later, Elite Dangerous. He didn’t just do clever video tricks, he also delivered a procedurally generated open galaxy on an 8-bit computer, pioneering what we now call open-world game play. Elite fit into only 22 KB. An engineering masterpiece.)

Programmers of those early times, earned a significant amount of pride in being the first to discover new ways to push the hardware limits, and to produce new effects that had not yet been seen, or even considered possible on the available hardware. I think my pride in taking on larger personal hobby projects, comes from having grown up and become a programmer through this earlier time.

Programming Heroes

Despite my efforts over the years, I never learned to ski. My wife, by contrast, is an accomplished skier with medals from local competitions. Through some twist of fate, she married a man who doesn’t ski, while I married a woman who doesn’t code.

Often, when explaining technology to her, I resort to sporting analogies. Once, during a long drive home, she asked: “In extreme sports we have heroes. Do you have that in programming?”
Of course we do. From Alan Turing, Grace Hopper, Niklaus Wirth, and Bjarne Stroustrup, to John Carmack, David Braben, and Tim Sweeney. Programming has its heroes, not because they mastered known techniques, but because they invented new ones.

The greatest painters aren’t revered because no one can copy them, many can. They’re revered because they created techniques and styles that didn’t exist before. The same is true in programming. John Carmack’s DOOM rendering techniques are well understood today. I even re-implemented them myself in the late 90s. What makes him a hero is that he invented them, and shipped.

This realization ties back to my struggle. Pride, competition, and identity pushed me back toward building my own engine instead of aiming towards finishing games. Even the expectations of peers within the Pascal community played a role.

The Real Reason

While pride and competition are factors, they aren’t the whole story.
The rest is simply comfort.

Pascal is familiar. Its syntax, compilers, editors, they’re my comfortable old slippers. Unity, Blender, C#, even Visual Studio are unfamiliar, and that makes me feel like a beginner.
Falling back into Pascal soothes that discomfort. But it’s also a sinkhole. Writing a game engine is already a massive time investment. Writing one in Pascal, with fewer off-the-shelf libraries, increases that cost.

“If you want to make an apple pie from scratch, you must first invent the universe.” — Carl Sagan

Looking back, it’s hard not to feel that a great deal of time slipped by without moving me meaningfully closer to my goals, and that realization has made it clear that something needs to change. At this point, the habit no longer serves my goals. I need to kick it.

Where I'm at now

At the end of Episode 1, I showed some low-poly Blender models. Not good art, but progress.
I’m now modeling mid-poly characters. Still not “good,” but intentionally so.

These new models I think are a significant step up from my earlier low-poly efforts, but they are somewhat out of proportion and crude.
What is important about them however, is that they have clean topology, designed for deformation during rigging and animation.

 

I'm targeting a polygon budget of 11-12k for a complete character model. With proper texturing and clothing, I believe the lack of detail can be masked effectively. These are already, I think, sufficient to serve as base meshes from which many characters can be created. I'll need to alter the proportions of each, in the direction of some character reference, in order to achieve a final model, but then I can re-use these same base meshes again and again, to create further derived characters.

I’m intentionally avoiding the traditional high-poly sculpt, then retopology workflow.
While that approach yields realism, it’s extremely time-consuming. Instead, I’m embracing stylized assets that can be rigged once and reused many times.

These models were created by following tutorials from the YouTube channel "@2amgoodnight" https://www.youtube.com/@2amgoodnight - The presenter of which, I do not know the name of. The title "Genshin Impact" from "HoYoverse" is a video game that I know next to nothing about, however, the developers of it at some point released the 3D assets for download - I think in order to allow players and fans to 3D print them. The presenter of "2AM" inspected and reverse engineered these models, learning how they were made, and how to reproduce them using Blender. He then crafted tutorials out of this study. He also hosts a patreon account where assistive assets are provided too, and so I surely became a member.

Now, my models aren't quite so good even as the tutorial results, I am still very much the student. The tutorials are also anime-focused, not my end goal, but they provide a usable foundation, without heavy sculpting or retopology. That time savings matters. They are perfect for my goals.

So, this is where I am. Closer to the end of another year, and barely any closer to having created anything that would count as a video game. I'm also not aiming at this point for my "magnum opus" or anything like that. I know that I'll want to experiment with small toy games for the sake of learning the features of the Unity engine, and, I'll want to create many more assets like the above, to practice and hone my blender skills. The truth is however that I leave you with essentially the very same revelation that I did at the end of Episode 1.

I am now (back) on track to become an Indie game developer using Unity.
For those of you that would not be bored by time-lapses, here's the product of my efforts thus far, in video form...

Where to start?
I don't mean this blog post, but literally, with game development, where do I start?
Well this has been something of an uncomfortable conundrum for me, because, my skill set is not well rounded at all. In some areas I'm very strong and in others very weak, and deciding exactly where to begin on this game development journey is therefore a case of taking my skills into account, and deciding where to apply my energy. A problem that I've struggled with in one form or another for my entire life.

The Game Engine

If I'm an expert at anything at all in this life, it's programming. As I mentioned in my introduction post, I was given a programmable computer at just five years old. I began copying programs from the user manual, and altering them to learn how things worked. I don't think there has been more than a single consecutive week since, that I've not had a computer in front of me at some time in the day. It's my thing, and depending on the choice of tool-set, I'm quite good at it. In fact, I'd claim to be TOO good at it, something of a perfectionist, and this lead me to my first conundrum...

When I look at the available game engines for Indie developers, the three biggest names are Unreal, Unity and Godot. Each of these engines is a powerhouse in their respective use case, but all three of them have issues which, as a "perfectionist programmer" trouble me. I look at how they function and things bother me, from OOP based hot loops, to inefficient lookup, to black-box threading models and so on. These issues troubled me so much that I decided I might just build my own Game Engine using my programming language of preference. No, not C or C++ but Pascal. So I made a start on it...

What you're seeing in the screen shot is quite unimpressive looking, it's rendering a "rainbow plane" in my own custom game engine. It's actually far more impressive than it looks. I wrote an entire runtime library with a custom, thread affinity and numa aware heap allocator, various collection allocators, and its cross platform. This engine supports an OpenGL based renderer on Windows and Linux, including Aarch64 ARM. It handles windowing on Windows and X-Server with gaps to plug in Wayland and dummy window managers for Android and iOS. It has space to plug in alternative rendering API's to use Vulkan, Metal / other. It is entirely procedural code and data-oriented, with numa locality of memory, a fabric layer to orchestrate multi-threading, a dedicated thread for rendering, another for scene simulation, and thread-pools for array-slice based cache locality. If this is all word salad, let me give you the brief : This engine is engineered in as immaculate a way as I know how, and it took around six months to get to the point that I could render this rainbow box!

(Okay, it actually does more than this - in prototypes I've had 50k spinning rainbow cubes on display, in twin windows, without melting the CPU, but that's a mere aside from my point.)

That's the problem right there. I have the engineering skills to write a complete Game Engine of my own, and to do a good job of it, at least as I see it, but it's going to take far too long to get to the point that it's actually a usable engine. Not only that, but I've been driven by this form of insanity for a long time. For instance, the available compilers for Pascal have a limited number of targets, and so I've even begun writing my own compiler with a Pascal-based syntax, which is able to target x86-64/Aarch64 with its own encoders written from scratch, its own linker written from scratch. This is a rabbit hole! Simply because I could re-invent software technology from scratch, does not mean that I should!

I considered switching to C or C++ too. You see, another limitation of Pascal is simply that it's not the compiler that "won" the compiler wars of the 80's and 90's. That crown went to C, and by extension to C++. The result is that in order to do something like this in Pascal, you must interact with C based ABI's and API's. Doing so requires a capable compiler, and careful translation of header files from C to Pascal. There are some existing headers out there, but they tend to be of poor quality or behind in being maintained because Pascal just hasn't been as popular a language. I know enough C and C++ to do these translations, but doing them right can take days - and there are a lot of them to do. Consider the engine I've described above for example. Just to get that to work, I had to translate the Windows API headers, the Posix headers, OpenGL, X-Server, XInput, Wayland, and there were many more to come, including Vulkan, Metal and so on... not to mention bridging to Android and supporting iOS. If I switched to C++ for my engine, I could save myself this work because those headers not-only already exist for C++, but they are maintained for it, because they're written in C++ or compatible C.

Then I looked at the C and C++ tool-chain space for cross platform development, something I've not looked at in many years. The space is dreadful. I've been spoiled with Pascal because its unit system allows for modular construction of cross platform code. The compiler takes care of the linking stage, it's syntax is sufficient that it knows what to link for any given target, and depending on the compiler it either links for its self, or drives an external linker. In order to use C or C++ today, you must first select a compiler, linker and debugger, then select a compatible build system from the many available, then select the runtime you want to link against, then find an IDE or Editor which understands the build system and figure out how to configure the thing. The slickest experience I think is Visual Studio 2022 Community Edition, but, it only runs on Windows and if you're not using its CMake support it only supports building for windows. So, I considered VS Code - which means adding a handful of plugins and configuring them each to find the compiler, the linker, the build system, the RTL, the SDKs and so on and so on. Starting a new project is not a case of hitting a menu item to create a new project, it's a matter of carefully crafting build files which litter the source code, just to get something to build and be ready for cross-platform use.

Okay, so. If I take on this task and get through it (as I did, it took some hours to figure out), then I get to a working C++ compiler... and, well, the syntax is just horrible. It has all the nice comfortable features that you might want, if you know the special incantations to use them. In my case, I wanted a procedural programming style as I'd used for my own engine in pascal, because procedural is deterministic in terms of performance, cache friendly, and actually quite pleasant to work in too. It reminds me of those good old days... C is the procedural language, but it lacks a lot of nice features such as namespaces and generics (templates), so I figured, okay, I can use C++ but limit myself to its procedural features. There's a lot to like, and it does provide most of the features that I'd want, but it's ugly as sin. C++ is designed by committee, and it shows. It's a language that feels like every syntax feature has been "bolted on" over time, where-ever there was space. Having specialized around Pascal for both my career and hobby for so long, I'm actually not a little horrified that this is where the C/C++ development world has ended up. Why do people put up with it? Well it seems that they don't all. There are developers out there that, as I did, decided to write their own compilers to ease the pain, and they are further along that process than I am. More power to them, but continuing that project myself right now is a deep distraction from my goals.

STOP!

So I decided to stop this insane rabbit-holing. I WILL at some point in the future return to building my own compiler and game engine, because that itch is just never going to go away, but as I've explained in my introduction post, my goal is to be writing games. This is what I want to be doing with my life. This feels like waking up, like I've been sleeping since the 90's. You see, in the 90's if you wanted to make video games, more or less, you were going to write a dedicated game engine for each game. I'm from the era in which you first wrote the code to put graphics on the screen, then you wrote the code to control the audio device, then you realized you'd neglected all the red-tape like input and simulation, so you got to work writing those. Games were simpler, and so too was the technology. Using a 3D rendering API would still have been rare, you'd instead write graphics to a linear memory buffer, manually. In the time since then, writing games for modern hardware and using modern API's has become ever more complex. If you want to write games today, you don't sit down and write your own engine, or get crazy and write your own compiler.... well, some do, but they clearly have longer time-lines than I do - I want to be writing games now, so it's time to just select an engine and roll with it.

So lets do a quick evaluation of "the big three." Unreal engine is incredibly powerful and high fidelity, however, I'm not going to be needing it's high-end features, at least, not any time soon, so is it worth it? It's generally considered to be a game engine for first-person games only. Sure it can be used for other types of games, but you're fighting against what it was built for, and that's first-person high fidelity. Not only that, but the programming language employed by it is C++, which I can do, but as I've already explained, I do not enjoy. So lets count that one out.

So Unity or GoDot? Well this is actually a very simple one to answer, but with a minor complication. GoDot employs a python-like programming language called GDScript, and despite some "Jitting" capabilities, it's essentially an interpreted language. This is not necessarily a blocker, but in my experimentation with it, I found it's performance to be quite poor. It does support C# also, but as an extension. GoDot doesn't target the hot consoles (nintendo / sony etc) due to licensing issues, though its projects can be ported to those consoles. Typically, porting would involve employing a porting company to do the port. Because the porting company have already ported the GoDot engine itself, they can short-cut to porting your games. If you use C# however, it may not be possible to do the port directly, because the consoles don't generally support the necessary runtime. So, Godot is out for me. I don't like the programming language, and I don't like the questions about potentially targeting consoles some day.

The Unity engine is based around C#. Unlike GoDot when using C# however, when targeting consoles it does something a little clever. It performs ahead of time compilation of the C#, compiling it down to its immediate-language, and then it ports that immediate-language representation to C++ and does a native build. For this reason, the Unity engine is able to support console targets out of the box. You do need to be approved by the target company first, but once you've signed all the relevant NDA documents and been approved, Unity will give you the tools to port and deploy your games to consoles yourself.

What about the language C#? Well, frankly, Microsoft may or may not appreciate me saying this, but it's essentially Pascal with curly braces. You see, the Chief Architect of C# is the very same man that was once the Chief Architect of the Delphi Pascal language. To claim that Pascal rubbed off on C# might be a stretch, but the influence of Anders Hejlsberg is undeniable in either language. I'm not really a huge fan of the OOP nature of the language for game development, but, I also don't really have to concern myself with it too much. You see, Unity has already been optimized to be capable of some very high-fidelity and high-performance results within its own code base, it's taken care of, so if I consider C# as merely the "scripting language" that I'll use, as is the intention for the Unity engine, then it's not too high a cost. Better yet, the high fidelity capabilities of Unity aren't a barrier as they might be in Unreal, because Unity supports a gradient of graphical capabilities and a "Universal Render Pipeline" - A pipeline designed to scale from limited mobile or hand-held devices, through to high end PC's.

The Unity Controversy

There was some controversy in recent years with Unity as a company. There was a fiasco involving the introduction of a runtime royalty fee, the back-dated changing of terms of use, and what the community described as a "trust me bro" attitude from the company with regards to this royalty fee. For the most part, as I'll explain in a moment, these issues have all gone away since, but I'd first like to take a moment to explain my own experience with this.

I've been watching Unity for a long time, since its first version perhaps, or a very early version at least. The company grew incredibly quickly, winning accolades for its fast growth actually for several years running. Why? Well, at that early time it really was living up to the company promise of "Democratizing game development." It was a company that made a game engine available for free, with very light restriction on its use for commercial purposes, and a fair, perpetual licensing model. As years went on however, it became obvious that the company was hungry for money. They rolled out a subscription model, and had a somewhat aggressive lock-in mentality towards it. I was already put off by this, but it seemed that they rolled this way for a decade or so. Unfortunately, they used that same time doing what I think was a mistake - they chased the Unreal engine. It looked as though they wanted to compete in the super-high fidelity market with Unreal, to cash in on the high-end corporate clients, and they did so to the detriment of the smaller studios and indie developers that they'd targeted with their earlier "democratizing" mission statement.

When Unity rolled out the questionable royalty fee, and back dated their terms of service (which may even be questionable legally), it hurt them. The community felt truly disenfranchised and began leaving the engine for GoDot (open source). Unity's stock price took a nose dive, and the "bloggosphere" began scathing retaliations. Small to medium game studios gifted huge amounts of money to GoDot in an attempt to promote its development as an alternative to Unity.

Unity responded by replacing their CEO and as I understand it, many of their C-level staff. The new CEO (Matthew Bromber) came in during May 2024, and immediately reversed out the royalty fee requirement, and then simplified their licensing model. Matt (Matthew) has made public statements that he has done so to be more developer-friendly, in efforts to rebuild trust in the company. I think that this is the right move. If it works, still remains to be seen. A year later, their market still hasn't fully recovered, and this is understandable. Trust takes time to build but can be destroyed in an instant. I don't envy what Matt has to do in restoring the market - but - Unity is still a very strong product and today, is a viable option again for small and indie studios.

The Solution

Having decided to shelve my own game engine project and run with Unity, my decision making process has been lightened significantly. As I explained at the start of this post, some of my skill set (such as the programming) is already up to the task, but other parts of my skillset are behind. Creating artwork for example, I'm not strong at. I have some basic skills using Moho Animation Studio (a product I would recommend to anyone with a use for it), for 2D vector graphics creation and animation. I also have the basic fundamental skills with blender. My problem is that I'm no artist essentially. While I have skills with those two products, they are at a fundamental level, not a high proficiency, and so as I study the process of creating usable game artwork, I do so in programs that remain at least a little unfamiliar.

So how exactly did making the engine decision make my decision making easier? Well now, I know where to spend my time! I no longer have to worry about writing a video game engine or a tool chain, I have an engine that I can use, and I know more or less how to work with its tool chain. While I don't claim to "know unity" in terms of the available code, classes, etc, I know that I can read manuals or tutorials and easily understand what is being done. While I don't write C# often, I know it well enough that I can consult the internet when I forget how something is done, and I'll get up to speed quickly. I don't need to concern myself with cross-platform concerns (mostly), I know that the engine is capable of it. I can dump all of the slow-grind components of building up a game, and just script what I need when I need it... and of course, I'll follow some tutorials to get up to speed. Instead, I can practice my artistic skills, which are not only in need of the practice, but, offer far more short-term rewards. I will no longer have to settle for being proud of having put a rainbow plane up on the screen, instead, I can be proud that I made a 3D dancing character and got that into a game project.

Given my limited skills, I decided to go with a "Low Poly" aesthetic and began following tutorials to create low-poly assets and characters using Blender. I don't really have a game concept in mind for them yet, these are just practice projects essentially, but I'm already making some amount of progress...

These low-poly models made thanks to the free tutorial from Crashsune Academy / Love-chan : https://www.youtube.com/watch?v=Use9T2IX1XE&list=PLcaQc6eQjXCxWXmn5jxE_GTOft9ZxChu1

With special thanks to Grant Abbitt (https://www.youtube.com/@grabbitt) who's tutorials on GameDev.tv got me up to speed with the blender basics necessary to begin the above tutorial series.

So, I can now make very "beginner" level low-poly characters and animate them.
Getting my own engine to the stage that it could run these animations would probably be another 6 months of effort!
I never thought I'd say this, but now I'm on track to become an Indie game developer using Unity.

In 1984, when I was just five years old, my parents bought me a Tandy TRS-80 Color Computer 2. To them, it was a way to support their child’s odd obsession with “becoming a computer programmer” — an idea I’d gotten from a cartoon where a computer takes over the world. To my teachers, it seemed a strange choice: “Why buy a child a business computer instead of a toy?” But to me, it was magic.

I copied programs from the user manual, played early games, and soon realized I didn’t just want to play them — I wanted to make them. That passion carried me through the Commodore 64 (in BASIC and assembler), the Amiga 1200 (AMOS, MC68k assembly, and Pascal), and eventually into the world of PCs where I discovered Turbo Pascal, Delphi, and FreePascal. That path led me into a long and fruitful career in application development.

And yet, I never stopped wanting to make video games.

The Missed Gate at Codemasters

One of my earliest bold moves was driving to the Codemasters office near my hometown. I was 17, had no interview scheduled, but drove up to the gate anyway and actually talked my way inside, claiming to have an interview. I had parked in the parking lot, when the security guard came running, red-faced, to tell me there were no interviews that day and promptly sent me home. Looking back, it’s funny — but it also says a lot: I wanted in badly enough to risk looking ridiculous.

Life took me elsewhere. I built a career in applications software — steady, profitable, even rewarding in its own right. But the itch to make games never went away.

Rediscovering the Classics with My Son

Recently, I started digging into my vintage computer collection. I fired up some of the classics I grew up with — from Monkey Island to Dreamweb. I shared them with my son, who’s eight now. Honestly, I expected him to shrug them off. After all, he has a modern PC and a tablet overflowing with games.

But to my surprise, he loved them. He got hooked on point-and-click adventures, laughed at old platformers, and showed me that those decades-old pixels still had life in them. Watching his enjoyment flipped a switch for me: I bet I could make games like this.

Enter: Studio Vandalism

So here we are. I’ve started Studio Vandalism — my indie game studio. To call it a “studio” today is generous: it’s just me, a PC, some half-formed prototypes, and an eight-year-old critic eager to give feedback. But this is where I’ll document my journey to becoming an indie game developer. I dream of turning this into a functional business which I can share with my son.

I’m not coming into this as a seasoned game dev. I’ve dabbled with Unity, Godot, Blender, Inkscape, and Moho Studio — just enough to be dangerous, not enough to be fluent. I know I have a lot to learn. But that’s the point of this blog (and the YouTube channel that will follow): to share the process, not just the result.

Join me as I chronicle my journey.