I used to do this type of post every Christmas, when I had my blog in Spanish, but for whatever reason is a tradition I didn’t port to this blog. Although I’m not sure I want to start doing it, 2023 has been weird in several ways and it may be interesting doing some reflection here.

A good example is that after leaving Twitter for Mastodon, turns out that the social network where I am most active is… IRC.

I was a heavy IRC user on the mid to late 90s, but after that I only connected when I was working on an open source project and either I needed support or I was contributing and it was useful to be there –for example, when I was working with OpenStack Kolla–. For me, it was instant messaging with XMPP (Jabber back then) what replaced IRC, and I didn’t think I was going back. XMPP didn’t succeed the way I was expecting and that’s mainly why I’m only on Signal now–, but that is a story for a different day.

Where I am “active”? Mostly on Libera: #gamedev, and others channels like #haskell-gamedev or #cpc; and AfterNET: #dosgameclub and #ludumdare.

I also spent a lot of time on tilde, but because I was connecting to IRC via ctrl-c club; when I decided to connect directly from home because the club was kind of unstable, I dropped that network because there was no way to conceal your IP –unlike Libera via cloaking and AfterNet by default–, and I didn’t like it. I know it probably doesn’t matter, but there you are.

Although the channels are dedicated to specific topics, turns out people may talk about anything; which is kind of the opposite of Masto thinking about it: a social network about anything but we choose to focus on the topics we like. You find a lot of channels that aren’t very active, if at all, and sometimes there’s that user that is very annoying and that may even spoil the channel to the point of not being worth it; but that’s OK because you can just leave the channel if that’s the only thing you get from it.

The DOS Game Club podcast channel is a good example of good and healthy community, and links nicely with another thing I didn’t see coming this year until it happened: making DOS games. Also: one of the channel members lives in my same neighbourhood, which is a happy coincidence that allowed us to met for a beer!

This year I have released two very different games for DOS:

• Gold Mine Run!: targeting the second age of DOS gaming; meaning 32-bit, VGA and Sound Blaster.
• The Return of Traxtor: targeting early IBM PC/XT; meaning 16-bit, CGA and PC Speaker.

I’m happy with these two games, and I have released a library for DJGPP to make easier reuse the code I wrote for “Gold Mine Run!”. I started doing some bits with CGA/EGA, but I didn’t get too far. In any case, I think there are chances of more DOS games coming from yours truly.

I even streamed the development of one of the games, which was very intense because I tried to finish the game for a game jam, and there was no enough time. And then I stopped streaming.

I kind of like doing it, but I was making a big effort to ignore that I don’t like how both Twitch and YoutTube fund themselves with ads –and tracking users–. I investigated other options, like live streaming with Peertube or Owncast; but got to the conclusion that streaming video is expensive, and I’m not sure that what I stream is worth it. It is a bit like the cost of Mastodon, really –although it is much less, and I’m happy donating a small amount every month to the SDF social media efforts–. I may revisit my decision next year, but at the moment I don’t see a way forward with that.

I have worked on other things, but none of them got close to be on a finished state –most notably “Outpost” for the ZX Spectrum 48K that I really wanted to finish this year–. As I mentioned recently, I’m sharing my gamedev time with reading books, and that was a factor. Looking forward to see what will happen in 2024.

Finally, my return to old protocols didn’t stop with IRC. I also spent some times reading groups on Usenet; although I’m not posting often, so I guess I’m still not completely in. I’m keeping my notes on Newgroups up to date, in case anyone wants to take a look. Things move slow, but they still move!

Other than that, this blog keeps going, and posted a couple of times on my Gemini capsule –although I’m not spending time reading there, since last year–.

I have played games this year, but not long ones after I abandoned Persona 4 on the PS2 –another one to the unfinished pile–. But I discovered Lutris, and that has simplified gaming for the whole family. I linked our GoG account, and tinkering is over! Basically: if the game works on Linux, Lutris will make it work as optimally as possible, which is allowing us to play games I didn’t even know my humble PC could run. I still have a lot of games to play from itch.io –by the way, how disappointing has been their take on Masto–, but I don’t miss the time that sometimes take to get a game to run OK-ish!

