My colleagues hasn't finished the work on the backend. Thus, I couldn't do much at work this week. Instead, I think I'm going to write about other stuff.

I updated my PR to Django to better handle backwards-compatibility. I spent some time trying to figure out how to make the following behavior in argparse:

• Have an optional argument that accepts at most one value at a time.
• That argument can be used multiple times and the values will be appended to a list, e.g. --arg foo --arg bar would result in arg to be ['foo', 'bar'].
• It should be possible to use the argument without any value, e.g. --arg (like an argument with action='store_true').
• It should be possible to determine whether the argument was provided or not, i.e. whether --arg is in sys.argv. (However, in this context, it's not ideal to check sys.argv as we're in a method that already accepts a dict of pre-processed arguments.)

The first two aren't a big deal as you could just create an argument starting with --, then use action='append' and default=[].

The last two are what make it tricky, though. In the end, I managed to sort of get it with the following:

parser.add_argument(
    '--arg', '-a', dest='argument', action='append',
    default=argparse.SUPPRESS, nargs='?', const='',
)

Explanation:

• default=argparse.SUPPRESS means that if the argument isn't provided, then it won't be in the Namespace object.
• nargs='?' makes the argument consume one value if possible. It falls back to default if the option string isn't present.
• Combining an optional argument, nargs='?', and a const lets you have a default value (const) for the argument if the option string is present but no value is provided (i.e. just providing --arg, not --arg foo).

The documentation for nargs explains it with examples.

I did some housekeeping for giscus and this website. Most of the work is done towards adding security headers. Both giscus and this site went from D to A+.

I've been thinking about trying out game development. I don't think I'd be doing it as a career, but I'd like to do it just for personal satisfaction. Plus, I think it would help me appreciate games better.

I have this idea of a custom Half-Life 2 campaign ever since I was in middle school. I already had the story and setting in mind. I even thought about utilizing some mechanics of the base game to provide dialogue without any voice acting.

However, I did not proceed with my idea as I didn't know much about level design. I mean, I could learn the tools. But it is hard to imagine the architecture of the buildings and stuff. I want the layouts to make sense, not just from a gameplay viewpoint, but the architecture as well. And I am no architect.

So that idea has been in the back of my mind for, what, eight years or so I think? It's become something sentimental for me. I know it's not easy to accomplish, and I accept if I would never do. But I know that it's at least worth a try.

I remember planning to reuse as much stuff from the base game as I could, as I didn't really know how to code or make assets back then. I don't actually need to compile the SDK, as most of the work would be just Hammering stuff. However, as now I know a thing or two about programming, I might as well prepare.

And so this week, I tried to compile the Source SDK from source ^_(heh). Which, come to think of it, was probably why I signed up on GitHub so many years ago.

It's an old technology that's kind of abandoned and under-documented, but the community is still there. From what I read, you need to use Visual Studio 2013 in order for it to compile without making many adjustments. So I installed it and compiled the SDK. It went fine.

After playing around with Hammer again, I realized that it might be too soon to start this project.

I haven't had much experience in game development.

After I consulted this with my friend who's quite experienced in the field, he suggested that I should start small. Maybe make something with Godot.

I'm not against the idea. In fact I was thinking about doing it, after knowing how little I know about level design. However, making a new game from scratch would require even more ideas, and I haven't got any good ones.

My friend suggested that I could try remaking an existing game. At first I couldn't think of a game would be feasible and interesting to be remade. Then, I remembered something.

There's this "lost" game in the Half-Life community that was released back in the early days of Steam. It's a really short game, but I remember it was very interesting. It's no longer in the store, but if you're looking in the right place, you'll still be able to play it. I remember one of the developers planned for a remake back in 2015 or so, but it seems that it was scrapped.

I think it's a perfect candidate for a remake.

So, I decided to try out Godot.

I installed it and read the docs. I followed the "Your first game" tutorial, which allowed me to quickly learn the concepts and patterns in Godot. Here's the result:

Based on my initial impressions, I like Godot. My only comparable experience is that of Unity, and I think things are much easier to understand in Godot than Unity.

I like Godot's approach of Scenes and Nodes, which lets you make clean components for your game. I also really like its Signal implementation for the pub/sub pattern.

One thing that I'm a bit unhappy about is that the editor doesn't seem to provide suggestions for global functions like get_tree(), so I always have to type the whole names manually. I haven't tried the VS Code extension, so maybe it's better there (though I doubt it).

Anyway, looks like I have fun stuff to do for the next weekends!

I watched Nomadland on Sunday. It was... beautiful. I don't understand how, but it really captivated me. I think it was hopeful, sad, heartwarming, and heartbreaking at the same time. And it triggered my itch to go somewhere far... and just be out in the open.

I even cried at the end, all the way until the credits stopped rolling.