My week in game dev #20
The holiday to-do list
Brrr, chilly out! Good weather for coding and newsletter writing…
I actually took a proper coding break over Christmas. Well, in so much as I took a break from UrbX because I really needed to decompress from it. Instead I decided to take a look at the Amiga again. It’s a long long time since I did any Amiga dev and I truly remember very little. I even had to relearn how the machine works in terms of desktop and files and stuff - and it all felt very alien.
After considerable faffing around, I have a fairly decent dev environment involving Visual Studio Code (sigh) and a plugin package that builds C and asm to the Amiga emulator; WinUAE. Shame I couldn’t get it to work on MACOS but not to worry. Moreover, it’s not as good/fast as the PDS system we had in the 1990’s… but nothing ever is.
With that working I read a ton of stuff about the Amiga’s juicy bits - the Copper, Blitter, Playfields, palettes, etc. Because to get much out of it, you need to be hitting the hardware hard at a very low level.
Yeah, I start to remember now - it’s tweeky stuff.
Interestingly, I reckon the Spectrum Next is at least the equal of Amiga AGA in many ways - certainly the Next’s hardware sprites are better - but the Amiga has the beautiful 68k CPU and, therefore, no bank switching which counts for a lot in my book. I do love the Next, but my goodness, I really dislike the memory banking.
I also decided, after much deliberation, to code the Amiga UrbX engine in C, despite my heaping praise on the CPU. The reason is strategic, because to have the ‘game’ engine in C would be very useful for any future ports to DS/Switch/Dreamcast/Xbox, etc. A 68000 codebase would be less useful. Anyway, if there’s some Amiga performance issue I can mix in assembly, but I don’t anticipate it.
And that’s as far as I have got with that.
Another side project is my Obsidian remake.
Now, the idea with this was to deconstruct the original 1986 game (e.g. 43Kb of binary) into a rebuildable assembly code + data. But having poked around at it I think it’s such a mess that disassembling it is a no go. It’s just too fiddly to pull the code and data apart.
The goal is not just to rebuild it, but to ‘fix’ it. And by this I mean make it better to play as it’s much too raw in it’s original form. After this I’d port it to the Spectrum and C64 and re-release in digital and boxed form. Like, just for the hell of it.
Looking at the original it’s actually so simple that it might well be easier to just to recode it. I have managed to pull out most of the graphics from the original binary, but, oddly, can’t find the map data. What weird format did I store them in? What the hell was I thinking of back in 1986?
Anyway, I have a new shell app that draws a few map blocks on the screen!
And that’s as far as I have got with that.
Where did the holidays go? Back to UrbX now. It’s at that point where there are lots of loose ends and it starts to get confusing. The point of ‘maximum complexity’, as I referred to phenomena during the low points of those big Revolution games. This game is simpler, but it’s assembly code… The only option is to push through. I think it’s very close to turning the corner where the march to the finish line is revealed. It is, after all, more than 70% complete.
Now we need to get organised for the Kickstarter and get a Steam page setup because the idea is that you can player ‘UrbX Next’ on Windows, Mac and, of course, an actual Next. Future versions will be enhanced to make the most of each particular platform. We don’t want to do quick and easy ports.
For that Steam page we need a brand name. Stoo and I went back and forth on this problem for weeks. Naming things is hard.
But finally, behold! Welcome to the world - ‘Brazen Gameplay’ :)
(Brazen for short, but everyone needs a buyable domain name…)