Devlog

How I ‘Vibecoded’ a Python App with GitHub Copilot (Without Knowing Python)

by

As a solo developer and family man, your most valuable resource is time. My daily routine should be about crafting levels, tweaking mechanics, and making dwarves look cool. But being able to debug my game and load different states was getting tedious, the bigger the game and asset database got.

Every time I needed to test a specific scenario lile a late-game weapon, a character at level 5, a boss fight with low health, I had to dive into a raw json file. It was a cycle of manually copy-pasting item IDs, triple checking syntax, and praying I didn’t introduce a typo that would corrupt the whole file. It was an inconvenience that was slowly eating away my will to live, and more importantly, my development time.

There was just one problem: I’m a Unity/C# guy. Python? Might as well be ancient Dwarven runes to me. The thought of spending days or weeks learning a new language and a UI framework just to build a simple internal tool was bad.

So I fired up VS Code, installed Python, installed the GitHub Copilot extension, and decided to see if I could… well, vibe a tool into existence.

The Goal: Make the Computer Understand What I Want

I knew I couldn’t just tell the AI, “make me an editor.” I had to give it the puzzle pieces. Luckily, I had two very clear ones:

  1. The Save File (savegame_999.json): The dynamic state of the player’s game. Full of cryptic stuff like "equippedWeaponID": "ranged_sharpshooter".

  2. The Asset List (GameAssetSummary.json): A clean, simple “dictionary” I exported from Unity, listing all the valid item and character IDs in the game.

JSON
//Example from the savegame. This represents one character. 
//There are also Level States. quest states, general game progress and more.

