The drawback of having so many interests is that I keep myself way too busy. The challenge is knowing what to prioritize.
Brick Mill Games, LLC
The work at Brick Mill Games continues apace. We could be further along than we are in building our on-line game system if it wasn’t for external interruptions. Last week, the code hosting site we use, BitBucket, seems to have stopped allowing us to use our own Git/LFS server. Let me explain.
There are various code hosting sites that use a software repository system called ‘git’. These sites include BitBucket, GitHub, GitLab and others. They allow users to host their code projects there. Some accounts are free and some are paid for. Our accounts at BB are free.
Git is great at storing and comparing text-based code files. In addition to managing these code repositories, the git-based sites also have a very useful interactive web sites to manage both the code and the users who have access to that code. You can do team code reviews, etc. It’s a nice front-end on top of the bare-bones back-end code file storage.
LFS, or Large File Storage, is an extension to git that allows users/projects to store binary files: PDFs, spreadsheets, images, videos, etc. When these types of files are stored alongside code, it is usually because these files contain information and/or data associated with the project, either directly or indirectly. For example, BMG currently uses spreadsheets to store the orders-of-battle for our battle modules. They are part of the data generation process used to define a module that the code will work with.
Without getting into too much detail, the server which stores these large binary files does not have to be the same server that stores the code files. There is a reason for this. Code files tend to be quite a bit smaller than spreadsheets and images and documents. That is why BitBucket, and the others, can support free accounts.
BitBucket and the other sites can support LFS… but at a cost. To avoid paying for this, I wrote my own Git/LFS server and use this to store our large files on our own system and avoid the cost. And it was working fine for the past five years until last week.
Both the Brick Mill Games repositories and my personal repositories can no longer upload binary files to our Git/LFS server. It fails with an HTTP 418 error, which translates to “I’m a teapot”. This is both a joke and not a joke. It can download and it can get information from our server, but once it is time to do the actual upload, it fails. Or, to be fully accurate, it fails to contact our server to do the upload. This sequence of events happens on both my macOS and my Linux systems.
Here’s a bit of a technical explanation on what I think is happening:
- git contacts BB in order to “push” changed files to the repository
- BB responds with tokens that will be used to identify the files on the LFS server
- git contacts our LFS server with a batch request: “I need to upload these files. Send me the information I need to get this done.”
- Our LFS server responds with the URLs and authentication information necessary to do this
- git should then use these URLs, which include our server domain, and upload the files
- Our server never gets the subsequent upload
- It’s uploading somewhere, but fails
There is a lot of debugging work to be done this coming weekend to prove this theory. But as other code hosting sites seem to be blocking or restricting free accounts in these tightening economic times, it wouldn’t surprise me if BitBucket noted our domain in the URL and simply blocked the upload. Or, it’s simply a bug on their end. Regardless, I’m going to be very busy with this this weekend.
Nor’easter XXVII
Regardless of the on-line game platform, the game system itself still needs some playtesting. For this, we use Vassal, a free Java-based client that … works? At least, it’s free.
Paul and I, after the pandemic hiatus, will be returning to the Nor’easter game convention and playtesting the TOCS game system. We might do our newest Utah Beach module.
A New Hand
In addition to all of that, we brought a new coder on board to help us out. He’s young and hungry and he’s already finished his first task. Of course, onboarding a new programmer is not a zero-time process, so that also eats into my available time. That said, his contributions are going to help us a lot.
Mill #6
This blog site takes up a bit of time, though it’s not exactly evident. I missed this Wednesday’s cocktail recipe post due to other time constraints. I mixed up a good Corpse Reviver #2 on Tuesday, but didn’t take photos and we didn’t have any more lemon juice and the snowstorm pushed a lot of my already tight schedule around and, and, and…
Genealogy: The Acadian Guérins
The biggest post I’ve written for this blog has been in draft mode for over three months. It is turning from a vanity blog post into an actual historical article which I might try to get published elsewhere. Unfortunately, the difference between blog post and historical article lies in how much research you need to do. I’ve enlisted my friend, Vickie Turcotte, for help in chasing down some out-of-print books on Acadian history that were written in French. Hopefully, these can fill in some blanks that the on-line sources aren’t filling. Regardless, some people from that time period just disappear from the historical record and I may never know their fates. To wet your whistle, here’s a snippet from the article:
Nothing about Acadian history remains a side project for long, nor should it. It is a long and complicated piece of history that quickly takes center stage once you are immersed in it. Acadian history is not merely one tale of tragedy, but an interwoven woeful saga of its own.
It is not my place, nor is it the purpose of this article, to rehash the entirety of this sordid drama. I can only pick one warp, one weft from the tapestry, somewhere nearer the edge perhaps, and bring it to light.
This is the story of François Guérin, but it is not merely the story of François Guérin. Though I am not directly related to him, I am connected to him by heritage. By the time of the earliest Acadian census in 1671, François had already passed away, leaving only his widow and children to be reckoned. But now his story, and the story of his family, can be told.
Stay tuned…
Steel & Steam 3.0
Development on the final iteration of this game progresses. I’ve added a few new ideas to speed up the game and added a second map to see if this game can be turned into a transferable system to other geographic areas and scales. I’m hoping to get the next round of playtests up and running this spring.
Various development notes and samples can be found in the Steel & Steam Press Room off the blog’s home page.
Winter’s Victory by NES
For over the past 10 years, I’ve been helping Mark Hinkle at NES design and develop his monster Napoleonic wargame, Winter’s Victory. Before I started this process, I was not a Napoleonic gamer, apart from playing Avalon Hill’s War & Peace way back in the day. Now, I find it to be very interesting, at least this particular game is, if I should say so myself.
After quite a long gestation period, it is finally getting published. I’ve been to the printing company and I’ve seen the counter sheets being printed prior to their being sent to the die-cutter. We’re now in heavy-duty proofing mode and trying to make sure we’ve accounted for everything in the rules. The team is still playtesting as well, making sure that all game situations can be handled by the rules as written. It’s a lot of work, but it’s coming together quite nicely.
So… Yeah
Any one of these projects could take up the majority of my time and I’m juggling a bunch of them. In addition to the above, I’m not mentioning genealogy side projects that I’m doing for friends of mine and I’m not accounting for the time I spend with my son and/or the time I spend with Claire. Nor am I mentioning the time I spend on my day job.
So… yeah… I’m keeping myself quite busy. I wouldn’t have it any other way.