Other than that, I have an Anbernic RG-350 that I bought in 2019 –and I haven’t used much– that now is my Pokemon Sapphire machine. Ready to pick up and play any time, I’m 13 hours in and it is good fun. I haven’t played many 8-bit games this year, old or new. Nothing has excited me enough anyway.

And I think this is enough for a recap, although I’m sure I must have left out some things. I guess if those were important, I should have written about them in the blog anyway.

Life is busy. With work, family and all, there is that much time left for myself. And for a very long time I have been very focused in doing one thing, which means not doing a lot of other things. So I wasn’t reading many books because I was putting most of my free time into gamedev. No regrets there, but I like reading as well.

Last year I started reading more serious books with my younger son, not sure if it was too early. Anyway, you never know, so we started reading “The Hobbit, or There and Back Again”. Well, I was reading it. Then after that book came another, more appropriate to his age, and eventually he started reading the title of the chapters, then the first paragraph, then a whole chapter, and now he reads books on his own.

We have this routine that we read together for 30 minutes to an hour every day, before going to bed. He is reading whatever he’s got from the public library, and I do the same. Which means I have been chaining books non-stop since then, and that translates into 22 book this year –and I think I will finish another two before the end of the month–.

Until he decided he didn’t want to read with me any more, we read a lot of children books according to the library; although I would say they are probably more young adult, as some of them treat topics a bit too mature for my son. For example, the “How to Train your Dragon” series by Cressida Cowel, surely they start silly and perfect for a 6 year old, but being 12 books, the last three had a very serious look at very grown up topics like good and evil, love, age or death. These books are easy to read, not too long with a large font and some drawings, so it is very likely I won’t read over 20 books next year.

I’m also trying to include the occasional technical book, but I’m finding it hard. For example, this year I read “Writing an interpreter in Go” by Thorsten Ball, that is pretty good –without being as good as Robert Nystrom’s “Crafting Interpreters”–. After giving Go a good go, I decided that I didn’t want to spend more time with that language, and I think that affected my enjoyment of this book.

You can always put down a book, if it doesn’t work for you. We had to do that with “The Lion, the Witch and the Wardrobe”, “Howl’s Moving Castle” or “Only You Can Save Mankind”; and that’s OK.

This year I have discovered Brandon Mull’s series: Fablehaven and Dragonwatch, and I enjoyed them very much –although after 10 books I must confess I was experiencing some fatigue–, and I’m enjoying Richard Osman’s “Thursday Murder Club” books –I have read two, and the third is already waiting for me on my desk–.

All this means I’m doing less gamedev, although I have released two games this year! The more paced activity may have a positive impact in my production, or it may do the opposite: the never-finishing-things monster is always there, waiting in the shadows. Beware!

I guess it is was a bit unexpected, because there are other projects I could be working on. For example, the long running –and often neglected– “Outpost” for the ZX Spectrum 48K, a few ideas for DOS –including some sweet code to support CGA and EGA–. But that’s how creativity works: when inspiration comes, it is hard to not listen.

The working title of this new project for the Amstrad CPC is “The Heart of Salamanderland”.

The name is the work of my younger son, that is helping me with the script and the framing story, which is great and also hard!

I’m targeting the Amstrad CPC, 64K in a single load, loading from cassette or disk –there will be a CPR version for the GX4000 as well–, and graphics in mode 0.

I’m building on top of one of my two main engines for this type of game. I’m not sure if it is the right one, because it is performant but uses quite a lot of memory. At least I’m sure it will allow me to pack plenty of action on each screen.

I have been investing on a new map renderer based on meta-tiles of variable size and I think we may end with a good-sized game thanks to that –I wrote about encoding schemes for map data some time ago–. I’m not too stressed about it: if the game is not too big, I can make a sequel if people like it.

This project came about because I the last couple of months I read two series of fantasy books by Brandon Mull: Fablehaven and Dragonwatch, and I loved the adventure mood. So the game is a bit inspired by those books –the main character specially, I’m tempted to call him “Patton Burgess”–.

