GitHub Repo

Not that this version is exactly done, but I was thinking: Would it be interesting to start over and do Asteroids in a different style?

The original game is a very tight assembly-language program. It has no objects or any high-powered technical things of any kind, just some simple data and the ability to branch and call functions. I wouldn’t go that far. In fact, for a somewhat valid comparison, I’d do it again in Kotlin, but “simpler”, without a lot of separate object acting more or less autonomously.

It would consist, I suppose, of a function that performs one frame of action, which is really what we have now with this:

        extend {
            drawer.fontMap = font
            game.cycle(seconds, drawer)
        }

But how might it start to really differ? Game.cycle looks like this:

    fun cycle(elapsedSeconds: Double, drawer: Drawer? = null) {
        val deltaTime = elapsedSeconds - lastTime
        lastTime = elapsedSeconds
        tick(deltaTime)
        beginInteractions()
        processInteractions()
        finishInteractions()
        drawer?.let {draw(drawer)}
    }

It might look a lot like that, although I could imagine that there might just single loop over everything, where in the current design we loop overall the objects (that are interested) with each of tick, beginInteractions, processInteractions, finishInteractions, and draw. We might still take the approach of updating everyone, then checking collisions, then drawing, although I could imagine doing drawing of each screen object right after processing it for collisions rather than in a separate pass. It does seem to me that one wants to have every thing at its position as of the current time before checking interactions. It might make a difference, although visually I suspect you couldn’t tell the difference.

Where might we start? Without actually doing it, I can imagine at least two different starting approaches.

One might be to draw from the very beginning, at first maybe just a dot or something, and make it drift around the screen, then a couple of different kinds of dots, and so on.

Another approach would be to save the drawing until near the end, programming the whole thing as a kind of internal simulation. I did that to a degree with the current scheme, and once I started drawing I got a bit more careless about doing everything with tests.

If the game is going to be more monolithic, more like one big loop over dumb objects, it might be difficult to test, requiring more scenario type tests. On the other hand, as soon as I even say that I start to think, no, there will have to be a patch of code that takes two objects and processes them, and that can be a function. We might have to look into the objects to see how they were changed or something, but we could still test at a micro level. We might even do better than last time.

I would do a very version with tests, even though the original Asteroids was surely done with a more manual style of testing: there weren’t things like our current testing libraries in those days. Basically you assembled the program and ran it to see what it did. We did have the “DDT” debugger, so could step the program and inspect registers and the like. Ah, those were the days. These days I almost pride myself for not even knowing how to use the debugger, relying on my tests (and a few simple print commands). Thing is, I know myself well enough to know that once I start using the debugger, I’ll be stepping and stepping and backing up and stepping not quite so far … spending serious amounts of time debugging.

I’m not the best at this, but I do better with tests and the occasional print to see what has happened.

I think I’d like to see the game coming together, not just see its tests running, but I believe that I’d go faster if I left the display of things toward the end, because while it only takes a few seconds to run the tests and then I’m back to work, when I run the game to see what it does, it takes me a minute to fly around enough to test whatever I’m testing, even if I only try it once. And I almost always try it more than once. So a turn-around of maybe thirty seconds turns into a few minutes.

It’s tempting to try it. I probably will.

The hardest part will be setting up a new project, but I’m pretty sure my friends will help me.

Will it be interesting to readers? I hope so. Let me know, either way!