I was taught that “can’t” → “can not” (not allowed) and “cannot” (impossible) are semantically different, but this is real grammar nerd shit and most people use them interchangeably.

Big fan of Ness and Dr. Mario. Menacing with projectiles, sliding in low while the other player is briefly stunned, and doing my thing.

Lowkey we went a little bit overboard on the platforming engine. We created a system of “rooms” and “portals” which allow the level designer to link together as many Godot scenes as they want. All the rooms get loaded outside of the scene tree, they are scanned for portals, the rooms linked by those portals get loaded, and so on. Rooms are swapped in and out of the tree as the player transits through portals. The checkpoint loading/saving is also built on top of this architecture, duplicating a room when it is entered, and replacing the original with the duplicate when the player dies.

It is nearly suitable for a metroidvania, but we discovered a handful of bugs with Godot’s node duplication behavior which make it very fragile in practice. On the other hand, no reset logic needs to be implement on any of the entities. You can leave a room and return to it exactly as you left it. If you die in a room the second time you entered it, the enemies you’ve killed the first time will still be dead. This technique is not really documented anywhere. It seems like Node.duplicate() was only intended for use in editor tooling.

The final game ended up being pretty linear, after all that, lmao. I think there’s only one location where it is even possible to backtrack.

There are all sorts of good ideas in collaborative art that get shot down by a narrow vote edged out by people with poor taste or incorrect views of those ideas.

Or deadline pressures.

Shit. I guess I accidentally flipped the switch when I was updating the text. It’s fixed now.

The password was beanis tho.

He’s very complicated

That might be a bit modest

Should be fixed now. Thanks for sharing.

Input is mostly A+B+D-Pad, with left and right bumper (re-assignable) to switch weapons

Oh lmao

It runs on a timer as an attract screen and the timer doesn’t check if a menu is open

it only rolls before the title screen the first time the game is played. After this, it is skippable

I actually have very little practical experience with Docker beyond a high level understanding of how it works. In my experience, activating the docker systems unit was sufficient.

If you’re using Docker, Debian should be fine. The containers include their own runtimes and make the software running on the host mostly irrelevant. For what its worth, I run matapacos.dog on Debian (without Docker). You couldn’t ask for a better server OS in my opinion.

The author is pretty active on Mastodon. I’ve been meaning to play their game for a while.

Watch this space: https://itch.io/jam/queercomgames2026

The original Boom was (only ever) published for DOS. Active development ended in 1999. The thing which makes it notable is that it was the first 3rd-party source port to add new map design features (quite a number of them, too). You almost certainly don’t want to use Boom today unless you are in a true retro-computing mood and are prepared to bust out DosBox or a PC emulator (the requirements are essentially identical to running the vanilla Doom binaries).

The good news is that Boom came out and stabilized so early that it effectively became a defacto standard. Many, many custom levels are developed with Boom-compatibility as a target (even today), and nearly all modern source ports support these maps (with the deliberate exception of Chocolate Doom).

There is also a lineage of ports which descend from Boom, like DSDA-Doom by way of PrBoom+, or even the official engine which ships with “Doom + Doom II.” Even modern ports which can’t trace their heritage back to Boom will typically include snippets of code from it for one reason or another.

I believe it is minor custodial things like adding a couple UI sprites and maybe updating copyright notices. Won’t change gameplay at all, but it will be rejected by most servers in multiplayer ports due to the checksum mismatch.

Chocolate-doom for “pure” vanilla experience, including all limits and bugs (a bit rough, but a very well maintained port. Beautiful clean C codebase, especially compared to some other source ports, but even compared to the original id Software LinuxDoom source).

DSDA-Doom for true vanilla gameplay (as deemed by the speedrunning community) with lots of modern accoutrements. Broadest demo playback compatibility and mod support sans ZDoom (highly recommended, my first choice for anything).

UZDoom for mods which require it (there are many good ones, despite it playing a bit differently).

Would have been cool to see a video / talk on Blueprint / Workbench. I was playing with the idea of developing a GTK application a few months ago and came to realize that Glade is dead (long dead) and has since been replaced by Cambalache. I played around with Cambalache for a bit, but then discovered Blueprint, which is IMO is a much more sensible way to design UIs.

From my experience, it feels like the intended workflow for the Draft workbench is for producing prints for 3D objects created earlier in either the Part, PartDesign, or Architecture workbenches. A similar workflow to Creo Parametric / ProE. FreeCAD’s Sketcher workbench is excellent for creating well-constrained 2D geometry (better than Creo IMO), but lacks GD&T or other annotation features. It may be possible to design in Sketcher and go straight to Draft without going through Part / PartDesign, but I have never tried this workflow.

FreeCAD can also be scripted (in Python, rather than a LISP dialect), but I have never seen this used in the wild. While a lot of work in AutoCAD might be done via one-liners, Python scripting in FreeCAD is a lot less common, used mostly for plugin development rather than day-to-day modeling.

RE: your other comment, CAD software tends to depend highly on industry. I work in a contract manufacturing shop and we need to work with a number of CAD systems. Some of our customers use SolidWorks, some of our customers use Creo, we generally work with whatever system they provide their models in (though this does break down into personal / department preference as the original model is transformed into individual machining operations to produce operation sketches and do CAM work in ESPRIT, MasterCAM, or various 3D printer slicers to produce contoured CMM fixtures). The firms which do the original engineering / design work basically get to make the choice. I suppose AutoCAD is really popular in some industries, but not in mine. That said, DXF is still treated almost like a lingua franc format - sort of like a 2D STEP file.

IMO, AutoCAD is way overrated, and this isn’t just my FOSS zealotry speaking :) The actual truth is that ALL CAD software is garbage.

A rational firm (read: very few of them) would respect the engineer’s judgement and license whatever software they insist on using - assuming they could briefly describe what a CAD kernel or a geometric solver is as part of the hiring process.