I am not a developer by trade and any experience I have is of using C# and various iterations of Visual Basic in the distant (7+ years) past. I use PowerShell in my day-to-day but this can’t really be described as a genuine programming language. One of my ‘bucket list’ items for 2025 was to figure out how to write a Space Invaders game and something I have been procrastinating over for months. This was mainly a project in how do I write it but also served as a great way to learn or at least re-acquaint myself with a programming language I’d lost touch with. Since this was to be a fairly steep learning curve, I figured I should give myself a fighting chance by choosing a language that :

1. I am somewhat familiar with
2. Is suitable for such a project.

So for part 1, C# it was. I say part 1 because now I have a good idea of how to put the game together, I would like to take this further and write a version in another language and possibly even a recognizable version in PowerShell. This should give me some exposure to other languages I currently have little to no knowledge of (I’m looking at you, C++ and Python).

But you can get AI to write the whole thing, surely? Well, yes, true and I’m not going to lie, to some extent, using AI is almost unavoidable. When starting on a particular subroutine it would basically read my mind about what I wanted to do next. Really. It’s not like I’m new to this (AI in general or looking for fixes to programming issues) but I’d start to type the name of a routine to make the saucer fly across the screen and it would largely write the thing for me before I’d finished typing the name of the sub. Blown away. That said, not everything was quite right and many times its assumptions weren’t what I wanted so going through the code to fix these issues wasn’t just ‘satisfying’ but necessary.

Then there were annoyances which I genuinely wanted AI to solve but try as it might, it just couldn’t. First versions occasionally left artifacts of the laser fire on the screen that wouldn’t go away. Co-Pilot kept making suggestions but either these didn’t work or worse still, broke the code. And it was during these frustrating times that my free access ran out and I was left to fend for myself (more or less). Back to Stack Overflow for fixes (in the end this solved itself when I was forced to adopt the OnPaint method for sprites – more on this later).

Eventually I had a working game on my desktop development machine which I was quite proud of. It looked just like the real thing and although I’d furnished it with a few more flourishes than I’d originally planned (my starting goal was to make a very basic game that could be ported easily from language to language) I was happy with it. Then I tried it on my laptop. Oh dear. Every time I fired a laser it slowed the game down. Sound was also hogging the UI thread too…my God, this computer must be several million times the speed (and memory) of my old Beeb that used to run this game, so why is it having such a hard time?

This called for a re-write to some extent. Quite a large extent, in fact. I had to put the main game loop on a background thread; the sound had to be pushed out onto a background thread too (this helped a lot but still isn’t perfect by any stretch). However the really big change was to replace the way the sprites were presented. My initial version had all graphics as a separate PictureBox – this was ideal as it was simple and would potentially make future versions eas(ier) to write. Unfortunately this proved incredibly resource-intensive and although it ran OK on my desktop machine, it really struggled on my laptop. Begrudgingly I had to bite the bullet and swap this for the OnPaint Method. Although the learning curve for this increased (dramatically in fact), this did have two main advantages:

1. The OnPaint method is significantly more performant. Each PictureBox is a full windowed control, which means it has its own window handle (HWND) and processes system messages. For a game with lots of objects like aliens, bullets, and lasers, creating and managing a PictureBox for each one consumes substantial system resources and this led to poor performance and noticeable lag, esp on my laptop. In contrast, OnPaint performs a single, highly optimized drawing operation directly onto the form.
2. Smooth Animation (Double Buffering): The OnPaint method works seamlessly with the form’s DoubleBuffered property. By setting this.DoubleBuffered = true;, all drawing operations within OnPaint are first rendered to an off-screen buffer and then drawn to the screen in a single operation. This improved animation noticeably.

There are other benefits to this too which I’ll leave out here for brevity’s sake and ultimately it was worth the effort to get the game working with this method instead. The PictureBox version can be found here and the OnPaint version here. Links to the full project are also at the end. I still think there is value in the PictureBox (and single threaded) version if only as the academic exercise of creating the game in it’s simplest* form.

_{*It’s not in it’s simplest form. I could have made it a lot simpler. As I said, I got a little carried away.}

GAME FLOW

Although I won’t pretend I started out with a ‘design’ in mind, this is something that kind of presented itself as I got further into the project. I have used VS2022’s Mermaid Editor extension to help create a flow diagram of how the whole thing works:

I have, somewhat lazily, embedded the flying saucer as a project resource and this is the only graphic in the project that remains as a PictureBox. So in short, this is on the form and not ‘created’ in code. The same can be said for the hi-score form which I have designed in the editor rather than created in code. I make no apologies for this and feel free to change and use what you like for your own project, should you wish to. All the graphic and sound files will, as a result, need to be in the same directory as the exe file (“EalingAttack.exe“). Oh yes and on that subject, I had various names for it throughout the project. It started with a reference to my road (BirkbeckInvaders) before eventually settling for EalingAttack (my borough in London). As such you’ll see references to these and they could do with cleaning up in an ideal world. Finally, I have added descriptions of what everything does throughout the code for anyone who’s interested.

I haven’t decided when the next installment will be yet but don’t hold your breath. Ideally I need to start spending some time with the family again :-). I promised a follow-up article on 6502 assembly as well which I still haven’t got round to yet. I’ll probably tackle that first though as it will be a shorter project but again, in my own time which could be whenever.

CONTROLS:

Oh and I forgot to add a controls screen so it’s:

Left/Right arrow for the turret movement and spacebar to fire. As alluded to above, sound is still an issue on some machines, particularly the background sound. If this noticeably affects gameplay, you can toggle it by pressing ‘S‘.

Finally – feel free to create your own upgrades and leave links in the comments.

GITHUB :

bondy666/Space-Invaders: Learn to program Space Invaders in multiple languages

Either clone it or for those who just want to play the game go to Code > Download zip, unpack and run the exe. I promise, there are no nasty surprises (apart from the bad coding).

Late edit – found one or two bugs which could do with fixing (should be easy enough!). Get to level 6 and see what I mean. High score table needs some finessing too.

_______________________________________________________________________________

EDIT JAN ’26

Quick and dirty web version. This is notable only for the fact it runs in an Azure Container Instance. If the link doesn’t work then I’ve probably deactivated the CI.

http://spaceinvaders.ahhmehcbc3e3cybu.ukwest.azurecontainer.io

GitHub:

https://github.com/bondy666/Space-Invaders/tree/896f13f0366b25fc5bc8eed8c7ae74a13a5b0df9/WebInvaders