There's a pattern that's come to its inevitable end for the QBASIC "ports" I've been making: "Numberguesser" was a direct clone, "Back Door" streamlined the play style under the hood, "The Mine & The Cavern" was totally rebalanced and the story / structure rewritten, and "Mowdown"'s entire flow and scope was scrapped and redone. Yesterday's release "Engulf" completes the journey away from authenticity by not even bothering to resemble its original layout (or anything possible in QBASIC for that matter).

"Engulf" was a game in the somewhat-misnamed "Games For Your Atari Computer" book of type-in programs for, well, Atari computers published in 1983. 7 of the 21 listings were actually one-pagers for graphics demos or minimally useful applications like "Decision Maker" and "Morse Code" that were clearly there to pad pages but was still fun to watch your computer do at the time.

When I was digging into QBASIC on a DOS PC years later in 1996, I remember wondering how much of the Atari BASIC code would translate to QBASIC so I typed "Engulf" in and ran it. The AI calculations seemed not to work properly so I probably messed about with those, then kept adding new features like primitive animations of cities and trucks being blown up for each move and bonuses and so on.

Truth be told it was never all that fun even in the 80s -- the only strategy is really to not get so bored of the alien's pseudo-random moves that you turn the game off before you inevitably engulf it. Even after two remakes, it's still at its core the exact same play experience. The real value of coding this over the past week's idle hours was delving into the finer points of Godot's process order and making efficient branching in both nodes and logic, as well as trying out some CRT shader code in the context of a game.

At the moment there's only five animations that are picked from when you nuke a cell. Maybe over the next few months or so I'll periodically add one or two here and there if I think of something that amuses me enough to bang together and recompile in 10 minutes. For now, "Engulf"'s served its purpose for me, now it's your turn -- go and get your three minutes of entertainment value out of it!

See? Programming isn't all I do these days after all!

Today's release "Empty Rooms" was a fun delve for me because it has my very first recorded attempts at playing my own straight-up folk music, the understandably somewhat shaky "Don't You Ever Learn" and "Fork In The Road" from June 1998. At the time I was digging deep into Bob Dylan's pre-Street-Legal discography and had just had my latest band fall apart (again), so I was keen to try writing something that wouldn't necessarily be reliant on others to perform live for a change.

The rest of the album hails from a few months later in October, largely comprised of songs from a couple impromptu jams in Thibodaux with me on vocals / rhythm guitar and Wess Walker on lead guitar that I layered bass, drums and harmony vocals over afterward. Fortunately I was able to find the source cassettes from those sessions because the only release copy of it I could find in my collection had degraded to a warbly gargling mess.

Up to that point I'd occasionally dipped here and there into acoustic guitar songwriting styles, but always with more of an alt rock bent and definitely never as genre-strict as I had on most of this demo. Even with keeping so tight and formal to the genres here, it was ironically freeing and thrilling to find myself able to write songs in styles that, until then, I had never considered I'd be capable of attempting. "Oh man, I couldn't do that, I only know how to write punk and alt" suddenly wasn't accurate for my guitar songs anymore, and what an exciting realization that was to have and cultivate. Within less than a year I'd discover antifolk and really start going down rabbit holes.

So at this point we're getting near enough to the end of the reissues that I can list them without making too long of a sentence. There's a couple Toxic Crayons / 200 Proof demos from 1997, a Dead Outlaws demo from 2002, a web-only exclusive collection from 2006 from the lead-up to Rain Cabinet's release, and another web-only exclusive of songs from short-subject films we did in 2007. Barring those and one or two that I may have forgotten about and will eventually come across some future trip into storage, everything else is already up here. Next one comes when it comes! And now back to my regular programming.

I thought for sure that today's game release, a port of 1997's "Mowdown" would take a lot longer to put together -- partly because it's only the second action game I've attempted on my own in Godot (and I had forgotten a lot of what I'd haphazardly searched for, copied and kludged together to make February's "Sludge Runner" concept demo), but mostly because of the numerous gory ASCII animations that were probably the whole reason I even made the original game. Really, "game" should be in double scare quotes when talking about the original version. I remember it being rough but upon playing it again, hoooo boy, was it ever a stuttery, buggy, ugly, lazy, hateful slog of a mess.

That said, I'm very pleased with how the new version's come out. In keeping with my trend for the last three Qbasic ports, this one's been altered from the original even more than the last one was. Like the 1997 one, it's still about as bare-bones as it gets: try to shoot at a semi-randomly moving target, dodge its shots, and reload your next shot at the left edge of the screen.