{
    "saveSlotName": "Debug Save",
    "lastSaveTimestamp": "10/03/2025 13:34:23",
    "currency": 100,
    "rescuedDwarvesCount": 3,
    "lastSceneID": "PC 3 - Demo Collection - 2 - The Corridor",
    "crewStates": [
        {
            "templateID": "dwarf_amos",
            "runtimeName": "Amos",
            "currentLevel": 1,
            "currentXP": 0,
            "maxActionPoints": 2,
            "currentActionPoints": 2,
            "movementRange": 15,
            "currentHP": 8.0,
            "maxHP": 13.0,
            "isDead": false,
            "godMode": false,
            "isSelected": false,
            "isStunned": false,
            "equippedWeaponID": "ranged_sharpshooter",
            "equippedWeaponState": {
                "weaponTemplateID": "ranged_sharpshooter",
                "currentAmmo": 100,
                "maxAmmo": 100,
                "durability": 100.0,
                "maxDurability": 100.0,
                "appliedModifierIDs": [],
                "damageMultiplier": 1.0,
                "firingRateMultiplier": 1.0,
                "spreadMultiplier": 1.0,
                "bulletsPerShotBonus": 0,
                "penetrationBonus": 0
            },
            "equippedWearableSlots": {
                "HeadItemID": "GlassesTypeH"
            },
            "equippedEquipmentIDs": [
                "actionequipment_action_mountain_brew_1",
                ""
            ],
            "learnedAdditionalSkillIDs": [],
            "baseWeaponDamage": 1,
            "baseMeleeDamage": 1,
            "initialBaseWeaponDamage": 1,
            "initialBaseMeleeDamage": 1
        }
        
  //...
  //...
  //...

My idea was simple: a tool that could look at every field like "ranged_sharpshooter" in the save file, check the asset list, and present me with a nice, clean dropdown menu of all available weapons so I could just click on “melee_brodins_axe” instead. No typing, no mistakes. Save the file. Repeat.

The Process: Pair Programming with a Robot Friend

What followed was one of the most productive coding sessions of my life. I was writing instructions in plain English as comments and letting Copilot turn them into actual Python code. And test it. And fix it. All on autopilot. It was really impressive. The simplicity of python and the integration of copilot with the log terminal made it really simple.

1. Make me an App: My first instruction was basically the programming equivalent of “Hey, can you get me a window, that allows me to edit my savegames?”

#Create a GUI with a menu to open, edit and save this Savegame JSON file

…and boom, Copilot spat out the entire boilerplate. It wasn’t pretty, but it was a window. And it worked.

2. The Magic Trick: This was the real test of the vibecoding philosophy. Instead of detailing every step, I gave Copilot a high-level, almost telepathic command:

# Look at both the savegame file and the GameAssetSummary file.

# Find the relationships between them. Let me edit the save file with real references.

I hit Enter, and the AI just… did it. It understood the relationship between the two files. About 95% of the time, Copilot just got it. It correctly inferred that equippedWeaponID should be linked to the Weapons list and a character’s HeadItemID to the Wearables list. I didn’t have to spell it out. It was connecting the dots based on the data’s structure and my high-level intent. This was the moment I truly understood the power of this approach.

3. The Fun Stuff: From there, it was just plain fun. I was basically making wishes in the comments: I can edit any aspect of any character, edit the crew composition, set the level and quest progresses, edit the Inventory, even put on hats and equip items. It felt like cheating, in the best possible way.

The Result: A Tool I Couldn’t Have Built Myself

The final editor is a thing of beauty, not because of how it looks, but because of what it represents. It’s a tool that would have taken me days of frustrating trial-and-error to build, and I got it done in an afternoon. It has everything I need. Really useful tool. I’m even thankful. Thank you Github Copilot and Claude. Good job, team.

Want to try it out? I pushed the results to github with some sample files. For it to be fully production ready I still have to put a bit of work into it. But it’s already very helpful: https://github.com/tobar-io/Into-The-Deep-Save-Game-Editor

Back to developing my game.

Thanks for reading!

Tobi

Devlog: The Great Refactor – Taming Scriptable Objects for a Robust Save System

by

Ahoy, fellow Dwarves!

Today, I want to take you on a deep dive into the engine room of Into The Deep. While I’ve been busy forging the levels for Act 1, a huge effort has been underway in the background: a complete and critical refactoring of the game’s core architecture, specifically how it handles and saves your progress.

The Glorious Trap of Scriptable Objects

Anyone who has worked with Unity loves ScriptableObjects (SOs). They are a blessing for prototyping. You can create data containers as assets, drag-and-drop references in the Inspector, and everything just works. It’s wonderfully simple.

The one that started it all. Like many Unity developers, I was completely blown away by Ryan Hipples ideas and completely changed my way of prototyping by using referenced scriptable objects. No problem for prototypes… but for persistent game data.

My initial approach for save games was built entirely on this structure. I had a PlayerData SO, which held a reference to a CrewSO, which in turn held references to CharacterSOs. When Amos took damage during a playtest, my code would simply change the health value directly inside the Amos_CharacterSO asset. Convenient? Absolutely. A good long-term idea? Not so much.

I had walked right into the classic trap: I was using SOs, which should be templates, as storage for mutable runtime data. It’s like building a house and then drawing on the original blueprint with a marker to show where you put your couch. The next time you use that blueprint, you’ll be wondering why there’s a couch already drawn on it.

The Cracks in the Foundation

This approach worked for a quick demo, but as I started building a real game, the problems became glaringly obvious:

  1. “Dirty” Project Assets: This was the biggest headache. If Amos died in Play Mode and his health was set to 0 in the SO, it stayed at 0 after I exited Play Mode. I had to manually reset my project data constantly to get a clean test run. This is error-prone and incredibly annoying.
  2. No Multiple Save Slots: How could I possibly manage three separate save files when they all reference and modify the exact same CharacterSO assets? It’s impossible. Each save would effectively overwrite the state of the others.
  3. The Serialization Dilemma: To save a game to a file (like a .json), you need to serialize your data. Unity’s JsonUtility can only serialize simple data types (strings, ints, floats, etc.). It has no idea how to convert a direct reference to a project asset like a ScriptableObject into text. That reference is just a “pointer” inside the engine; in a text file, it’s meaningless.

It was clear: the system had to be rebuilt from the ground up.

The Solution: The Great Separation of Template and State

The new system is built on one fundamental principle: a strict separation between Template Data (the blueprint) and State Data (the current save game).

1. The Blueprint (Template):

My ScriptableObjects (CharacterSO, WeaponSO, etc.) are now treated as pure, read-only templates. They only contain the base values: a character’s name, their maximum health, a weapon’s base damage. They are never modified by code during runtime.

C#
// CharacterSO.cs - The Template (Read-Only)
[CreateAssetMenu]
public class CharacterSO : ScriptableObject
{
    public string characterID; // e.g., "amos_eisenfaust"
    public string characterName;
    public float maxHealth;
    // ...other base stats...
}

2. The State (Instance):

For the data that changes, I’ve created new, simple C# classes (often called POCOs) that don’t inherit from anything and just hold data.

  • CharacterState: Stores only what changes for a character, like currentLevel, currentXP, currentHP.
  • GameSaveData: This is the main container for a complete save file. It holds lists of these State objects (e.g., List<CharacterState> squadStates).

The crucial trick is that these State classes don’t store direct references to the SO assets. Instead, they only store a simple string ID. So, Amos’s CharacterState doesn’t contain the Amos_CharacterSO asset, it just contains the string “amos_eisenfaust”.

C#
// CharacterState.cs - The Saved Data
[System.Serializable]
public class CharacterState
{
    public string templateID; // The "link" back to the CharacterSO
    public float currentHP;
    public int currentLevel;
    // ...other dynamic data...
}

How It All Works: IDs and The Database

To make this work, I created a central GameAssetDatabase. This is a single ScriptableObject that holds references to all my template SOs (characters, weapons, levels, etc.).

The new save/load flow looks like this:

  • Saving: A DataManager collects all the State objects (from all characters, quests, etc.), bundles them into a single GameSaveData object, and serializes it into a JSON file. The string IDs can be saved perfectly.
  • Loading: The DataManager reads the JSON file and reconstructs the GameSaveData object in memory.
  • Instantiating: A SquadManager looks at the list of loaded CharacterState objects. For each one, it takes the templateID (e.g., “amos_eisenfaust”), goes to the GameAssetDatabase and asks, “Give me the CharacterSO with this ID.” Once it has the template, it spawns the character’s prefab and applies the loaded state (currentHP, Level, etc.) to it.

This pattern of separating data and referencing assets via IDs wasn’t entirely new to me. My previous explorations into multiplayer with Netcode for Gameobjects use a very similar approach, as you can’t send complex object references over the network—only serializable data like IDs. That experience really taught me to appreciate this robust, decoupled architecture.

The Best of Both Worlds: Making Testing Easy Again

The biggest drawback of this clean system is losing the convenience of setting up test scenarios in the Inspector. I can no longer just drag a “Test_Savegame_SO” into a manager.

My solution is an Editor-only tool. I’ve created a special SaveFilePresetSO that only exists inside the Unity Editor. Here, I can drag-and-drop CharacterSOs, set test values (Level 5, 1000 gold, etc.) just like before. A custom button in the Inspector, “Generate JSON Save File”, then converts this preset into a clean, loadable .json save file.

C#
// SaveFilePresetSO.cs - An Editor-Only Tool
[CreateAssetMenu]
public class SaveFilePresetSO : ScriptableObject
{
    [Header("Test-Setup")]
    public int saveSlotIndex = 99;
    public int currency = 1000;
    public List<CharacterPreset> crewRoster; // Can drag CharacterSOs in here!
    // ...
}

[System.Serializable]
public class CharacterPreset
{
    public CharacterSo characterTemplate; // Direct SO reference for editor convenience
    public int level = 5;
}

This gives me the old convenience without compromising the clean runtime architecture.

The Moral of the Story

If there’s a lesson here, it’s this: Refactor sooner rather than later. The initial comfort of a “hacky” prototyping solution creates a massive “technical debt”. Unraveling that architecture later is an enormous and sometimes frustrating task, as it touches almost every single system in the game.

But there’s a silver lining: being forced to go through every class, from CharacterUnit to GameManager, also gives you a unique opportunity to clean up, improve, and solidify your entire codebase. It’s safe to say this ID-based architecture will be my standard practice for all future projects. The days of using ScriptableObjects for dynamic data are definitely over!

Thanks for reading!

Tobi

Into The Deep – Full Focus on Act 1!

by

Ahoy, fellow Dwarves!

For decades, our people have wandered in exile since the fall of our great mountain-home, Ølheim. But now, the time has come to reclaim it!

Amos – King of Ølheim

Thank you for your support and for being part of this community. It’s time to give you a more detailed look behind the curtain and share our plans for Into The Deep, with a full focus on Act 1 of the game. Our goal is to forge a rich, tactical experience, and your feedback is the fuel that keeps our smithing fires burning!

Heading into Production!

I’m happy to announce that after countless hours of hard work, the foundational gameplay systems (like combat, movement, and squad mechanics) are now “largely” in place (who am I kidding?). This means we are officially moving into the production phase!

Our main focus from now on will be on level design – crafting the exciting, challenging, and story-rich missions of Act 1. Alongside this, I’ll be developing the cool new features that round out the experience, like the evolving Camp and the introduction of NPC traders.

This plan is our blueprint for turning the core gameplay into a full-fledged adventure.

Gameplay Philosophy

My biggest inspiration is the fantastic gameplay of games like SteamWorld Heist. The development is committed to these core principles:

  • Tactical, Skill-Based Combat: Every shot counts with a manual aiming system with a reliable trajectory. This will allow for skill shots and ricochets! Using the environment to your advantage will be crucial. But better stay in cover!
  • Squad: You won’t just be controlling generic soldiers. Every character you recruit, starting with Amos and Glimra, will have unique starting abilities and skill trees. Your choice of squad members will have a real impact on your strategy in each mission.
  • Customization: Finding loot is exciting! You’ll discover a wide variety of weapons and utility items (like grenades and buff potions). Equipping your squad for the upcoming mission is a huge part of the fun.
  • Progression: Your efforts will be visible. I want to create a clear sense of progression, not just for your characters, but for your base of operations. The camp will evolve from a few tents into a lively hub, showing your journey.

The Journey Through Act 1: The Mine

Your quest begins with a single goal: to find a way back into the lost city and take the first steps towards fulfilling an old prophecy that promises to restore the dwarven spirit.

I’m experimenting with comics as a narrative format

Act 1 is designed to be a complete, self-contained adventure that forms the foundation for the rest of the game. Our plan is to build 5 main, handcrafted levels that will guide you through the story of Act 1, from your first steps into the darkness to a dramatic final confrontation. For all you explorers out there, I’m also planning to sprinkle in optional side-missions and hidden secrets for you to discover. Each level will introduce new challenges and story elements.

The Camp: Your Growing Home

Your base of operations evolves with you!

  • Phase 1: You’ll start in a rudimentary camp on the surface, with just a few tents and a campfire.
  • Phase 2: By the end of Act 1, you’ll establish a proper operational base down in the mine’s tavern. This will be a lively hub where you can see the dwarves you’ve rescued.
  • NPCs with a Purpose: Rescued characters will offer services!
    • The Brewer: A legendary master craftsman, said to be the last dwarf who knows the recipe for the famed Ølheimer brew. He’s key to fulfilling the prophecy and can create powerful buff potions and healing items for your team.
    • The Trader: A resourceful dwarf who will buy your excess loot and sell essential supplies.
    • more to be announced

A Word from a Solo Developer

Into The Deep is a passion project developed by just one person – me! This is a massive undertaking, and bringing this world to life is both a challenge and a joy.

I also want to be transparent with you all. I had to scale back my output over the last few months as I was getting close to burnout trying to juggle my day job, family, and game development. It’s a tough balance! However, I’ve found a better rhythm now and am back to making slow but consistent progress. I’ll also do my best to post more frequent updates and automatically generated changelogs, which you can follow in our new Changelog Section.

My primary goal is to build a cool, polished, and complete short adventure for you to enjoy. This means I have to be smart about which features make it into the initial release. While I have a vision for the game, my focus is on delivering a higher-quality core experience first.

The biggest problems are graphical assets. If I would do anything on my own, it would add years to my development schedule, so I’m glad that I can buy much of the stuff I use. This may lead to a bit of inconsistent experience. But I hope my eye as a designer and product manager will enable me to set this off a bit.

Focusing on a “Guiding Thread”

There is a German expression that describes exactly what was missing in the development phase. A “red thread” – a thread that holds everything together and makes it coherent, that indicates the direction like the North Star. I think I’ve found it now by defining the basic story and plot. Now I can weigh every decision against it. Now that I have it, I feel motivated to finally tackle the levels and take care of the design.

I’m tracking every core system that has to work for act 1 or needs polishing or refactoring in a list … hey. At least I’ve got a plan.

I think that will be a point that will be at the top of the post mortem of this project, and it really would have saved me a lot of frustration. My nature tends to say “make it quick and try it out”, and my lack of experience with systems has forced me to work around problems as long as I can instead of solving them right away. But hey! This is my first real solo game development project. That’s part of it.

Join Our Community & Future Playtests!

As we dive deeper into production, I hope to hold irregular playtests to gather your invaluable feedback. The best way to stay updated on this and to become part of our growing dwarven clan is by joining our official Discord server.

Join us here: https://discord.gg/prF4CrRSrg

Into The Deep Demo Surfaces – Grab Yer Axes and Plunge In!

by

Hey everyone! I’m excited to announce that the first demo of Into The Deep is now live and available to download on itch.io, as well as playable directly in your browser.

About the Game

Into The Deep is a turn-based tactical adventure game that plunges you into the dark depths of a lost dwarven city. You’ll lead a brave group of dwarves through dangerous catacombs, fighting to reclaim their home from an ancient evil.

This is my first game, and it began as a learning project in early 2024. Now, I’m finally able share a playable version with all of you! The game still has a long way to go, but I want to gather feedback from players as fast as possible, because I’m completely unable to say if I go the right direction without help. In Germany we have a saying “I can’t see the forest through all the trees”. And that sums it up quite well.

What’s in the Demo?

This demo focuses on giving you a feel for the core gameplay mechanics. It’s centered around tactical turn-based combat, where your squad of dwarves must outsmart enemies in strategic battles. While there’s a lot more planned (like story and progression systems), this demo gives you a glimpse of the core of Into The Deep.

You’ll have access to:

  • Two playable levels that showcase the tactical combat system.
  • A few initial abilities for the characters Amos and Rocky.
  • The chance to experiment with different weapons, skills and strategies
  • Three enemy types

What’s missing?

Quite a bit! There’s no story or progression yet, and a few key features—like camp upgrades, more levels, and new characters—are still in development. But your feedback at this stage is incredibly valuable!

What’s Next?

Here’s a preview of what’s coming up:

  • Camp Expansion: Upgrade your camp to unlock better gear and recruit new characters.
  • New Characters: Amos and Rocky will receive more unique skills, and a third dwarf will soon join the team.
  • More Levels: New, more challenging levels are in the works.
  • Items, Skills, and Loot: More equipment, abilities, and loot are on the way, including some exciting new headgear and abilities.

Regular Updates

I’m working on the game daily, and I plan to release updates on a regular basis. You can expect to see new features, improvements, and bug fixes rolled out frequently. Keep an eye on this page for the latest news and changelogs!

Join the development journey!

I’m still learning as a developer, and I’d love to hear what you think. Your feedback will directly influence how the game evolves! There’s a feedback form in the demo (though currently not working due to a Trello issue), and you can always join my Discord to chat, share ideas, or report bugs.

Thank you all for your support! I’m looking forward to hearing your thoughts and seeing where this journey takes us.

But most importantly: Have Fun!

– Tobi

Into The Deep: A Tactical Sidescroller Adventure – Announcement

by

Hey everyone! I’m excited to share that the Into The Deep demo will soon be available on itch.io. You’ll also be able to wishlist it on Steam!

About the Game

Into The Deep is a tactical sidescroller inspired by games like Steamworld Heist and XCOM. This is the first game that I plan to finalize and release, and I’ve poured a lot of time and passion into it. I started it as a learning project, and now I’m eager to see how players will respond. I learned a ton! I would have done many things different if I would start again. But it works! I’m really looking forward to it and to start my gamedev journey with it.

What to Expect from the Demo

In this early demo, the focus is on the core gameplay mechanics and the overall feel of the game. Although the story and progression aren’t included yet, I’m eager to hear your thoughts on the gameplay. You’ll experience turn-based tactical battles, leading a group of dwarves in strategic fights against their fallen brothers and other dangers lurking in the dark.

Join the Development Journey

As a new developer, I greatly value your feedback. I’ve included a feedback form directly in the game, and I would love to hear your thoughts on how to improve the experience. Whether it’s about the gameplay, controls, or overall vibe, every bit of feedback will help shape the future of Into The Deep. Also: I need to know if there is any demand for a game like that.

To stay connected, join my new Discord to chat, share bugs and features ideas, and keep up with the latest development updates. I’m committed to being as transparent as possible, and I’ll regularly share progress on Discord and my Development Trello.

Join the Discord Community | Follow Development on Trello

Subscribe to my newsletter!

Building a flexible drag and drop hacking system with Scriptable Objects.

by

The Mission of this devlog: To provide players with the power to hack various objects in the game world, unleashing a multitude of actions, from disabling cameras to causing explosions. In short: Causing Mayhem. So, let’s get right into it.

Drawing Inspiration from Watch Dogs

Watch Dogs, a game that allows players to hack into an interconnected city, served as my primary muse. I was captivated by the idea of giving players the ability to manipulate their surroundings and devised a plan to bring this level of interactivity into my own project. Also I am very inspired by its clean and functional UI.

Conceptualizing the System

My system revolves around a few core components:

1. HackableSO (Scriptable Object): At the heart of my system lies the HackableSO, a Scriptable Object representing objects in the game world that can be hacked. Each HackableSO carries critical information such as descriptions, sprites, battery costs (if applicable), and most importantly, a list of HackableActionSOs.

2. HackableActionSO (Scriptable Object): These Scriptable Objects hold the logic for actions that can be executed on a HackableSO. Actions like “Disable Camera” or “Trigger Explosion” are defined as HackableActionSOs. They encapsulate the execution logic for their respective actions.

3. Drag-and-Drop Interface: My system makes it possible to include as many interactions to one hackable as I want. Just to select a HackableSO and attach HackableActionSOs to it. Done.

4. Runtime Execution: When a player decides to hack a HackableSO, all the associated HackableActionSOs spring into action, executing their designated functions.

Code Examples

Here’s a sneak peek into the code that brings my dynamic hacking system to life. I’ll focus on the two key Parts: HackableSO and HackableActionSO. These just get called via a hacking ability like that: hackableSO.Execute();

C#
// HackableSO.cs
using System.Collections.Generic;
using UnityEngine;

[CreateAssetMenu(fileName = "Hackable", menuName = "Scriptable Objects/Hackable", order = 0)]
public class HackableSO : ScriptableObject
{
    // ... (other variables)

    public List<HackableActionSO> hackableActions;
    List<HackableActionSO> instances = new List<HackableActionSO>();

    public void Initialize(Transform position, GameObject gameObject, ObjectHackable objectHackable)
    {
        // Initialization logic for HackableSO
        // Instantiate HackableActionSOs and add them to the 'instances' list
    }

    public void Execute(Transform position, GameObject gameObject, ObjectHackable objectHackable)
    {
        // Execution logic for HackableSO
        // Loop through 'instances' and execute associated HackableActionSOs
    }

    public void Deinitialize(Transform position, GameObject gameObject, ObjectHackable objectHackable)
    {
        // Deinitialization logic for HackableSO
    }
}

In this code snippet, HackableSO is responsible for initializing and executing HackableActions. It maintains a list of instances of HackableActionSOs to ensure that each action can be executed independently.

C#
// HackableActionSO.cs
using UnityEngine;

public class HackableActionSO : ScriptableObject
{
    public virtual void Initialize(Transform senderTransform, GameObject senderGO, ObjectHackable senderObjectHackable)
    {
        // Initialization logic for the action
    }

    public virtual void Execute(Transform senderTransform, GameObject senderGO, ObjectHackable senderObjectHackable)
    {
        // Execution logic for the action
    }

    public virtual void Deinitialize(Transform senderTransform, GameObject senderGO, ObjectHackable senderObjectHackable)
    {
        // Deinitialization logic for the action
    }
}

Meanwhile, HackableActionSO serves as the base class for all hackable actions, providing methods for initialization, execution, and deinitialization, making it easy for me to create custom actions.

Example for a HackableSO Configuration

Here is an example for that Hackable Action that just instantiates Objects like particle effects and sound.

C#
public class InstantiatePrefabAndSound : HackableActionSO
{
    public bool stopAfterSeconds;
    public float secondsToStop;
    public List<GameObject> ObjectsToInstantiate;
    public List<AudioClip> audioClips;
    
    public override void Initialize(Transform sendertransform, GameObject senderGo, ObjectHackable senderobjectHackable)
    {
        // Additional initialization logic can be added here
    }

    public override void Execute(Transform sendertransform, GameObject senderGo, ObjectHackable senderobjectHackable)
    { 
        foreach (var gameObject in ObjectsToInstantiate)
        {
            var go = Instantiate(gameObject, sendertransform.position, Quaternion.identity);
            go.transform.parent = sendertransform;
            go.SetActive(true);
            if (stopAfterSeconds) Destroy(go, secondsToStop);
        }
        
        foreach (var audioClip in audioClips)
        {
            // Play sound once
            AudioSource audio = senderGo.AddComponent<AudioSource>();
            audio.clip = audioClip;
            audio.spatialBlend = 1;
            audio.Play();
            if (stopAfterSeconds) Destroy(audio, secondsToStop);
        }
    }
    
    public override void Deinitialize(Transform sendertransform, GameObject senderGo, ObjectHackable senderobjectHackable)
    {
        // Additional deinitialization logic can be added here
    }
}

Devlog: Litte box of joy

by

So, I’ve spent the last few days sorting through the mess in my project and rolling back to an earlier state from my trusty git repo. Gotta admit, the motivation’s been taking a hit with all the rewiring and development work looming ahead. But you know what? Today was a different story. Managed to wrap up all those loose ends and finally jumped back into the development phase where the real fun is. Feels awesome to just let loose and work on some simple, quirky mechanics again.

I was just thinking about my Reddit thread asking for ideas about indoor stealth mechanics. Instantly, my brain went, “the Box!” Seriously, the simplest and coolest idea. Spent about an hour or so putting it all together: rough animations, particle effects, an Ability class, and the interaction event that kicks it all off. And guess what? It’s like the perfect little chunk of joy.

Found the fun!

Devlog: Crouching Ability

by

After my rant about relying too much on premade Assets, I’m making progress on my new custom character controller. The first and maybe most important Part of stealth locomotion is the Crouching/Sneaking ability. So I opened up Etras Starter Assets, inherited the base ability class and wrote my solution from scratch.

WebGL Demo

Features

  • The crouching ability can be triggered by toggling or holding
  • An “over-the-shoulder” cinemachine camera gets activated, as soon as the view gets narrower
  • The player will only stand up if there is enough headroom, to reduce clipping
  • The component will detect if there is a space in walking direction where crouching is possible
    • Optional Layermask detection
    • Enables crouching automatically
    • Checks if the space is between crouching height and standing height to minimize unwanted detections
C#
    private bool DetectCrouchableObstacle()
    {
        if(m_IsCrouching) return false;
        var rayCastOrigin = autoCrouchRaycastOrigin.position;
        var rayCastOriginlocalPosition = autoCrouchRaycastOrigin.localPosition;
        
        var isAboveStandingHeight = Physics.Raycast(rayCastOrigin, Vector3.up, defaultStandingHeight - rayCastOriginlocalPosition.y, autoCrouchDetectionMask);
        var isAboveCrouchHeight = Physics.Raycast(rayCastOrigin, Vector3.up, crouchHeight - rayCastOriginlocalPosition.y, autoCrouchDetectionMask);
        return isAboveStandingHeight && !isAboveCrouchHeight;
    }

Things to improve

  • Enable Rootmotion
  • Fine tuning of the camera behavior – Update existing camera instead of adding a new one.

Challenges

  • Unity Character Controller behaviour
    • When switching back to standing height too early, the player collided with the walls and got catapulted in walking direction
    • I tried it with lerping from crouch to stand first, but that led to different issues
    • Fix: Check for collisions on the whole character radius with boxcast instead of raycast
C#
    private bool CanStandUp()
    {
        return !Physics.BoxCast(transform.position, characterController.bounds.extents, Vector3.up, transform.rotation, defaultStandingHeight, obstacleMask);
    }

Main Take aways

I set myself the challenge when writing the component and for future components that it must be immediately understandable even to outsiders. That was kind of really fun. Also:

Simple, decoupled one-purpose components are so nice.

Starting from Scratch – A Retrospective

by

I’ve found myself in this situation again. This is just a rant about myself. What was initially a beautiful project, designed to be a lean prototype, has once more spiraled out of control. That means dealing with dozens of assets all intricately connected, expensive plugins, overloaded integrations, and a web of dependencies. Coupled with a switch from URP to Build-In Render Pipeline mid project due to compatibility reasons. The project is fine per se. I have no big problems and it still is maintainable. But it feels bloated with redundant files and piles of stuff I will never use again.

So, here we go again, launching attempt number three – a fresh start. My goal is to bring my vision to life without getting bogged down in micromanagement. That’s why I’ve decided to kick things off with my first devlog. Hi there!

Introduction

I’m Tobias, and this marks the very first devlog of my journey as a solo developer. Over two decades in the game industry have taught me many things… not programming, though. Instead, I’ve learned how to navigate office dynamics and human interactions in that environment. You might be thinking, “Office? Do you mean the room where I keep my gaming rig?” Nope. I’m referring to a place where a diverse group of people must coexist and where 90% of problems are dumped on just 1% of the employees – the IT department. This is where our protagonist, Peter Struggle, comes into play.

Game Concept

Meet Peter, the lone IT employee in a company plagued by mountains of daily main and secondary tasks. His mission: to minimize open tasks by the end of the day. However, every interaction with a fellow employee adds a new task to his list. Players face a choice: take the risky but quick path, potentially piling up tasks, or opt for stealth and diversion to keep interactions, and subsequently tasks, to a minimum. When Peter has zero tasks left, he gains bonuses that can be used to enhance his skills and tools. The gameplay draws inspiration primarily from games like Splinter Cell and Hitman, incorporating casual graphics and humor to fit the scope of a solo developer, mixed with popcultural references to IT Crowd, The Office, Severance, Mr. Robot and Silicon Valley.

Third Person Controller

Ah, the allure of Feature Creep strikes once more. But I started out on the right foot with the versatile, community driven and beautifuly barebones “Etra’s Starter Assets” controller – a free gem that I can’t recommend enough. It’s a straightforward and remarkably efficient controller, complete with some useful extras.

So, I started integrating Peters abilities – crouching, shadow detection, sneaking, interaction UI, and even an extended interaction component. No issues there. Integrating Rewired? Smooth sailing. Implementing Final IK? Mission accomplished. Even integrating movement via behavior trees was a breeze. The true power lies in the asset’s well-structured simplicity. No mysterious scriptables or confusing dependencies. If you need component X, simply add it wherever you want. Need to disable an ability? Just call .enabled=false. Need an extension? Use the event system. The Unity way.

The temptation of the Unity Summer Sale – The sunk cost fallacy strikes back

But then the summer sale came. After buying and trying out “Invector,” I thought I was through with character controllers. I have a strong aversion to bloated assets that weigh down entire projects. However, the highly praised Opsive Third Person Controller caught my eye during the Unity Summer Sale. What could possibly go wrong? After all, it’s the best-selling asset around, and the Opsive Behavior Tree is a seriously awesome asset. So, I took the plunge and made the purchase, despite some lingering doubts – even after watching this video:

“It feels bloated, but also like something is missing.” I cannot agree more.

So, after spending days of reading documentation, watching tutorial videos, and trying to piece everything together, I found myself filled with buyer’s remorse. I was saddened by the fact that I had abandoned my beautiful custom controller for this massive monolith of an asset and lost the speed and traction, that I started with. Integrating it with other packages, even official integration packages, became a real headache. I was overwhelmed. I felt frustrated spending hours on simple tasks like incorporating my sound manager system or getting a feel for the locomotion and camera movement. In the end, I used the old approach, placing function on top without utilizing the built-in functions of the character controller. Unfortunately, it felt like adding a fifth wheel to a car – an awkward and unfitting addition. I always have the feeling that it could break any second.

This is just an example for a general problem I have with some premade assets. The Opsive Character Controller is a very good asset, the developer is awesome and the support is stellar. But in a fast iterating prototyping phase, it just slows me down. Others may find the “completeness” of the asset comforting, but for me its ballast. I just want to have a blank slate that I can hook some components on or remove them, without breaking everything. But this is something I learned the hard way. Keep it specialized. There is no “one size fits all” solution in game dev.

What I definitely will use the Opsive Character Controller for in my prototyping phase is the awesome integration with the Behavior Designer or AI Navigation in general. Its just flawless and setup in under a minute. And thanks to the extended animation system, it just looks good from start.

I have already prepared some Behavior Trees and Character Sheets that I can reuse 1:1. What would a stealth game be without “Wait, who’s there? Oh, it was just the wind”. Only that in my game it will sound more like “Hey Peter! I have a problem with my PC. Can you help me?”

Modular Asset Packs

As the owner of quite a few modular asset packs from Synty and co., I am naturally often tempted to load everything I have directly into the project. That’s obvious. You want to “quickly and easily” click together a few levels. I noticed that using pre-made graphics tempted me to focus on too many details already. Therefore, I decided to work only with prototypes from now until the basic systems are finished. This should help me to concentrate on the essential issues of the development. I will go back to a basic tool for prototyping and level design: Greyboxing with Probuilder. Simple and easy. This way, questions of believability should only arise later, when it comes to the final level design. For now, it’s about “finding the fun”.

The Office Scene I tried to fit in all my mechanics made of prebuild modular Assets.

I found it challenging to find a balance in level design that emphasizes stealth mechanics while providing a believable environment. Normal office buildings consist of long corridors and individual offices with little open space. Many of the stealth game mechanics I want to incorporate require the player to have a good overview and not be constantly surprised by enemies running out of offices or the like. Using premade assets led me to “work around” the mechanics to find solutions for the assets I have. I think that is a big game design mistake I made. But maybe I will go in further detail in a later post about stealth mechanics.

New Beginnings – Have you tried to turn it off and on again?

And so, the first entry of Struggle Peter’s devlog begins with “Embracing the Awkward.” Back to the drawing board. Starting a new project. Salvaging the old one. And before putting in assets, really thinking about “Do I really need this in my folder?”, “Does it serve my vision?”. I’m more motivated than ever to bring my Project to life. It’s a learning project. Not a big one. All the problems I encountered, I encountered countless times before. Maybe this time I learned my lesson. Maybe. Man, I love this.

Notion is a big help to stay organized.

My Plan for the future of the project

  • Stay agile at all costs
    • Stick to the MVP
    • Delivering fast working increments
    • Let people test
    • Reduce Micromanagement
    • Have a playable version ready in one month
      • Post iterations on itch.io
  • Managing expectations
    • I started this project to learn how to develop and release a simple game
    • Even with my experience, I’m still a beginner and nobody expects my first real game to be perfect
  • Keep track of and report the progress, even If I am the only one who will ever read it (this blog)
  • Always try to clean up the mess after a long coding session.
    • Organize so that it is also quickly understandable and readable by others. Even if it is the future self. He kinda forgets everything all the time.
  • Keep Notion as my Game Design Document and Vision Board, its excellent for that
    • Mark MVP Features to keep organized
  • Don‘t buy assets until it‘s clear where the project is going – ignore FOMO
    • Understanding and integrating new and unknown assets take a lot of time. I dont have a lot of time.
  • Assets that I feel comfortable with and will add to the project to boost productivity