Another big inspiration is the classic Castlevania, that is a series that I love. So I gave Patton –let’s call him that for now– a whip, and in a way it works fine with Mull’s ideas. It is just that we don’t fight Dracula and friends. The quest is different, we are trying to find an old relic: the Heart of Salamanderland. And there will be undead, wizards and demons. I may be mixing realms, but that’s OK.

It is currently a work in progress and there are still things that aren’t clear. The usual memory constraints apply, so I have to decide what gets in and what doesn’t. But at least I would expect an action platformer, with a good number of interesting enemies, a few screens to navigate, and some puzzles so solve. All in my style, that is something that can’t be changed I’m afraid.

I usually post development updates on my Mastodon account and there’s a thread on CPC Wiki.

I have never used a game engine before and, when working with 8-bit, I have this thing of starting from scratch to learn the machine, even if sometimes there are good libraries available.

I’m not sure what I was expecting when I tried Godot. Works perfectly on Linux and my machine, and it is open source, so two of the important boxes for me are ticked.

It all has come about because my 6yo son has been programming in Scratch –it works on the browser, but not that great on Linux; there’s Scratux but has its problems–, and we have now when is “TV time” that he wants to watch videos about programming. So we ended watching a bit about Godot, so here we are now learning how to make a 3D platformer. That escalated quickly!

My first impressions by looking at how the 2D part works is that there are forms, a lot of forms, which I see it can be an advantage –like it was a good thing for some people in Visual Basic or Delphi–, but I always found it a bit of a problem as things grow beyond some size. But then, you can control a lot –if not everything– from GDScript that looks very much like Python. So you may not need to deal with all those forms, and that can be a good thing.

In any case, when I was watching to some tutorial about the 2D part of it –because 2D and 3D are almost like two different engines–, I was thinking most of the time that I could make it simpler. But can I, really? I guess if I look at all the work I put into one of my small engines, is not that much. However, I make an engine focused and specialised in the needs of the game at hand, while Godot has to support lots of different takes of a 2D game.

And then is when we looked at the 3D part, that doing it from scratch is something I have given up since my awkward attempts some years ago; and I see the potential. Which to be fair is probably what people that can’t (or won’t) make their own engines from scratch may feel when they look at the 2D part of Godot.

At the end I suspect it is going to be down to the models, the textures, the assets; because looks like Godot has what is needed and it is very accessible.

A different topic is finding how to do it. The books don’t look like a good option because Godot is changing quickly –version 4 is quite new–, and there is also a lot of content with questionable quality abusing the idea of people that don’t know better and want to make a game. I haven’t been lucky finding written tutorials, because we live in an age that people will make a 30 minute video on YT for 5 minutes of actual content –all monetised, like, subscribe, and hit the bell; and there’s my Patreon–. So there is mostly videos, and those aren’t great for reference.

Anyway, we are having fun, even if we haven’t made anything significant. I guess at some point I’ll start looking at Blender again and, with a bit of lucky, it won’t be the end of this. But Godot is nice and has potential, I like it.

A couple of years ago I released the Return of Traxtor source, because I thought it could help people willing to start making games for the CPC writing things from scratch, and also for some historical value: it was my first good enough Amstrad CPC game.

Since then I have been busy and I must confess I totally forgot about open sourcing more games –although Gold Mine Run! was open source from the start–. I have different engines for making CPC games that I consider current, and unfortunately not that many ideas –or time– to make games, so it is kind of sad that the code is not being used in new projects.

From my Amstrad CPC production, Kitsune’s Curse is probably my favourite, and it uses a very special engine that is intended to make mid-size games on 64K by using as little memory as possible. It implements what I called mini-buffers, as opposed to a large buffer covering all the drawable area.

It tracks dirty tiles and minimises the amount of drawing on the screen, which is nothing new, but by using small buffers that are dynamically allocated so background and masked sprites can be drawn to it, the memory use is reduced drastically. In “Kitsune’s Curse” only 2560 bytes are used for mini-buffers, compared to the 16384 bytes of a hardware back-buffer.

Yes, that makes things complicated and it affects performance, but “Kitsune’s Curse” had 60 screens, 8 different enemies, 64 tiles, and all in 64K with one single load; and can handle up to 10 sprites of 8x24 pixels. So I think it was a success!

