8 Months of Unity Dev with Claude Code transcript

I found a workflow that feels right to me, and by that I mean it makes me less likely to quit making games when I'm making it solo, right? It's one thing to be an artist in a game studio, that's very easy um compared to trying to make your own video game. And for the longest time I've tried to like learn to code, I've taken classes like, I don't know, 15 years ago. There is something that about that process that um it just didn't click with me.

It's not that I'm like stupid, I I I I can't learn. I can learn it. It's just It's more about a matter of interest, and I finally found a approach that I really enjoy, not because it's better or faster or whatever arguments people like to make. It's more that it just feels good to me, and that is for the coding part, I don't write code. I just use cloud code. And in this video, I'll actually show you my newest approach for how I get stuff into the game by creating a shop for my game.

And this is the last real new feature in my game. All right, so one thing I did, and you'll notice in this video, I toned down the colors a little bit. Some of the comments I get are pretty brutal, and the idea is that usually, and this is my experience, um if someone says, "Hey, your graphics um look cheap." Usually that implies something It looks kind of like a mobile game, and generally that means maybe too saturated.

At least in my game, I that's what I how I took it. One thing that I did is I added a toggle on the main menu, settings menu, where you can enable it for dark mode, which basically, if you look at here, I just desaturate the saturation. Uh what? It's kind of implied, right? Basically, I desaturate the image, and then I darken the outer edges of the frame. And I'm starting to like this approach or this look a little bit more.

So, I have a new shop feature that I need to start working on. So, this is my general prompt that I use for generating my implementation. And just to give you an idea of what the actual shop looks like. In my game, I have this giant prefab called don't destroy on load prefab. Everything here just doesn't get destroyed, is persistent. And specifically, what I'm working on is a new panel called shop. Basically, before I start working on any new UI feature, I first build out the UI.

So, in this case, I've built out this thing called shop. And let me see if I can make this a little bit easier to tell. I've basically pre placed the nodes where the card's going to be. There's going to be artifacts, there's going to be potions, and there's a card removal button. Just to give you an idea of how simple it is, all the code needs to do is just basically instantiate the card prefabs inside of here, and it should just line up.

Just in order to make sure that Claude doesn't spend a lot of tokens searching for where my shop panel is, I like to give it a reference. Right now, you see how this is not blue? That means there's no prefab of this shop panel. What I'm going to do is I'm just going to drag and drop it into my project. Now, it's blue. So, if I exit this, and I go into the shop panel, this is a nice way for Claude to just be able to read this without having to read my don't destroy on load prefab.

Otherwise, if I don't do that, in order for Claude to to read where my shop object is in this prefab, it has to go through so many things. And if I open up my manager, um let me show you. There's all these different managers, and all this gets fed into the context window, and really I just want to avoid that. Everything here has scripts on it. And all of this would go and add noise into the context. So, in order to avoid that, I've added this shop panel prefab, so that it can just go directly there.

I'm going to right click, copy path. I'm going to go into this Google Docs. Here, I'm just going to paste the path. I'm going to let Claude figure the rest out. And then also to show you, I have a design document. So, this document here is the other file I'm going to share with Claude. And this is purely design. It's not technical. It's just a design spec sheet. There's not one thing in my game that I try to one shot.

I just found that it's not even a useful thing for how I like to work. It also frees me up on not having to create perfect documentation before I I proceed to actually start working on things. Copy file path. I'm going to go back into here. So, now it has my design document, and it has the general prefab. And now, I'm just going to copy paste this into Claude. Now that I'm here, I'm going to paste the information. All right, so it looks like it gave me the implementation plan, and I'm just going to read it real quick.

Sometimes I like to run a quick audit. Audit in this case is a command that I created. It tells Claude to spawn a bunch of sub agents. They all get the same prompt. They all have to read my project rules, which is strict rules that I've defined in my Claude.md file. And then, they all need to compare the design intent documentation I've gave to Claude. We need the design and the project rules respected within Claude's implementation.

Sometimes, before I get too deep in reading the implementation, I just run this audit. The audit's there to catch easy errors. I don't want to waste my time thinking deeply about faulty implementation plans. So, I'm going to run that right now. I've made this so that I can specify how many sub-agents to use. In this case, because this is a huge task, I'm going to do option three, which uses five sub-agents. And generally speaking, I avoid having such a dense implementation plan.

This is probably the most dense implementation plan I've done in the last month. So, this is unusual. For this video, it's fine. But I I have no expectations of it getting it fully right. It won't, because I didn't do a great job in designing the implementation plan. It's not fully scoped out, but that was my intention. I expect to run probably 20 more prompts before I land somewhere that feels right. So, here I got the audit results.

Solves the issue, yes. Follows rules, no. Verdict, no. So, it failed most of the audit. And keep in mind, just generally speaking, none of this is really true. Yes, no, these are meaningless. It is almost never correct. And that's okay, cuz I don't I'm not actually looking for perfect. I'm just looking for something that is closer to right. Yes, please revise the implementation plan until you pass the audit. Update the implementation plan and let me know when you're ready to rerun the audit.

This task is really complex. So, it's very likely that it'll never truly pass the audit. Generally speaking, if I really want to make sure that the audit is almost near perfect, then I would probably make this implementation plan probably 10 times smaller. All right, that looks much better. And I'll go ahead and I don't think it's ever going to pass a full yes on everything. Not with the amount of ambiguity I've added into the implementation plan.