From there, it vastly improves on every aspect of presentation and execution. Once unpleasantly jittery stutters are now smooth glides; each death doesn't cut to a black screen to animate anymore but rather deposits the body right on the playfield as the game continues; there's actually a goal now (kill the opponent ten more times than he kills you); the joke options were expanded and made more functional, particularly the "Mowdown Hoedown" option that fills the playfield temporarily with waves of rushing clones from all directions, completely disorienting any lock you had on your target -- in the original, it just lazily threw a few dozen static bodies on the screen and called it a day. No, this new port's still not a very good game, like, at all, but compared against its origin, it may as well be Bioshock.

Converting the animations from realtime DOS to useable transparent PNG frames actually ended up being the quickest part of the process, thanks to screen recording with OBS, frame snapshots in Vegas, and some command-line batch posterization / transparency conversion with ImageMagick. I'd been dreading this part the most because I was imagining having to reconstruct all the ASCII frames one at a time, but thanks to that workflow it was easy and took less than an hour all in. A few compression artifacts here and there made it through to some of the frames from the video process, but I know you'll get over it.

Next up I want to convert a few more of the QBASIC games (since there's only a few left) and then jump back into some of the better tutorials I've had bookmarked since January. I think another couple or three months of this kind of drilling and study oughta get me fluent enough in Godot to adequately approach making the game ideas I've been tossing into a text document for a very long time now.

Today's game hates you and it doesn't even know you. Go play it for about a minute, you'll find out.

Like "Back Door" from last month, the inspiration for "The Mine and the Cavern" came from a game in Antic magazine, a monthly publication focused on Atari computers in the 80s. We had a subscription which included the issue of the month (or two months when they started to run out of money) and a disk filled with that issue's type-in programs and some bonuses that were too long to print a listing for. William Austin's game "The Goldmine & The Princess" was one of the featured disk bonuses for April/May 1990, the second-to-last issue before Antic became an also-ran section in an Atari ST magazine. Something about the game apparently stuck with me enough six years later to program my own version of many of its ideas in Qbasic. I dropped the cow trading aspect and vastly simplified the mine interface, then leaned as hard as I could into the randomization to make a truly unfair experience.

And here I am 26 years later programming another version of it again in Godot. This one's drilled a lot of Godot's scripting nuances into me, since every aspect of the play is almost completely variable-driven. I ended up straying further from the 1996 version than I did with last month's "Back Door" port.

There were three 50-level caverns I had added after the mine that were completely removed from this port because they were a hideously boring slog of nothing new. The story was changed considerably, as was the endgame, though a lot of the mine and village text remains unaltered. The depth labels in the mine were changed from simple numbers to short descriptions of the surroundings, many taken directly from William Austin's program.

The odds were massively rebalanced -- the chance of encountering insta-death traps were severely reduced ("a giant skull!!"), as were poisonings and attacks. Damage also heals now with each step instead of necessitating a trip back to the surface for every little cut and rat bite. The map on the side was also changed from being on by default to being an item that needs to be found, adding to the early game's confusion. One of the game's goals is no longer just waiting at the bottom of the cavern but must be accessed in other ways. There are more but you get the idea.

Even with all these changes, "The Mine and the Cavern" is still unbelievably mean and borderline unplayable. The story / documentation used to have descriptions of the hazards and items. I took them out because if I were playing a game like this blind, the draw of it for me would be figuring out what's happening, though that's likely Stockholm Syndrome from starting out on games like Raiders of the Lost Ark on the 2600. More than once while coding this I've been tempted to do a ground-up remake for phones and tablets as I can see some potentially very addictive elements somewhere deep underneath the ugly arcane ASCII and outlandishly arbitrary game resets. Maybe I will.

I've been wanting to rehome the "What's Next" section on the Updates page for a while now as well as do away with the "3 Most Recent" items that I'm pretty sure nobody ever scrolled down to look at and were always a hassle to update with new entries. Done and done. You can now read about what's in the works on the front page below the calendar.

Do you remember the Qbasic games I made in the mid 90s? No, of course you don't! The links and files were always up in the Arcade section of the site but let's be honest, if you didn't already have DOSBOX and Qbasic, you were never in a million years ever going to install them just for the sake of playing these things, nor should you have -- they're under the heading "Shit Games" for a reason, after all.

Well now you won't need to jump through multiple hoops to experience at least two of these abominations, "Numberguesser" and "Back Door", which are already up and playable in your browser, recoded from the ground up in Godot. I'll be doing at least a couple more over the next few months as well, and right here's where the more logical of you may be thinking "What a weird and dead-end use of your time. Why?"

It's a way for me to start digging in to usage-based learning of Godot beyond just parroting procedures. To follow up on last month's post about programming, the few tutorials I've found for Godot that aren't aggressively unhelpful have been fantastic for getting a grip on the big ideas and workflow of the language, but solely following someone else's game recipes makes it tough to get a lot of aspects to really stick or make sense outside of abstract application because of a few things:

· Godot version inconsistencies. These are no fault of the tutorial creator -- features change between versions, though with Godot these are sometimes surprisingly drastic in their syntax and processes. The comments sections are typically very useful in learning about and working around these, to the point that I'd recommend reading the comments on such videos before watching them so you're prepared for any surprises.

· Misguided / inefficient / plain wrong methods. These are absolutely the fault of the tutorial creator, and very often pop up in even the best of the tutorials I've seen so far. Most stem from the creator's failure to grasp the concept they're attempting to teach, which is doubly disappointing when the tutorial had been going so well up to that point. Comment sections are again invaluable for better alternatives, though mileage will vary on how correct and/or clear the commenter is, or which one is more correct than others, particularly when you're still new to the language.

· One-off afterthought uses of greater functions that really deserve more focus and explanation. Some tutorials are worse than others with this, but they all inevitably have at least a few examples of this. The official Godot documentation is a cold unaccommodating brick of assumptive definitions which often gives you absolutely nothing to work with in figuring out use cases for all these terms and commands if you're coming in fresh and ignorant.

All that said, the better tutorials are still vital for starting out with any efficiency. For any of you also interested in digging into Godot, the very best ones I've come across to this point have been BornCG's (definitely check the comments for a couple of wrong-method fixes) and Heartbeast's (feel free to play back at 2x speed as his speaking cadence can be very laconic at times -- also keep an eye on the Godot version differences and watch the comments for workarounds if you're checking out an older tutorial of his).