I used the same engine in The Dawn of Kernel as well, but then I wrote two more engines: one focusing on performance (used in Brick Rick) and another one for vertical scrolling games (used in Hyperdrive). I should make more games and less engines, isn’t it?

In any case, the source code of “Kitsune’s Curse” is available on this git repo. Like in my previous releases, this is how the code was when I released the game in 2020 –although I made some effort to update the tools, so things compile in a current operating system and no Python 2 is required–. It is not a framework or a library. Yet I think it may be an interesting read or a good base to start new projects, who knows?

I have documented most of the generalities of the code in the README.md, specially the interesting bits regarding the engine. There is a lot of Z80 assembly but, when possible, there is also the equivalent C code in a comment. Hopefully that will make understanding the code easier!

Over the last few years we have enjoyed some great games that included the source code, and I have learned a lot from them. I’m glad that “Kitsune’s Curse” is joining that club.

What do I mean by final software? I haven’t put much thought on a definition but, if I had, it would be around the idea of software that it is finished, that its utility and usability doesn’t changed over time, you can go back to it an build it at any time, and it is as good or bad as it was when it reached its final state.

I have been thinking about how non-final SpaceBeans is, even if I have decided that is feature complete and that I won’t add more functionality, I can’t stop updating it because its dependencies are non-final and there will be bug fixes and security updates.

SpaceBeans is a Gemini server built using Scala –and a small number of dependencies–, the Java way of building software means that the end product is a ‘JAR’ file that includes all dependencies; so it is my responsibility as project maintainer to have those updated. If I stop updating the project –updating dependencies eventually leads to API changes that require changes in my code–, it is possible the software can’t be used because security.

This wouldn’t happen if the end product was a package for example for Debian –ideally included in the distribution itself–, so it would be the maintainers of this fantastic operating system who would do the work of keeping the dependencies –and my software, by porting fixes– free of security issues. I think this is a much better model.

I would say this is something I kind of get on my games for 8-bit systems. The machines I target are final –their spec won’t change–, and thanks to open source, you can always get the compilers and tools I used to build the software when I worked on it, and build it as it was build at that time. And the resulting binary is final.

In the case of SpaceBeans, it is mainly down to the dependencies. If your project is small and focused enough, I believe you can get to that final state where no more features are needed and there aren’t any more known bugs –and it could be even bug free, I guess–, as long as your dependencies don’t change. Because a third party like Debian makes it happen, or because you have little or no dependencies, or your software has a limited attack surface so security doesn’t really matter.

Recently I read in Mastodon about slow software, which sounds similar to some of the ideas behind permacomputing. I’m not sure if any of them deserve a movement, but some of their proposals are very interesting and worth learning about.

According to git, it has been 12 days –not really, because this is when I have free time–, and 15972 bytes in total. The Return of Traxtor for DOS is now available to download!

It has less colors than the Amstrad CPC version –and no music, even if the PC speaker sound effects are kind of cute–, but it plays really well. Probably the most playable of all the versions, in my humble opinion. And possibly, the less buggy as well.

The CGA is fun to program, and I’m very impressed by IA16 GCC. I wouldn’t mind making another game for the original IBM PC, but not sure if it is worth it. For whatever reason, this early age of PC gaming isn’t that appreciated. And I’m not sure is just the CGA palette.

I may try the middle ground: find out how to program the EGA and add some Ad-Lib music!

I was reading this post by Foone on Masto:

Hot take: DOS gaming is not one era. It’s two.

Before and after 32bit extenders.

And I totally agree. DOS games, and DOS software in general, had a first age that was 16-bit, and a later one that was 32-bit and lasted until around 1997.

My first DOS game –or shall I say my first released game for DOS– was Gold Mine Run!, that is a 32-bit game. It requires a 386 or later, VGA and Sound Blaster; which is very different to what we had in the first age of 16-bit DOS.

So when the DOS COM Game Jam was announced, I thought: wouldn’t it be fun to make a game for the early IBM PC?

The 64K limit is not a big deal if we consider that most of my 8-bit games require less than that –even if you target a machine with 64K of RAM, that includes the video memory as well–. I could potentially port any of my 8-bit games to PC and it should fit in a COM file, embedding data and all.

