My FlatPress blog

What’s the point?

Why am I playing with these old computers? Why am I trying to do development for them? Surely there are more sensible things to spend my time doing…

Well, yes. I’m playing with them, partially out of nostalgia, my childhood was spent around some of these machines, and even those that are a bit before my time, or I just didn’t have, interest me for their significance in the story of computers and games, but also because I’m interested in working with limited resources.

Now, I’m not going to throw away my smartphone. As with most people, I’ve become a little to reliant on the thing, but I do look at modern computers and think whether we need the power, because a lot of the time, it feels like software makes me work slower than it used to. Also with games, is that game actually better, or just has better graphics?

I am not abnormal, I realise I may have rose tinted glasses when it comes to “the good old days” and my playing around with my computers has reminded me of this. Floppy disk loading times are no joke, let alone cassette loading. And playing some of my old favourite games reminds me how clunky the controls were. There are some games which have aged well but in general, we have learned a lot about what makes game design work. Some of this is down to better response times on input, higher fidelity output allowing for more expression in the design, and raw performance being able to churn through incredibly complex AI. Some of it, however, is more about consistent and predictable input behaviour, clear goals and targets, and a deeper understanding of what players actually care about. Given these things, it should be possible to create a game on an old console or computer which learns from these things and is genuinely fun to play, even without nostalgia colouring our judgement.

There are a few examples of this already. There are many retro style, or pixel art games being developed and released on a similar premise right now. These are great as they try to prove this point to a wide audience, those without old hardware and don’t want to set up emulators, but it’s not quite what I’m getting at. For that, I’d like to draw your attention to Planet X2 by The 8 Bit Guy. This game is not graphically amazing. If you compare C64 games ‘of the day’ with what the demoscene can squeeze out of the hardware, it’s firmly on the side you’d expect from a C64 game. While it does have some quite impressive technical things, I don’t think this is really what makes it good. Perhaps some of them allow the game to be good, but I think what really makes Planet X2 for C64 good is that it takes what we have learned from modern RTS games (at least modern in comparison with C64) and figures out how to make those gameplay design decisions make sense on such a limited platform.

So, of course I want to make a game.

Of course I do. As do millions of others. I have a specific game, or perhaps series (as if I had time to finish even one…) my primary plan is to release the game on a modern platform, but then make ports to some 8- and 16-bit platforms, if possible. I have chosen point and click adventure as my genre of choice as I have a fondness for them, and while there are some very very good old ones, I have some modern ideas I think could work nicely. The intention is for me to build a custom “engine” like SCUMM, which I can use to produce scalable games. In theory, you could give a C64 executable the package from a x64 build and it might just work. In practice of course, I’m intending to produce some assets specifically for each platform.

NOTE: I feel the need to point out that I am not so naïve as to think I can make a system which could actually load packages produced for a 64bit target on an 8bit machine, but I am hoping to make it so that I can relatively easily build packages from mostly the same source data.

How does this tie in with my earlier post about wanting to do all the development on the target console, or at least what feels like the correct system? Well, it doesn’t really. It is something that has been plaguing me for a while. But I think I’ve come to terms with it. The compromise I’ve made with myself is that I will attempt to develop some small games and utilities on the actual consoles, and maybe some larger ones too if I ever get time (hah!) but then for the above project, I would develop the game on a more modern computer (probably a Raspberry Pi for reasons I may explain later) but then develop the engine (or player, or virtual machine, or however it is thought of) on the respective platforms. Whether this will work out or not will depend on a lot of factors. Some of which I am exploring, some I am sure will come up, but I’m not aware of yet. While I like the idea of producing all the authoring tools on the target platform too, my limited time would probably force me to focus on maintaining just one set, at least initially. Of course I will be evaluating my development, and if it would seem like a reasonably sensible investment, I may then also write packaging tools, dialogue tree editors, animation previewers etc.

As with all my projects, and as I keep pointing out, progress will be slow due to time restrictions. But then, why am I looking at developing for so many totally different platforms? I guess one answer might be insanity. The reality is, though, when I have so little time, I want to work on something fun. Fixing bugs is rarely fun, it can be satisfying when you squish a particularly nasty one, sure. A lot of game development is not fun though, it is grind and slog. It is debugging and testing. While I’m certainly not saying I will not do that, if I’ve got an hour spare to do some work in the evening, perhaps I would find it difficult to be motivated to do that then, I might find it much easier to start fiddling with another project. If those projects actually benefit my main project, even just a little, that can only be a good thing in my opinion.