Dev log:

2025-06-08

I've been using a certain company's line of development environments for years, and probably still will for work, but like a lot of other products it's a) pushing more AI and b) just emailed me their new acceptable use policy, which I'd probably never violate, but give me the feeling that they have the means to shut off my ability to use the program at any time.

So, I decided to see if Emacs would make a good replacement for what I need.

I've been using Emacs off and on since I convinced my boss I needed to take a Java class back in '94. Configuration had always been a matter of searching the Internet for other users' .emacs (config) files, but a few years ago I stumbled on Spacemacs, which was kind of what I was looking for, which led me to Doom Emacs, which is what I'm using now (and, at this point, wouldn't use Emacs without).

Navigating projects

Once you have Doom Emacs configured with C and LSP support, you'll get similar language hints that you'd see in CLion or VS Code. Using Projectile and regular Emacs keybindings let you navigate your project. (Emacs keybindings below, if you're using Evil (vi) mode, adjust accordingly).

• C-c p ? - Find References
• C-c p s - Search for a string in the project files (requires ripgrep)
• C-c p a - Switch between the currently open .c and .h file
• C-x b - Switch between open files
• C-c p c c - build/compile project
• C-c p f - Find file in current project

I'll add more keybindings here as I use them and maybe more info on my setup here if I think anyone's interested.

2025-05-21

I guess I hit one of many mid-development burnout cycles. I decided it would be a good idea to take a step back and make a yet simpler game instead of this tiny RPG. I even went so far as to pull out the boilerplate code from Canary to serve as a platform for future games.

But I fought against this urge (after a time) and went back to Canary, and was immediately thwarted by a bug that crashed the game about half of the time going from the initial character creation screen to the dungeon screen. It took longer than it should have to isolate it to a poorly initialized Entity. Entities talk, you see, and they have an integer timer that dictates how many frames their speech shows on the screen. If that number is greater than zero, the engine displays the text in their speech buffer and subtracts one from that counter. About half the time, an entity was being initialized with a non-zero speech timer, and the engine was trying to get the length of the text buffer, which didn't have anything in it, so it was dying within the strlen function.

In the end, I got to learn a lot about c debugging, cgdb, and running CMake so that it would add debug info to the program. It also made me realize that I need to clean up the entity construction code and other places that are allocating memory.

2025-05-04

Reformatted the css here to make this log easier to read. Playing the heck out of Vampire Survivors.

2025-05-03

Another short update. I was thinking about making an rss feed for this site (I like feeds, but I haven't found a way to read them that I stick with). Does anyone just hand-edit their rss file and have their site grab it and format it with Javascript?

Anyway, this site is probably more just for me than anyone else as I try to keep myself motivated to work on the game. If you're reading it, though, thanks!

2025-04-26

Spent some time re-organizing the game repository and switching from a Make based build to CMake. Sometimes you have to clean the house, I guess.

Might waste some time converting this page into something easier to edit, right now I'm typing into an index.html file.

2025-04-19

Thinking about this project, and thinking about my other projects that fell by the wayside. I wonder about just how many game development projects have been started that just fizzled out. It's probably like asking how many garage bands there have ever been.

Anyway, I spent $600 and got a low-end M4 Mac Mini. 16 gigs of ram and a 256 gb ssd doesn't seem like a lot, but it's compiling the game in less than two seconds (compared to my i7 machines that are taking 13 under Windows and 7 with Linux). I wanted to keep track of the system stats, though, so I was looking around for something unobtrusive.

Lo and behold, I found the perfect thing, installable with brew:

> brew install stats

Which gives me the stats I was looking for right in the menu bar, like so:

Which kind of brings me to thinking about a future phase of development when I'm automatically downloading and building Canary under Mac, Windows, and Linux whenever I check the code in.

2025-04-08

I'll tell you what: my first try at implementing the pathfinding algorithm was a disaster. I had the general idea right, but creating(malloc-ing) and deleting(free-ing) all of the necessary nodes to find the path was not code you want to write in a hurry. I ended up debugging errors with (probably) freeing memory I'd already freed, and eventually realized that maybe I didn't need to do all that work on the heap (and subsequently clear all that out to get ready for the next guy who needed to find the quickest path by which to deliver a swing at the player's head).

That was the second thing I realized, though. The first was that my unit tests (which I'm pretty dependent on in my day job) could use some work.

Unit testing in C, at least as far as I've been able to find, is a lot less advanced(?) than it is in more modern languages like Python or Java. I kinda got Unity (no relation to the game engine) working, but, much like pathfinding algorithms, it's not something you want to try to add in a hurry. I took the Makefile suggestions literally and ended up with a spaghetti file of declared variables that started making me feel... uncomfortable.

So: I went looking for alternative solutions, and found this article that explains how to use Pytest (a unit test framework for Python) to test C code. With which I was able to compile my pathfinding file and use Pytest to exercise my get_path(...) function. Well, almost.

One of the parameters for get_path is a 2d array that represents the obstacles that might be between the angry scientist and the player, and I didn't have much luck creating the ctypes array in a way that was acceptable to the get_path function. Solution: create a get_path_with_empty_array function in the C file that create an empty 2d array and then calls get_path with that. For the purposes of testing whether the algorithm as written will play nicely with the system memory... so far so good. (The other parameters are the x/y coordinates for the attacker and the target (as integers, it might have been easier to send the entity data, but that's one fewer dependency the pathfinding file has))

2025-01-25

At some point I decided my task board should be a 'minimum viable product' board, so now I have 10 notes there that I'm ignoring while I finish getting an A* algorithm implemented in C. I had it working earlier than I thought it did: when I ran it it kept going crazy and crashing the program with corrupted memory. What I eventually realized was that I was setting the end position to the player location, which was registering as a blocked tile, so the algorithm started checking infinite other ways to access this impossible-to-land-on tile. Now that I set the end goal to getting within 1 tile of the target it works great. Other checked-off tasks include:

• Exit saving
• Quick saving
• Screenshots (to tell where you were when you saved)

I also got the Steam page mostly populated, I got an email from the review process that I need to make some tweaks to the page graphics.

2024-10-20

Inspired by Friday's post, I dug in on Saturday and added an sqlite db to the mix to hold the entity type data. I had planned to use Gnumeric (spreadsheet) for game data, but the flexibility of integrating directly with a database seemed better in the long run.

I'm not ready to make data importing fully dynamic (the entity types are still #define PLAYER 10 in a constants file), so I wrote a python script to parse the .h file #define directives to match up with 'PLAYER', 'MONSTER_1', etc. in the database. From there it turns the db row into a binary version of the integer values and stores it in entities.bin which can be read by the game. These are just the entity 'types', the actual game entities are cloned from these base entities.

I'd marked October's "load entities from external file" and "use spreadsheet to define entity data" off the list, but I'm tracking down a few bugs today instead of moving on to the final October task of "Simplifying the model to make serialization easier".

2024-10-18

Over half-way through October. I've done a few minor things but have hardly gotten started on this month's list of tasks. I did get the ball rolling on publishing through Steam though, so there is that bit of wishful procrastination to check off the list.

2024-09-22

I took a few days off work to get some game coding time in, this week I got the basics of a character creation screen put together and made it pretty far with the saving and loading of games. Also started the process of distributing Canary through Steam.

2024-09-18

Starting a public work log as I get closer to finishing this game. I still have 6 months of planned work to go through, and I'm sure more things will come to mind.