It is Thursday again and looks like I have time for a early morning entry on the series, so let’s do it!
My Canvas 2D engine
I got to the point where the engine does most of the basics; which in reality is not much considering that there is no game. I have an idea to make a simple platformer with procedurally generated levels –why make things simple?–, but I got stuck when I tried to draw some graphics.
I do have some tiles that are OK, but they are not very inspiring and I suspect the end result would be too bland. In reality it feels like the type of programmer art you would expect in a game jam, so I’m not too excited.
I put it on ice until for now. Perhaps I should get some palette/restrictions from an 8-bit machine and use that as style. I’m not a big fan of modern games that looks like a ZX Spectrum game but obviously is something that would be impossible to implement on a ZX Spectrum, considering that I can make ZX Spectrum games.
It is possible that I’m overthinking this and instead I should decide that is that I want from this project. Is it just making a simple game using modern-ish Javascript as a tech demo? Is it making a platformer with procedurally generated levels? Is it a prototype to test ideas that later I could implement on an 8-bit system?
It could be all of them, but I don’t know!
Work on Outpost
After I started the combat in my unnamed CRPG –seriously, I need a name–, I programmed the PC movement and I didn’t like too much the code structure, so I decided to walk away for a couple of days.
Then I fired Outpost and… I like how this looks! The engine is solid and there are so many new things I haven’t programmed before that I feel I should finish and release it.
So I’m back to do level design, and things are looking promising, actually.
We have doors!
I have designed 8 objects, most of them to be used as part of a puzzle, which works more or less as “key/door”.
Perhaps the most obvious was doors –of course!–. These require the access card, and once you have it you can open them, but only in one direction –we are not going to question the overall design of the “Outpost”, are we?–.
I have some potentially interesting ideas for another 4 objects, but I still need to come out with some story more than the vague idea I have. I implemented terminals essentially to show information, perhaps as diary entries, so I should use them!
ubox MSX lib has CI
Arguably this is something I could have implemented in GitHub as well, but I think GitLab is slightly easier, so thanks to the initiative of Pedro de Medeiros –so far the only external contributor to the project–, we have added continuous integration to ubox MSX lib repo in GitLab. Currently it only compiles everything, but that’s enough for now, because it helps us to ensure no change we make will break thins that bad.
You can see the output of the build job.
I’m thinking what can we test, really. We could run unit tests for code that is Z80 independent, and that could be compiled with a modern compiler and run in the CI containers, or we could use a Z80 emulator –doesn’t have to emulate and MSX really–, and generate Z80 and run it in the emulator.
Both sound like good strategies, but before committing to write a lot of code, I would like to be sure there are tests we can/want to write.
Titan support in SpaceBeans
In not really gamedev news, I’ve started implementing support for Titan protocol, which is a simple extension to Gemini that allows uploading files. It is one of those idiosyncrasies of Gemini, where extending the protocol is a no-no, so instead people come with these “alternative protocols” that is basically and add-on that could be part of the main protocol.
Anyway, it shouldn’t be too hard to implement, and considering that Lagrange browser supports it, I think it is going to be a nice addition to SpaceBeans. You could manage your gemlog fully from one single application!