I decided that I would target:

• MS/DOS or compatible
• IBM PC (8086)
• CGA
• PC internal beeper
• All in a COM file (that means 64K or RAM on disk; I could use more memory if needed), so I can submit it to the Jam!

This is basically what I had available on my first PC, an Olivetti Prodest PC1.

But then, I didn’t want to stress myself again and potentially not submitting the game because I didn’t have enough time. I hadn’t programmed the CGA before, I didn’t know if I could comfortably cross-compile from Linux to DOS and 16-bit. So I went for a simple –yet fun!– game: The Return of Traxtor. I have implemented the game a few times –my favourite is The Return of Traxtor for the CPC–, so it should be fine.

At the end, it wasn’t that bad, even if the CGA is fiddly and closer to what you would do on a ZX Spectrum –encodes 4 pixels in one byte– than what you would do on a VGA.

My strategy is not that different to what I did in “Gold Mine Run!”:

• Using build-ia16 to have a version of GCC that targets Intel 16-bit (8086) and can generate DOS binaries (including COM) on Linux.
• Embedding the data in the binary using objects and the linker (see for example raw.py).
• The keyboard controller is the same –although I had to rewrite it to use real mode interrupts, fun!–.

The first part was getting to draw on the CGA, following the docs I could find –see: Colour Graphics Adapter: Notes–. It required writing some assembler because of the real mode memory addressing, but I got it working reasonably fast in an evening. Then the interrupt handler for the keyboard was tricky as well, but after that, all it was writing plain old C code.

So far the project is progressing nicely –see my Mastodon account–, and looks like I’m going to finish a good version of the game and on time.

The name is kind of misleading, because is not a port to DOS of my ubox MSX lib, but I call this sort of library “ubox” when I’m building them –even if it is for internal use; they exist for Amstrad CPC and ZX Spectrum–. I hope it doesn’t cause any confusion.

After I released Gold Mine Run! I knew that if I wanted to make another game for DOS, I had to extract what I had written for this game and make it a library.

It is true that I could have made part of the work when I wrote the game, but I decided early on during the development of the game that I wouldn’t waste time thinking about abstractions or reusing code when it wasn’t clear that I would be able to finish the game. Now that there is not uncertainty –the game is finished!–, it is time to do the boring stuff.

And it is done, so I have published a repo with ubox lib for DOS. It is pretty much what I used for the game, with some extras –like an asset manager– and, in some parts, cleaner code.

I don’t know if it can be useful to anybody else, but I guess that now that I have the library, I will have to make at least another game to justify the effort. What I’m sure that I’m not going to do is maintain the library as a project to facilitate people to make DOS games; because I did that with the MSX library, and I haven’t enjoyed the experience too much.

So there isn’t documentation, although the library is tiny, so anybody should be able to read the code and figure out how it works, and even adapt it if needed. I’m happy for people to send bug reports and fixes, but I don’t want it to grow in directions that I don’t like –or, specially, that I don’t use–. Feel free to do whatever you want with your version of it, respecting the license (that is).

Regarding what I’m going to do next for DOS, I’m still undecided!

Last night I released my first game ever for MS/DOS: Gold Mine Run!

I mentioned here when I started that I had used some of the tools back in the 90s, and that I had the crazy idea to stream the process of making the game (the videos are in this playlist).

Although the engine and the stream were completed about two weeks ago, that wasn’t really a game: it needed level design and music, both things that I didn’t want to do on the stream.

At the end, I decided to add 30 stages, which is about right considering the amount of content –there are limited enemy types–. I didn’t feel like I was repeating myself too much when designing the stages, because there were enough components to keep it somewhat fresh. Yet, it is a small jam game anyway.

I did some gamedev in DOS back in the day, and I feel a bit like I am 25 years late to this, but still had a lot of fun making this game. Without my experience in the last 10 years I wouldn’t have been able to produce Gold Mine Run!, that’s sure. But then I have the feeling I could have made the same game using C and SDL2 –or even Haskell!–, and target current platforms (Linux, Windows and Mac at least). Would it have been the same game? Probably!

Now that this project is out of the way, I can pay more attention to my TODO list. Exciting!