Revisiting the Qbasic games I made gives me both familiar territory (granted, it's territory that I covered plural decades ago) as well as unguided concrete goals to plan and build toward and, more importantly, figure out real applications of the concepts I've been drilling by rote for a couple of months. It also allows you to, um, "enjoy" these "games" in all their unbalanced and awfully executed original glory, as I'm going to recreate them as close as I can to how they originally played, looked, and sucked. There's two now, go check them out for the 60 or so seconds you can stand them!

Oh yeah, I also took the opportunity to alter the look of the Arcade page for the first time since 2017. Its previous layout was meant to mimic Atari's early game catalogs, specifically this one from 1982. It was fun to design but in the end was very impractical for clearly communicating details and was also a massive inefficient pain to update so it's gone now -- I'm sure you'll be okay.

I'm pretty sure we can count on one hand now how many old releases and demos of mine aren't available online. Frequent flyers on this site know that I like to reissue the missing pieces from the catalog as I come across them, and that for many of them I'm able to find at least some isolated elements like drum parts or vocals that I can polish the EQ on and mix down into cleaner sounding tracks. Today's reissue, "Passive Blue" from April 1999, didn't allow that.

I've had my only chewed-up cassette copy of it digitized for years in all its furry, buzzy, barely audible and un-reissueable glory. It's been a particularly maddening project because I haven't run across any of the raw takes and I *know* there were at least two tapes I used to record some of the songs pingpong style, and another tape I recorded some of the songs on a cheap 4 track, because it was the first time I'd used a 4 track. I keep everything and definitely wouldn't have recorded over source tracks, so it's weird to not have found a trace of this one's takes (or the master for that matter) when there's other reissues I found fully preserved raw tracks for that I barely remember even making.

So instead of just sitting on the reissue until the heat death of the universe, I've done what I can to EQ the ragged dub I have to a better sonic standard. A lot of the lyrics capture what I remember of that time very well: joyfully killing time hanging out with friends when not lamenting being in a terrible job and relationship I was too inert to get out of (her and I still had five months to go at that point before it mercifully ended, good lord). Give it a listen, it's up now! Time to dive back into some programming.

For the past eight days I've been mostly coding in Godot, specifically a from-scratch rebuild of Sludge Runner, which was a grip platformer concept demo I released two Junes ago that I had coded in GMS at the time. It's served as not only an excellent crash course for me in grasping Godot, but also really shining a spotlight on the differences between the two languages.

As nice as it would be to have a comprehensive and obvious preference for the new over the old, that's never how anything works and there's definitely some things I miss about GMS, though not even remotely enough to dump money into their terrible new subscription model that prompted my exodus to the open source plains of Godot. Here's a few of my early observations for any of you maybe considering one of these, but also for me to review a year or so on and see how much my opinions change by then, if any:

· Identifying, influencing and instancing objects from other objects as well as instituting global aspects felt a lot more straightforward to me in GMS, whereas in Godot there's a few more hoops to be leapt through to get the same result. I have a feeling I'll always hold at least a minor grudge that Godot doesn't have an "other object" property on collisions, because it made things so much more straightforward in GMS than Godot's current node-based workflow.

· GMS's drag-and-drop aspects gave both a visual representation for connections as well as a simple bonehead method to create them, whereas Godot's most basic functions are largely propelled by stark code text. I don't mind text code, I started with Atari BASIC after all, but it was nice to have a choice when I wanted to let a diagram do some heavy lifting for some of the more rote functions.

· GMS had tons of effective tutorials and clear examples out there for any imaginable desired effect thanks to over 20 years of both their own excellent documentation as well as community-driven instruction. Godot is still new and this will come in time for it, but for now the documentation is opaque and very often assumes previous mastery, and most of the tutorials I've run across are hatefully awful, though there are a few good ones out there (you'd be served to trawl comments in some of these to see better practices though, as some utilize some bizarrely unproductive workarounds).

