I’d like to introduce my game “Sternenschwarm” for the CPC6128, which I programmed a while ago. I started around 2023… Despite using AI assistance even back then, it took me almost 2 years… Though the LLMs only really helped get the implementation across the finish line. Most of the work was done purely for the fun of coding something myself with my own hands (= keyboard).
Computer: CPC 6128. I use the entire RAM (bank switching)
You can play it using the arrow keys.
The game gets harder from level to level. To make up for this, you can “cheat” on the title screen: using keys 1 through 8, you can set how many shots you can fire in rapid succession…
Occasionally, enemies do NOT move back and forth. That’s because the program continuously measures how many objects it can move. The game runs at a fixed 25 frames per second. It uses double buffering and flips every two VSYNCs (20 ms each at 50 Hz). That gives a frame budget of 40 ms. A steady pace stutters less than fluctuating framerates, which is why the rate is locked rather than uncapped.
Development platform: “Retro Virtual Machine 2.1”. Unfortunately, I sold my CPC 30 years ago.
To create the graphics, I wrote my own editor. It can save images and sprites in various file formats and byte orders. If anyone is interested, I can share it here.
A few stats:
Assembly: 7,356 lines excluding blank lines and comments.
Python tools: 8
optimal distribution of graphics across memory banks 0 to 3
This is excellent! Love the fluid movement, and the only issue I have is that the enemies already on the screen stop moving when another lot of enemies is flying in, making it quite easy to shoot them. But then again, I’ve not beat your score yet so maybe it’s just helpful!
Nice, first run 40k… Without a lot of attention to ‘survive at all cost’.
if you add a ‘capturing’ boss (top level ennemy) you can even put it in the Galaga trhread
Small bug: when stage finished (text on screen), bullets (enemies and player) are freezed, then released again when stage begin. They are not dangerous during the freeze, but I don’t know if they are when released.
This is a good level game already. Nice graphism / animation / challenge. Better than a lot of paying games back in the day. Lack just some bits to be top level: some jingle between stage or sound ambiance in stage, a bit more of ennemy movement pattern maybe.
Thanks a lot for the feedback. Here are a few insights into the implementation of the game, to help explain a few “quirks” of the game design.
Memory footprint: In order to rotate the “enemies”, they are stored in memory for every phase of movement. They are included in the program code exactly as shown.
These images alone take up around 38 KB. To keep the animations smooth, I use double buffering, which requires another 16 KB. Managing all the objects takes up 792 bytes (via a dedicated table).
All in all: I have to use the additional 64 KB of the CPC 6128.
Refresh rate (strictly locked at 25 frames / second): I once wrote an Asteroids game for the CPC. It “died” due to the sheer number of moving objects. (If I can still find it, I’ll post it here.) That’s where the idea came from that the number of moving objects needs to be tied to the refresh rate. An Asteroids game isn’t suitable for this, because it feels awful to play when individual asteroids stutter. This game (Sternenschwarm), on the other hand, detects internally whether it still has time to move an object before being caught up by the raster beam. Priority is given to objects that haven’t reached their spot in the formation yet. Occasionally, you can see that only a few objects in the formation move, while the others follow later.
End boss: The game has barely any memory left on the machine. Also, I’m terrified of having to handle large objects on screen… The project is pretty much wrapped up.
Font glitch: As far as I know, this bug shouldn’t be happening anymore. I actually had this back in the early stages of development; a copy-paste error carried over a call. I’ll track down the bug when I get a chance. Thanks for pointing it out.
Pretty cool! I have to admit, this definitely would’ve been one of my favorite games if it had been around back then.
I’m a huge Galaga fan anyway, and this game is clearly inspired by it — most Galaga-inspired games are pretty lousy — but this one is really good and a lot of fun to play.
If you ever get around to tweaking anything, I’d have one request:
It looks like the formations at the beginning always play out exactly the same way. Galaga has at least a bit of variety there, giving each level its own staging pattern. I think that would really do this game a lot of good and boost the motivation to give it another go.
One more question: Is it even possible to wipe out all the squadrons in the Challenging Stage? I got the impression that it’s impossible to position myself to actually catch every single enemy. In Galaga, that’s doable in principle. Then again, of course this game is allowed to be different…
yes, the formations always play out exactly the same way. In my first post about this game, I showed the movement patterns across two images. Varying them sounds like an interesting idea.
In fact, I have two relatively simple ideas for potentially implementing these new patterns: shifting them slightly to the left/right (by 2, 4, or 6 pixels), or simply providing a few more static movement patterns. As for the idea of piecing together movement patterns from many smaller segments, I’d first have to check what that would mean for the code in detail… I don’t really want to dive that deep right now, as I’m currently working on another software project.
I’ve never really thought about the “optimal position”.
Thanks for your suggestions! I’ll keep them in mind. Maybe at some point I’ll find the time and inclination to dive back into this game.
Nah, that’s not what I meant by segments at all. Still static movement patterns, just more of them—say, 15 or so. Then, for each level, there’s a mapping of wave/formation to one of those 15 movement patterns.
Level 1: Formation 1 arrives in movement pattern A, Formation 2 in movement pattern B, …
Level 2: Formation 1 arrives in movement pattern G, Formation 2 in movement pattern A, …
Level 3: Formation 1 arrives in movement pattern B, Formation 2 in movement pattern K, …
etc.
That should already be enough to make chasing the high score more exciting, since you’d take up different positions depending on the level to catch as many as possible while they’re flying in, all while taking less risk.
There will be more flight paths (movement patterns) for objects (I don’t always want to write “enemy”):
To create the flight paths, I wrote a flight path editor in Python.
Horrible to use, but it works… You can see in the image that the flight paths consist of defined points. Each of these points describes its relative position to the previous one on the playing field, as well as the sprite or movement phase of the “object” following the path. I’ve defined many such movements and made sure they can be joined together “harmoniously”. Exception: When the object approaches its target position, since I’m continuing to use the existing “pathfinding routine” for this. Depending on how many flight path segments I create (about 10–15?) and stitch together in the game (1–3), some interesting formations might emerge. Number of conceivable flight patterns (with 10 segments): 10 + 10x10 + 10x10x10 = 1,110. To make things easier for players getting started, these won’t be activated until level 9.
Final boss is coming!
The game was never designed to move large objects. So I’ll assemble the final boss from small sprites…
(that’s what they’ll be… Put together from individual adjacent sprites. However, I probably won’t be able to pull off an animation)
Whatever processing time is left over, I’ll use to have a few familiar objects fly around for defense. Whenever they’re all shot down, a new set appears.
Tractor beam
It’s coming. But for technical reasons, very rarely! (Technical reasons behind this… maybe more on that later.) Let yourself get captured once. It’s worth it . But then finish the level without losing a life!!!
Music and sound effects
A few more will be added, but no additional music.
This is just a quick snapshot to show that I’m working on it.
The Python program (on my development environment) used to decompose the flight paths of the objects and generate their coordinates as bytecode.
The tunes between levels were provided using ChatGPT as tone sequences.
The sprite editor I used to draw and rotate the sprites. This is a Python program that also runs on my workstation.
I think you can tell from the “game play” that the game was lovingly crafted by hand.
If you feel it belongs under AI, feel free to make that change. I have no strong feelings about it — in a good way. I’m really just writing the software for myself, just for fun.
Definitely, being in this category doesn’t mean the game is completely vibe-coded (actually I must change the category title), just that AI was used in it.
)
. But then finish the level without losing a life!!!