Why I switched to Claude Code

At a gathering with some friends last year, one of my friends excitedly shared with the group how much fun he was having with Anthropic's Claude Code. At the time, I was using the Cursor IDE and thought I was getting all the benefits of current AI models. I didn't think I was missing out on anything. I was wrong.

I wasn't just wrong about Claude Code; there are, of course, other similar tools. However, for my use cases, Claude Code is a much better tool.

First of all, I dig the terminal. I enjoy working in the terminal, and I find it both efficient and powerful. This is one of the reasons I've always enjoyed modern DevOps. A lot happens in the terminal, and I like it that way.

Second, I don't feel that I'm losing anything. Instead of using the Cursor IDE, I use Visual Studio Code (VS Code). Everyone knows that Cursor is a fork of VS Code, and that becomes obvious when you take Cursor out of your workflow. I use VS Code to see diffs after I've approved changes in Claude Code. In my mind, that's actually better than approving changes in the IDE.

Another factor is that using Claude directly means that I'm not paying a premium on top of the model price. I'm getting the model directly from the developer. All of this just adds up to a better experience for my workflow.

Breakpoints not working in VSCode with Unity 2021.3.16f1

I'm currently using the LTS build of Unity (2021.3.17f1) and Visual Studio Code (VSCode) to develop a 2D game with my kids. I'm using VSCode because I use it for pretty much all my development. I hope they reverse their decision and properly support it for Unity in the future.

When I first set up the project, breakpoints were working fine in VSCode. I'm not sure what broke along the way, but here I am a few days later and the debugger isn't working. I had to reinstall Mono at one point to solve the common VSCode issue that the project doesn't load properly.

Here's what I had to do to get it working (see the initial setup link below). First, I clicked on the "Run and Debug" icon in VSCode, then I choose "create a .json launch file." After this, VSCode prompted me for which debugger to use. Of course, I chose "Unity Debugger." After that was all done, I clicked on Run and Debug in VSCode and the debugger started and attached to Unity. Finally, I switched to Unity and either enable debugging for the session or for all projects. At this point, there was a small green bug icon in the bottom right of Unity. After the scripts were compiled, I ran my game from Unity and the debugger was able to hit my breakpoints.

Here is the documentation page for this setup: Visual Studio Code and Unity. I had already installed the Unity Debugger and C# extensions the first time I got it working. I also came across a YouTube video of the VSCode for Unity setup.

Searching around, I naturally found a tonne of suggestions to fix this problem. Here are some of the suggestions I found that did not help with my setup:

• Reboot and restart Unity and VSCode
• Import all assets. Assets > Reimport All
• Close VS. Delete Assembly-CSharp.csproj and Assembly-CSharp-Editor.csproj (this file wasn't in my project) in your project folder. Open VS.
• Editor Attaching enabled in External Tools. This option doesn't exist in my version.
• Delete all .csproj  and .sln files and regenerate them.

Debugging Pygame Zero Games in VSCode

As part of my ongoing effort to expose my kids to various science topics, I picked up a Python game development book for kids and I'm working through it with my youngest. As part of that process, I was just setting up Pygame and Visual Studio Code (VSCode) over the holidays.

The setup didn't take long, but I did run into an issue. When I ran our code from the terminal, the games worked fine. However, when we tried to debug from VSCode, the Pygame Zero game window wouldn't--Pygame opened on the taskbar but just closed again. I did find the solution, so I thought I'd same some other people some Googling and document it here. The book just references IDLE, so it doesn't get into running the example games in an IDE such as VSCode.

The book I chose is Coding Games in Python*. It's specifically targeted at kids, so it's a colourful book filled with a basic introduction to coding and some simple game examples. I highly recommend it.

Getting back to the issue, I could successfully set breakpoints, but as soon as they were done, Pygame would close, and the game window would never appear. The answer is on page 25 of the book (which I skipped because I already had the setup done :) and it's also in the Pygame Zero doc page about IDEs. Here's the solution (paraphrased):

Pygame Zero includes a way of writing a full Python program that can be run using python. To set up VSCode for debugging, add this line at the top of your file:

import pgzrun

Then add this line to the end of your file:

pgzrun.go()

* Coding Games in Python was written by Carole Vorderman MBE, Craig Steele, Dr. Claire Quigley, Daniel McCafferty, and Dr. Martin Goodfellow.

Debugging TypeScript Phaser Apps Server and Client-side Using VS Code

I’m using the Phaser game development platform to teach my kids some video game design and programming concepts (I previously used LEGO to draw my daughter into building game sprites). As a new Phaser user, I'm finding there isn't enough writing out there about using the Phaser 3 HTML5 game development platform with TypeScript, so I feel I should add my 0.02c. My first contribution is about debugging with breakpoints in Phaser and Visual Studio Code (VSCode).

Note: You can read more about setting up VSCode for TypeScript debugging on the Microsoft site, but one tip is to remember you'll need to make sure you have "sourceMap": true in your tsconfig.json file.

Most likely, if you're using Phaser for a multi-player game, you're probably using Node.js and Express to fire up a server for the Phaser client-side code. I found this complicated debugging with breakpoints in VS Code, and I haven't been able to get a single configuration to hit breakpoints in both the server and client-side code. This makes sense, but I still thought it would be handled more easily.

If I launch a debugger for the server, any breakpoints I've set in my client-side code show "Breakpoint set but not yet bound" or the more direct error, "Breakpoint ignored because generated code not found (source map problem?)" My workaround is to launch the debugger depending on which breakpoints I need.

Server-side debugging

To debug the server, use VSCode attach to process and choose the dist/server.js process (server.js is the transpiled version of my server.ts file that starts the Node.js server).

Client-side debugging

To debug the client (uses Visual Studio Code Chrome debugger extension), I use VSCode to launch the debugger with the Launch client-side task.

Here is the entire launch.json file that supports both client and server-side debugging with breakpoints: 

{

    // Use IntelliSense to learn about possible attributes.

    // Hover to view descriptions of existing attributes.

    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387

    "version": "0.2.0",

    "configurations": [

        {

            "name": "Launch client-side: localhost:8080",

            "type": "chrome",

            "request": "launch",

            "url": "http://localhost:8080/index.html",

            "webRoot": "${workspaceFolder}/dist/client"

        },

        {

            "name": "Attach to Process dist/server.js",

            "type": "node",

            "request": "attach",

            "processId": "${command:PickProcess}",

            "port": 8080

        }

    ]

}