· Player input, this one's a giant one. One thing I will not miss at all in GMS is having to exhaustively cover all player input in my code, especially when I wanted to allow for multiple control methods (keyboard or gamepad, etc). In Godot, this is handled right in the project settings menu and it couldn't be easier to implement references. The gamepad buttons are even labeled with their different counterparts depending on the brand of controller (PlayStation, XBox, Switch, etc.)

· GMS's text and label handling is just objectively bad in comparison to Godot's. While there's some awkwardness to the organization of some of the inspector menus in Godot, it appears to be getting better with each version release, and even at its earliest it was way better than GMS's sight-unseen kludge.

· Speed is another giant factor. Godot boots, compiles, and exports exponentially faster than GMS. No sign-ins, no bloated installation, no paid upgrade nags. Its HTML5 performance seems considerably more consistent as well, though I've only tested the two Sludge Runner game builds against each other so far.

· 3D was possible in GMS but was clearly an afterthought. While Godot's no Unity, it's galaxies beyond GMS as far as 3D and there's a lot of promise for future versions.

· I do prefer the syntax structure of Godot's GDScript to GMS's GML language. Give me tabbed structure over curly brackets any day of the week.

Anyway

The Godot build of Sludge Runner is up on itch.io just like real games, and I'm satisfied with my language migration. Improvements over the old GMS version include full scrolling, parallax animated backgrounds, zoom-out, and reset. Feel free to play both and compare, I throw nothing away, even when I probably should. I plan to get back to this engine soon with the full game I've got planned for it, but I want to program some other things first. More on that when there's more on that.

Oh and we won the Escape From The Secret Lab show last Sunday! Thanks to all of you that contributed to our score for that. If you missed it then you missed a wild set and even wilder judges, you can watch the replay here! Now I just bide my time waiting to collect our third plaque from the bad doctor.

Working up the promos for that reminded me how much I like making videos so I'm kicking around some ideas for the next video project. Anything else would just be dooming it to not happen, so like everything else I work on, you'll hear about something when there's something to hear about.

It looks like Dr. Pinkerton learned nothing from last time, so we're coming back to beat him again, this time at his new lab in space! The Jak Locke Rock Show is back on the unique Escape From The Secret Lab live streaming rock music game show this Sunday, February 6th. Just like before (and that time he turned us into zombies for his band's show and ruined my chess set), there's a video promo that we put together that you can watch right now. Go on, I'll wait, I don't mind.

I also bought the Casio Privia PX-560M keyboard I've been wanting since 2015 according to my wishlist on Sweetwater. It was time to improve my live piano sound from the Yamaha Piaggero I got in... huh, 2015. Now I remember I went with the Yamaha then because it was 11 pounds lighter (not to mention a third of the price). It wasn't a bad keyboard and I got some abuse and service out of it, but the Casio's a few leagues ahead of it in sound, feel and function.

Getting it has had the unexpected but welcome side effect of me playing piano daily which I haven't done in nearly plural decades, so I've been working up a ton of new songs for the piano segment of The 45s show and getting my keyboard chops up better than they've been in a very long time.

Though you wouldn't know it from my output, programming games has always been a giant interest of mine, long before I wanted to play music or any of the other things I've tried doing. The programming language I had been using exclusively for the past 15 years, GMS, decided to go to a subscription-based model for its distribution packages. Software-as-a-service is a vile bandwagon so I've jumped ship to the open-source Godot.

As a result I've spent the last two weeks going through every tutorial I can find and also studying its scripting language, and even this early on I'm seeing that a lot of its architecture is a ton more efficient than GMS's was for the kind of game concepts I'd like to make.

Speaking of those, the image next to this paragraph is my "game ideas" document I've added to over the past ten years -- there's over 100 game, engine and element concepts I've been meaning to get to "just as soon as I find some time."

Well you never find some time, you have to make it, and what I've been learning has been very inspiring to make the time to get these happening. I know waaay better than to put out any deadlined announcements about this sort of thing, but I can say to expect more game stuff from me moving forward.

Oh and to follow up on the last post, so far the only correction I've had to make to anyone is clarifying that there's no apostrophe in "The 45s". Not bad, all things considered!