So, I think this is in a good spot. Yes, this looks correct to me. Are you ready for implementation? You can see in the bottom right corner my contacts left until auto compact is 12%. Generally speaking, when you hit that point, you want to go into a new chat. Lately, I've just been letting it run in auto compact, and it's generally fine. Can you please finish the remaining tasks for me? This includes creating the necessary files and doing any of the necessary wiring for me.

Thanks. So, is the shop ready for me to test in game? All right, so let's go ahead and take a look at the prefab. Here is the shop. You'll see all of these new scripts. Question, on the shop controller, I don't see the references connected for the card removal slot, the removal cost text, and the close button. Is this intentional? All right, the references are in. So basically, obviously, none of this really works right now.

But the idea is that I will slowly, over the coming days, get closer and closer as I QA test this. If you compare this video that I'm showing you of a playthrough of my game to the previous video before this, you'll notice a lot has changed. When I first started making this idea out of inspiration, I was like, I'm going to work on this for 1 year. Or I think it's going to take me 1 year. And as I've been getting closer to a playable state, I've realized I need to scope back a lot of the main features.

Cuz right now, I'm I'm in the dark. I'm developing into the void in some sense, until the game is playable and people can actually give me some feedback on it with without just watching YouTube videos. And I have no problem working on this game for a long time and making features if I knew players would really enjoy it and have a great experience. I don't want to waste my time, basically. I've been severely cutting back on a lot of the features that I wanted into the initial first beta because balancing is brutal.

Um the amount of bugs is crazy, the amount of cars that I was planning, the the amount of biomes, all that stuff. So what I've done is, I've scoped back. The goal has been adjusted to within a year, I want it to be the demo playable, all that stuff. That would be like a like a launch of sorts that in order to do that, I've cut out a lot of the features that were planned for the demo. So, um before I had plans for nine characters, I dropped that down to three.

Three biomes, I dropped it down to one. The reason why the idea of solo indie development resonates with me is is this idea that I don't work on something without sharing with people. Like with the when you're working in a game studio, they're like, "Okay, NDA, you can't talk about this. Don't don't even speak about it. Don't Like, there's all these rules, and I really don't like that. And I and I feel like I don't want to fall into that trap.

The strength of being a solo indie developer is if you don't enjoy that kind of workflow, you don't have to do it. And I don't want to do that. And I think I'm trying to find the right balance because clearly I don't want people playing a game that I know is not done, but giving the wrong perception like the intention is to release a buggy game. And I want to find a good balance where I'm not just like holding the game tight and like, "No one gets to see this until it's perfect." I don't like that kind of workflow, but also I don't want to show it so early that it gets people discouraged.

Maybe that's like setting expectations. I have no visibility if people even like what I'm building. And not just, "Oh, it looks nice on YouTube videos." Right? So, that's the thing is how much do I need to cut as somebody with my skill set so that I can actually deliver something that is reasonably playable as a demo on Steam. I don't know if this is going to be a great user experience for people to play. Like, are people going to love this?

Are they going to enjoy it? Is there going to be somebody? Originally, the intent was making something that I would enjoy making enough so I don't quit mid-development. It just has the the right amount of challenges for me to not quit, but also the right amount of interest for me to not quit while I'm developing it. And that was one of the foundations for starting working on this. My main task is hopefully I can make this game enjoyable for some people, like actually enjoyable.

Cuz I'm not really interested to just making something that just sucks. And by suck I I don't mean like obviously visually it looks it looks good, right? Like nothing nothing um like it's not bad. It's not bad looking. It's good. Um but I don't want to release a game that doesn't bring joy to anybody. I treat Claude Code as just a search engine. It has the answers in it. Especially for the games that I'm trying to create or the features that I'm trying to create.

I'm not creating anything that's truly novel. All the stuff that I've been doing has been done millions of times. It's in the training data set on Claude in within Claude Code's training set. So basically what I remind myself and this is what I tell myself is it's just a search engine. If I ask it to do help me with some feature and it doesn't do it right or it there's discrepancies with what I asked for versus what I get it's up to me to adjust the prompt until it goes fetches me the information that it has.

It has it. When you're solo, if you don't show up, nothing gets done. That is not true in a like a regular studio. A lot of people might not be showing up. The project might be getting carried by just 10% of the studio and 90% are just like like they're not doing much um comparatively, right? And even in that scenario, the game gets built out. Um but if you're solo, the benefit is there is not that waste, but also um it's all on you, which I think that's the reason why I really like the idea of being a solo developer.

Since this is my first time developing solo, it's the thing that I've noticed the most. When you're deep into development and things are hard and sometimes it's you're trying to find the fun, finding coping mechanisms to get past that hump, it's an experience I'm familiar with, so I'm not really too concerned with it, but it's just when I feel it, I'm like, "Wow, it's it's so different. It's so different when you're developing solo.

It feels so much better to go through that feeling when one um you're not making negative money, um two, you have other people to um share the experience with. Um developers, you know, I you have friends, family, all that stuff that that that don't count. I mean, I'm sure that would help, right? That helps. Uh obviously it helps for me, but there's something different about working with people where you can there's like a shared experience.

There is something about support. I I don't like it's like I don't need to be encouraged, but it's nice to be encouraged. And this is why YouTube is nice because without YouTube, this thing is just the process would be missing something. Cuz outside of YouTube, there's literally no feedback. And I think that's why it works so well having like a YouTube channel. I know I've heard some people saying like, "Oh, you don't need a YouTube channel." All that sort of stuff.

I like don't even think about marketing. If you're like me, it's just nice to get some sort of like a feedback loop outside of just having a demo. Cuz the thing is I don't have a demo yet, but um it takes a while to create a demo for for I for most games. By the time you create a demo, you're you're um if it's a good demo, you're pretty much there.